Installation fails when trying to install as a dependency with global libvips on macOS

Hello,
On macOS, when installing as a dependency with global libvips, it fails. However, if I clone this repo and run npm install then npm run install, it builds successfully.
I've also tried creating a clean macOS VM, only installing Xcode cli tools, homebrew, vips, node, and then try to install it in a empty directory with the SHARP_FORCE_GLOBAL_LIBVIPS environment variable. However, it still fails.
I'd appreciate any help, thank you 🙏
Logs when running npm run install in this repo

user@users-Virtual-Machine sharp % npm run install

><EMAIL_ADDRESS>install
> node install/check

sharp: Detected globally-installed libvips v8.15.2
sharp: Attempting to build from source via node-gyp
sharp: Found node-addon-api 8.1.0
sharp: Found node-gyp 10.2.0
sharp: See https://sharp.pixelplumbing.com/install#building-from-source
gyp info it worked if it ends with ok
gyp info using<EMAIL_ADDRESS>gyp info using<EMAIL_ADDRESS>| darwin | arm64
gyp info chdir src
gyp info find Python using Python version 3.12.4 found at<EMAIL_ADDRESS>
gyp info spawn<EMAIL_ADDRESS>gyp info spawn args [
gyp info spawn args '/Users/user/sharp/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args 'binding.gyp',
gyp info spawn args '-f',
gyp info spawn args 'make',
gyp info spawn args '-I',
gyp info spawn args '/Users/user/sharp/src/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args '/Users/user/sharp/node_modules/node-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args '/Users/user/Library/Caches/node-gyp/22.5.1/include/node/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/Users/user/Library/Caches/node-gyp/22.5.1',
gyp info spawn args '-Dnode_gyp_dir=/Users/user/sharp/node_modules/node-gyp',
gyp info spawn args '-Dnode_lib_file=/Users/user/Library/Caches/node-gyp/22.5.1/<(target_arch)/node.lib',
gyp info spawn args '-Dmodule_root_dir=/Users/user/sharp/src',
gyp info spawn args '-Dnode_engine=v8',
gyp info spawn args '--depth=.',
gyp info spawn args '--no-parallel',
gyp info spawn args '--generator-output',
gyp info spawn args 'build',
gyp info spawn args '-Goutput_dir=.'
gyp info spawn args ]
<string>:114: SyntaxWarning: invalid escape sequence '\/'
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
  CC(target) Release/obj.target/nothing/../node_modules/node-addon-api/nothing.o
  LIBTOOL-STATIC Release/nothing.a
warning: /Library/Developer/CommandLineTools/usr/bin/libtool: archive library: Release/nothing.a the table of contents is empty (no object file members in the library define global symbols)
  TOUCH Release/obj.target/libvips-cpp.stamp
  CXX(target) Release/obj.target/sharp-darwin-arm64/common.o
  CXX(target) Release/obj.target/sharp-darwin-arm64/metadata.o
  CXX(target) Release/obj.target/sharp-darwin-arm64/stats.o
  CXX(target) Release/obj.target/sharp-darwin-arm64/operations.o
  CXX(target) Release/obj.target/sharp-darwin-arm64/pipeline.o
  CXX(target) Release/obj.target/sharp-darwin-arm64/utilities.o
  CXX(target) Release/obj.target/sharp-darwin-arm64/sharp.o
  SOLINK_MODULE(target) Release/sharp-darwin-arm64.node
  TOUCH Release/obj.target/copy-dll.stamp
gyp info ok
user@users-Virtual-Machine sharp %

Possible install-time or require-time problem

[x] I have read and understood all of the documentation relating to installation.
[x] I have searched for known bugs relating to this problem in my choice of package manager.

You must confirm both of these before continuing.
Are you using the latest version of sharp?

[x] I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.
If you are using another package which depends on a version of sharp that is not the latest,
please open an issue against that package instead.

[x] I am using Node.js with a version that satisfies ^18.17.0 || ^20.3.0 || >=21.0.0
[ ] I am using Deno
[ ] I am using Bun

If you cannot confirm any of these,
please upgrade to the latest version
and try again before opening an issue.
Are you using a supported package manager and installing optional dependencies?

[x] I am using npm >= 10.1.0 with --include=optional
[ ] I am using yarn >= 3.2.0
[ ] I am using pnpm >= 7.1.0 with --no-optional=false
[ ] I am using Deno
[ ] I am using Bun

If you cannot confirm any of these, please upgrade to the latest version of your chosen package manager
and ensure you are allowing the installation of optional or multi-platform dependencies before opening an issue.
 -I/glib-2.0<EMAIL_ADDRESS>-O3 -gdwarf-2 -flto -mmacosx-version-min=10.13 -arch arm64 -Wall -Wendif-labels -W -Wno-unused-parameter -std=c++11 -stdlib=libc++ -fexceptions -Wall -Oz -MMD -MF ./Release/.deps/Release/obj.target/sharp-darwin-arm64/common.o.d.raw   -c
npm error gyp info it worked if it ends with ok
npm error gyp verb cli [
npm error gyp verb cli '/opt/homebrew/Cellar/node/22.5.1/bin/node',
npm error gyp verb cli '/Users/user/sharp-test/node_modules/.bin/node-gyp',
npm error gyp verb cli 'rebuild',
npm error gyp verb cli '--directory=src'
npm error gyp verb cli ]
npm error gyp info using<EMAIL_ADDRESS>npm error gyp info using<EMAIL_ADDRESS>| darwin | arm64
npm error gyp info chdir src
npm error gyp verb clean removing "build" directory
npm error gyp verb find Python Python is not set from command line or npm configuration
npm error gyp verb find Python Python is not set from environment variable PYTHON
npm error gyp verb find Python checking if "python3" can be used
npm error gyp verb find Python - executing "python3" to get executable path
npm error gyp verb find Python - executable path is<EMAIL_ADDRESS>npm error gyp verb find Python - executing<EMAIL_ADDRESS>to get version
npm error gyp verb find Python - version is "3.12.4"
npm error gyp info find Python using Python version 3.12.4 found at<EMAIL_ADDRESS>npm error gyp verb get node dir no --target version specified, falling back to host node version: 22.5.1
npm error gyp verb install input version string "22.5.1"
npm error gyp verb install installing version: 22.5.1
npm error gyp verb install --ensure was passed, so won't reinstall if already installed
npm error gyp verb install version not already installed, continuing with install 22.5.1
npm error gyp verb ensuring devDir is created /Users/user/Library/Caches/node-gyp/22.5.1
npm error gyp verb created devDir /Users/user/Library/Caches/node-gyp
npm error gyp http GET https://nodejs.org/download/release/v22.5.1/node-v22.5.1-headers.tar.gz
npm error gyp http 200 https://nodejs.org/download/release/v22.5.1/node-v22.5.1-headers.tar.gz
npm error gyp verb extracted file from tarball node-v22.5.1/include/node/v8-platform.h
... [truncated to fit in github's character limit]
npm error gyp verb extracted file from tarball node-v22.5.1/include/node/v8-value-serializer.h
npm error gyp verb tarball done parsing tarball
npm error gyp verb check download content checksum, need to download `SHASUMS256.txt`...
npm error gyp verb checksum url https://nodejs.org/download/release/v22.5.1/SHASUMS256.txt
npm error gyp http GET https://nodejs.org/download/release/v22.5.1/SHASUMS256.txt
npm error gyp http 200 https://nodejs.org/download/release/v22.5.1/SHASUMS256.txt
npm error gyp verb checksum data {"node-v22.5.1-aix-ppc64.tar.gz":"48557f896cb790ab505ae8f5554c1f85dbcf2f932ee3532aeae749ff983a996a","node-v22.5.1-arm64.msi":"c49a7a51492786b59ae0353ef5f59612b6dd28988421d98ed91340428bddd525","node-v22.5.1-darwin-arm64.tar.gz":"7602384855f1e169b60e51c360e5a2c672b89a19ccda0199ce4675d68fefaaf2","node-v22.5.1-darwin-arm64.tar.xz":"5b519d0b297b1cf02926dcf4c4753b8c42b0862ce74c9cb9fe958fa5517bb7c9","node-v22.5.1-darwin-x64.tar.gz":"6acb4533bc0a43a468f90bbd49230aa16c7c57b2a3451efe02175feea346754d","node-v22.5.1-darwin-x64.tar.xz":"ef81ee849caef087a1bff261954d31e66d666949cf5ea6288f6644037ffe15f1","node-v22.5.1-headers.tar.gz":"c01f304130da4d1335df0ded861e482f315f28d470bb5607a693a24666fc9718","node-v22.5.1-headers.tar.xz":"3c9c5ce61b8f2ce09baeafdfc3df4d9d90421bd8cf5e07f6cd54ffeb9e4251c7","node-v22.5.1-linux-arm64.tar.gz":"8dfaf4b2ce3c639771f6be7001bac81ece0eea3cd6668666c00100bf175a14ee","node-v22.5.1-linux-arm64.tar.xz":"8b88f7fb681d95f8a2ecb7cf87f2cefa6769d3e74ff7309806bf201816e7c136","node-v22.5.1-linux-armv7l.tar.gz":"f9a8f033e5fc8283de1cbea44cb55af08e89495f190ceffb165b11b4c85d22be","node-v22.5.1-linux-armv7l.tar.xz":"54f381ab9bd06b810902864e57b1582b12539c51e45789c57664b14523114137","node-v22.5.1-linux-ppc64le.tar.gz":"ae771855e9e9604b2cda3017142ed534f7e8952cb3e97116080a0f4b2abe9273","node-v22.5.1-linux-ppc64le.tar.xz":"8fb4da9dc3d59720910a348958a83b8f5f057498f415e8fb2156c5f86137e2f4","node-v22.5.1-linux-s390x.tar.gz":"9ca83ac9bac853b67d651e0f88a06e713514ed31ffb833eb899c7b3d05b07794","node-v22.5.1-linux-s390x.tar.xz":"7074a6e0f0437fc4494a664bf8f724ea24ea68414cf400441e11b4f37c303bc6","node-v22.5.1-linux-x64.tar.gz":"2a7b8b8aa5c739ae55233d59f78736911a8a5da5ea1c63f0e843da270d039499","node-v22.5.1-linux-x64.tar.xz":"9d4747dbbc1a91b1324f43c77e13eeddc4d4c54685665540cd7b7ad82e1b2fbc","node-v22.5.1.pkg":"230a13f342b19023e9a77670db6f8e3dcde252194e31be785f3c177331b32c8d","node-v22.5.1.tar.gz":"4a1b383f6036def4bb183f18e71a10b58784db269f9953618418bbaf47692972","node-v22.5.1.tar.xz":"924f381a32cf26b6bedbe95feedde348450f4fd321283d3bf3f7965aa45ce831","node-v22.5.1-win-arm64.7z":"1f94462762068ca4ebaea01590cf7957b4f4c30781b2ad9d036338011bfcfd9d","node-v22.5.1-win-arm64.zip":"0eb0eeeca2465877f7ed15605d0e5fb778cfa35de16f9963e71c0e3aa85b8c29","node-v22.5.1-win-x64.7z":"8ddb106dacd15a1613c2710f17cc2f3dbf390fdf6179a95cf527721f8975a4cb","node-v22.5.1-win-x64.zip":"71b74712aa5c6587c428b39d9ec9aa013bfcfa38a2a0ed8e68b3922dda1b69f4","node-v22.5.1-win-x86.7z":"c28433719ad23e9514694c752654163785a123da770c084d6ab98fadee2ce54f","node-v22.5.1-win-x86.zip":"b7e0fa9acdcfc10662a1be16363b57a86a555ecdc822e31b95133e2c19324988","node-v22.5.1-x64.msi":"c86df5e925f8d3f492a8a7b62a2a972271a9f718e6595a679f001f312f53863e","node-v22.5.1-x86.msi":"f8a9425c5d837ae14f939225a873c4afb075785ca8787548fc44c2ab0caeeb68","win-arm64/node.exe":"8f0855f74cf85797ed4b8d6c8fa9452d3dc70ee28945135f98137c038e72180d","win-arm64/node.lib":"30e63a6726cda6539eeb37c311adf915bccd5c1462723b97a6c07ac91e8ae728","win-arm64/node_pdb.7z":"538470312f6c886112d38697ac647449e614453f8487360c8d4232f0671d1c91","win-arm64/node_pdb.zip":"c783f5f29a7dbd7b88b455936b9f8cb9060652f2f46544aa4e8e1c67faf4de36","win-x64/node.exe":"c8d7b7260fa0659580362267e0634707cce855c6af7fef9a082bf03d6b9f19fd","win-x64/node.lib":"c4d08d45267da3625a30730bf5c8e41518f25d9809179feb267f1b393f5c5f05","win-x64/node_pdb.7z":"a8d6e7c08cac1407ab0f80612b67896ee6b645b00c40be7ee0ef12b7ee325174","win-x64/node_pdb.zip":"50f64ff12a188afd12e81650541ebe598e4da568c5a2c5940549189a8ef276f5","win-x86/node.exe":"f3ce11a330281e8dcd4e1501463dab55a683046a68027518df3ed785d1d94b7a","win-x86/node.lib":"fc3bf3c1e561da1e1c152be9aa5ed1bce8d263a5124841a4ba41ebc37c727f3e","win-x86/node_pdb.7z":"b5ab926ec26d8799fc1e7b590ceb887fd590f26639a57859260af9f953d2ed75","win-x86/node_pdb.zip":"2760619d70bbf076b731d1696b02d10adbdb138c3bf4f9bf330a18bf2b59c500"}
npm error gyp verb download contents checksum {"node-v22.5.1-headers.tar.gz":"c01f304130da4d1335df0ded861e482f315f28d470bb5607a693a24666fc9718"}
npm error gyp verb validating download checksum for node-v22.5.1-headers.tar.gz (c01f304130da4d1335df0ded861e482f315f28d470bb5607a693a24666fc9718 == c01f304130da4d1335df0ded861e482f315f28d470bb5607a693a24666fc9718)
npm error gyp verb get node dir target node version installed: 22.5.1
npm error gyp verb build dir attempting to create "build" dir: /Users/user/sharp-test/node_modules/sharp/src/build
npm error gyp verb build dir "build" dir needed to be created? Yes
npm error gyp verb build/config.gypi creating config file
npm error gyp verb build/config.gypi writing out config file: /Users/user/sharp-test/node_modules/sharp/src/build/config.gypi
npm error gyp verb config.gypi checking for gypi file: /Users/user/sharp-test/node_modules/sharp/src/config.gypi
npm error gyp verb common.gypi checking for gypi file: /Users/user/sharp-test/node_modules/sharp/src/common.gypi
npm error gyp verb gyp gyp format was not specified; forcing "make"
npm error gyp info spawn<EMAIL_ADDRESS>npm error gyp info spawn args [
npm error gyp info spawn args '/Users/user/sharp-test/node_modules/node-gyp/gyp/gyp_main.py',
npm error gyp info spawn args 'binding.gyp',
npm error gyp info spawn args '-f',
npm error gyp info spawn args 'make',
npm error gyp info spawn args '-I',
npm error gyp info spawn args '/Users/user/sharp-test/node_modules/sharp/src/build/config.gypi',
npm error gyp info spawn args '-I',
npm error gyp info spawn args '/Users/user/sharp-test/node_modules/node-gyp/addon.gypi',
npm error gyp info spawn args '-I',
npm error gyp info spawn args '/Users/user/Library/Caches/node-gyp/22.5.1/include/node/common.gypi',
npm error gyp info spawn args '-Dlibrary=shared_library',
npm error gyp info spawn args '-Dvisibility=default',
npm error gyp info spawn args '-Dnode_root_dir=/Users/user/Library/Caches/node-gyp/22.5.1',
npm error gyp info spawn args '-Dnode_gyp_dir=/Users/user/sharp-test/node_modules/node-gyp',
npm error gyp info spawn args '-Dnode_lib_file=/Users/user/Library/Caches/node-gyp/22.5.1/<(target_arch)/node.lib',
npm error gyp info spawn args '-Dmodule_root_dir=/Users/user/sharp-test/node_modules/sharp/src',
npm error gyp info spawn args '-Dnode_engine=v8',
npm error gyp info spawn args '--depth=.',
npm error gyp info spawn args '--no-parallel',
npm error gyp info spawn args '--generator-output',
npm error gyp info spawn args 'build',
npm error gyp info spawn args '-Goutput_dir=.'
npm error gyp info spawn args ]
npm error <string>:114: SyntaxWarning: invalid escape sequence '\/'
npm error gyp verb build type Release
npm error gyp verb architecture arm64
npm error gyp verb node dev dir /Users/user/Library/Caches/node-gyp/22.5.1
npm error gyp verb python<EMAIL_ADDRESS>npm error gyp verb `which` succeeded for `make` /usr/bin/make
npm error gyp verb bin symlinks created symlink to<EMAIL_ADDRESS>in "/Users/user/sharp-test/node_modules/sharp/src/build/node_gyp_bins" and added to PATH
npm error gyp info spawn make
npm error gyp info spawn args [ 'V=1', 'BUILDTYPE=Release', '-C', 'build' ]
npm error warning: /Library/Developer/CommandLineTools/usr/bin/libtool: archive library: Release/nothing.a the table of contents is empty (no object file members in the library define global symbols)
npm error ../common.cc:13:10: fatal error: 'vips/vips8' file not found
npm error #include <vips/vips8>
npm error          ^~~~~~~~~~~~
npm error 1 error generated.
npm error make: *** [Release/obj.target/sharp-darwin-arm64/common.o] Error 1
npm error gyp ERR! build error
npm error gyp ERR! stack Error: `make` failed with exit code: 2
npm error gyp ERR! stack at ChildProcess.<anonymous> (/Users/user/sharp-test/node_modules/node-gyp/lib/build.js:216:23)
npm error gyp ERR!

  System:
    OS: macOS 14.6.1
    CPU: (6) arm64 Apple M3 Max (Virtual)
    Memory: 9.69 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.5.1 - /opt/homebrew/bin/node
    npm: 10.8.2 - /opt/homebrew/bin/npm

When installing the Sharp library on macOS, the relevant header files for the libvips library could not be found. Although you have set the SHARPFORCE_CLOBAL_LIBVIS environment variable, the installation still cannot be successful. This may be due to environmental configuration or path issues.
Did you install it using Homebrew? Why don't you try Servbay, which is a development environment configuration tool on Mac, and redeploy the environment.

The SHARP_FORCE_GLOBAL_LIBVIPS is an advanced feature that most people will not need and is currently impacted by a bug that https://github.com/lovell/sharp/pull/4111 will fix as part of the next release, so please don't use it for now.
The output you provided of running npm install --verbose --foreground-scripts sharp contains the following, which may help you:

sharp: Detected globally-installed libvips v8.15.2
sharp: Attempting to build from source via node-gyp
sharp: Please add node-addon-api to your dependencies

Please ensure you've added all of the additional dependencies required for building from source as detailed at https://sharp.pixelplumbing.com/install#building-from-source

Hi, thanks for the reply. The output of the complete error message is the one where I've installed node-addon-api and node-gyp before, following the requirements, but it still doesn't work.
For thenpm install --verbose --foreground-scripts sharp section I just followed the issue template's instruction. I understood the dependencies.

Please can you provide the output of npm install --verbose --foreground-scripts node-gyp node-addon-api sharp without setting the SHARP_FORCE_GLOBAL_LIBVIPS environment variable.


fix: temporary use Vike's brillout/pnpm-8 branch

Vike's main branch uses pnpm 9 while vite-ecosystem-ci uses pnpm 8. This causes vite-ecosystem-ci + Vike to fail.
This PR is a temporary workaround. I'll revert this PR once Vite uses pnpm 9.

we should figure out a way how to run projects on different majors instead, this would otherwise force projects to provide a compatible branch like this one for every pnpm major update

Agreed, let's close this one.


Missing Icon in Connection Card Created After Configuring HYPR Authenticator in IS Console

Describe the issue:
The connection card generated after configuring the HYPR authenticator in the IS console doesn't contain the corresponding icon.

How to reproduce:

Expected behavior:
The Connection card should contain the corresponding icon.
Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: [e.g., IS 5.10.0, IS 5.9.0]
OS: [e.g., Windows, Linux, Mac]
Database: [e.g., MySQL, H2]
Userstore: [e.g., LDAP, JDBC]

Optional Fields
Related issues:

Suggested labels:

This issue is no longer reproducible in the latest build.


Rust syntax highlighting: Destructured slice function arguments

Description
Rust syntax highlighting of destructured slices in function arguments is incorrectly colouring values as types.

Steps to Reproduce
Enter code:
fn foo_1([b1]: [u8; 1]) {}
fn foo_2([b1, b2]: [u8; 2]) {}
fn foo_3([b1, b2, b3]: [u8; 3]) {}
fn foo_4([b1, b2, b3, b4]: [u8; 4]) {}
fn foo_5([b1, b2, b3, b4, b5]: [u8; 5]) {}

fn main() {
    let bytes: [u8; 2] = [5, 6];
    let [fx, fy] = bytes;
    let bytes: [u8; 4] = [1, 2, 3, 4];
    let [a, b, c, d] = bytes;
}

Expected behavior: Destructured function arguments slice values should have the same colour as destructured values in the main method.
Actual behavior: Some are coloured like types.
Versions
$ atom --version
Atom    : 1.33.0
Electron: 2.0.11
Chrome  : 61.0.3163.100
Node    : 8.9.3

Thanks very much for the report!
Would you mind reopening this issue in the https://github.com/tree-sitter/tree-sitter-rust repository? We use multiple repositories to keep the work items tied to the code they apply to (and I believe that's where the issue belongs since we don't have a core language-rust package). This helps the maintainers spend more time working directly on Atom and less time triaging issues.
Thanks for meeting us half way 👍

since we don't have a core language-rust package

@rsese is that right? There's this thing at https://github.com/atom/atom/tree/master/packages/language-rust-bundled that looks a bit like a core package.

@alexheretic Yeah, it's core (just introduced in the latest release). The issue itself still belongs on tree-sitter-rust, as that's the one that provides the parsing rules.

Ok, I'll raise issues there in future.

ahh yeah sorry about that - I think I instinctively looked for an atom/language-rust package and didn't find one (I think the name was taken so we used the -bundled naming).  Thanks for clarifying @Aerijo :bow:


Update failover default settings

What changed?
Change default settings for managed failover

Why?
To limit the impact on failover

How did you test it?
roughly metrics on staging

Potential risks
N/A

Coverage decreased (-0.03%) to 68.811% when pulling 2058e02a4ee01a42944d3ed3c183afcbd53c7220 on cli-0.15 into 35afbd2dad97c3edab6b27f57e377440b0e572f2 on master.


doc: mgmt: mcumgr: Add details on making handlers

Adds a guide on how to make out-of-tree MCUmgr function handlers and groups, with an example showing a test implementation.
Fixes #59492

@kartben anything to add?


Fixes issue #86.

This pull request fixes the problem discussed in issue #86, which is using Geocoder with pagination libraries such as will_paginate and Kaminari.

Closing this in favor of the no_grouping branch (see my comment on issue #86). Thanks so much for your work on this, including performance tests.


Fix interlacing

@konnng-dev I took your changes from https://github.com/Art4/glide/pull/2 to fix interlacing.
Though when testing the generated image, interlacing doesn't seem to work for JPEGs when using GD.
With Imagick identify -verbose kayak.jpeg | grep Interlace gives Interlace: JPEG but with GD it gives Interlace: None.
It seems to work fine for PNGs for either driver.
@Art4 BTW Glide v2 doesn't interlace PNGs but you have added interlacing for all PNGs in v3. Is that intentional?

Interlacing for all png was added by @konnng-dev in https://github.com/Art4/glide/pull/1

Hmm.. I am leaning towards reverting it and maintaining status quo.

Oh, it was indeed my fault
I can submit a new PR just interlacing JPEGS. But I would like to have option to interlace pngs on demand as well.

But I would like to have option to interlace pngs on demand as well.

You can open a separate PR for that.

Gonna merge this. Will look into JPG interlacing not working with Gd later or just state that as a limitation if me or someone else can't sort it out.


Proof-reading sanskrit verses, vol 3

This issue devoted to proof-reading of volume 3 of our text.

step4a1/verses_03.txt copied to boesp-prep-sam repository as file
sanproof/boesp-3_slp1.txt.   This is for proofreading by @sanskritisampada.
step4a1/verses_03_deva.txt copied to boesp-prep-ab repository as file
sanproof/boesp-3_deva.txt.  This is for proofreading by @Andhrabharati.

@sanskritisampada has finished proof-reading of volume 3 sanskrit verses.
@Andhrabharati  :  Request you provide your proof-reading of volume 3 now.

I had stopped it after doing 100 pp.
Let me resume the work and post in couple of  days.

Hope you can wait till then, @funderburkjim!
Otherwise, here is the portion I did (before stopping)--
verses_03_deva (AB) 100pp.txt
Will wait for your response on this, to resume.

Hi,  I can wait  until all of volume 3 proofreading is done.  No rush.

@funderburkjim
Here is my version of verses_03_deva file--
verses_03_deva (AB).txt
Hope this helps in deciding the text in some manner.
[As many of my posts do not get any response nor seem to be considered in any manner, I've decided not to give any more observations.]

Will work on comparison between volume 3 verses from @Andhrabharati and @sanskritisampada.

diff1
Work done in step4a3 directory.
Preliminary adjustments:

removed the separate comments from AB version, into readme_ab_3.txt
Adjust Sampada's version based on

'extra lines' notes from readme_ab_3.txt.
Also a couple of 'L' number errors.

dff1 result: 567 lines with differences (out of 3521 sections, 16%).
@Andhrabharati   boesp-3_deva_diff1.txt  has the differences.  Request you to provide
a revision of verses_03_deva (AB).txt,   No rush -- it will take Sampada a while for her review.
@sanskritisampada  Will provide files for your review via email.

I was feeling that I did not do a proper work this time, and it indeed turned out to be so.
Out of the 567 differences, I had erred at 327 places; and there were print errors at some of the remaining places.

Here is my revised file--
verses_03_deva (AB)-Rev.1.txt
With this, @funderburkjim might like to update the diff file(s) to Sampada to save her some time.

@Andhrabharati  Thank you for the revision.
There are now 251 lines with differences to resolve (316 less than before), according to boesp-3_deva_diff1_rev1.txt.
I have communicated the revised differences to Sampada.

all but about 20 resolved
Sampada has finished a next revision, based on review of  remaining 251 differences.
There are now 17 differences between versions of Sampada and Andhrabharati.
Relevant files are in step4a3 directory .
Request  @Andhrabharati  and  @sanskritisampada to review the boesp-3_sam2_comments.txt file.
I have indicated my opinion in the 17 'PREFER' and 4 'USE' comments in this file.
Request AB/Sampada to add comment in this issue indicating any disagreements with
my choices.
When these differences are resolved, I'll install the proofed boesp volume 3 verses.

<info L="4771.1" page="3.26" gtypes="HS"/>

; AB text is wrong here.

<info L="4927" page="3.61" gtypes="S,D,F"/>

; मूलभृत्यापराधेन is discussed at the FN, so no change needed in the main text.
; AB version has नागन्तून्प्रतिमानयेत् only, as per the book.

Verse 5226.1: difference at line 4

; Go with <s>Bintte</s> as suggested.

Verse 5268: difference at line 4
in print, Devanagari of first word hard to dissect.

; AB text is wrong here.
Here is what the font shows for the words--

And the scan has

<info L="5306" page="3.135" gtypes="S,D,F,V5"/>

; Here is what the scan has

<info L="5487" page="3.171" gtypes="S,D,F"/>

; AB text is wrong here.

<info L="5488" page="3.171" gtypes="S,D,F"/>

; Let's see how the font would have both words-

and compare with the scan

and finally, the Ind. Spr. verses are arranged alphabetically (wrt the starting words), and यावद्भ्रि comes after यावद्भा, but यावद्ध्रि would make it out-of-sequence.

<info L="5579" page="3.190" gtypes="S,D,F,V5"/>

; राचते is in the main text and the रोचते (as a v.l. form) is discussed at the FN. So, better to go with the main text as is (as in the Boethlingk's ed. of Bhartrhari)

<info L="5689" page="3.210" gtypes="S,D,F"/>
... ...
<s>spfhyanti</s>  is not a known verb form.

; The scan has it as

It appears that स्पृहयन्ति is mostly occurring in Vedic texts; so it is a Vedic verb-form, not a classic type.

<info L="5710" page="3.215" gtypes="S,D,F"/>

; The scan has it as

<info L="6049" page="3.290" gtypes="S,D,F,V5"/>

; Go with the non-spaced option.

<info L="6249" page="3.333" gtypes="S,D,F"/>

; The scan has it clearly as

<info L="6401" page="3.363" gtypes="S,D,F,V5"/>

;  Just see what the scan has

Verse 6842: difference at line 4

; Just see what the scan has

comments from Sampada
Sampada added comments to the previous comment file.
This is in boesp-3_sam2_comments_final.txt. (additional comments marked 'sam:')
Sampada agrees with the 'Jim prefer' solutions, except for one case 7223.1, where the question
is between suSoBante  and su SoBante.
Verse 7223.1: difference at line 4
<s>sTAnaBrazwAH suSoBante</s> s. den folgenden Spruch.
<s>sTAnaBrazwAH su SoBante</s> s. den folgenden Spruch.
I have not corrected acc to AB. I think this is a scan error.
Jim: PREFER <s>su SoBante</s>
  agrees with scan.
  <s>su</s> here used as adverb ('they shine well').
sam: I have not seen <su> as an adverb being written separately from the verb. It is usually written as prefix. Are there more such instances in boesp?
sam: I still think it should be <suSoBante>

Do @Andhrabharati or @drdhaval2785 have any comment on 'su' with verb forms?
BTW,  within our digitization of boesp,  the use of 'su' with verb forms is quite rare.
I find only 2 instances of ' su '   (su as separate word).  The current case and the verse this case refers to:
<S n="4157">
<s>pUgIPalAni pattrARi rAjahaMsAsturaMgamAH .</s>
<s>sTAnaBrazwAH su SoBante siMhAH satpuruzA gajAH ..</s>
</S>

There are a couple of cases where 'su' is prefixed to  an indeclineable 'ya' verb form:
99: <s>kzantavyameva tasyAhuH suparIkzya parIkzayA ..</s>
7100: <s>sucintya coktaM suvicArya yatkftaM</s>

Do @Andhrabharati or @drdhaval2785 have any comment on 'su' with verb forms?

Let Boethlingk himself answer this!!
Look at the PWG entry 'su'-

5710 scan
Here is the scan from my copy of volume 3 pdf (from @thomasincambodia ):

And, for easy comparison, here is AB's version from above

Note my scan more 'smudgy' than AB's.
Will use 'niyantendriya'.
In addition to scan evidence (clearer scan definitely shows 'niyant'),
there are a couple of words in mw spelled with 'niyant', e.g. 'niyantavya'.
So maybe 'niyanta' is a variant spelling of 'niyata', though this seems unlikely.
My best guess is that 'niyantendriya' is a print error.

separate su
Good reference supporting 'su' used as separate word!

That too as an adverb, to show to Sampada!

Thanks! Noted.
Regards
Sampada
On Wed, 10 Aug 2022 at 23:14, Andhrabharati @.***>
wrote:

That too as an adverb, to show to Sampada!
—
Reply to this email directly, view it on GitHub
https://github.com/funderburkjim/boesp-prep/issues/49#issuecomment-1211044769,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACTKJXZRMRNY7WGD2C6NQO3VYPS67ANCNFSM5LUIYNBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
"Faith,more faith!Faith in your possibilities,faith in the Power that is
at work behind the veil,and the offered guidance."            - Sri
Aurobindo

5268
yadDyayaM or yadvyayaM ?
I have changed opinion, and now think that yadDyayaM should be used.
Reason:  Alphabetical ordering of the shlokas:
5267 yadDAtrA ...
5268 yadDyayaM ...  In alphabetical order. But yadvyayaM would be out of order.
5269  yadDyAyati
Perhaps the sandhi analysis is 'yad hi ayam' ?

Final revision
I've made a resolution of the 21 pending cases.
(Note: all files mentioned in this comment are in step4a3 directory.)
The final (slp1) version of the verses is boesp-3_slp1_final_2.txt.
Only 7  (of the 21) generate changes to the Sanskrit verses in this final version, in comparison to the verses in verses_03_deva.AB.-Rev.1.txt.  Further details on the other 14 can be found in readme.txt starting at FINAL REVISION OF VERSES.
notes on the 7 changes
Request @Andhrabharati and @sanskritisampada  to review readme.txt at the section  THE 7 CHANGES MADE and make any further comments.
Probably verse 4927 should be given special attention, since I have used the printed form
mUlaBftyoparoDena but both AB and Sampada agree on mUlaBftyAparADena.
We are almost done with this exercise!

So maybe 'niyanta' is a legitimate spelling variation of 'niyata' ?

It is not a spelling variant; niyata is an adj. and niyantA is a noun.
niyatendriyA is 'having controlled senses' and niyantendriyA is (niyantA + indriyA) 'controller of the senses' or 'who controls the senses'.
The full context is--
"raTaH SarIraM puruzasya dfzwamAtmA niyantendriyARyAhuraSvAn"
SarIraM puruzasya raTaH dfzwam = SarIraM is puruza's raTaH (chariot) and AtmA niyantA aSvAn indriyA Ahuh = AtmA is the charioteer who controls indriyA, the horses.

Probably verse 4927 should be given special attention, since I have used the printed form
mUlaBftyoparoDena but both AB and Sampada agree on mUlaBftyAparADena.

I had mentioned thus already above--

<info L="4927" page="3.61" gtypes="S,D,F"/>

; मूलभृत्यापराधेन is discussed at the FN, so no change needed in the main text.

Probably it got skipped in Jim's reading.

yadDyayaM or yadvyayaM ?
Reason: Alphabetical ordering of the shlokas: 5267 yadDAtrA ... 5268 yadDyayaM ... In alphabetical order. But yadvyayaM would be out of order. 5269 yadDyAyati
Perhaps the sandhi analysis is 'yad hi ayam' ?

In fact, this was my original thought as well!

6119 AB concur? (meter requires 'samo')

This has skipped my eyes somehow.
Nothing to differ, the print is very clear.

5710
niyantA
@Andhrabharati  Thanks for explanation.  Now I see this is nominative singular of niyantṛ
4927
I did see your comment, but did not understand it.
mUlaBftyoparoDena  is the form used in the verse. @sanskritisampada  We leave it to the reader to take account of the footnotes.  (the typos in the footnote will
be a topic for another round of proofreading).
5268
yadDyayaM is being used.
Conclusion:  No additional changes needed in boesp-3_slp1_final_2.txt.
Will go ahead with installation.

installed
The revised verses now installed.
You can use this url to see current status of a given verse, e.g. verse 5710:
https://funderburkjim.github.io/boesp-prep/web1/boesp.html?5710
The xml form of the boesp digitization is in several transliterations, all in the step0 directory.

boesp.xml  slp1 -- the main form. Other forms derived from this
boesp_hk.xml  Harvard Kyoto transliteration
boesp_deva.xml  Devanagari
boesp_iast.xml  IAST transliteration

Closing this issue


Remove Task.String()

Either String() includes all Task fields or we just remove it ;-) I think the latter option just makes it easier to maintain in general.

:+1:

LGTM


[ Misc ] Refactor MoE to isolate Fp8 From Mixtral

MOTIVATION:

Prior to this PR, MoE layer + weight loading logic is repeated for all models
Prior to this PR, fp8 logic for MoE is coupled with Mixtral and unsupported for other MoE Models as a result
Prior to this PR, difficult to add other quantization methods without significant duplicated code in model files, which is very hard to maintain (e.g. made it hard to land #2761)

THIS PR:

Creates concept of FusedMoEMethodBase, UnquantizedFusedMoEMethod, Fp8FusedMoeMethod
Creates concept of FusedMoE layer (akin to MergedColumnParallel + RowParallel
Confirm correctness with lm-eval harness
Confirm able to use FusedMoELinear with Qwen2Moe

FOLLOW UP PR:

Support Fp8 checkpoints for models other than Mixtral: (weight loading for scales is currently overfit to Mixtral)
Convert other MoE models to use FusedMoELinear: to enable Fp8 for those cases
Finally integrate GPTQ / AWQ MoE kernels (#2761)

ACCURACY:

Mixtral

MODEL="mistralai/Mixtral-8x7B-Instruct-v0.1"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=4,distributed_executor_backend="ray" \
  --tasks gsm8k --num_fewshot 5 --limit 1000 --batch_size "auto"

main:
|Tasks|Version|     Filter     |n-shot|  Metric   |Value|   |Stderr|
|-----|------:|----------------|-----:|-----------|----:|---|-----:|
|gsm8k|      3|strict-match    |     5|exact_match|0.643|±  |0.0152|
|     |       |flexible-extract|     5|exact_match|0.648|±  |0.0151|

branch:
|Tasks|Version|     Filter     |n-shot|  Metric   |Value|   |Stderr|
|-----|------:|----------------|-----:|-----------|----:|---|-----:|
|gsm8k|      3|strict-match    |     5|exact_match|0.643|±  |0.0152|
|     |       |flexible-extract|     5|exact_match|0.648|±  |0.0151|

Qwen2 MoE

MODEL="Qwen/Qwen2-57B-A14B-Instruct"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=4,distributed_executor_backend="ray" \
  --tasks gsm8k --num_fewshot 5 --limit 1000 --batch_size "auto"

main:
Tasks|Version|     Filter     |n-shot|  Metric   |Value|   |Stderr|
|-----|------:|----------------|-----:|-----------|----:|---|-----:|
|gsm8k|      3|strict-match    |     5|exact_match|0.812|±  |0.0124|
|     |       |flexible-extract|     5|exact_match|0.834|±  |0.0118|

- branch:
|Tasks|Version|     Filter     |n-shot|  Metric   |Value|   |Stderr|
|-----|------:|----------------|-----:|-----------|----:|---|-----:|
|gsm8k|      3|strict-match    |     5|exact_match|0.810|±  |0.0124|
|     |       |flexible-extract|     5|exact_match|0.834|±  |0.0118|

Until we have the large models re-added to the CI, I run the following script offline:
TP_SIZE=4
FEWSHOT=5
LIMIT=250
BATCH_SIZE="auto"

# Mixtral
MODEL="mistralai/Mixtral-8x7B-Instruct-v0.1"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Mixtral - Quantized in place
MODEL="mistralai/Mixtral-8x7B-Instruct-v0.1"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray",quantization="fp8" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Mixtral - Quantized
MODEL="neuralmagic/Mixtral-8x7B-Instruct-v0.1-FP8"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray",quantization="fp8" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Qwen
MODEL="Qwen/Qwen2-57B-A14B-Instruct"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Qwen - Quantized in place
MODEL="Qwen/Qwen2-57B-A14B-Instruct"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray",quantization="fp8" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Llama3
MODEL="meta-llama/Meta-Llama-3-8B-Instruct"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Llama-3 Quantized in place
MODEL="meta-llama/Meta-Llama-3-8B-Instruct"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray",quantization="fp8" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

# Llama-3 - Quantized
MODEL="neuralmagic/Meta-Llama-3-8B-Instruct-FP8"
lm_eval --model vllm \
  --model_args pretrained=$MODEL,tensor_parallel_size=$TP_SIZE,distributed_executor_backend="ray" \
  --tasks gsm8k --num_fewshot $FEWSHOT --limit $LIMIT --batch_size $BATCH_SIZE

BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

@comaniac ready for re-review

This should be good to go.

Note that Qwen and Mixtral run in the CI at fp16
I ran the accuracy results for fp8 offline


bump versionist and thus yard CVE

Patches https://nvd.nist.gov/vuln/detail/CVE-2017-17042
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

It's a minor version bump that only includes the gem dep update.


Use user-provided private SSH key instead of self-generating one

This answer to Issue #36 (here) keeps the Terraform tfstate file from needing to store an unencrypted copy of a generated private key by exchanging a resource that allocates a private key with a data source that accepts an existing key as bound input.
Adds one new input variable, private_ssh_key_file, which defaults to ~/.ssh/id_rsa.

At this stage I do not want to deviate this part of behavior from other set of this series (azure and gcp processing)


[Feat] :  Adding Multi-Lingual Support to Rentalog

🚀 Pull Request
Description
This PR introduces multilingual support to the Rentalog web application, allowing users to interact with the platform in their preferred language. The implementation enhances the user experience and accessibility, ensuring that our application is more inclusive for a diverse audience.

Related Issue

Closes #267

Type of Change
What kind of change does this pull request introduce?

[x] 🚀 New feature

Screenshots (if applicable)
https://github.com/user-attachments/assets/7e2e5f45-5575-445c-a387-eae051487af5

Checklist
Please ensure the following tasks are complete before submitting the pull request:

[x] I have tested my changes and ensured they work as expected.
[x] I have added any necessary documentation or comments.
[x] I have checked the existing issues and pull requests to avoid duplicates.
[x] I have starred this repository.
[x] I have reviewed my code for best practices and readability.

my last PR had too many conflicts and i'm new to git so I created a new PR, please dont mind this


Fixes #140: Flattens file structure in components/

This PR does the following:

Flattens everything within src/react-components/src/components and updates their imports

Front End Review:

[ ] View sidebar in Storybook

Blocking #168 on this because uh, I ended up also having to resave every file when I did this. 😑
I did destroy some otherwise logical groupings in doing this, but stuff wasn't alphabetical in the sidebar otherwise.

@M0nica when you say linting issues, did you see any files that looked funky to you?

@M0nica when you say linting issues, did you see any files that looked funky to you?
[EDIT] Whoops, you meant that not all of the files have been linted. Working on that now!

Travis was complaining

src/tests/components/Dropdown-test.tsx:52:13
ERROR: 52:13   quotemark           ' should be "
src/components/UnorderedList/UnorderedList.stories.tsx:138:13
ERROR: 138:13  react-a11y-anchors  Links with the same HREF should have the same link text. First link at character: 9 line: 34
ERROR: 138:13  react-a11y-anchors  Links with the same HREF should have the same link text. First link at character: 9 line: 34

@M0nica ahhh, thank you! I'll wait for Travis to complete its current build and update accordingly

@M0nica ready for review again!


UI Snapshot Test: Contextual menu shows Fit-to-frame/Fill-frame

What
UI Snapshot Test: Contextual menu shows Fit-to-frame/Fill-frame
Why
https://skype.visualstudio.com/SPOOL/_workitems/edit/3045934
https://skype.visualstudio.com/SPOOL/_workitems/edit/3045935
How Tested

Process & policy checklist

[ ] I have updated the project documentation to reflect my changes if necessary.
[ ] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[ ] This change causes current functionality to break.

Duplicate PR: https://github.com/Azure/communication-ui-library/pull/2647


[Experimental] Add an option to flatten JSON array to each Embulk record for JSON Parser plugin

For #1102 and a follow-up of #1103
Usage
Sample JSON
[
  {"id": 1, "name": "Alice"},
  {"id": 2, "name": "Bob"},
]

Config YAML
in:
  type: ...
  parser:
    type: json
    __experimental__flatten_json_array: true

Result
+-------------------------+
|             record:json |
+-------------------------+
| {"id":1,"name":"Alice"} |
|   {"id":2,"name":"Bob"} |
+-------------------------+

Thank you for reviewing! Let me merge.


Spaces at end of file path of instanced objects don't get truncated

It seems that the added spaces at the end of the filename in my .i3dm file are not being truncated, causing Unreal to not find the specified object.
LogHttp: Warning: ProcessRequest failed. The URL '../../proto_0.glb       ' is not a valid HTTP request.
Padding is a recommended practice when generating .i3dm files, as can be found here: https://github.com/CesiumGS/3d-tiles/tree/62832c3d8294e2c530ac928f6ef4ccc62f4d176f/specification/TileFormats/Instanced3DModel#padding
Using Cesium for Unreal 2.6 with a instanced 3D-Tileset which is working outside of Unreal

Thanks @Doenerlord, that does sound like a bug to me. @timoore please let me know if you disagree.

This is actually bug in cesium-native, so I'm going to (try to!) transfer the issue to that repository.


opensearch-py client and enable llama-index's MetaFilters.  Use appro…

…x-knn when no filters, and use painless-scripting method when there are (pre-)filters.
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #7004
Type of Change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] I stared at the code and made sure it makes sense
[x] I manually tested against my own aws opensearch instance and some test data, similar to the opensearch notebook in llama index.

Suggested Checklist:

[x] I have performed a self-review of my own code

I have been trying this on a modified OpenSearchDemo notebook and am encountering an exception.  Probably shouldn't merge yet.

I demoed the filters in the OpenSearchDemo notebook and addressed the linting  issues.  I have tested this with my AWS OpenSearch service instance, but not with the docker instance as written in the notebook.
I also modified the filters so that you can do full-featured filter-context queries as documented at https://opensearch.org/docs/latest/query-dsl/query-filter-context/

@logan-markewich Hopefully this is ready enough now

@logan-markewich Hopefully this is ready enough now

looks like still some small lint issues 😅  I can try to fix and land this tomorrow morning.


updates for week 5 Text2SQL

Project
Text2SQL
Changes
Add updates for week 5

@Apoorvgarg-creator Kindly have a look


Adds support for emp3-mirror-cache - feed injection

see #68

[core] Disabled previous mirrorcache functionality.
[api] Added mil.emp3.api.MirrorCache to support integrations with emp3-mirror-cache services.
[api] Overloaded EMP_Exception constructor to accept a Throwable.
[test] Updated test-basic to enable testing of MC features.
[test] Added input dialog when plot testing 'Many Units'.
[build] Moved travis scripts to gradle directory.
[build] Removed some 'empty' projects from appearing in IDE.
[build] Unlinked MirrorCache projects from build; updated dependencies accordingly.
[build] Removed projects from build: test-validator, test-mirrorcache-standout, test-mirrorcache-joystick, test-mirrorcache-echo.

162 files? It looks like this was used to remove the validator also?

Yes, among other projects. From the notes above:

[build] Removed projects from build: test-validator, test-mirrorcache-standout, test-mirrorcache-joystick, test-mirrorcache-echo.


Go SDK

Is your feature request related to a problem? Please describe.
As of now, Trigger.dev only support JS-SDK. Please add support for Go SDK as well.
Describe the solution you'd like to see
_
Describe alternate solutions
Use built-in Go routines
Additional information
No response

This would be really cool and we definitely will expand beyond TypeScript/JavaScript.
But I want to manage your expectations: it won't be this year.
The SDK isn't a thin client because it needs to do more than just API calls. So adding and maintaining new languages is a lot of work. It doesn't make sense to add languages when v3 is quite early and lots of features are being added. It's far easier to add languages a bit later.


Support for Anvil recipes?

There is no such thing as anvil recipes.
The anvil uses an event system, so for example, to "remove" an anvil recipe, you can do:
CTEventManager.register<MCAnvilUpdateEvent>(event => {
    if <item:minecraft:diamond_sword>.matches(event.left)
        event.cancel();
});

Which will remove any anvil thing with a diamond sword in the left slot.
You can read more about the event here
https://docs.blamejared.com/1.16/en/vanilla/api/event/MCAnvilUpdateEvent/
And if you need any help with it, you can ask here:
https://discord.blamejared.com


Made ALM::*system private

The publich members of Interaction, Fcs, ..., classes are better to be private.
Implemented getters in ALM class to move *system public variable to private. In fact, it may not be a good idea to implment too many getter for each detailed parameter. But this is tentatively necessary to do.

Thanks for the changes.


[WIP] Ignoring pre-release status when checking against resolved packages

Ignoring pre-release status of a new requirement when checking it against packages that have already been resolved. #2471
The thinking is that if something dragged in a pre-relase version (e.g. the dependencies file) then we actually want pre-release of that package.
In my testing this seems to work. Even if the pre-release status is ignored in IsInRange(), the actual pre-release versions are still compared, so a requirement ">=2.0" will fail if a resolved package has version "2.0-pre". Could use some checking from someone who knows the code better though.

I want to add some test-cases to this before we merge it :)

The one from https://github.com/fsprojects/Paket/issues/2471
At least one where we ensure that we don't pull prereleases from unrelated space of the search tree
At least one where we have the same conflict on transitive packages
Maybe more.

We can add these to the resolver unit tests...

@zzdavid I think it's not 100% correct. I pushed to your fork (github allows that) to extend your PR. see 08dec38

pushed @stift's tests

@forki if I read the change correctly, you only allow pre-release on packages in the dependencies file? Might that not be too limiting? I was actually happy to allow pre-release unconditionally here since it has already been resolved. We're only checking if the new requirement is ok here, so the proper thing to do is to trust that the resolution is correct and check the version as it is.
Just want to raise the question. If you say this is the way it should be, I'll take your word for it :)

@zzdavid yes it's actually needed to restrict it. Otherwise you will end up with following situation:
depsfile:
nuget A

resolution goes:
A 1.1 (deps: B >= 0 prerelease)

A 1.1
B 1.1-alpha (deps: C >= 0 prerelese)

A 1.1
B 1.1-alpha (deps: C >= 0)

A 1.1
B 1.1-alpha
C 1.2 (deps: B >= 0)

^^ this would be valid with your change, but I think it should not

@forki It looks like a bug in package A (without prerelease) if it depends on a prerelase of B. With package A in pre-relase it makes sense.
nuget A alpha

with the resolution
A 1.1-alpha (deps: B >= 0 prerelease)
B 1.1-alpha
C 1.2 (deps: B >= 0)

The resolution looks correct to me, at least if A and B are developed together, and worked in 4.8.8 but will fail now.

Ok let's say D introduces the B >= 0 restriction. Doesn't matter - point is something later can still need it


[FEATURE] Documentation for dependencies

First check

[x] I added a very descriptive title to this issue.
[x] I used the GitHub search to find a similar issue and didn't find it.
[x] I searched the FastAPI documentation, with the integrated search.
[x] I already searched in Google "How to X in FastAPI" and didn't find any information.
[x] I already read and followed all the tutorial in the docs and didn't find an answer.
[x] I already checked if it is not related to FastAPI but to Pydantic.
[x] I already checked if it is not related to FastAPI but to Swagger UI.
[x] I already checked if it is not related to FastAPI but to ReDoc.
[x] After submitting this, I commit to:

Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
Or, I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
Implement a Pull Request for a confirmed bug.

Example
Here's a self-contained minimal, reproducible, example with my use case:

from fastapi import FastAPI, APIRouter, Depends, HTTPException, status

app = FastAPI()
router = APIRouter()

def get_token() -> str:
    raise HTTPException(status.HTTP_401_UNAUTHORIZED)

@router.get("/foo")
async def foo(token: str = Depends(get_token)):
    return {"text": "I can raise 401"}

@router.get("/bar")
async def bar():
    return {"text": "I do not raise anything"}

app.include_router(router)

Description
Since dependencies can interfere request processing (raising exceptions), I think that it's an oversight that they can not contribute to generated documentation.
There are 2 possible solutions to document 401 response here:

define  it in APIRouter():
This is not sufficient because /bar will have it too even though it will never return this code.
copypaste same responses everywhere where get_token is used:
This will work with 2 endpoints, but not with 200.

The solution you would like
My suggestion is to add an optional dependency decorator with some subset of endpoint/router parameters to customize documetation:
from fastapi import FastAPI, APIRouter, Depends, HTTPException, status
from fastapi import dependency  # new inport

app = FastAPI()
router = APIRouter()

@dependency(
    responses={status.HTTP_400_BAD_REQUEST: {"description": "Unauthorized"}}
)  # new decorator
def get_token() -> str:
    raise HTTPException(status.HTTP_401_UNAUTHORIZED)

@router.get("/foo")
async def foo(token: str = Depends(get_token)):
    return {"text": "I can raise 401"}

@router.get("/bar")
async def bar():
    return {"text": "I do not raise anything"}

app.include_router(router)

Implementation details

This can be implemented by adding some magic variable like __fastapi_dependency_settings__ to function with decorator.
If nested dependencies define conflicting status code (or endpoint itself define conflicting response status), top one should be used.
This solution is fully backwards compatible. Not sure about dependency decorator name though.

@tiangolo Any idea on this one ? Maybe another way to do it ?
Or if you are ok with the idea, I can try to implement it.

This is pretty much exactly the thing I'd want to see in FastAPI. The most common thing that annoys me with FastAPI is that to get responses in the OpenAPI documentation I need to add them manually to the responses, and there are no real options for how to make it happen automagically. I was considering some sort of metaprogramming options with decorators, trying to figure out what router the route is attached to and modifying it, but this would seem like a much more reasonable resolution. The main goal of documenting response types for dependencies is accomplished neatly here, and it would not really change the existing code while providing new optional functionality. This should of course be supported also on @router.get("/foo", dependencies=[Depends(get_token)])


Build samples for Android.

Hi I building drishti with following parameters for Adnroid under Linux:
export PATH=~/develop/drishti/polly/bin:~/develop/tools/cmake/bin:$PATH
export ANDROID_NDK_r10e=~/develop/tools/android-ndk/android-ndk-r10e
bin/drishti_build.sh android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections Release --strip
File content of drishti_build.sh:
ARGS=(
--toolchain "${TOOLCHAIN}"
--config "${CONFIG}"
--verbose
--ios-multiarch --ios-combined
--fwd ANDROID=TRUE
DRISHTI_BUILD_SHARED_SDK=YES
DRISHTI_BUILD_TESTS=NO
DRISHTI_BUILD_EXAMPLES=YES
DRISHTI_COPY_3RDPARTY_LICENSES=ON
GAUZE_ANDROID_USE_EMULATOR=NO
HUNTER_CONFIGURATION_TYPES="${CONFIG}"
HUNTER_SUPPRESS_LIST_OF_FILES=ON
--archive drishti
--jobs 2
--test
"${INSTALL}"
)
polly.py ${ARGS[@]} --reconfig
The first what I want - build examples for android (*.apk).
In build result I have a several *.elf files for ARM architecture (_install/drishti_eye, etc), and I don't find *.apk files.
I think, may be I should switch-on tests by DRISHTI_BUILD_TESTS=YES, but test failed in my device.
chunk of tests log:
1: [----------] 2 tests from HCITest
1: [ RUN      ] HCITest.RunTestCPUAsync
1: /home/gera/develop/drishti/drishti/src/lib/drishti/hci/ut/test-drishti-hci.cpp:199: Failure
1: Expected: (monitor.getFaces().size()) > (0), actual: 0 vs 0
1: [  FAILED  ] HCITest.RunTestCPUAsync (1780 ms)
1: [ RUN      ] HCITest.RunTestGPUAsync
1: /home/gera/develop/drishti/drishti/src/lib/drishti/hci/ut/test-drishti-hci.cpp:199: Failure
1: Expected: (monitor.getFaces().size()) > (0), actual: 0 vs 0
1: [  FAILED  ] HCITest.RunTestGPUAsync (1380 ms)
1: [----------] 2 tests from HCITest (3160 ms total)
1:
1: [----------] 2 tests from EyeSegmenter
1: [ RUN      ] EyeSegmenter.StringConstructor
1: [       OK ] EyeSegmenter.StringConstructor (199 ms)
1: [ RUN      ] EyeSegmenter.StreamConstructor
1: [       OK ] EyeSegmenter.StreamConstructor (195 ms)
1: [----------] 2 tests from EyeSegmenter (394 ms total)
1:
1: [----------] 6 tests from EyeSegmenterTest
1: [ RUN      ] EyeSegmenterTest.EyeSerialization
1: [       OK ] EyeSegmenterTest.EyeSerialization (950 ms)
1: [ RUN      ] EyeSegmenterTest.ImageEmpty
1: [       OK ] EyeSegmenterTest.ImageEmpty (944 ms)
1: [ RUN      ] EyeSegmenterTest.ImageTooSmall
1: [       OK ] EyeSegmenterTest.ImageTooSmall (925 ms)
1: [ RUN      ] EyeSegmenterTest.ImageValid
1: [       OK ] EyeSegmenterTest.ImageValid (4007 ms)
1: [ RUN      ] EyeSegmenterTest.ImageIsBlack
1: [       OK ] EyeSegmenterTest.ImageIsBlack (937 ms)
1: [ RUN      ] EyeSegmenterTest.ImageIsWhite
1: [       OK ] EyeSegmenterTest.ImageIsWhite (936 ms)
1: [----------] 6 tests from EyeSegmenterTest (8700 ms total)
1:
1: [----------] 1 test from FaceTest
1: [ RUN      ] FaceTest.RunSimpleTest
1: [       OK ] FaceTest.RunSimpleTest (2818 ms)
1: [----------] 1 test from FaceTest (2818 ms total)
1:
1: [----------] Global test environment tear-down
1: [==========] 29 tests from 12 test cases ran. (30617 ms total)
1: [  PASSED  ] 27 tests.
1: [  FAILED  ] 2 tests, listed below:
1: [  FAILED  ] HCITest.RunTestCPUAsync
1: [  FAILED  ] HCITest.RunTestGPUAsync
1:
1:  2 FAILED TESTS
1: 1
1: *** END ***
1: CMake Error at _3rdParty/gauze_test/DrishtiTest.cmake:228 (message):
1:   Command exits with error code: 1
How I can get a samples with drishti demo (*.apk) for run it in my android device?

If you add DRISHTI_BUILD_QT=ON to the CMake option list (in polly it is polly.py ... --fwd DRISHTI_BUILD_QT=ON) it will enable the Qt package and the facefilter application.  Note: The Qt package can take a long time to build.  That will also enable the real-time facefilter sample application.  Before you run, you will have to add an entry to the config file for the basic intrinsic camera parameters using a name corresponding to the ID (according to Qt) of your device/camera.
See:
https://github.com/elucideye/drishti/blob/a7f42af6bf1c6e367ff400b79c27c96967d72886/src/app/qt/facefilter/facefilter.json#L62-L78
    "front": {
        "description": "Front-facing camera",

        "sensor": {
            "intrinsic": {
                "size": {
                    "width": 2560,
                    "height": 1440
                },
                "principal": {
                    "x": 1280.0,
                    "y": 720.0
                },
                "focal_length_x": 1000.0
            }
        }
    },

I'm not sure why your tests are failing.  The same tests should run on the emulator during CI builds.  What device are you using?

Thanks for answer! Today I try to do it. I using Alcatel 5010D (PIXI 4), before test I enable debug by USB in device.

Hi, I add DDRISHTI_BUILD_QT=ON, but now I have a following bug:
Building Android package using ant.
Using ant: /home/gera/develop/tools/apache-ant/bin/ant
Buildfile: /home/gera/develop/drishti/drishti/_builds/android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections-Debug/src/app/qt/facefilter/build.xml

-set-mode-check:

-set-debug-files:

-check-env:
 [checkenv] Android SDK Tools Revision 25.2.5
 [checkenv] Installed at /home/gera/.hunter/_Base/32f280c/3ce59a5/a5d4092/Install/android-sdk

-setup:
     [echo] Project Name: QtApp
  [gettype] Project Type: Application

-set-debug-mode:

-debug-obfuscation-check:

-pre-build:

-build-setup:
[getbuildtools] Using latest Build Tools: 22.0.1
     [echo] Resolving Build Target for QtApp...
[gettarget] Project Target:   Android 4.4.2
[gettarget] API level:        19
     [echo] ----------
     [echo] Creating output directories if needed...
     [echo] ----------
     [echo] Resolving Dependencies for QtApp...
[dependency] Library dependencies:
[dependency] No Libraries
[dependency]
[dependency] ------------------
     [echo] ----------
     [echo] Building Libraries with 'debug'...
   [subant] No sub-builds to iterate on

-code-gen:
[mergemanifest] Found modified input file
[mergemanifest] Merging AndroidManifest files into one.
[mergemanifest] Manifest merger disabled. Using project manifest only.
     [echo] Handling aidl files...
     [aidl] Found 2 AIDL files.
     [aidl] Compiling 2 AIDL files.

BUILD FAILED
/home/gera/.hunter/_Base/32f280c/3ce59a5/a5d4092/Install/android-sdk/tools/ant/build.xml:649: The following error occurred while executing this line:
/home/gera/.hunter/_Base/32f280c/3ce59a5/a5d4092/Install/android-sdk/tools/ant/build.xml:655: Execute failed: java.io.IOException: Cannot run program "/home/gera/.hunter/_Base/32f280c/3ce59a5/a5d4092/Install/android-sdk/build-tools/22.0.1/aidl" (in directory "/home/gera/develop/drishti/drishti/_builds/android-ndk-r10e-api-19-armeabi-v7a-neon-hid-sections-Debug/src/app/qt/facefilter"): error=2, file is missing.

But I after this bug I saw directory and aidl exist.

Sorry for the delay.  It's hard to know what's going on based on that log.  This is using ant based command line apk packaging to facilitate deploying on the device.  The CMake module is here:
https://github.com/hunter-packages/android-apk
There are some small apk packaging sample projects which use this that might be worth testing on your setup + device to help debug the issue you are facing (I suspect you are probably quite close to being able to run):
https://github.com/forexample/android-cmake
That said, since ant has been removed from recent Android Studio releases, and CMake is now a first class citizen, this stuff will be dropped for facefilter in the near future in favor of an official Gradle + CMake build.  The latest Android Studio 3.2 Canary 4 now supports use of standard/external/non-bundled CMake > 3.7, which makes this project buildable in Android Studio through CMake (https://github.com/forexample/android-studio-with-hunter).
Qt itself will also be dropped in the near future in favor of lightweight native iOS and Android facefilter projects, which should be much faster for this build-from-source project.  The facefilter demo is the one part that isn't covered by CI builds, due to Qt build times, so moving to native projects should also make that possible.

Hi, just wondering if there is anything to report on the Qt-free facefilter app? We are evaluating Drishti for a project, but finding it slow going as we are new to CMake, etc.
Any general tips on how to speed up builds in general, or whether we'd be foolhardy to try to de-Qt-ify the app ourselves?
Thanks...

Hi Ted.

just wondering if there is anything to report on the Qt-free facefilter app

Not yet.  (I'm assuming you are targeting Android based on this issue's title.)  I've been busy with some other work lately.  I don't think the external/standard CMake support in Android Studio has made it out of the Canary channel yet.  That is kind of a prerequisite for using Hunter, so I wouldn't add the native stuff until that functionality is stable.

Any general tips on how to speed up builds in general,

This project uses Hunter, so all dependencies will be cached, which means your build will radically reduce after your first end-to-end build, as you'll only be building your in-repo code at that point.  You can also configure a network/server cache to share between users, but I wouldn't recommend that until you are more familiar with Hunter.  If you build with polly you can also experiment with --jobs N to try to speed things up.
There can be a learning curve for CMake, but IMHO the effort is well worth it.  Ruslo maintains a nice modern CMake overview that is worth a read here: https://cgold.readthedocs.io/en/latest/
I'm not sure what problems you are facing, but the .travis.yml and appveyor.yml scripts can serve as a functioning build reference.  If you have more specific questions I can try to help.  There is also a gitter channel for Hunter specific questions where people are typically very helpful.

or whether we'd be foolhardy to try to de-Qt-ify the app ourselves?

The main challenge for mobile (iOS + Android) is handling the input camera -> GPU feed efficiently.  This assumes real-time performance and/or per frame rendering/VR/AR is critical for your application.  For iOS platforms, this is supported by the iOS texture cache (as implemented in GPUImage(2)).  In recent Android releases, this is handled in the Java layer through Camera 2 + SurfaceTextures.  If your team is familiar with this stuff, it might not be a significant effort, otherwise it could take a few weeks.
Sorry I don't have a more concrete timeline for the Qt replacement.  I just need to find enough weekend/evening time to make it happen, which can be harder in Summer :)  I'll be sure to post updates here.

Hi David - I'm actually working in iOS, but happened across this thread because I was trying to figure out how to build the Qt app.
We'll stick with the Qt code for now - BTW, I ran into a known Qt issue when building for ios 11.3, which is documented here, in case that helps someone: https://wiki.qt.io/Qt_5.9.5_Known_Issues
Anyway, thanks for your help!

Hi - Any advice on how to go about getting the intrinsic camera parameters and device ID for QT to add to the json file? I'm new to QT and I've been having trouble finding clear directions. Thanks!

see #701, src/examples/facefilter/android-studio should build as a standard android project (requires 3.2 beta for external cmake support)


Yobiiq EM4301 data converters

Hi @artem-barysh-dev
Please don't merge this converter yet. There is a bug in the decoder.
I will fix it before


Error during connection

Hello,
first of all I want to thank you for this container, we are using it since a couple of years and it works pretty well.
We are having a problem with the last update, when we try to connect to the server it says "500 OOPS: failed to open xferlog log file:/var/log/vsftpd/vsftpd.log".
Deleting /var/log/vsftpd/vsftpd.log solves the problem.
Thank you again

Hi!
Thank you very much, I'm glad you find this useful. Fixed xferlog_std_format.
Cheers!


Log says rip was successful but no rip exists (UHD)

I guess the simple question is, does this support 4K UHD disks?
I just set up the docker container on a machine running UNRAID. I insert a disc and it gets picked up and after only a few seconds later it says the job is done and ejects the disk.
06.07.2021 13:32:57 : BluRay detected: Saving MKV
renamed '/out/Ripper/BluRay/BABY_DRIVER' -> '/out/Ripper/BluRay/finished/'
06.07.2021 13:33:09 : Done! Ejecting Disk

This is a 4K UHD disk. My blu ray drive has firmware which can read these (previously used on a windows machine). I tried with a standard bluray and it has been on Saving MKV for about 10 minutes which I assume means it's actually working.

I suspect this may have something to do with the encryption key for the disk. I tried an makemkv only container and got an 'unknown volume key' error for this disk.
Tried another UHD disk in the docker-ripper container and it had the same behavior (indicated success after a few seconds) but this one seems to be running fine through the makemkv decryption process.
At this point not sure if this is a bug per se or just a lack of having the language in logging to indicate the decryption failed (if in fact this container is even configured to handle decryption of UHD)

This likely is a makemkv issue.


Add ECS Fargate Integration

What does this PR do?
Adds ECS Fargate task integration for APM, Logging, and infrastructure monitoring via the DD Agent and Fluenbit
Motivation
Wanted a standard, easy solution for adding Datadog integration to a Fargate task

Testing Guidelines
Not yet tested. Wanted to see if this is a PR that would be accepted before completing it.
Additional Notes
Happy to complete this if you guys are interested in accepting it.
Types of Changes

[ ] Bug fix
[X] New feature
[ ] Breaking change
[ ] Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

[ ] This PR's description is comprehensive
[ ] This PR contains breaking changes that are documented in the description
[ ] This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
[ ] This PR impacts documentation, and it has been updated (or a ticket has been logged)
[ X] This PR's changes are covered by the automated tests
[ ] This PR collects user input/sensitive content into Datadog

Closes #105

@astuyve Bump?

hi @automartin5000 - thanks for reaching out. The Datadog CDK construct spans multiple teams internally here at Datadog, so I've reached out to the team which owns Fargate for feedback on this PR.
Thanks!

Thanks!

Any update? 😄

Hi @clamoriniere, is your team the best team to review this PR?

Hi @automartin5000
@levan-m's team is the team responsible for this repository.

FWIW, I've now rewritten this code several times  in the couple years since this was opened 😅 and think I have it down pretty well to easily update here if desired.

@automartin5000, appreciate your contribution and sorry we weren't able to review it so far. Unfortunately Container Ecosystems team has not been investing in CDK support and lack the expertise to properly evaluate and review this change.
I would suggest we keep the PR open in case CDK gets prioritized in the future.


OpenAPI: update openapi_generated.go to support TTLSecondsAfterFinished

Signed-off-by: JetMuffin<EMAIL_ADDRESS>

This change is

/ok-to-test
/lgtm
/approve
Thanks for your contribution!

Coverage decreased (-0.07%) to 58.08% when pulling 6dad5676238aa2fea117abfd1783e77adb53c20c on JetMuffin:openapi into bb430c980ad03b187a5de607dc12503250ec8200 on kubeflow:master.

Coverage decreased (-0.07%) to 58.08% when pulling 6dad5676238aa2fea117abfd1783e77adb53c20c on JetMuffin:openapi into bb430c980ad03b187a5de607dc12503250ec8200 on kubeflow:master.

/retest

/retest

/retest

/retest :joy:

/retest

INFO|2018-08-03T04:10:33|/src/kubeflow/testing/py/kubeflow/testing/util.py|62| level=error msg="handle object: merging object with existing state: unable to recognize \"/tmp/ksonnet-mergepatch290154148\": no matches for kind \"Workflow\" in version \"argoproj.io/v1alpha1\""
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/src/kubeflow/testing/py/kubeflow/testing/run_e2e_workflow.py", line 344, in <module>
    final_result = main()
  File "/src/kubeflow/testing/py/kubeflow/testing/run_e2e_workflow.py", line 334, in main
    return run(args, file_handler)
  File "/src/kubeflow/testing/py/kubeflow/testing/run_e2e_workflow.py", line 222, in run
    util.run(["ks", "apply", env, "-c", w.component], cwd=w.app_dir)
  File "/src/kubeflow/testing/py/kubeflow/testing/util.py", line 74, in run
    " ".join(command), process.returncode), "\n".join(output))
subprocess.CalledProcessError: Command 'cmd: ks apply kubeflow-tf-operator-presubmit-v1-769-6dad567-916-133a -c workflows exited with code 1' returned non-zero exit status 1

@jlewi Do you have any idea about the issue? I think it is not caused by the PR.

/retest


Dockerfile build [production-stage 4/8] COPY --from=0 build/dist /usr/share/nginx/html

I get this when building with Docker:
[production-stage 4/8] COPY --from=0 build/dist /usr/share/nginx/html

Any ideas?

Sure I can do that. I think I got it working but need to test on my cluster. Do you fancy a helm chart within its own directory within the project or is that better to be kept in a seperate repo?

Let's say, one is deploying into Kubernetes and one's external domain would be myapi.example.de on Port 80.
Could you kindly give an example for BASE_URL and server-url in RAPIDOC_OPTIONS?


request additional api function for getting finer-grained time step information

in my application, I have a need to know when the next time step boundary will occur, and for what reason. Epanet tracks this internally, but it mutates some internal data when doing so. proper implementation would not mutate the data structure but just return the time horizon for informational purposes.
possible reasons for time stepping are:

report time step boundary
hydraulic time step boundary
water quality time step boundary
tank fill/empty event
rule- or control- based event (time/level)

This would be a great addition, potentially including this information as an output into the full report would be beneficial for users of the GUI.
Early in the calibration of a model, if something isn't set correctly, the first way you know is because of excess timesteps, and currently you need to go through each asset to find out what's causing it (typically a full or empty tank)


[FEATURE] Adding chatbot prompts to require name and email for user

Hi,
I'd like to have the chat collect user name and email address prior to answering any user questions.
Could I do this by modifying (from https://github.com/FlowiseAI/FlowiseChatEmbed#configuration):

You can try using Zep Memory

When detected a new user you can use a new Session Id in Additional Parameters for it to act like a new conversation

After that you can use Zapier NLA tool to record it into anywhere you want
The docs on how to use Zapier NLA
Flowise Example: #114

I'm interested in this feature, too. I use pabbly connect for my integrations.

Hi @mmhurston,
Flowise PR 715 currently in progress.

PR - https://github.com/FlowiseAI/Flowise/pull/1948 in work


Rename to align with IFS

IFS contains the "at_final_destination_" as part of the name - so renaming them here to align...

Based on our naming convention, it would have to end on date because it is a date.


Drop down height of nimble-select fixed to 350px instead of full available height

🐛 Bug Report
In previous version of nimble-select (<26.0.0 and Angular 17) the drop down of the nimble-select would take the full available height till browser bottom border, since version 26.0.0 (oder little bit older, i dont know exactly) the drop down height is fixed to 350px and i see no possibilities to change it
💻 Repro or Code Sample
Open your Storybook and select under slots "Many options", then open the select drop-down
https://nimble.ni.dev/storybook/?path=/docs/components-select--docs
🤔 Expected Behavior
The drop down sould take the full available height till browser bottom border
😯 Current Behavior
The drop down is limited to 350px
💁 Possible Solution
🔦 Context
Seems to been seen first after Angular update and version 26.0.0 of @ni/nimble-angular.
The behavior is correct with version 24.4.6 of @ni/nimble-angular.
🌍 Your Environment

OS & Device: Windows 10
Browser: Edge version 127, Firefox version 127

@PetitCalgon there was an intentional change to limit dropdown heights to 10.5 items, see: https://github.com/ni/nimble/issues/1870
The intention is that for a large set of options (>15) that the select is configured as filterable to enable quick navigation / inspection of large sets: https://nimble.ni.dev/storybook/?path=/docs/components-select--docs
And very large sets enable dynamic filtering and showing only partial sets: https://nimble.ni.dev/storybook/?path=/docs/components-select--docs#dynamic-options
Those are the expected workflows for managing large sets of options. Do those cover the workflow you are implementing? If not can you give details into how your workflow differs?

Thank you.
Our usecase is little bit different.
We use the nimble-select (and never the combobox) for medium list (about 25 items)
Two worklows:

a list of date intervals (a selection of week, months, quartals)
a list of jupyter notebooks (grouped with nimble-list-option-group)

For larger list with runtime values (for example batches, serial numbers, etc.), we have a nimble-drawer with a textbox to filter the entries and for every entry a checkbox or radio button (for multi/single choice) + buttons ok/cancel
Displaying only 10 1/2 items in my intervals / jupyter notebooks list is unclear for our users.
Is ther a way to change the height, or giving me the possibility to choose which height I want, standard (=10 1/2 items), big (~ 20/21 items), no limit ?

Displaying only 10 1/2 items in my intervals / jupyter notebooks list is unclear for our users.

Can you give screenshots and explain why it is unclear?
In addition some things to consider:

the list does scroll so users can scroll to their need option
long lists by default mean lots of mouse travel for users when many options are shown
the window can be various sizes as set by the user, and the select dropdown will only fill the space available. So it should clear that more options are available regardless of current window size. All 20+ items will not be visible in a small window / mobile window.
for a list of 25 items filtering should be enabled. Particularly for a list of intervals with a known structure, I'd hope users can quickly filter the list in a couple characters. Typing "3/" or "Mar", etc to filter quickly, etc

Hello Raj,
I'm sorry "unclear" is the wrong translation, i meant something like too few items are displayed.
Here are some screenshot for you:
Old select dates version with long list

Versius new select dates version with short list:

Same for old jupyter notebooks (with own CSS style for grouping, older version where nimble-group-item was not available)

Versius new version

Don't forget, that the users (for example managers) are pretty bad UX user, they can't assimile the difference between a combobox, an auto-complete and a select.
With the old version of the select, in 2 mouse-click, they would have select the notebook or the wanted date intervall.
With your solution and autocomplete / filter, they would have to click on the combo, delete the text (with delete key, or better right key and countless backspace till everything is gone), then would type something, choose it with the mouse ...
So 2 mouse-click or countless keystrokes?

@PetitCalgon Thank you for showing some screenshots. Neither of your new version examples demonstrate the above recommendation of enabling filter-mode: standard for the select for large sets of options.
We do believe that for both of these use cases enabling filtering on the select (not switching to a combobox, etc) will give a consistent user experience across NI products for selecting an option amongst a large list of options. If you are employed at NI / Emerson I'd recommend reaching out to @fredvisser to discuss the use-cases further and to share your application with the Nimble team so we are aware of your designs / use-cases.

We'll give it a try, but please provide an option to localize the "Search" placeholder
<input class="filter-input" aria-controls="listbox-1" aria-activedescendant="option-27" placeholder="Search" value="">
Our application has english, german, french and japanese languages.

Specifically for the search field localization see configuring the "filter search" text configuration in the docs Meyers referenced: https://nimble.ni.dev/storybook/?path=/docs/tokens-label-providers--docs
Also @PetitCalgon if you are an NI employee, please reach out to @fredvisser on teams to make sure you're added to the NI org on GitHub and to introduce yourself and your app. Thanks.

I'm not an NI employee, I'm an Hensoldt employee in Germany working with SystemLink and writing plugins for SystemLink.

I'm not an NI employee, I'm an Hensoldt employee in Germany working with SystemLink and writing plugins for SystemLink.

Ah, good to know and welcome! 🎉


An internal compiler expectation was broken: region @17-6 not in list of dbgs

$ roc dev

An internal compiler expectation was broken.
This is definitely a compiler bug.
Please file an issue here: https://github.com/roc-lang/roc/issues/new/choose
thread 'main' panicked at 'region @17-6 not in list of dbgs', /Users/m1ci/actions-runner2/_work/roc/roc/crates/repl_expect/src/run.rs:521:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

app "hello"
    packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.5.0/Cufzl36_SnJ4QbOoEmiJ5dIpUxBvdB3NEySvuH82Wio.tar.br" }
    imports [pf.Stdout]
    provides [main] to pf

main =
    dbg
        T (Str.split simple1 "\n\n")

    Stdout.line
        """
            Part 1: TODO
            Part 2: TODO
        """

simple1 =
    """
    1000
    2000
    3000

    4000

    5000
    6000

    7000
    8000
    9000

    10000

    """

Environment info:
roc nightly pre-release, built from commit 3d8884a96d4 on Fri Nov 24 09:18:30 UTC 2023
Apple M1 Max
macOS Sonoma 14.1.1

I managed to run the roc compiler in debug mode and found that the error is thrown here:
https://github.com/roc-lang/roc/blob/ef39bad7c61983f2329a11d2d23f7d038215c9d7/crates/repl_expect/src/run.rs#L521

I updated to basic-cli 0.7.0 and recompile from source, and now I get another error:
ld: Undefined symbols:
  _roc_dbg, referenced from:
      _#UserApp_main_d394208415ac8fe0ce8aa0ddf6a845c7cc74d818698e3d25c85705ce311f5ec in roc_app1Bl6CO.o
main: is already signed
thread 'main' panicked at 'not yet implemented: gracefully handle `ld` (or `zig` in the case of wasm with --optimize) returning exit code Some(1)', crates/compiler/build/src/program.rs:1089:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

https://github.com/roc-lang/roc/blob/23c2b15115e9fd4e7224a17a388a020f3c74ffd3/crates/compiler/build/src/program.rs#L1089

I failed to reproduce this on an apple silicon mac running Sonoma.
I was running the code below with roc hello.roc:
app "hello"
    packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.7.0/bkGby8jb0tmZYsy2hg1E_B2QrCgcSTxdUlHtETwm5m4.tar.br" }
    imports [pf.Stdout]
    provides [main] to pf

main =
    dbg
        T (Str.split simple1 "\n\n")

    Stdout.line
        """
            Part 1: TODO
            Part 2: TODO
        """

simple1 =
    """
    1000
    2000
    3000

    4000

    5000
    6000

    7000
    8000
    9000

    10000

    """

Can you give it a try with today's nightly @lindskogen?

Tried reproducing again today and the issue seems to have gone away!


Include Lasagne in the wbia-cnn package

Add https://github.com/Lasagne/Lasagne as a submodule
Lasagne hasn't been releasing to pypi and we don't want to install using
git+https://github.com/Lasagne/Lasagne because it seems you can't mix
it with pip install wbia-cnn.  There's some restrictions on having
dependencies that are not on pypi.
Instead, we'll bundle Lasagne into wbia-cnn.

Include Lasagne in the wbia-cnn package
So the wbia-cnn wheel will now include wbia_cnn and lasagne.
We can stop relying on the pypi version of Lasagne and use this version
instead.

Ok builds are now passing :+1:  Ready for review


Fix Protobuf Error with serialized_options

Error was:
TypeError: new() got an unexpected keyword argument 'serialized_options'
This requires Protobuf 3.6.0 or above to support serialized_options,
but repo.sawtooth.me is only at Protobuf 3.4.1 for Sawtooth 1.0 and 1.1 at least.
The fix is to remove the unsupported serialized_options argument.
Signed-off-by: danintel<EMAIL_ADDRESS>

A symptom of the error is this message appearing after typing docker-compose up, causing 3 containers to not run (simple-supply-rest-api, simple-supply-tp, and simple-supply-subscriber):
TypeError: __new__() got an unexpected keyword argument 'serialized_options'
The error occurred while processing Dockerfile for the respective container.

I don't think we should manually edit the generated protos. Would installing a newer version of protobuf in the containers fix this?

The manual editing is a workaround.  The basic problem with Protobuf in repo.sawtooth.me is the protoc compiler is newer than the protobuf library.  Protoc generates stuff that the protobuf library does not understand.
A newer or at least consistent version of protobuf would fix this, but repo.sawtooth.me is beyond my control (and beyond the control of most people).
Dan
From: dplumb94<EMAIL_ADDRESS>Sent: Wednesday, May 29, 2019 1:44 PM
To: hyperledger/education-sawtooth-simple-supply<EMAIL_ADDRESS>Cc: Anderson, Daniel<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [hyperledger/education-sawtooth-simple-supply] Fix Protobuf Error with serialized_options (#30)
I don't think we should manually edit the generated protos. Would installing a newer version of protobuf in the containers fix this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/hyperledger/education-sawtooth-simple-supply/pull/30?email_source=notifications&email_token=AH26URPEOWUGN4QM2PVFF3LPX3TJ5A5CNFSM4HNQS5A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQSYUI#issuecomment-497101905, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH26URIKTRCLWPHYIZ6AHWLPX3TJ5ANCNFSM4HNQS5AQ.

Closing this PR in favor of PR #32 Update to Sawtooth 1.2.
That PR, #32, fixes the problem of the corrupt protobuf packages in the internal sawtooth.me repository for Sawtooth 1.0 and 1.1 (Xenial) because the latest Sawtooth 1.2 uses Bionic instead of Xenial, which has up-to-date protobuf compiler and libraries.


Feat/add lottie player

💬 Proposed changes
This PR adds a lottie animation to the landing page using lottie-web along with some custom components and hooks. Also adds new sections to the landing page.
✨ Preview
Desktop

Mobile

🖥📱 Browser / Device tests

Firefox Nightly (109.0a1), Windows 11
Chrome 108.0.5359.100, Windows 11

@vogelino @dnsos I have applied the requested changes. Ready for re-review.

Merging now because this is slightly blocking. There are a few finetunings left that will be done in the other ticket.


Array based structure

Wouldn't it be more reasonable to use an array based structure for storing vector and matrix data? This would enable implementing several generic operations like equal comparison in the abstract base classes without the speed decrease from having to rebuild the arrays every time. Sure we may lose some performance when fetching array values instead of direct variable references and looping through values without addressing them directly, but that should be within reasonable limits and the code becomes much shorter and nicer.
One major negative side would be that something like v[0] isn't as readable as just x. For this, I'd suggest shortening the getter functions to non-standard form like x() since it's rather reasonable to forgo some standards in this case. We could then use these getter functions instead of the array references for added verbosity. Even if the getters can't be shortened (for example to preserve API), it's still just a few characters more and we could also do stuff like v[X].
I can work out a pull request for this, I just need the acceptance of the repo owner so that I won't be doing useless work since there's still quite a bit of it related.

Thanks for the suggestion, but to be honest, I'm not so keen on this.  It would be a lot of refactoring, plus the code is already pretty clean.  Granted it's verbose under the covers, but I'm okay with that since the interface is straightforward.  I'm more interested in avoiding array copies and indirection, etc.
I would be cool with adding some constructors (in places that don't have them) that take arrays.


Precomputed entity attributes

Rendered
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

For Component 2 I slightly prefer the 2nd option (consolidating EvalResult and Value), but I'm fine with the RFC as-is.


Webpack BannerPlugin watch build not using current time

Bug report
What is the current behavior?
Date Variable in BannerPlugin is not updated if webpack is building the file via watch mode.
If the current behavior is a bug, please provide the steps to reproduce.
Create a webpack.config.js with a banner which contains a Date variable like this
const path = require("path");
const webpack = require("webpack");
const appDir = path.resolve(__dirname, "");
const version = require("./package.json").version;
const author = require("./package.json").author;

const banner = [
  "/*!",
  ` Build ${new Date()} - ${version}`,
  "",
  ` Author: ${author}`,
  "*/"
].join("\n");

var buildDir = path.resolve(__dirname, "./dist/");
var js_filename = 'sample-min.js';
var js_entry = './sample.js';

const config = {
  entry: js_entry,
  output: {
    filename: js_filename,
    path: buildDir
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        include: appDir,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader"
        }
      }
    ]
  },
  plugins: [
    new webpack.BannerPlugin({
      banner: banner,
      raw: true,
      entryOnly: false
    })
  ],
  watch: true,
  watchOptions: {
    poll: true,
    ignored: ['node_modules']
  }
};

module.exports = config;

Then create a sample.js file
console.log('just a sample');

In package.json define the following dependencies:
{
  "name": "SampleWebpack",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "clean": "npm run cleanProd",
    "cleanProd": "rimraf ./dist",
    "build": "npm run clean && npm run buildProd && npm run buildDev",
    "buildDev": "webpack -d --config webpack.config.js --progress --colors"
  },
  "dependencies": {},
  "devDependencies": {
    "@babel/core": "^7.5.5",
    "babel-cli": "^6.26.0",
    "babel-core": "^6.26.3",
    "babel-eslint": "^10.0.2",
    "babel-loader": "^8.0.6",
    "compression-webpack-plugin": "^3.0.0",
    "cross-env": "^5.2.0",
    "css-loader": "^3.1.0",
    "eslint": "^6.1.0",
    "extract-text-webpack-plugin": "^3.0.2",
    "html-webpack-plugin": "^3.2.0",
    "node-sass": "^4.12.0",
    "path": "^0.12.7",
    "rimraf": "^2.6.3",
    "sass-loader": "^7.1.0",
    "style-loader": "^0.23.1",
    "webpack": "^4.38.0",
    "webpack-cli": "^3.3.6"
  },
  "keywords": [],
  "author": "",
  "license": ""
}

Now after you run npm i, you can run
npm run buildDev

The first bundle is build correctly with the current timestamp. Any other bundles which are created by the watch process will contain wrong timestamp.
What is the expected behavior?
It should rebuild the bundle with the current timestamp and not use a cached? one.
Other relevant information:
webpack version:  4.38.0
Node.js version: 11.4.0
Operating System:  Win 7 Professional 64 Bit

You are running new Date only once in your config.
Maybe you want to pass a function to the banner option of the BannerPlugin


feat(napi): add parseBuffer POC

Hi! I have created a proof of concept of improving using oxc in JavaScript. The method is not polished but it provides valuable insights for future direction!
Feel free to close~ It is for reference only :)
Context
This is a proof of concept implementation of passing binary AST to JavaScript. JavaScript can selectively read flexbuffers-based AST nodes on demand to avoid the deserialization toll.  More context here.
Changes

Add a parseSyncBuffer napi method to return a binary AST from Rust to JavaScript. The AST is in flexbuffer format.
Add a test_buffer.js to test usage of flexbuffers in JavaScript. It is in cjs format because flexbuffers does not support ESM :/

Result
Some preliminary results, for reference only.
~ node test_buffer.js
testJSON: 4.043s
testBuffer: 2.395s

Buffer based API is 100% faster than JSON.
Future Ideas

Flexbuffers itself is slow. A better binary protocol is desired!
Using binary reader to traverse AST is undesirable. A proxy-based API to emulate object behavior will be nice.

Can you post your benchmark results? This looks really promising when polished!

Hey @Boshen , I have already attached the benchmark result in the PR summary.  Here is the extracted version.
~ node test_buffer.js
testJSON: 4.043s
testBuffer: 2.395s


[wip]Sai/fri high arity

Thanks for working on this! There's also a concurrent work by Axiom https://github.com/Plonky3/Plonky3/pull/592

Asking here since it seems more relevant:

Thank you for your work on this! I must admit that your method is smarter than mine. My PR is primarily focused on the requirements for a simple verifier. As demonstrated by SP1, the VM recursive verifier is less efficient than the circuit version. This is why I designed my scheme to prioritize a more circuit friendly verifier. Overall, your method looks good to me, if we do not plan to create a flexible circuit like the one in Plonky2.

Could you help me understand what your idea was in how to make the higher arity more circuit friendly? Particularly if arity = 4 and we have matrices of height 17, 16, 5, 4? Would I need to set the start degree to 4 to have higher arity work?

Asking here since it seems more relevant:

Thank you for your work on this! I must admit that your method is smarter than mine. My PR is primarily focused on the requirements for a simple verifier. As demonstrated by SP1, the VM recursive verifier is less efficient than the circuit version. This is why I designed my scheme to prioritize a more circuit friendly verifier. Overall, your method looks good to me, if we do not plan to create a flexible circuit like the one in Plonky2.

Could you help me understand what your idea was in how to make the higher arity more circuit friendly? Particularly if arity = 4 and we have matrices of height 17, 16, 5, 4? Would I need to set the start degree to 4 to have higher arity work?

We can set the starting degree to 14. Above this degree, we use log_arity = 1. Below this degree, we use log_arity = 4. The prover must pad their tables if a table cannot match the higher-airity steps.  In your example, we fold tables in the order 17->16->12->8->4, with padding 5->8 in the trace table. The table padding for lower degrees will be very fast.


Shulker dupe discovered for unflagged items inside a shulker that is broken

resolved in hotfix for 1.0.8. Will be pushed after testing


Nesting dropdown for 'navbar' skin

For style that use a 'navbar' skin such as boot-flatly it would be great to see the (first) nesting hierarchy as a dropdown
Is this easy to achieve or should I use navbar for this ?
Cheers

Hi @PierreR. I haven't tried specifically modifying the stylesheets for a navbar-like look. It should be possible with a bit of hacking around but if you only need it for one instance, it might be easier to just use a standard navbar element.
I have a lot of projects going on at the moment so I'm afraid development on this repository has slowed down, but if you do find a way to do it I'm quite happy to review a PR :)


Cookies: Needs guide + examples

Now that the Cookies API is documented on our references page, we need to provide some instructional content and examples.
This probably makes the most sense on the SSR page, as cookies are specific to SSR mode.

I have an example I'd be happy to contribute it to the Astro examples if needed
https://github.com/MicroWebStacks/astro-examples#13_client-persistent-counter

Sounds great, @wassfila! 🙌
Looking at the SSR page now, it seems like something alongside and approx the same length/depth as Astro.request.headers and Astro.redirect would fit. That is, a very basic, minimal usage example to show Astro.cookies in use, and then link to the reference page for the details. This page isn't the place for a full-featured example, but it would be nice to have a visual of it in use.

I think this should be closed?

Oh yes, well spotted @pilcrowOnPaper! Thanks again @wassfila 🙌