Selecting on non-existing object-properties, leads to an error instead of returning null

CrateDB version:
4.5.3 / 4.6
Environment description:
cloud / local

Problem description:
Selecting on non-existing object-properties, leads to an error instead of returning null. This is not quite consistent with selecting on object-properties in a table, which in case an object doesn't contain a property, returns null instead.
The idea would be to use it to directly ingest JSONs into a table and make use of parameterised queries / prepared statements.

Steps to reproduce:

SELECT ''::OBJECT['x'];
--> Error! SQLParseException[The object `{}` does not contain the key `x`]
SELECT '{"x":1}'::OBJECT['y'];
--> Error! SQLParseException[The object `{x=1}` does not contain the key `y`]

SELECT col1['x'], col1['y'], col1['z']
FROM UNNEST(['{"x":1,"y":2}','{"y":2,"z":3}']::ARRAY(OBJECT));
--> Error! ColumnUnknownException[Column col1['x'] unknown]

not a problem:
SELECT col1['y']
FROM UNNEST(['{"x":1,"y":2}','{"y":2,"z":3}']::ARRAY(OBJECT));
--> SELECT OK, 2 records returned (0.001 seconds)

with tables it typically isn't a problem if properties don't exist within objects:
CREATE TABLE obj (obj OBJECT(DYNAMIC));
INSERT INTO obj (obj) VALUES ('{"x":1,"y":2}'),'{"y":2,"z":3}');
SELECT obj['x'], obj['y'], obj['z'] FROM obj;
--> SELECT OK, 2 records returned (0.001 seconds)

relates to https://github.com/crate/crate/issues/6553

This is somewhat related to https://github.com/crate/crate/issues/6553 and https://github.com/crate/crate/issues/9383
We could consider extending how we create the type information for unnest, so that the object will contain columns based on all rows.


Fix curl request in rest code samples

Why:
I copied to code sample literally to my GitHub actions workflow and spent a couple of hours to find out why my curl request didn't work... I'd like to prevent this for the next developer.
Closes: https://github.com/github/docs/issues/26396

What's being changed (if available, include any code snippets, screenshots, or gifs):
See linked issue.

Check off the following:

[ ] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

👋 Closing this per https://github.com/github/docs/issues/26396#issuecomment-1618442478


How do I fix problem of can NOT found ZLIB

I'm trying to complie a prj by cmake+vcpkg+vs2019 ,host: win10
I have installed vs 2019(LANG:ENG) , vcpkg install zlib openssl ...
added CMAKE_TOOLCHAIN_FILE to cmakelist.txt
but when compile got an error of can not found zlib. As Follow:
I don't know why cmake can not find the lib and header file.
How to fix that ?  thanks.
E:\Prj\rat_lite-master>..\cmake-3.18.2-win64-x64\bin\cmake.exe .
CMake Error at E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
  E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindZLIB.cmake:115 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:35 (find_package)

-- Configuring incomplete, errors occurred!
See also "E:/Prj/rat_lite-master/CMakeFiles/CMakeOutput.log".

E:\Prj\rat_lite-master>..\cmake-3.18.2-win64-x64\bin\cmake.exe .
CMake Error at E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
  E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindZLIB.cmake:115 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:35 (find_package)

-- Configuring incomplete, errors occurred!
See also "E:/Prj/rat_lite-master/CMakeFiles/CMakeOutput.log".

vcpkg:
E:\Prj\vcpkg>vcpkg install zlib
Computing installation plan...
The following packages are already installed:
    zlib[core]:x86-windows
Package zlib:x86-windows is already installed

Total elapsed time: 2.626 ms

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

E:\Prj\vcpkg>vcpkg install zlib[core]:x64-windows
Computing installation plan...
The following packages are already installed:
    zlib[core]:x64-windows
Package zlib:x64-windows is already installed

Total elapsed time: 1.619 ms

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

top of cmakefile.txt
cmake_minimum_required(VERSION 3.8)
SET(CMAKE_TOOLCHAIN_FILE "../vcpkg/scripts/buildsystems/vcpkg.cmake")
project(rat_lite)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(BUILD_EXAMPLE ON)
option(BUILD_SHARED_LIBS "Build shared library" OFF)
set (CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/modules")

include(CMakeLists-ExternalProjects.txt)

the libs are installed under the packages direcotry:

@mok-cn Please update vcpkg, remove zlib and rebuild it.
Thanks.

Thanks for reply , I've updated vcpkg ,but the problem seems not resoled.
The process and output:

**E:\Prj\vcpkg>git pull**
remote: Enumerating objects: 97, done.
remote: Counting objects: 100% (97/97), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 140 (delta 79), reused 70 (delta 68), pack-reused 43 eceiving objects:  92% (129/140)
Receiving objects: 100% (140/140), 82.60 KiB | 233.00 KiB/s, done.
Resolving deltas: 100% (79/79), completed with 51 local objects.
From https://github.com/microsoft/vcpkg
   32eccc181..1095c177a  master     -> origin/master
Updating 32eccc181..1095c177a
Fast-forward
 ports/fastrtps/CONTROL                             |   5 +-
 ports/fastrtps/fix-install.patch                   |  14 --
 ports/fastrtps/namespace_tinyxml2.patch            |  17 ---
 ports/fastrtps/portfile.cmake                      |  17 +--
 ports/ffnvcodec/CONTROL                            |   3 +-
 ports/graphite2/CONTROL                            |   2 +-
 ports/graphite2/disable-tests.patch                |  15 +-
 ports/graphite2/portfile.cmake                     |  11 +-
 ports/inja/CONTROL                                 |   5 +-
 ports/inja/cmake-version.patch                     |  13 --
 ports/inja/portfile.cmake                          |   9 +-
 ports/jsoncons/CONTROL                             |   2 +-
 ports/jsoncons/portfile.cmake                      |   4 +-
 ports/jsonnet/001-enable-msvc.patch                | 161 +++++++++++----------
 ports/jsonnet/002-fix-dependency-and-install.patch | 119 ++++++++-------
 ports/jsonnet/CONTROL                              |   2 +-
 ports/jsonnet/portfile.cmake                       |   4 +-
 ports/kd-soap/CONTROL                              |   4 +-
 ports/kd-soap/kd-soap.patch                        |  12 --
 ports/kd-soap/portfile.cmake                       |  18 ++-
 ports/liblinear/CMakeLists.txt                     |   4 +-
 ports/liblinear/CONTROL                            |   4 +-
 ports/liblinear/portfile.cmake                     |  15 +-
 ports/libmaxminddb/CONTROL                         |   3 +-
 ports/libmaxminddb/fix-linux-build.patch           |   6 +-
 ports/libmaxminddb/portfile.cmake                  |   8 +-
 ports/libqrencode/CONTROL                          |   2 +-
 ports/libqrencode/fix-found-wingetopt.patch        |  13 --
 ports/libqrencode/portfile.cmake                   |  15 +-
 ports/librsync/001-enable-static-libs.patch        |  13 --
 ports/librsync/CONTROL                             |   4 +-
 ports/librsync/portfile.cmake                      |  19 ++-
 ports/libsndfile/0001-Improve-UWP-support.patch    |  37 -----
 ports/libsndfile/portfile.cmake                    |   9 +-
 ports/libsndfile/vcpkg.json                        |   3 +-
 ports/mimalloc/CONTROL                             |   3 +-
 ports/mimalloc/fix-cmake.patch                     |  81 +++++------
 ports/mimalloc/portfile.cmake                      |   9 +-
 ports/nanodbc/CONTROL                              |   3 +-
 ports/nanodbc/portfile.cmake                       |   9 +-
 ports/polyclipping/CONTROL                         |   2 +-
 ports/polyclipping/fix_targets.patch               |   3 +-
 ports/scintilla/0001-static-lib.patch              |  14 ++
 ports/scintilla/0002-static-crt.patch              |  37 +++++
 ports/scintilla/CONTROL                            |   1 +
 ports/scintilla/portfile.cmake                     |  12 +-
 ports/sentry-native/CONTROL                        |   2 +-
 ports/sentry-native/portfile.cmake                 |  14 +-
 ports/skyr-url/CONTROL                             |   2 +-
 ports/skyr-url/portfile.cmake                      |   4 +-
 ports/unqlite/portfile.cmake                       |  20 +++
 ports/unqlite/vcpkg.json                           |   7 +
 ports/xbyak/CONTROL                                |   5 -
 ports/xbyak/portfile.cmake                         |   4 +-
 ports/xbyak/vcpkg.json                             |   7 +
 scripts/azure-pipelines/linux/azure-pipelines.yml  |   4 +-
 scripts/azure-pipelines/osx/azure-pipelines.yml    |   4 +-
 scripts/azure-pipelines/signing.yml                | 109 ++++++++++++++
 scripts/azure-pipelines/test-modified-ports.ps1    |   8 +-
 .../azure-pipelines/windows/azure-pipelines.yml    |   4 +-
 scripts/azure-pipelines/windows/packages.config    |   4 +
 scripts/azure-pipelines/windows/signing.signproj   |  36 +++++
 scripts/buildsystems/msbuild/vcpkg.targets         |   2 +-
 scripts/ci.baseline.txt                            |   8 -
 toolsrc/CMakeLists.txt                             |  11 ++
 toolsrc/src/vcpkg/binarycaching.cpp                |   2 +-
 66 files changed, 558 insertions(+), 465 deletions(-)
 delete mode 100644 ports/fastrtps/fix-install.patch
 delete mode 100644 ports/fastrtps/namespace_tinyxml2.patch
 delete mode 100644 ports/inja/cmake-version.patch
 delete mode 100644 ports/kd-soap/kd-soap.patch
 delete mode 100644 ports/libqrencode/fix-found-wingetopt.patch
 delete mode 100644 ports/librsync/001-enable-static-libs.patch
 delete mode 100644 ports/libsndfile/0001-Improve-UWP-support.patch
 create mode 100644 ports/scintilla/0001-static-lib.patch
 create mode 100644 ports/scintilla/0002-static-crt.patch
 create mode 100644 ports/unqlite/portfile.cmake
 create mode 100644 ports/unqlite/vcpkg.json
 delete mode 100644 ports/xbyak/CONTROL
 create mode 100644 ports/xbyak/vcpkg.json
 create mode 100644 scripts/azure-pipelines/signing.yml
 create mode 100644 scripts/azure-pipelines/windows/packages.config
 create mode 100644 scripts/azure-pipelines/windows/signing.signproj

**E:\Prj\vcpkg>.\bootstrap-vcpkg.bat**

Building vcpkg.exe ...

  pch.cpp
  archives.cpp
  checks.cpp
  chrono.cpp
  cofffilereader.cpp
  downloads.cpp
  enums.cpp
  files.cpp
  hash.cpp
  json.cpp
  machinetype.cpp
  parse.cpp
  strings.cpp
  stringview.cpp
  system.cpp
  system.print.cpp
  system.process.cpp
  unicode.cpp
  binarycaching.cpp
  binaryparagraph.cpp
  build.cpp
  buildenvironment.cpp
  cmakevars.cpp
  commands.autocomplete.cpp
  commands.buildexternal.cpp
  commands.cache.cpp
  commands.ci.cpp
  commands.ciclean.cpp
  commands.contact.cpp
  commands.cpp
  commands.create.cpp
  commands.dependinfo.cpp
  commands.edit.cpp
  commands.env.cpp
  commands.fetch.cpp
  commands.format-manifest.cpp
  commands.hash.cpp
  commands.info.cpp
  commands.integrate.cpp
  commands.list.cpp
  commands.owns.cpp
  commands.porthistory.cpp
  commands.portsdiff.cpp
  commands.search.cpp
  commands.setinstalled.cpp
  commands.upgrade.cpp
  commands.upload-metrics.cpp
  commands.version.cpp
  commands.xvsinstances.cpp
  configuration.cpp
  dependencies.cpp
  export.cpp
  export.chocolatey.cpp
  export.ifw.cpp
  export.prefab.cpp
E:\Prj\vcpkg\toolsrc\src\vcpkg\export.prefab.cpp(1,1): warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失 [E:\Prj\vcpkg\toolsrc\windows-bootstrap\vcpkg
.vcxproj]
  globalstate.cpp
  help.cpp
  input.cpp
  install.cpp
  platform-expression.cpp
  metrics.cpp
  packagespec.cpp
  paragraphs.cpp
  portfileprovider.cpp
  postbuildlint.buildtype.cpp
  postbuildlint.cpp
  registries.cpp
  remove.cpp
  sourceparagraph.cpp
  statusparagraph.cpp
  statusparagraphs.cpp
  tools.cpp
  triplet.cpp
  update.cpp
  userconfig.cpp
  vcpkgcmdarguments.cpp
  vcpkglib.cpp
  vcpkgpaths.cpp
  versiont.cpp
  visualstudio.cpp
  vcpkg.cpp
  正在生成代码
  Previous IPDB not found, fall back to full compilation.
  All 19744 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
  已完成代码的生成
  vcpkg.vcxproj -> E:\Prj\vcpkg\toolsrc\windows-bootstrap\msbuild.x86.release\vcpkg.exe

Building vcpkg.exe... done.

Telemetry
---------
vcpkg collects usage data in order to help us improve your experience.
The data collected by Microsoft is anonymous.
You can opt-out of telemetry by re-running the bootstrap-vcpkg script with -disableMetrics,
passing --disable-metrics to vcpkg on the command line,
or by setting the VCPKG_DISABLE_METRICS environment variable.

Read more about vcpkg telemetry at docs/about/privacy.md

**E:\Prj\vcpkg>vcpkg.exe remove zlib openssl turbo-jpeg**
The following packages are not installed, so not removed:
    turbo-jpeg:x86-windows
The following packages will be removed:
    openssl:x86-windows
    zlib:x86-windows
Removing package zlib:x86-windows...
Removing package zlib:x86-windows... done
Removing package openssl:x86-windows...
Removing package openssl:x86-windows... done
Package turbo-jpeg:x86-windows is not installed

E:\Prj\vcpkg>vcpkg.exe remove zlib openssl libjpeg-turbo
The following packages are not installed, so not removed:
    openssl:x86-windows
    zlib:x86-windows
The following packages will be removed:
    libjpeg-turbo:x86-windows
Another installed package matches the name of an unmatched request. Did you mean zlib:x64-windows?
Another installed package matches the name of an unmatched request. Did you mean openssl:x64-windows?
Package zlib:x86-windows is not installed
Package openssl:x86-windows is not installed
Removing package libjpeg-turbo:x86-windows...
Removing package libjpeg-turbo:x86-windows... done

**E:\Prj\vcpkg>vcpkg.exe install zlib openssl libjpeg-turbo**
Computing installation plan...
The following packages will be built and installed:
    libjpeg-turbo[core]:x86-windows
    openssl[core]:x86-windows
    zlib[core]:x86-windows
Detecting compiler hash for triplet x86-windows...
Starting package 1/3: libjpeg-turbo:x86-windows
Building package libjpeg-turbo[core]:x86-windows...
Using cached binary package: C:\Users\liu\AppData\Local\vcpkg\archives\ae\aebb7fe6293007535c9ff9040f93d724065463c2.zip
Building package libjpeg-turbo[core]:x86-windows... done
Installing package libjpeg-turbo[core]:x86-windows...
Installing package libjpeg-turbo[core]:x86-windows... done
Elapsed time for package libjpeg-turbo:x86-windows: 1.329 s
Starting package 2/3: openssl:x86-windows
Building package openssl[core]:x86-windows...
Using cached binary package: C:\Users\liu\AppData\Local\vcpkg\archives\2a\2aaed53c71572f01b436eb84dd6e55be70ae4db5.zip
Building package openssl[core]:x86-windows... done
Installing package openssl[core]:x86-windows...
Installing package openssl[core]:x86-windows... done
Elapsed time for package openssl:x86-windows: 245.7 ms
Starting package 3/3: zlib:x86-windows
Building package zlib[core]:x86-windows...
Using cached binary package: C:\Users\liu\AppData\Local\vcpkg\archives\f7\f791b199b58c0187873a393f22aec2bbad1c7a0a.zip
Building package zlib[core]:x86-windows... done
Installing package zlib[core]:x86-windows...
Installing package zlib[core]:x86-windows... done
Elapsed time for package zlib:x86-windows: 586.7 ms

Total elapsed time: 11.23 s

The package libjpeg-turbo is compatible with built-in CMake targets:

    find_package(JPEG REQUIRED)
    target_link_libraries(main PRIVATE ${JPEG_LIBRARIES})
    target_include_directories(main PRIVATE ${JPEG_INCLUDE_DIR})

The package openssl is compatible with built-in CMake targets:

    find_package(OpenSSL REQUIRED)
    target_link_libraries(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

**E:\Prj\vcpkg>vcpkg.exe install zlib openssl libjpeg-turbo  --triplet x64-windows**
Computing installation plan...
The following packages are already installed:
    libjpeg-turbo[core]:x64-windows
    openssl[core]:x64-windows
    zlib[core]:x64-windows
Package libjpeg-turbo:x64-windows is already installed
Package openssl:x64-windows is already installed
Package zlib:x64-windows is already installed

Total elapsed time: 7.335 ms

The package libjpeg-turbo is compatible with built-in CMake targets:

    find_package(JPEG REQUIRED)
    target_link_libraries(main PRIVATE ${JPEG_LIBRARIES})
    target_include_directories(main PRIVATE ${JPEG_INCLUDE_DIR})

The package openssl is compatible with built-in CMake targets:

    find_package(OpenSSL REQUIRED)
    target_link_libraries(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

**E:\Prj\vcpkg>vcpkg.exe remove zlib openssl libjpeg-turbo  --triplet x64-windows**
The following packages will be removed:
    libjpeg-turbo:x64-windows
    openssl:x64-windows
    zlib:x64-windows
Removing package zlib:x64-windows...
Removing package zlib:x64-windows... done
Removing package openssl:x64-windows...
Removing package openssl:x64-windows... done
Removing package libjpeg-turbo:x64-windows...
Removing package libjpeg-turbo:x64-windows... done

**E:\Prj\vcpkg>vcpkg.exe install zlib openssl libjpeg-turbo  --triplet x64-windows**
Computing installation plan...
The following packages will be built and installed:
    libjpeg-turbo[core]:x64-windows
    openssl[core]:x64-windows
    zlib[core]:x64-windows
Detecting compiler hash for triplet x64-windows...
Starting package 1/3: libjpeg-turbo:x64-windows
Building package libjpeg-turbo[core]:x64-windows...
Using cached binary package: C:\Users\liu\AppData\Local\vcpkg\archives\2c\2cf8d0a02212198937cd399c4c5653c0b6dd30c4.zip
Building package libjpeg-turbo[core]:x64-windows... done
Installing package libjpeg-turbo[core]:x64-windows...
Installing package libjpeg-turbo[core]:x64-windows... done
Elapsed time for package libjpeg-turbo:x64-windows: 1.056 s
Starting package 2/3: openssl:x64-windows
Building package openssl[core]:x64-windows...
Using cached binary package: C:\Users\liu\AppData\Local\vcpkg\archives\74\7447b1e16728a35cda5bcb1e40c10d1f82b598a5.zip
Building package openssl[core]:x64-windows... done
Installing package openssl[core]:x64-windows...
Installing package openssl[core]:x64-windows... done
Elapsed time for package openssl:x64-windows: 174.2 ms
Starting package 3/3: zlib:x64-windows
Building package zlib[core]:x64-windows...
Using cached binary package: C:\Users\liu\AppData\Local\vcpkg\archives\cb\cb1d45ce180deb11e94c328a8a390829488eadfd.zip
Building package zlib[core]:x64-windows... done
Installing package zlib[core]:x64-windows...
Installing package zlib[core]:x64-windows... done
Elapsed time for package zlib:x64-windows: 671.9 ms

Total elapsed time: 8.521 s

The package libjpeg-turbo is compatible with built-in CMake targets:

    find_package(JPEG REQUIRED)
    target_link_libraries(main PRIVATE ${JPEG_LIBRARIES})
    target_include_directories(main PRIVATE ${JPEG_INCLUDE_DIR})

The package openssl is compatible with built-in CMake targets:

    find_package(OpenSSL REQUIRED)
    target_link_libraries(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

**E:\Prj\rat_lite-master>..\cmake-3.18.2-win64-x64\bin\cmake.exe .**
CMake Error at E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  **Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)**
Call Stack (most recent call first):
  E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  E:/Prj/cmake-3.18.2-win64-x64/share/cmake-3.18/Modules/FindZLIB.cmake:115 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:39 (find_package)

-- Configuring incomplete, errors occurred!
See also "E:/Prj/rat_lite-master/CMakeFiles/CMakeOutput.log".

**E:\Prj\rat_lite-master>**

The CMakefile .txt:
Line39: find_package(ZLIB REQUIRED)
cmake_minimum_required(VERSION 3.8)
#set(VCPKG_ROOT "${CMAKE_SOURCE_DIR}/../vcpkg/scripts/buildsystems/vcpkg.cmake" CACHE PATH "")
SET(CMAKE_TOOLCHAIN_FILE "e:/prj/vcpkg/scripts/buildsystems/vcpkg.cmake")

project(rat_lite)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(BUILD_EXAMPLE ON)
option(BUILD_SHARED_LIBS "Build shared library" OFF)
set (CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/modules")

include(CMakeLists-ExternalProjects.txt)

if(WIN32)
	set(REMOTE_ACCESS_PLATFORM_INC
        include/windows
    )
	add_definitions(-D_CRT_SECURE_NO_WARNINGS -DNOMINMAX)
elseif(APPLE)
    set(REMOTE_ACCESS_PLATFORM_INC
        include/ios
    )
else()
	set(REMOTE_ACCESS_PLATFORM_INC
		include/linux
    )
endif()

if(MSVC)
	set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
else()
	set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic")
endif()

find_package(ZLIB REQUIRED)
target_link_libraries(main PRIVATE ZLIB::ZLIB)
find_package(OpenSSL REQUIRED)
find_package(LIBJPEGTURBO REQUIRED)

set(COMMON_INCLUDE_DIRS
	include
	${CMAKE_BINARY_DIR}/bin/include
	${OPENSSL_INCLUDE_DIR}
	${ZLIB_INCLUDE_DIRS}
	${LIBJPEGTURBO_INCLUDE_DIRS}
)
include_directories(
	${COMMON_INCLUDE_DIRS}
)

add_library(${PROJECT_NAME}
	include/RAT.h
	src/ClientDriver.cpp
	src/ServerDriver.cpp
)
add_dependencies(${PROJECT_NAME} websocket_lite input_lite clipboard_lite screen_capture_lite)
if(WIN32)
	target_link_libraries(${PROJECT_NAME} Crypt32 Dwmapi)
elseif(APPLE)
	find_library(corefoundation_lib CoreFoundation)
	find_library(cocoa_lib Cocoa)
	find_package(Threads REQUIRED)
	target_link_libraries(${PROJECT_NAME} ${CMAKE_THREAD_LIBS_INIT} ${corefoundation_lib} ${cocoa_lib})
else()
	find_package(X11 REQUIRED)
	find_package(Threads REQUIRED)
	target_link_libraries(${PROJECT_NAME} ${CMAKE_THREAD_LIBS_INIT} dl ${X11_LIBRARIES} ${X11_Xfixes_LIB} ${X11_XTest_LIB} ${X11_Xinerama_LIB})
endif()

if(${BUILD_SHARED_LIBS})
	set_target_properties(${PROJECT_NAME} PROPERTIES DEFINE_SYMBOL RAT_LITE_DLL)
endif()
if(WIN32)
	set(LIBEXTENSION .lib)
else()
	if(${BUILD_SHARED_LIBS})
		set(LIBEXTENSION ${CMAKE_SHARED_LIBRARY_SUFFIX})
	else()
		set(LIBEXTENSION ${CMAKE_STATIC_LIBRARY_SUFFIX})
	endif()
endif()
if(${BUILD_SHARED_LIBS})
	target_link_libraries(${PROJECT_NAME}
	${CMAKE_BINARY_DIR}/bin/lib/${CMAKE_SHARED_LIBRARY_PREFIX}websocket_lite${LIBEXTENSION}
	${CMAKE_BINARY_DIR}/bin/lib/${CMAKE_SHARED_LIBRARY_PREFIX}input_lite${LIBEXTENSION}
	${CMAKE_BINARY_DIR}/bin/lib/${CMAKE_SHARED_LIBRARY_PREFIX}clipboard_lite${LIBEXTENSION}
	${CMAKE_BINARY_DIR}/bin/lib/${CMAKE_SHARED_LIBRARY_PREFIX}screen_capture_lite${LIBEXTENSION}
	${OPENSSL_LIBRARIES}
	${ZLIB_LIBRARIES}
	${LIBJPEGTURBO_LIBRARIES}
	)
endif()

install (TARGETS ${PROJECT_NAME}
	RUNTIME DESTINATION bin
	ARCHIVE DESTINATION lib
	LIBRARY DESTINATION lib
)

install (FILES
	include/RAT.h
	include/Logging.h
	DESTINATION include
)

if(BUILD_EXAMPLE)
	add_subdirectory(src/server)
	add_subdirectory(src/client)
endif()

enable_testing()
add_subdirectory(test)

看起来cmake 3.18.2版本修改了findzlib.cmake，导致了你查找不到zlib。
请使用3.17版本再次重试。
我们正在PR #12612中将cmake更新至3.18.2，届时会修复该问题。
谢谢。

换了3.17
现在提示40行错误，target_link_libraries(main PRIVATE ZLIB::ZLIB)
-- Found ZLIB: optimized;E:/Prj/vcpkg/installed/x64-windows/lib/zlib.lib;debug;E:/Prj/vcpkg/installed/x64-windows/debug/lib/zlibd.lib (found version "1.2.11")
CMake Error at CMakeLists.txt:40 (target_link_libraries):
Cannot specify link libraries for target "main" which is not built by this project.
这个和vcpkg有关系么？

main的意思是你的TARGET_NAME，换成你add_library或者add_executable中第一个参数就好了。

@mok-cn
Is this still a problem for you now?

编译问题后来解决了但是运行起来不能连接，看不到远程桌面。你的客户端是用一种脚本写的我不太明白，如果有时间可以帮我看下哈发自我的iPhone------------------ Original ------------------From: NancyLi1013<EMAIL_ADDRESS>Fri,Nov 6,2020 4:23 PMTo: microsoft/vcpkg<EMAIL_ADDRESS>mok-cn<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Re: [microsoft/vcpkg] How do I fix problem of can NOT found ZLIB(#13614)
@mok-cn
Is this still a problem for you now?
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/microsoft/vcpkg/issues/13614#issuecomment-722945845",
"url": "https://github.com/microsoft/vcpkg/issues/13614#issuecomment-722945845",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

@mok-cn 应该是dll没复制到你library或executable目录下，复制一下就好了。

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.

Hi,
I'm having the same problem when including poco as a depedency to my project. My CMakeLists.txt file has the following:
set(ZLIB_INCLUDE_DIR ${VCPKG_ROOT}/installed/${TRIPLET}/include)
if (MSVC)
  set(ZLIB_LIBRARY ${VCPKG_ROOT}/installed/${TRIPLET}/lib/zlib.lib)
else()
  set(ZLIB_LIBRARY ${VCPKG_ROOT}/installed/${TRIPLET}/lib/libz.a)
endif()

find_package(ZLIB REQUIRED)
find_package(OpenSSL REQUIRED)
find_package(Poco CONFIG REQUIRED COMPONENTS Foundation JSON Net Util)

When running cmake on Linux it generates without issue. However, on Windows I get the following output errors.
Total elapsed time: 41.9 us

The package openssl is compatible with built-in CMake targets:

    find_package(OpenSSL REQUIRED)
    target_link_libraries(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)

The package poco:x86-windows-static provides CMake targets:

    find_package(Poco CONFIG REQUIRED)
    # Note: 9 target(s) were omitted.
    target_link_libraries(main PRIVATE Poco::Net Poco::XML Poco::Zip Poco::Data)

The package spdlog:x86-windows-static provides CMake targets:

    find_package(spdlog CONFIG REQUIRED)
    target_link_libraries(main PRIVATE spdlog::spdlog spdlog::spdlog_header_only)

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

-- Found ZLIB: C:\Users\jpsaxr\vcpkg/installed/x86-windows-static/lib/zlib.lib (found version "1.2.11")
-- Found OpenSSL: C:/Users/jpsaxr/vcpkg/installed/x86-windows-static/lib/libcrypto.lib (found version "1.1.1i")
CMake Error at C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find ZLIB (missing: ZLIB_INCLUDE_DIR) (found version "1.2.11")
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-3.18/Modules/FindZLIB.cmake:115 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  C:/Program Files/CMake/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  C:/Users/jpsaxr/vcpkg/installed/x86-windows-static/share/poco/PocoConfig.cmake:12 (find_dependency)
  CMakeLists.txt:114 (find_package)

-- Configuring incomplete, errors occurred!
See also "C:/Users/jpsaxr/gitlab/sdk_cpp/CMakeFiles/CMakeOutput.log".
See also "C:/Users/jpsaxr/gitlab/sdk_cpp/CMakeFiles/CMakeError.log".

@acceleratxr You should also add -DVCPKG_TARGET_TRIPLET=x86-windows-static to cmake.

To anyone having the problem try using zlib:x64-windows

Having the same problem here with a fresh vcpkg installation using x64-windows.
git clone git://github.com/microsoft/vcpkg
cd vcpkg
bootstrap-vcpkg.bat
vcpkg integrate install
vcpkg install zlib:x64-windows

Set -DCMAKE_TOOLCHAIN_FILE=C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake as listed in the tool but still had the same errors as provided above.
proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_DEFAULT_TRIPLET:STRING=x64-windows -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -Hd:/work -Bd:/work/build -G "Visual Studio 16 2019" -T host=x64 -A x64
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is MSVC 19.29.30038.1
[cmake] -- The CXX compiler identification is MSVC 19.29.30038.1
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - done
[cmake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
[cmake] -- Detecting C compile features
[cmake] -- Detecting C compile features - done
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake]
...snip...
[cmake]
[cmake] CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
[cmake]   Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
[cmake] Call Stack (most recent call first):
[cmake]   C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
[cmake]   C:/Program Files/CMake/share/cmake-3.21/Modules/FindZLIB.cmake:120 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
[cmake]   C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package)
[cmake]   CMakeLists.txt:261 (find_package)

@lslegal The reported Call Stack doesn't list share/zlib/vcpkg-cmake-wrapper.cmake. This is strange. Does the file exist?

@lslegal The reported Call Stack doesn't list share/zlib/vcpkg-cmake-wrapper.cmake. This is strange. Does the file exist?

It does.

According to the stack:
[cmake]   C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
[cmake]   C:/Program Files/CMake/share/cmake-3.21/Modules/FindZLIB.cmake:120 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
[cmake]   C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package)
[cmake]   CMakeLists.txt:261 (find_package)

I strongly suspect that the triplet you installed zlib does not match the current architecture. Please pass -DVCPKG_TARGET_TRIPLET=YOUR_SELECTED_TRIPLET to cmake command.

I am not sure why we keep having the same questions about reproduce it.
The steps I posted can reproduce it, always. Always as it happens randomly,
once it happened, that is it, it never works again.
I relatively strongly suggest some catching issues on the vcpkg or the
cmake vcpkg tool chain.
Redoing the setup, using the exact same steps, works again. Always. Same
architecture, same environment, etc.
On Thu, Sep 9, 2021, 9:31 AM Jack·Boos·Yu @.***> wrote:

According to the stack:
[cmake]   C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
[cmake]   C:/Program Files/CMake/share/cmake-3.21/Modules/FindZLIB.cmake:120 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
[cmake]   C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package)
[cmake]   CMakeLists.txt:261 (find_package)
I strongly suspect that the triplet you installed zlib does not match the
current architecture. Please pass
-DVCPKG_TARGET_TRIPLET=YOUR_SELECTED_TRIPLET to cmake command.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vcpkg/issues/13614#issuecomment-915711035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACE6KBBZXXARFZV5NG4BDLUBAL6VANCNFSM4RSYRQIQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

If you don't pass VCPKG_TARGET_TRIPLET. vcpkg will check your cmake options such as CMAKE_GENERATOR_PLATFORM and set the related triplet. See
https://github.com/microsoft/vcpkg/blob/7e044226c8a6f43dac7d9e0efd8edbf8ff5ecd04/scripts/buildsystems/vcpkg.cmake#L248-L337
I think the issue is caused by cmake cache.

@mok-cn The Call Stacks in your posts indicate that you don't use the vcpkg cmake toolchain. (I didn't spot _find_package in .../vcpkg.cmake.
@lsegal Is there a vcpkg.json in your CMake project? This would activate manifest mode which uses a different vcpkg install root than the one changed by vcpkg install zlib:x64-windows.

No vcpkg.json for me.
Where is VCPKG_TARGET_TRIPLET documented? I don't see any mention of needing to use this in a project. Presumably vcpkg should be picking from available triplets on the system.
FWIW zlib was installed as x64-windows, i.e., nothing fancy. Also, VCPKG_DEFAULT_TRIPLET is also set as a system-wide environment variable.

Trying to sort the various posts:

No _find_package (from vcpkg.cmake) in the find_package Call Stack: Not using the current vcpkg toolchain.

@mok-cn 2020 https://github.com/microsoft/vcpkg/issues/13614#issue-704792880
@acceleratxr https://github.com/microsoft/vcpkg/issues/13614#issuecomment-788370478
@pierrejoye https://github.com/microsoft/vcpkg/issues/13614#issuecomment-906587823

No share/zlib/vcpkg_cmake_wrapper.cmake installed: Not using the current zlib port.
vcpkg.cmake used, Wrapper installed, but no share/zlib/vcpkg_cmake_wrapper.cmake in the find_package Call Stack: Something strange is going on. Vcpkg not using the right install root?

@lsegal https://github.com/microsoft/vcpkg/issues/13614#issuecomment-914557843

For a clean start, it is probably also necessary to clean the CMake build directory of the user project.
Correct me if I'm wrong...

vcpkg.cmake used, Wrapper installed, but no share/zlib/vcpkg_cmake_wrapper.cmake in the find_package Call Stack: Something strange is going on. Vcpkg not using the right install root?

The CMAKE_TOOLCHAIN_FILE is provided in the command in my stack trace, that should be sufficient to set the install root, right?

For a clean start, it is probably also necessary to clean the CMake build directory of the user project.

The build directory was removed prior to running the above commands. Is there other cache?

No vcpkg.json for me.
Where is VCPKG_TARGET_TRIPLET documented? I don't see any mention of needing to use this in a project. Presumably vcpkg should be picking from available triplets on the system.
FWIW zlib was installed as x64-windows, i.e., nothing fancy. Also, VCPKG_DEFAULT_TRIPLET is also set as a system-wide environment variable.

VCPKG_DEFAULT_TRIPLET should be the triplet which you selected to build the ports.

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.

Similar issue here:

Using vcpkg.json
Using x64-windows-static
Using vcpkg.cmake as toolchain file
Using my chainloaded toolchain file containing some add_compile_options(), add_compile_definitions() and add_link_options()

I can see vcpkg built zlibd.lib but cmake --debug-find shows that .lib files are not searched at all:
.../vcpkg_installed/x64-windows-static/debug/lib/()zlibd(\.a|\.dll\.a)

.../vcpkg_installed/x64-windows-static/debug/lib/()zlibd(\.a|\.dll\.a)

@alef These are mingw suffixes, and they are not used in sane x64-windows-static build. You should open a new issue if it happens in fresh cmake build directory.

看起来cmake 3.18.2版本修改了findzlib.cmake，导致了你查找不到zlib。 请使用3.17版本再次重试。 我们正在PR #12612 中将cmake更新至3.18.2，届时会修复该问题。
谢谢。

按照你这么说的话,是不是cmake必须使用软件自己下载在download文件夹中的那个cmake?
因为vs2022运行vcvarsall.bat后运行的是自带的 cmake,
我已经通过经典模式安装x86,x64版本的zlib
然后用cmake脚本编译一个很简单的使用zlib的helloworld程序得到一以下错误提示
CMake Error at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.23/Modules/FindZLIB.cmake:120 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:8 (find_package)

按照你这么说的话,是不是cmake必须使用软件自己下载在download文件夹中的那个cmake? 因为vs2022运行vcvarsall.bat后运行的是自带的 cmake,
我已经通过经典模式安装x86,x64版本的zlib 然后用cmake脚本编译一个很简单的使用zlib的helloworld程序得到一以下错误提示
CMake Error at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) Call Stack (most recent call first): C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.23/Modules/FindZLIB.cmake:120 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:8 (find_package)

vcpkg有自己的cmake最低版本要求，如果不满足版本要求则会下载符合要求的cmake包，在cmake 3.18.2及以后均已修复此问题。所以如果你确保了你的vcpkg是最新的，则不应当出现这个问题。

I cannot read this language, but the Call Stack: If there is no vcpkg-cmake-wrapper.cmake for ZLIB, then you are not using the vcpkg CMake toolchain.

I  use lastest version vcpkg  in 2023.2.21.  but  also meet  cannot found  zlib ,but  I  has   installed zlib  with vcpkg  ,why these bug  is always  exist ?

I  found  one solution  , https://blog.csdn.net/eloudy/article/details/127626591
cmake .. -DZLIB_INCLUDE_DIR=C:\ProgramData\Anaconda3\pkgs\zlib-1.2.12-h8cc25b3_3\Library\lib -DZLIB_LIBRARY=C:\ProgramData\Anaconda3\pkgs\zlib-1.2.12-h8cc25b3_3\Library\lib


Banner Update

I have formatted the header text and para of the banner to make it easy to read/

Hi @zealshah29
Can I see a screenshot of the changes you made?
Thanks

Hi so I accidentally forked this repo: https://github.com/AbdessamadTzn/simple-contribution
And made changes over there, and then created a pull request on that forked repository.

Here's the changes I made

Hi @zealshah29
It looks like you forked the old banner
This is what the banner looks like now

Yes, but I am unable to fork your repository since I already forked the other one. Is it possible for me to make changes on the updated code and create a pull request on your repository?


32-bit auto-builds

Users like @kccuber need 32 bit builds to run Catalyst, if you could add that to the automatic build system that'd be great.

@webdev03

i dont need a 32 bit build, its just for that 1 old laptop

@kccuber-scratch they are nice to have

@JaydenDev Please do 32-bit builds!!! Also, statically linked. While you're at it could you build statically linked 32-bit binaries for xorg, fluxbox, and anything else needed for a GUI on https://copy.sh/v86/?profile=buildroot ? I'd greatly appreciate that.

Does github actions have this?

@JaydenDev Please do 32-bit builds!!! Also, statically linked. While you're at it could you build statically linked 32-bit binaries for xorg, fluxbox, and anything else needed for a GUI on https://copy.sh/v86/?profile=buildroot ? I'd greatly appreciate that.

that's repository bloat.

I can't build myself, and github actions can't really do it.

@JaydenDev Please do 32-bit builds!!! Also, statically linked. While you're at it could you build statically linked 32-bit binaries for xorg, fluxbox, and anything else needed for a GUI on https://copy.sh/v86/?profile=buildroot ? I'd greatly appreciate that.

that's repository bloat.

Was just requesting that as something unrelated to Catalyst. I'm really wanting to run GUI programs on v86 without using dsl or Tiny Core.

Github actions.. probably doesn't have this..

You can build 32-bit binaries on a 64-bit system. You can also build 64-bit binaries on a 32-bit system.

@hello-smile6 v86 is not whats on topic here, this is Catalyst development. This repository and built binaries are for Catalyst ONLY.

How to do that in Electron Forge?

How to do that in Electron Forge?

idk exactly

How to do that in Electron Forge?

Just pass parameters to electron-forge make. Read the docs.

"read the docs" isn't a helpful statement @hello-smile6

@webdev03 Well we'll just have to leave 32 bit users behind on this, 32 bit is obselete anyway

"read the docs" isn't a helpful statement @hello-smile6

Okay, then I'll find the info. Also, you can hide comments instead of deleting them.

"read the docs" isn't a helpful statement @hello-smile6

Okay, then I'll find the info. Also, you can hide comments instead of deleting them.

Deleting > Hiding

I'll try to do this.. please wait!

@webdev03 is it really possible tho?

Here you go.
https://chr15m.github.io/bugout/examples/messageboard.html#bCxAvXzKk2ziQzd66zkCSUg69foyWPcCF5

Wait a minute, wrong link.

Here's the info.
https://www.electronforge.io/cli#make

Here's the info. https://www.electronforge.io/cli#make

a command would be more useful ...

Got it.

electron-forge make --arch x32

Just run that on a 64-bit GitHub Actions Linux runner.

electron-forge make --arch x32

Just run that on a 64-bit GitHub Actions Linux runner.

This must include Mac32, Win32, and Linux32

Here's the info. https://www.electronforge.io/cli#make

a command would be more useful ...

Stop deleting my comments when they're on-topic!

Here's the info. https://www.electronforge.io/cli#make

a command would be more useful ...

Stop deleting my comments when they're on-topic!

stop spamming useless comments then...

electron-forge make --arch x32

Just run that on a 64-bit GitHub Actions Linux runner.

This must include Mac32, Win32, and Linux32

https://www.electronforge.io/cli#:~:text=please note you normally can only target platform X from platform X.
Don't think that's possible. And there's no such thing as 32-bit MacOS, I think.

electron-forge make --arch x32

Just run that on a 64-bit GitHub Actions Linux runner.

This must include Mac32, Win32, and Linux32

https://www.electronforge.io/cli#:~:text=please note you normally can only target platform X from platform X. Don't think that's possible. And there's no such thing as 32-bit MacOS, I think.

You think MacOS didn't exist pre-64bit.  I am not sure if my latest commit works, can you check?

@webdev03 Hold on, I gotta get a fresh cloned copy of the repo.

32 bit macOS exists. I am not sure if my latest commit works, can you check?

Oh, it does? Should we do ARM64 builds for people like @Chiroyce?

No, I mean to say, I did in the github action.

I had to make a tag.

32 bit macOS exists. I am not sure if my latest commit works, can you check?

Oh, it does? Should we do ARM64 builds for people like @Chiroyce?

that would require extensive work

32 bit macOS exists. I am not sure if my latest commit works, can you check?

Oh, it does? Should we do ARM64 builds for people like @Chiroyce?

that would require extensive work

Wouldn't it just be this?
electron-forge make --arch arm64

Could we just use a MacOS runner?

ARM64 isn't for github actions.

ARM64 isn't for github actions.

I know, but you should be able to build ARM64 binaries on x64 MacOS, which works on GitHub Actions.

@hello-smile6 lets not give people less reasons to not use M1 macs

I don't think it worked...

It's giving the same ones?

@hello-smile6 lets not give people less reasons to not use M1 macs

Why?
Linux is universal...

It's giving the same ones?

What did it say while building?

because I don't like Apple

because I don't like Apple

Wrong article, you can actually run Linux natively.

just keeping the x86_64 Mac builds so at the very least they aren't being ARM for laptops/PCs fans. ARM is strictly phones and tablets only forever

I use a MacBook Air, please don't discriminate against me lol

@webdev03 32 bit building failed, check here:
https://github.com/JaydenDev/Catalyst/runs/4652773189?check_suite_focus=true

I use a MacBook Air, please don't discriminate against me lol

I'll get you some ARM64 builds on my fork.

I use a MacBook Air, please don't discriminate against me lol

I'll get you some ARM64 builds on my fork.

they can be built on the official repo fine

I know what went wrong. It build x64 twice. Try this.
electron-forge make --arch x86

I'd prefer binaries be built on the official repo, unless the forks aren't a complete copy.

I know what went wrong. It built x64 twice. Try this.
electron-forge make --arch x86

64 bit isn't wanted...

I'd prefer binaries be built on the official repo, unless the forks aren't a complete copy.

I could always run git pull on my repo and build every 10 minutes.

It says x64 in the log. I keep on forgetting which architecture is which, but x64 is going to be the modern one or x86?

cant you just
--arch x32

ie32 is what I tried.

I know what went wrong. It built x64 twice. Try this.
electron-forge make --arch x86

64 bit isn't wanted twice tho... you are doing it twice with that command.

I think x32 is the wrong architecture name. I have a feeling it refers to it as x86.

Oh, that explains it.

no --arch=arch is correct, the docs say

no --arch=arch is correct, the docs say

Hmm, what was that about deletion of a read the docs comment? 😄

@hello-smile6 i read the docs and provided the information instead of linking docs.

@hello-smile6 i read the docs and provided the information instead of linking docs.

Oh.

Neither 1.1 or 2.0 will be ever releasing.
Thank you everyone for your contributions but I will be killing the Catalyst project, forever. I will be archiving soon, if you like Catalyst please either go to Ninetails or another Electron browser.

Catalyst back! @JaydenDev

Catalyst back! @JaydenDev

I'm going to remake this issue to declutter the conversation.

I'm going to remake this issue to declutter the conversation.

#110

#110


Fix rtd

Codecov Report

Merging #133 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #133   +/-   ##
=======================================
  Coverage   94.01%   94.01%
=======================================
  Files           4        4
  Lines         986      986
  Branches      223      223
=======================================
  Hits          927      927
  Misses         31       31
  Partials       28       28

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24b9c1e...fb7ad53. Read the comment docs.


Fix typo in about_mapstyle_vs_iterable.mdx

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Maybe better documentation?

I heard about this utility when it was mentioned in Juiced.GS and I thought it was the answer to what I needed: a way to combine the executable and resource fork into a IIgs disk image. Except this only runs on Windows it seems and there's no documentation in the main cpp file. Where is the resource fork stored? In the ._(filename) file? In some data stream of the file? Who knows?
All I see is:
    readfile(argv[1], "AFP_AfpInfo", (void**)&afpInfo, NULL);
    readfile(argv[1], "AFP_Resource", (void**)&afpResource, &fileRsrcSize);
    readfile(argv[1], NULL, (void**)&fileData, &fileDataSize);

What does AFP_Resource mean here?
I ultimately put this down after compiling the dependent libs on Linux and then realizing that this depends on Windows API so that's that.

Hi xandark,
This was very much a tool I wrote for myself and decided to throw on GitHub in the off chance someone else could use it. I didn't realize it was mentioned in Juiced.GS.  Neat.
Yes, this is Windows only. I figured the Visual Studio 2022 requirement for building would make that clear, but I'll see about adding a bit more detail to the readme.  Thanks for the note.
As for where the resource names come from, as the Golden Gate docs mention, on Windows, GG uses the NTFS file system and writes the IIgs resource info to the alternate data stream of the file, which is an NTFS-specific thing.  I don't know how this works on Linux or other file systems.  The names are standard Apple names for these things, and are also found in the Golden Gate source, or simply by using a utility that will display alternate data streams on an NTFS file.
Anyway, sorry for the confusion, I'll try to update the readme/add some code comments when I get some time.
Thanks,
Brian

Updated the readme with Windows/NTFS requirements.

Okay thanks for the clarification, and I've found an alternate tool for Linux.

Do you have a link?  I can add it to my readme, maybe it'll help someone else in the future.

Yes, the Cadius tool by Brutal Deluxe. The "ADDFILE" sub-command can add resource forks.
https://www.brutaldeluxe.fr/products/crossdevtools/cadius/

Actually, this is a better link because it has a Linux release:
https://github.com/mach-kernel/cadius

On Linux, if you want to have resource forks that are larger than 64K, you have to reconfigure and compile GG to separate the resource forks into a separate file that begins with ._
I realize this is very very niche, so I'm not pressing others to add support to their utilities. I'm just happy that Cadius allows me to construct a full fat file piece by piece.


Issue installing worker node

Hi,
Stuck on the worker node provisioning, would be good to get some help with this, these are the last few lines after from running the script "deploy_ne.sh "
using : OpenNESS 20.12.02 Release
--
Retrying task - attempt 9 of 10
Error occurred. Will retry after 5 seconds. You can find details below:
No package matching 'tuned-2.11.0-8.el7' found available, installed or updated

Retrying task - attempt 10 of 10
fatal: [node01]: FAILED! => {
    "attempts": 10,
    "changed": false,
    "rc": 126,
    "results": [
        "No package matching 'tuned-2.11.0-8.el7' found available, installed or updated"
    ]
}

MSG:

No package matching 'tuned-2.11.0-8.el7' found available, installed or updated

NO MORE HOSTS LEFT *************************************************************************************************************************************************************

PLAY RECAP *********************************************************************************************************************************************************************
node01                     : ok=85   changed=22   unreachable=0    failed=1    skipped=84   rescued=0    ignored=2

Regards,
ravi

Hi ..any update on this issue ?

Hi. This happened to me once, and although I got around it by just commenting out the tuned-2.11.0-8.el7 line and setting tuned_skip to true in group_vars/edgenode_group/10-default.yml, eventually I reinstalled OpenNESS and didn't run into that error. The difference I can think of is that the first time I was using CentOS 7.6-1810 (I think this was the supported OS for OpenNESS 20.09) and now I switched CentOS 7.8-2003 (supported OS for OpenNESS 20.12).

Ok thanks Jorge, the OS matches..will keep that in mind for the worker node, but still stuck with the controller issue. Would you have insight on that ?, issue is with certificates for Harbor...

Hi,
Looks like the K8S controller installation went fine, but how do i validate that the controller services are up ?, dont see Kubectl configured either on the controller too to excute any related commands..any help ?, any openness references to validate the controller and worker node setup, before deploying some applications ?
thanks


Fixes #2537, #3691, #3406 - New Overlapped Design, mouse/keyboard sizing - Progress on #2491

Fixes

Partially Addresses #2491 by

Finishes ViewArrangement.Overlapped support
Fixes #2537
Fixes #3735
Fixes #3406
Fixes #2484

Proposed Changes/Todos

[x] Remove temporary code in OnDrawContent and get z-order correct.
[x] Enhance Bars scenario to illustrate Popover menu concept
[x] Enhance Navigation scenario with ArrangementEditor; like AdornmentEditor makes it wasy to change view settings related to arrangement for testing/demos.
[x] Clone Navigation scenario to Arrangement scenario - one for each
[x] Implement support for ViewArrangement.Resizable
[x] Fix Draw
[x] Remove more code from Toplevel - See how far I can get in removing Toplevel allogether without re-doing all the Runnable stuff (for a later PR focused on IRunnable).
[x] Fix #2537
[x] Update docfx/docs and other API docs

For future PRs

[ ] Enable Runnable concept
[ ] Fix #3741
[ ] Fix #3742
[ ] Fix #3691
[ ] This PR re-broke the cursor flickering issue (#3408). Will fix this in #3444
[ ] Create a scenario that illustrates an "MDI" like app (replacing BackgroundWorkerCollection). Show how MenuBar and StatusBar can be in any View, even multiple.
[ ] Fix #3743
[ ] Fix #2483

Pull Request checklist:

[x] I've named my PR in the form of "Fixes #issue. Terse description."
[x] My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
[x] My code follows the Terminal.Gui library design guidelines
[x] I ran dotnet test before commit
[x] I have made corresponding changes to the API documentation (using /// style comments)
[x] My changes generate no new warnings
[x] I have checked my code and corrected any poor grammar or misspellings
[x] I conducted basic QA to assure all features are working

In making keyboard-based arrangement work, I needed to finally fix
#3406

Latest: Tiled mode is semi-enabled. Remaining challenges:

[ ] Need a simple way to declare tiled view size dependencies. Note that when I size Tiled1, Tiled4 gets confused.
[ ] Auto join of borders/drawing of titles needs fixing (#2483).

Closing. This branch is now rebased with

#3571


Update aws-core, http-client-spi, ... to 2.17.172

Updates

software.amazon.awssdk:aws-core
software.amazon.awssdk:http-client-spi
software.amazon.awssdk:netty-nio-client

from 2.17.104 to 2.17.172.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #129.


remove extra msg comments for build comment file

can one of admins view this change?

@samrocketman same as with #632, i would merge this and test current master afterwards.


SOME BASIC AND EXTRA FEATURES FOR BACKGROUND REMOVER.

Is your feature request related to a problem? Please describe.
I want to add some features in background remover

Demonstration of Brush size and softness

Auto Colour Remover

Magic edge detection manual remover (self define name)

Edge smoothing using gaussian blur. sharp edges look dirty :-X

Describe the solution you'd like
I've decided the solution in the telegram group here's link to that message

Describe alternatives you've considered
No alternatives but the features are combined of PicsArt and Background Eraser Application in Android.

Auto color removing is presented as a filter since long time ago

The feature I'm asking and the filter you're saying are World apart. See the video in where i use auto colour option in which select colour from image And it'll automatically remove those colours.

You can use Pipette


Display the full tileset image on investigate page

Hey team! Please add your planning poker estimate with ZenHub @sedwardsmarsh @ChristopherSterza @JMBeresford @Donovanphenry


issue #469 neogit can't start on windows

local uv = vim.uv or vim.loop

vim.loop deprecated in neovim 0.10

or os_name:find("MINGW")

for mingw/msys

filename = filename:gsub("^C:", "C%%")

replace "C:/folder/file" to "C%folder/file" as : (colon) is reserved in windows

can you still reproduce the issue on the master branch?

I believe I've made the platform detection here unnecessary with my recent changes to the same area of the code.
https://github.com/NeogitOrg/neogit/commits/master/lua/neogit/lib/state.lua
What error, if any, do you get if you use the fully up-to-date version of neogit?

The issue I see now is different. Each time I am promoted I need to Initialize a repository in my working folder where .git exists.

The code you changed in this pull request has conflicting changes with my PR that I had opened before this one was opened, and that addresses the same initial issue. I noticed your code also uses vim.uv which was a change I neglected to make. I asked elsewhere about the minimum version, and depending on the answer, using vim.uv all the time might be the way to go. https://github.com/NeogitOrg/neogit/discussions/953
Opening a new issue would be a good way for you to clarify the new issue you're seeing.

Submit a issue here: https://github.com/NeogitOrg/neogit/issues/954


Trigger release not on master branch did not work

Description
Changed the branch for release trigger from master to release but for some reason the release of 3.2.0 was triggered on master.

We now develop in develop branch and dependabot also creates the PRs to the develop branch.
So master triggers semantic release.


Battery sensor created multiple times

Hi again :)
I noticed a bug and i can not find a way to solve it.   We have battery devices like motion sensors, flood, smoke and so on.  They all have a master device which gets discovered in HA and sub devices - entities.
Problem is that for each sub device , like temperature, light sensor and so on , a new battery sensor is created in HA.

Why this matters ? Because there are many extra entities that do not have any purpose, it should be only one battery sensor per master device and most important because it messes up the naming once again:
For a motion sensor there is:
binary_sensor.pirfibarodining_living   - which is the motion sensor
sensor.pirfibarodining_living - which is the first battery sensor
sensor.lightsensordining_living_2 - which is the actual light sensor
sensor.lightsensordining_living - which is the second battery sensor.
So what happened is that the light sensor got the index 2 while the battery sensor got the naming of the lux sensor.  So automations do not work anymore.  I can not find any way to convince it to give the naming wihtout index to the actual light sensor.
Can this be solved somehow so we have only one battery device ?
thank you !!!

Hi @MomosX,
Understood. Just to provide you with more context - this is how Fibaro HC3 is designed. Battery status is assigned to both parent and child devices.
Agree and it makes sense to keep one physical battery status when working with Home Assistant.
The problem is that Fibaro considers battery status is an attribute for the existing devices, and Home Assistant considers battery status a separate sensor. This is why it is not a problem for Fibaro, but introduced user experience challenge for Home Assistant users.
I can consider implemented some sort of algorithm for battery status duplicate identification, and omit unnecessary device generation for Home Assistant

I can live with having multiple battery sensors for the same device.  But the main problem is the numbering.
In the example above sensor.lightsensordining_living used to be the lux sensor.  After a stop/start of the QA and i think also a reboot of HC3 , that name was assigend to the battery sensor and sensor.lightsensordining_living_2 became the lux sensor.
Nothing i did could change them back.   Would be great  if the baterry sensor received a name like sensor.lightsensordining_living_battery and the lux sensor retained its name.

Hi @MomosX,
Just finished implementing automated CI/CD, basic regression test suite and versioning, e.g. 1.0.188.
Going back to your question - the thing is that QuickApp does already generate unique numbering, but it doesn't feel used by Home Assistant in a way I would expect.

The current QuickApp implementation assigns unique ids for each entity:

MQTT topic => "homeassistant/sensor/<fibaro_numeric_device_id>_batteryLevel"
unique_id within the discovery JSON message to Home Assistant => "<fibaro_numeric_device_id>_batteryLevel"

As you can see your Home Assistant entity ids use totally different template than defined by the QuickApp.

It looks your sensor ids are generated by Home Assistant using entity "friendly name" property... which is weird because entity name can change frequently, while id to remain the same... not depend on "friendly name". I need to check Home Assistant MQTT specification why this is happening in such a way. There should be a good reason for this, and I also need to check if I can control such behaviour, and make Home Assistant use the ids supplied by the QuickApp.

Please let me know if I understood your question correctly?

Yes you did :) .  For as long as i can remember using your QA ,  HA used the device name from HC3, not any other identifier.  The device name was taken from the master device.  It used to be numbers like 1020 or 1030.1, but as i could not identify those devices in HA i changed the default names in HC3 with something meaningfull.

I'm thinking about possible solutions, and one of them would require you to use the new version of the QuickApp + MQTT data cleanup... would it be fine for you, or maybe it is easier to adjust your automations to use the different id?

By the way - I still struggle to understand how could it be that you primary sensor get "2" suffix.

Home Assistant was supposed to assign "2" suffix to the battery level sensor, because your primary one already existed.
Can you please advise if you did any MQTT data clean up before? Or perhaps you did anything else that trigger the main sensor to be removed, and then re-added by the QuickApp again?
The thing is that the newer versions of the QuickApp do not seem capable for changing the  existing Home Assistant entity ids... which make me think you removed your old entities first, then used the new Quick App Version and then Home Assistant reload devices using new names.
Is this correct assumption?

Hi @MomosX,
Just checked your comment at #33, and yes you did MQTT cleanup that explains the situation.
I keep thinking on a solution design. Just fyi why this is not a trivial thing:

depending on Home Assistant MQTT specification that is limited in terms how how entity ids are managed
if I influence Home Assistant entity ids generation logic with "device name" property then

there is no guarantee that Home Assistant will stick to this approach forever and they can change it any time in the future
other QuickApp users may have their automations broken if they rely on the current Home Assistant entity ids (even it is not perfect at the moment)

I don't think anyone else would be affected as until 2 weeks ago the battery stuff was not even working
and i'm not talking about influencing HA entity generation, but adding something to those devices in the QA.
No idea how those properties get from QA to entities in HA.  Does the QA publish them as separate sensors ?

Hi @MomosX

It is definitely possible to add "_batt"-like suffix to battery/power/energy device names to influence Home Assistant with generating unique entity ids (even it is not part of their MQTT specification).

I understand this is important for you, and I'm already looking for a solution, but trying it to be better (if possible).
If there are no better solution design identified - then I most likely need to stick the the suffixed as discussed.

This is just to provide more context why "_batt"-like suffix might not be the ideal solution:

This still leaves the issue open for non-battery devices. Imagine someone names two Fibaro temperature sensors same way and within a single room. Home Assistant will get the duplicate and add "_2" suffix for non-battery devices. This is why I'd like to use the solution design that fixes the issue for all device types and for any kind of room assignments
We'd have to use MQTT specification in a different way it is intended, and we replace one issue with another "smaller" one => usability issue with how devices will be named in Home Assistant for the new QuickApp users + for those existing users who clean their MQTT data => imagine people worldwide naming their Fibaro HC3 devices with a local language (German, Swedish, etc) and then we add "_batt" suffix that uses wording of a different language (English). Even if I add numeric suffixes instead => Home Assistant device names will be different than Fibaro HC3, while ideal is to have device names in sync, like it is described by Home Assistant MQTT specification
Home Assistant relies on "device name" for entity id generation today, but they can change it any time in the future because it is not part of their MQTT specification and so they don't have to implement new "entity id generation" logic in a backward compatible way

Does it help to show the bigger picture, or perhaps I misunderstood anything accedentally?

It sure shows the bigger picture :)

Generally yes.
I guess I understand what you may offer - make the main sensor broadcasted first, then battery/power/energy. So your automation can rely on a fixed main sensor id without suffixes? :-)
This could be a workaround and I'll explore where the message order gets broken.
However I'll keep looking for a better design (with Home Assistant Team) due to few reasons

The workaround above should mostly work for battery powered sensors, but leaving the possibility to get the same issues for other type of devices that are not powered by battery, but name the same and put to a single room. And we want to fix the issue for all type of situations, right? :-)
Proper solution design should not depend on the message order. Because MQTT itself doesn't guarantee the order => the desired solutions must be resilient to messages delivered in a different order.

Hope this helps.

"I guess I understand what you may offer - make the main sensor broadcasted first, then battery/power/energy. So your automation can rely on a fixed main sensor id without suffixes? :-)"  YES :)  took me a while to explain
And fully agree that a more reliable solution is needed but i don't think that can happen without the help of the HA team. Hopefully they will be opened as this is potential trouble with other integrations also.

Hi @MomosX
Good news - I have checked Home Assistant MQTT component sources and rechecked their MQTT specification - apparently there is an "object_id" attribute that we can use to generate unique entity ids.
So the issue will be resolved soon.

Ehhh that is indeed good news:)  that will solve all the issues with naming and with reloads , restarts oq QA or HC3. No more MQTT clearing :)

Hi @MomosX - feel free to use the latest 1.0.191 version, and let me know if it works for you?

"object_id" ? will test tomorrow and let you know.

Yes

there are few more improvements applied to the QuickApp, but double-testing the fix for your issue takes the first priority

So,
Deleted the old QA - for some reason i could not copy/paste the files - and installed the new QA.  All my devices in HA are gone, about 150 of them.
But looking at entities i like very much what i saw there ! All are finally properly named / recognizable.   This is the way they should have been from the beginning :)
So i'll gladly do all the modifications in my HA - again -  to all dashboards - quite a lot of work but it is worth it.
There is no way their names/id's can be messed up now.
I'll do the modifications tonight and keep you posted about how it works, but i expect it to be rock solid :)

Hi @MomosX,
Can you please advise what do you mean by not being able to copy/paste lua files? They are available at GitHub along with the fqa file.
Updating Home Assistant dashboard and automations with new entity ids is exactly what I was meaning earlier, when telling about existing QuickApp users' experience to be impacted :-). At the same time - this should be one-time-effort, while QuickApp stability improvement is long-term.

Please let me know if you have the issue resolved, so I can close this ticket?

Let me test it through multiple reboots of HC3, HA, MQTT clearing first pls.  I'm still updating all my HA dashboards... they look like this now:

I'll finish tonight the update of all entities and proceed to testing :)

This is exactly what expected after all the entity ids are new (& stable) now

"Can you please advise what do you mean by not being able to copy/paste lua files? They are available at GitHub along with the fqa file" - copy raw data from github but in the QA edit there is no paste anymore; just cot and copy.
I think it's because it goes over the maximum lines in the QA.  have to delete everything in the file, save, then can paste.

Waiting for your testing results, and I'll release notes for the existing users so it's not a surprise for them

I think we can close this as everything seems to be ok. Reboots, restarts, clearing MQTT, the etities come back always where they are supposed to and with the proper naming:)  Great work Alexander and thank you again.
Users will have to do a few modifications now but it's quite easy as you only have to search in HA for the device ID from HC3. Can't go wrong.
PS: as a side note , the QA version 1.0.191 was missing the variables for HC3 user/pass.

Hi @MomosX
There are no missing HC3 user/pass - it is a feature. QuickApp is now able to authorise itself, without making users add those two variables :-)
Quick App is getting better every iteration, I'm not event talking about new CI/CD environment with automated regression testing for better quality of the releases, like for commercial projects, except I don't get paid for it.


Manually moved package installed by Chocolatey can never be searched by Windows system

I Installed mingw package with Chocolatey in my Windows pc.  Chocolatey automatically placed Mingw at C:\ProgramData\chocolatey\lib\mingw\tools\install\Mingw... without asking me for a user-selected location.  So I manually move mingw to another desired location and set the environment path to that other location.  Now, every time I try to execute any *.exe in mingw\bin*.exe in command prompt, the system always says "Cannot find file at '..\lib\mingw\tools\install\mingw64\bin\gcc.exe' (c:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\gcc.exe).This usually indicates a missing or moved file."
It never searches the executable in the environment path I set.
I tried "cuninst" with all kinds of options (e.g. -n, etc.), the system still gave me the same message.
How do I fix this?

This is the default location where Chocolatey packages will be placed (under the lib folder of the location Chocolatey is installed to (c:\programdata\chocolatey by default). Chocolatey won't ask you for a location to install the packages to.
Chocolatey has shimmed the executables so that they are accessible on the path and moving them will break this link. When you moved them, the shims still point to the old location.
The solution is to move them back to where they were.
See these docs around overriding the install location.

Thanks Paul.  I re-installed the package and uninstall it using cunst.  The shims are now gone.  As for the --dir option to override the default installation location, I am not a customer of Chocolatey to be allowed to use option.  So, I simply go to SourceForge, download my package zip and unzip to my desired location.


Add support for AVX2?

It looks like more or less all the SIMD instructions in use have an AVX2 variant and this would provide about a 2x speed improvement, both on Intel and AMD cpus.
Would be cool to get that :sunglasses:

there's going to be one difficulty with shifting the simd vector by an amount only known at runtime. avx2 is really annoying to deal with due to its 128-bit lanes


Robustify JWL EOS, using robust divide function for divisions. Added …

…bounded argument exponential function to robust utils.

PR Summary
Improve the robustness of JWL eos. Better checking to prevent FPE's. Added bounded argument exponentials to prevent under/over flow.

PR Checklist

[ ] Adds a test for any bugs fixed. Adds tests for new features.
[x] Format your changes by using the make format command after configuring with cmake.
[ ] Document any new features, update documentation for changes made.
[ ] Make sure the copyright notice on any files you modified is up to date.
[ ] After creating a pull request, note it in the CHANGELOG.md file
[ ] If preparing for a new release, update the version in cmake.

I've added asserts in the ctor, @jhp-lanl @Yurlungur could you let me know what the physical bounds on those parameters so that appropriately bounding checks can be added to the ctor.

@dholladay00 where is this MR at? Should we merge it?

We could, I think I did this to reduce FPE's in SAP. Perhaps it's good to do in general. I'm not opposed to merging it.

It's a pretty small changeset. I think we might as well.

we should probably create an issue to robusify all analytic EOS's in a similar fashion.

we should probably create an issue to robusify all analytic EOS's in a similar fashion.

#327


Add find module for brotli

The module looks for brotli using pkg-config if available otherwise it will look for the library in the CMAKE_PREFIX_PATH. If found a target is created that mirrors the in source build of the library.
The brotli headers do not have versioning so a minimum version is not requested.

In https://github.com/libjxl/libjxl/pull/855 the CMAKE_MODULE_PATH is added to. This PR is dependent on that one landing first.

Thank you @jonsneyers and @eustas !


File system retriever should error if requested path not in the configure home

Otherwise a carefully crafted requests could pull any file on the server.

Can you give an example of such a request?  It is more than just ../../../etc/passwd, right?

That's basically what I was getting at.  There should not be a way to pass an absolute or relative path that escapes the configured base.


Mismatching types for shared_fmt! on armv7-unknown-linux-gnueabihf

A build for the armv7-unknown-linux-gnueabihf target is failing with the following error on a GitHub Ubuntu x86-64 runner:
 error[E0308]: mismatched types
  --> lib/crate/src/file.rs:74:21
   |
74 |                     shared_fmt!("node {node_ref:?} not found");
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `22`, found `10`
   |
   = note: expected union `FlexStr<_, 22, 7, 7>`
              found union `FlexStr<_, 10, 3, 3>`
   = note: this error originates in the macro `shared_fmt` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.

Obviously a confusion between the host and target platform.
Unfortunately a private project so I can't share any links to the code. We are using flexstr in multiple internal crates. It worked flawlessly until recently adding a new internal crate.

I'm not understanding how this is a flexstr bug? Somehow you have a mismatch between two different types of string with different sizing params.

Probably caused by an unrelated issue: https://github.com/HMIProject/open62541/issues/32
Sorry for the noise.


Can make the command nsenter simpler?

run docker-enter is easier. Can we run nsenter with same way? If the options are never changed.
change from:
PID=$(docker inspect --format {{.State.Pid}} <container_name_or_ID>)
nsenter --target $PID --mount --uts --ipc --net --pid

to
nsenter <container_name_or_ID>

Currently I create a simple script to simplify the command:
$ cat denter
PID=$(docker inspect --format {{.State.Pid}} $1)
sudo nsenter --target $PID --mount --uts --ipc --net --pid

Ah, why not use docker-enter directly in that case?

@jpetazzo
I think you knew the difference between nsenter and docker-enter, right?

Seems my request is not accepted, I close this ticket, because I have the work around already and it is good enough.

Ah, sorry, I hadn't understood your request.
To clarify (and for other people who could have similar ideas): nsenter is a tool in the util-linux package. I don't think that its authors and maintainers want to extend it to directly support Docker because that would be a fairly complicated extension. I believe (but I can be wrong) that the idea is to keep it simple and build on top of it. docker-enter precisely builds on top of it to integrate with Docker.

Sure, let me explain more.
With nsenter,
(1) $ PID=$(docker inspect --format {{.State.Pid}} 08a2a025e05f)
(2) $ sudo nsenter --target $PID --mount --uts --ipc --net --pid
(3) $ ls /var/log              < #start from here, I am in container, and type the linux command directly
(4) $ df -h

So with my work-around script, I run:
(1) $ denter 08a2a025e05f
(2) $ ls /var/log
(3) $ df -h
But with docker-enter, I need type:
(1) $ docker-enter 08a2a025e05f ls /var/log
(2) $ docker-enter 08a2a025e05f df -h

So I prefer my way, and that's the reason I raise this ticket.

maybe I raise a pull request to add new command denter directly. let me do it and please check if you accept this way or not.

But it already works that way:
docker@default:~$ docker run -dti alpine sh
bc5f1d9b7d7e7b2ff50906d987333a35f5614e09c95c72ba51cc6fb5e1df6f19
docker@default:~$ docker-enter bc5f
/ # ls
bin      etc      lib      media    proc     run      sys      usr
dev      home     linuxrc  mnt      root     sbin     tmp      var
/ # ps faux
PID   USER     TIME   COMMAND
    1 root       0:00 sh
    8 root       0:00 ash
   10 root       0:00 ps faux

thanks, I didn't know that. I am fine now.

OK, cool!


Make assertion to be connector agnostic

Make assertion to be connector agnostic
This fixes TestAccumuloDistributedQueries failure.

Tests fail due: #3121


Fix veryfast preset of handbrakeCLI nightly

As we just discussed.
Force handbrakeCLI to use medium preset

@cnrd I'll consider but first I want to find out what kind of crack the HandBrake development team has been smoking to make veryfast the default.
In the meantime, when using nightly builds, add -H encoder-preset=medium to your command line to get the default behavior.

Will do!
Thanks :-)

@cnrd OK, it looks like the change to veryfast as the default preset is intentional by the HandBrake development team, however misguided. And it looks like they've changed other defaults. Which means the fix I have to make will likely be more than just the preset.
Stay tuned.

@cnrd OK, I took your patch. Thanks.
But I had to fix your spacing (none before commas, please) and rewrap your line. Just be careful with that the next time.
Looks like I won't have to change anything else. But I'll test this for awhile before I release it.

Yeah I see that, sorry that was sloppy coding... I totally agree on only having spaces after a comma. Thanks for fixing it up.
Will be more careful if I propose other patches.

@cnrd No worries, man. Keep the patches coming. :)

@cnrd BTW, are you on Twitter? What's your account name so I can keep an eye on you? :)

I'm @ConradAndersen on Twitter, not that I really write much on there, mostly use it as a newsfeed :-)

@cnrd Ah! I thought that might be you. :)
BTW, I spent the day following up on your fix in a big way. Lots of changes to support HandBrake nightlies. There was far more wrong than I thought. So, I just released version 0.3.1.


Single-quoted attribute selectors

Attribute selectors using single quotes are removed.
var purify = require("purify-css");

var html = '<form action="foo/"><button id="a">Go</button><input id="b" /></form>';
var css = "form[action='foo/'] #a, #b { display: none; }";

purify(html, css, console.log);

This logs #b { display: none;}, omitting the expected attribute selector.  I figured out eventually that changing my CSS to use double quotes corrects the problem, but single quotes ought to be supported.

Should be good now, thanks


Extend JDBC URL pattern to support failover

This PR proposes to extend the JDBC URL pattern as follows to support failover.
jdbc:clickhouse://host1:port1,host2:port2[/database][?prop1=value1&prop2=value2]
To be clear, do not expect it to act as load balancing, the mechanism of failover is:

try to connect the first host at the beginning
if the first host is unreachable, then try the second, and so on
when the connection is broken, go 1

LGTM

Thanks a lot to @loneylee for bringing this amazing feature, I update the PR description to make it clear, and please double-check if I misunderstand something.

I am honored to be able to help the community, and if there are issues related to this issue in the future, I am willing to assist in solving it

LGTM, Let's merge !


Does the dataset on the website have trajectories for both sides?

In README file, the sampling scripts generate files n_0.hdf5 and n_1.hdf5 for both sides of agents.
However, the datasets downloaded from the official website only contain one file called all_data.hdf5.
Does the file contain the data of the two agents? If so, for a trajectory, how do I find the trajectory corresponding to the enemy agent?

The released datasets are derived from the original sampled data and include only the controlled side's information. For simplicity, in hok1v1, we merged the sliced files x_0/1.hdf5 into a single file, all_data.hdf5. We did not provide the transitions of the opponent side, as they are considered part of the environment in our benchmarks.
As noted, if necessary, you can easily sample new datasets with both sides' trajectories.

As noted, if necessary, you can easily sample new datasets with both sides' trajectories.

@cloud-qu Thanks for your explanation! I am trying to re-sample the datasets with both sides.
I read the description of datasets in the paper and appendix, but some details about data sampling seem unclear.

About the Multi-Difficulty datasets, only the levels of opponents are provided. I am wondering what are the specific levels of ego agents.
In Table 4 of the paper, does the winning rate of Multi-Difficulty refer to the built-in bot as the opponent? Or does it mean that the opponents are different opponents used in the sampling of each data set?
What is the specific value of all reward items? Is it the same as examples of reward config in hok_env?

Thank you for your interest in our work.

The levels of ego agents: For poor datasets, the levels of ego agents are 1 or 2 levels lower than those of the opponents. For expert datasets, the levels of ego agents are 1 or 2 levels higher than those of the opponents.
Unless otherwise specified, all winning rates mentioned in the paper refer to those against opponents of the same level as in sampling.
Reward configurations: We have released the reward configurations. Please refer to 1v1, 3v3

Hello, may I ask if you encountered this problem during the sampling process #4
@TimerChen


Data.JSString.length does not behave correctly with surrogates

{-# LANGUAGE OverloadedStrings #-}
import qualified Data.JSString as JSString

main :: IO ()
main = do
  let txt = "\915929"
      len1 = JSString.foldr (\_ -> (+ 1)) 0 txt -- 1
      len2 = JSString.length txt -- 2
  print $ len1 == len2 -- False

thanks for the fix


DESCANT and SCEPTAR waveform analysis for leangrsi

Code for analyzing waveform data for DESCANT and SCEPTAR.

Just double checking before we do this... Did you mean to do this in your master and merge it back to leangrsi? When I did it on my computer I merged MyFork:master back into MyFork:leangrsi, and then pulled MyFork:leangrsi into GriffinCollab:leangrsi. Just checking that this is what you actually intended.

I started with my master, pulled upstream master, then merged in leangrsi.
(I don't think that I will need to develop on non-leangrsi after this).
I'm reasonably confident that your leangrsi changes are properly integrated
(as evidence, the commits in the pull request are things that I
deliberately changed).
I originally tried to fetch leangrsi, then merge in master, but the merge
wasn't as clean (I think that it was trying to overwrite leangrsi changes
with stuff from the master).  I also didn't want to redo my changes as new
commits.
If you'd like, I could turn my master into my leangrsi, then do a pull
request from there.  Or if you can suggest something else, I could do that
too :p.
Greg
On Wed, Jun 3, 2015 at 4:40 PM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

Just double checking before we do this... Did you mean to do this in your
master and merge it back to leangrsi? When I did it on my computer I merged
MyFork:master back into MyFork:leangrsi, and then pulled MyFork:leangrsi
into GriffinCollab:leangrsi. Just checking that this is what you actually
intended.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/354#issuecomment-108608398
.

Nope this should be fine, I was just making sure the intent was there! I'll do a quick skim through this just because we are running here and it will help me find problems quickly (not that I'm saying there are any).

So, is this going on the master?  Is the master now the lean version?  I
think we still have some tigress coding to do.
On Jun 3, 2015 2:07 PM, "Ryan Dunlop"<EMAIL_ADDRESS>wrote:

Nope this should be fine, I was just making sure the intent was there!
I'll do a quick skim through this just because we are running here and it
will help me find problems quickly (not that I'm saying there are any).
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/354#issuecomment-108616617
.

No. He merged from his master to the collaborations leangrsi.

Excellent, I missed that. Thanks for the clarification.
On Jun 3, 2015 2:10 PM, "Ryan Dunlop"<EMAIL_ADDRESS>wrote:

No. He merged from his master to the collaborations leangrsi.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/354#issuecomment-108617158
.

Looks good Greg, I'll give it a quick pull over here and run it on some real data.

Excellent. I think the only change that could affect you is changing the
streaming of waveform in tgrsidetectorhits.h
On Wednesday, June 3, 2015, Ryan Dunlop<EMAIL_ADDRESS>wrote:

Looks good Greg, I'll give it a quick pull over here and run it on some
real data.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/354#issuecomment-108617499
.

It works! (Compiled and doesn't break old stuff).

On Jun 3, 2015, at 2:35 PM, gdemand<EMAIL_ADDRESS>wrote:
Excellent. I think the only change that could affect you is changing the
streaming of waveform in tgrsidetectorhits.h
On Wednesday, June 3, 2015, Ryan Dunlop<EMAIL_ADDRESS>wrote:

Looks good Greg, I'll give it a quick pull over here and run it on some
real data.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/354#issuecomment-108617499
.

—
Reply to this email directly or view it on GitHub.


update(docs): updated MPA documentation with the gulp tasks

update(docs): updated MPA documentation with the gulp tasks that are presently available

Coverage remained the same at 98.413% when pulling 9edb07a9dad28a896edb7110144091565f569250 on johnmeilleur:update-docs-mpa into e3ae5e4f8f8993c06fc176ac7525d2bbfff203b4 on ngOfficeUIFabric:dev.

manually merged to dev


You made an update yesterday...

Had version x.12 now version x.13 and now my menus are not working.

fixed the problem by editing the package.json file and pointing "main": back to "src/index.js" not sure what is wrong in the dist/vue-collapsible.js but the none of the v-collapse- directives are working

Seems like the build is not correct, i'll have a look at it and put up a PR asap

Does recent update fix your problem?


Design Meeting Notes, 5/27/2016

Narrowing within Function Expressions
const Modifiers on Function Parameters
functin f0() {
    let x = getStringOrNumber();
    if (typeof x === "string") {
        const f = () => x.length; // currently errors
    }
}

We don't make an effort to dive within functions expressions - we don't narrow within them.

However, when you have a const, you know for sure that you can definitely narrow.
We're making sure that works.
Problem is, you can't reflect that behavior with parameters today.

In a constructor can you have a public const?

We could say public readonly does that?

That's conflating the idea.
"It's uninteresting" and doesn't come up in practice

What about nested members of a const?

i.e.
const x = { foo: { bar: number } };
x.foo.bar;

IIFEs
Repro from #8381
(function() {

}())

Look at the PR

Enums & Algebraic Data Types

Simple approach is that you use singleton value types.

Currently, these singleton value types are limited to string literal types.
type Foo = "up" | "down";

var x: Foo;
switch (x) {
    case "up":
      // ...
      break;
    case "down":
      // ...
      break;
}

Gets more interesting with something like:
interface Up {
    kind: "uP";
    speed: number;
}

interface Down {
    kind: "down";
    fatal: boolean;
}

var x: Up | Down;
switch (x.kind) {
    case "up":
      x.speed;
      break;
    case "down":
      x.fatal;
      break;
}

Forgive the terrible example.

These need not be string literals - they could be numbers, enums.

Wouldn't it be nice if we could do this sort of thing with SyntaxKind in the compiler?

Each node would define its own specific discriminator in its kind field.
interface Node {
    kind: SyntaxKind;
}

interface PropertyAccess {
    kind: SyntaxKind.PropertyAccess;
}

Problematically, you couldn't quite do this with the OO-style property inheritance we get (open-ended in OOP, close-ended in FP).

Ideally, you could do exhaustiveness checking with this, but Node is open-ended right now.

So you'd do something like this:
interface NodeBase {
    kind: SyntaxKind;
}

interface PropertyAccess {
    kind: SyntaxKind.PropertyAccess;
}

interface CallExpression {
    kind: SyntaxKind.CallExpression;
}

type Node = PropertyAccess | CallExpression // | ...

What would the type of a Node's kind be now?

SyntaxKind.ProperyAccess | SyntaxKind.CallExpression | ....

Is SyntaxKind equivalent to that union type?

Not necessarily! That can be confusing!

So you'd have to do something like this:
const enum Color {
    Red, Green, Blue
}

type AllColors = Color.Red | Color.Green | Color.Blue;

So to avoid the AllColors example, you could imagine that we'd have a new kind of enum:
union enum Color {
    Red,    // 0
    Green,  // 1
    Blue    // 2
}

Couldn't use flags in this example.

TC39 convo on enums had symbols in mind.

Issues with that.

Need to be able to serialize that in an error message.

DR: I think we could do ADT-style stuff without needing enum types yet.

AH: Yes, and strings are fine, but you really can't do that with numbers.
DR: But ADTS are moe general.
AH: But string/number discriminators are the real value of this feature.
DR: Agreed.

DR: Problem is that the base-type/intermediate-types/union-type pattern is cumbersome - you've fixed the enum type, done nothing there.

There are a lot of tools that use the Mozilla Parser API to represent ASTs (babel, esprima, escodegen, acorn, and their respective plugins, etc).
That defines a Node like:
interface Node {
    type: string;
}

Then all the node types extend that, e.g.:
interface IfStatement extends Node {
    type: "IfStatement";
    test: Expression;
    consequent: Statement;
    alternate: Statement;
}

interface LogicalExpression extends Node {
    type: "LogicalExpression";
    operator: "||" | "&&";
    left: Expression;
    right: Expression;
}

You can see a full set of parser API typings here.
Similar to the meeting notes example, it would be great when dealing with these AST to be able to write:
function foo(node: Node) {
    if (node.type === 'Identifier') {
        node.name;
    }
    else if (node.type === 'MemberExpression') {
        node.object;
        node.property;
    }
    else {
        ...
    }
}

Yup @yortus that's the general direction we're hoping to land in.

Was there an outcome on const parameters?

I'd also like to reference #6062 in regard to the ADT work. Nothing has to be/should be specific to singleton types or enums - switching based on any kind of discriminating type structure should probably be possible. I could probably just clean that PR up and get feedback and we'd have what we want there.
I also have a half done implementation of exactly this:
interface PropertyAccess {
    kind: SyntaxKind.PropertyAccess;
}

based around my numeric literal types PR (though enum member types are mostly separate from them). Though most of my 'open questions' to myself from those resulted in questioning how they should be compatible with each other and numeric literals. I could clean that up a bit and divorce it from the numeric literal work if we're interested in it.

@RyanCavanaugh not much actual discussion on it as much as the details on it to be honest.


Composer requirements could not be resolved

In Contao 4.9.9 & using Contao Manager this cant be installed:
$ /opt/plesk/php/7.4/bin/php -q -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=UTC /var/www/vhosts/derhaeuptling.com/site_contao/web/contao-manager.phar.php composer update terminal42/contao-oembed contao/conflicts --with-dependencies --prefer-dist --no-dev --no-progress --no-suggest --no-ansi --no-interaction --optimize-autoloader
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Installation request for terminal42/contao-oembed ^1.0 -> satisfiable by terminal42/contao-oembed[1.0.0].
    - Conclusion: remove php-http/httplug 2.2.0
    - Conclusion: don't install php-http/httplug 2.2.0
    - terminal42/contao-oembed 1.0.0 requires php-http/httplug ^1.0 -> satisfiable by php-http/httplug[v1.0.0, v1.1.0].
    - Can only install one of: php-http/httplug[v1.1.0, 2.2.0].
    - Can only install one of: php-http/httplug[v1.0.0, 2.2.0].
    - Installation request for php-http/httplug (locked at 2.2.0) -> satisfiable by php-http/httplug[2.2.0].
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
# Process terminated with exit code 2
# Result: Misuse of shell builtins

it looks like an extension you already installed is requiring php-http/httplug version 2.2, which is incompatible with this extension at the moment.

it looks like an extension you already installed is requiring php-http/httplug version 2.2, which is incompatible with this extension at the moment.

must be contao itself.
Just gave it a retry with fresh contao:
composer create-project contao/managed-edition . 4.9
than
composer require terminal42/contao-oembed
same error:

looks like you're right 😞 interestingly I didn't have that problem in my installation, neither did @leofeyer on contao.org 🤔
$ composer why php-http/httplug
php-http/client-common  2.3.0  requires  php-http/httplug (^2.0)

$ composer why php-http/client-common
friendsofsymfony/http-cache  2.9.2  requires  php-http/client-common (^1.1.0 || ^2.0)

$ composer why friendsofsymfony/http-cache
contao/contao                       4.9.x-dev  requires  friendsofsymfony/http-cache (^2.6)
friendsofsymfony/http-cache-bundle  2.9.0      requires  friendsofsymfony/http-cache (^2.6)

While trying to upgrade this compatibility, I found out that it is most likely only a problem on your side. Contao and Symfony both work with version 1 of httplug. I guess you need to run a full composer update if you want to install the extension (or at least update Contao at the same time).

Release 1.1.0 no longer requires http-plug


Travis OSX testing

This Draft PR has been opened for the sole purpose of testing Travis's MacOS support with this project. Do not merge.

This travis config is getting out of hand!

Sure is, @thermokarst. Travis officially does not support python/MacOS builds, and fails when trying to install python 3.6, which it seems to want to do by default...?
A few teams have been able to make it work, but I think I'm almost ready to give Github Actions a shot. You mentioned having a repo where you were tinkering with that somewhere?

You mentioned having a repo where you were tinkering with that somewhere?

https://github.com/caporaso-lab/q2-phylogenomics/blob/master/.github/workflows/main.yml
I'm not 100% this'll work at the moment, but you could try to replicate the workflow linked above here in this repo.

This approach is crashing on OSX with package resolution issues from Conda. I'm going to put this on ice for now, and start tinkering with github actions here: https://github.com/ChrisKeefe/q2-diversity-lib/pull/3

Closed. Moving this repo to Github Actions: https://github.com/ChrisKeefe/q2-diversity-lib/pull/3