feat: add multi-language bindings for tiktoken using polywrap wasm wrapper

This PR introduces multi-language support for tiktoken-rs utilizing the Polywrap WASM toolchain.
Key points:

Facilitates efficient integration of tiktoken-rs in languages like Python and JavaScript.
Initial bindings provided for Python and TypeScript as a demonstration.
Performance note: Current default setup fetches some WASM dependencies at runtime, leading to potential delays. Embedding these can optimize performance.
Suggestion: Add support for loading .tiktoken files released by OpenAI, allowing runtime fetching and caching options for users.
With Polywrap, there's potential to expand support to Kotlin and Swift for mobile compatibility.

I'm eager to collaborate further to enhance the platform reach of this project.

Hey @krisbitney, It needs to be built using the custom build script we have there since we don't supprot rust workspace currently.

Hey @krisbitney, It needs to be built using the custom build script we have there since we don't supprot rust workspace currently.

That makes sense. It doesn't seem like we are likely to support Rust workspaces anytime soon.
For me, it seems the workspace build--i.e. cargo build from the repo root--is broken. Likewise with the yarn build script within the wrap, which uses the custom build script. Are they both working for you locally?

Hey @krisbitney, It needs to be built using the custom build script we have there since we don't supprot rust workspace currently.

That makes sense. It doesn't seem like we are likely to support Rust workspaces anytime soon.
For me, it seems the workspace build--i.e. cargo build from the repo root--is broken. Likewise with the yarn build script within the wrap, which uses the custom build script. Are they both working for you locally?

hey @Niraj-Kamdar @krisbitney something's not clear to me: how the build.sh script fix the problem of workspaces? we still to run another script right? couldn't it just be polywrap build?

Also I think adding Kotlin and Swift bindings are super high value for this.


Add Battery SOC display

Hi,
I like your card a lot. It would be great, if you could add a state of charge display for the battery (in percent).
Thanks, Waldemar

This is related to https://github.com/JonahKr/power-distribution-card/issues/13 so i will close it for now. You can check the State of development over there 👍
Thanks alot for your contribution


Support coursier-downloaded scala wrapper tests on Windows

This allows us to run tests with the scala runner wrapper coming from a coursier installation of the language.
We swap out the Scala CLI launcher used in the wrapper for one built for the purpose of our integration tests.
We used to skip running this on Windows until this change.

Note: this (hopefully) might make it easier to reproduce this issue:

https://github.com/VirtusLab/scala-cli/issues/3307


OpenCV 3.0.0-beta (was: OS X GStreamer.framework <-> ZLIB assert error)

On my OS X system /Library/Frameworks/GSTreamer.framework seems to be first in line for providing ZLIB (and possibly PNG) dependencies.  That framework provides an assert.h file which ends up leaving the assert macro undefined in files which rely on the standard /usr/include/assert.h macro.
I believe that is responsible for the errors I'm seeing in the OpenCV build now.  If I temporarily move GStreamer out of the way, that fixes the undeclared identifiers issues in the OpenCV assert calls.
Errors:
[ 53%] Building CXX object modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/src/loadsave.cpp.o
cd /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/modules/imgcodecs && /usr/bin/clang++   -DOPENCV_NOSTL -D__OPENCV_BUILD=1 -std=c++11 -stdlib=libc++ -fPIC   -fsigned-char -W -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -fdiagnostics-show-option -Wno-long-long -Wno-semicolon-before-method-body -fno-omit-frame-pointer -msse -msse2 -msse3 -fvisibility=hidden -fvisibility-inlines-hidden -Wno-deprecated-declarations -O3 -DNDEBUG  -DNDEBUG -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/3rdparty/libjasper -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/3rdparty/libjpeg -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/3rdparty/ippicv/unpack/ippicv_osx/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build -isystem /usr/local/include/eigen3 -isystem /Library/Frameworks/GStreamer.framework/Headers -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/modules/imgcodecs -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include    -o CMakeFiles/opencv_imgcodecs.dir/src/loadsave.cpp.o -c /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/loadsave.cpp
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/loadsave.cpp:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/precomp.hpp:50:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/imgproc_c.h:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/types_c.h:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/core_c.h:48:
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:485:5: error: use of undeclared identifier 'assert'
    assert( (unsigned)CV_MAT_DEPTH(type) <= CV_64F );
    ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:526:5: error: use of undeclared identifier 'assert'
    assert( (unsigned)row < (unsigned)mat->rows &&
    ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:533:9: error: use of undeclared identifier 'assert'
        assert( type == CV_64FC1 );
        ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:543:5: error: use of undeclared identifier 'assert'
    assert( (unsigned)row < (unsigned)mat->rows &&
    ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:550:9: error: use of undeclared identifier 'assert'
        assert( type == CV_64FC1 );
        ^
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/loadsave.cpp:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/precomp.hpp:50:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/imgproc_c.h:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/types_c.h:46:
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/core_c.h:1133:5: error: use of undeclared identifier 'assert'
    assert( _elem->flags >= 0 /*&& (elem->flags & CV_SET_ELEM_IDX_MASK) < set_header->total*/ );
    ^
6 errors generated.
make[5]: *** [modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/src/loadsave.cpp.o] Error 1
make[4]: *** [modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [OpenCV-release-prefix/src/OpenCV-release-stamp/OpenCV-release-build] Error 2
make[1]: *** [CMakeFiles/OpenCV-release.dir/all] Error 2
make: *** [all] Error 2

[hunter ** FATAL ERROR **] Build step failed (dir: /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV
[hunter ** FATAL ERROR **] [Directory:/Users/dhirvonen/devel/hunter/cmake/projects/OpenCV]

This really seems to have nothing to do with hunter, although it does affect hunter packages, and I'm posting this in case other people run into this same issue, which appears to be a side effect of the GStreamer framework shadowing the assert.h file locally.
UPDATE: Looking at the CMakeCache.txt of the OpenCV recipe, it seems GStreamer is picked up for both PNG and TIFF packages (which ends up putting the GStreamer assert.h in the preprocessor path), so providing a top level PNG_ROOT and TIFF_ROOT hint could be a work around.
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/CMakeCache.txt:WITH_GSTREAMER:INTERNAL=OFF
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt:PNG_PNG_INCLUDE_DIR:PATH=/Library/Frameworks/GStreamer.framework/Headers
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt:TIFF_INCLUDE_DIR:PATH=/Library/Frameworks/GStreamer.framework/Headers
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt://Enable Gstreamer 0.10 support (instead of 1.x)
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt:WITH_GSTREAMER_0_10:BOOL=OFF
/

/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe

xxxxxxx means you're using Hunter cloned from git. This usage case is for development and mean that HunterGate is not actually loading anything. So you need to update local git repository manually. In general you don't need to clone Hunter, HunterGate will do all the job for you.

On my OS X system /Library/Frameworks/GSTreamer.framework seems to be first in line for providing ZLIB (and possibly PNG) dependencies

It's not the case of Hunter. There must be a string ZLIB::zlib in cache. Please try to find CMakeCache.txt first in /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV directory. And this file must contain information about zlib:
> grep -i zlib /.../CMakeCache.txt

I'm testing libcxx toolchain on OS X, I see this flag in build:
-isystem /.../_Base/9308d01/ccec2c2/c018e63/Install/include

and some important info from cache /Build/OpenCV/Build/OpenCV-release-prefix/src/CMakeCache.txt:
> grep -i zlib
//The directory containing a CMake configuration file for ZLIB.
ZLIB_DIR:PATH=/.../_Base/9308d01/ccec2c2/c018e63/Install/lib/cmake/ZLIB
//Build zlib from source
BUILD_ZLIB:INTERNAL=OFF
//Details about finding ZLIB
FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[ZLIB::zlib][/.../_Base/9308d01/ccec2c2/c018e63/Install/include][v1.2.8()]

I'm using:
HunterGate(
    URL "https://github.com/ruslo/hunter/archive/v0.8.10.tar.gz"
    SHA1 "9308d01ea52c7b8cf1347073c982c679dbac3c09"
)

xxxxxxx means you're using Hunter cloned from git. This usage case is for development and mean that HunterGate is not actually loading anything. So you need to update local git repository manually. In general you don't need to clone Hunter, HunterGate will do all the job for you.

I have a few new hunter packages I've defined locally, so I've been using a hunter clone to support that (they are slowly getting pushed to hunter, but I'll probably always need to maintain some set of local package definitions for things I'm experimenting with).
I believe in this case GStreamer is picked up to satisfy OpenCV TIFF and PNG dependencies, but the new hunter.cmake OpenCV recipe is disabling those
hunter_cmake_args(
    OpenCV
    CMAKE_ARGS
        BUILD_DOCS=OFF
        BUILD_TESTS=OFF
        BUILD_PERF_TESTS=OFF
        BUILD_opencv_apps=OFF
        BUILD_EXAMPLES=OFF
        # Find packages in Hunter (instead of building from OpenCV sources)
        BUILD_ZLIB=OFF
        BUILD_TIFF=OFF
        BUILD_PNG=OFF
)

I hadn't looked through the updates to that file carefully, but they all make sense.    You had added that to  help hunterize OpenCV in the new "2.4.11-p1" release (to fix 3rd party conflicts), but my code is still dependent on the unhunterized "3.0.0-beta" release, so when it is told to use (but not build) TIFF, for example, it looks elsewhere.   When a 3.0.0-beta-p1 release is made that will probably fix the issue.  In short, this is probably due to an OpenCV module that is under construction, combined with a broken GSTreamer release.  After some more searching, I fetched the latest GStreamer.framework, and they have apparently renamed their internal assert.h file to something much friendlier.

I'm going to leave this open until the other opencv releases are hunterized (or temporarily removed).

I have a few new hunter packages I've defined locally, so I've been using a hunter clone to support that (they are slowly getting pushed to hunter, but I'll probably always need to maintain some set of local package definitions for things I'm experimenting with)

I was thinking about implementing injections correctly in smoother way. As I mentioned earlier take a look at this feature: https://github.com/ruslo/hunter/issues/56
Spoiler: in such way aslo can be supported GIT_SHA1 or even reading GIT_SHA1 from git submodule

Talking about c++11. I've got this error on my OS X build:
/.../hunter-packages/opencv/modules/highgui/src/window_cocoa.mm:153:42: error: cannot initialize a parameter of type 'NSApplicationActivationPolicy' with an rvalue of type 'int'

window_cocoa.mm:
147 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
148
149 #ifndef NSAppKitVersionNumber10_5
150 #define NSAppKitVersionNumber10_5 949
151 #endif
152     if( floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_5 )
153         [application setActivationPolicy:0/*NSApplicationActivationPolicyRegular*/]; // <<< conversion error
154 #endif

Which version of OS X and Xcode do you have installed?  I'm on OS X 10.9.5
and Xcode 6.2.
Is this the same error that was fixed by switching to ios-8-2-cxx98?  I'd
be curious if running the stock opencv framework python script points to
any solutions:
opencv//platforms/ios/build_framework.py
python platforms/ios/build_framework.py ios
I don't see anything that would seem to be specific to c++11 in those few
lines of code.
I noticed I still have these configurations in my CMakeLists.txt.  I'm
assuming your original ios-8-2 was similar.
list(APPEND CMAKE_CXX_FLAGS "-std=c++11")
list(APPEND CMAKE_CXX_FLAGS "-stdlib=libc++")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++11")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_ENABLE_OBJC_ARC YES)
On Sat, Apr 18, 2015 at 1:27 PM, Ruslan Baratov<EMAIL_ADDRESS>wrote:

Talking about c++11. I've got this error on my OS X build:
/.../hunter-packages/opencv/modules/highgui/src/window_cocoa.mm:153:42: error: cannot initialize a parameter of type 'NSApplicationActivationPolicy' with an rvalue of type 'int'
window_cocoa.mm:
147 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
148
149 #ifndef NSAppKitVersionNumber10_5
150 #define NSAppKitVersionNumber10_5 949
151 #endif
152     if( floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_5 )
153         [application setActivationPolicy:0/NSApplicationActivationPolicyRegular/]; // <<< conversion error
154 #endif
—
Reply to this email directly or view it on GitHub
https://github.com/ruslo/hunter/issues/72#issuecomment-94184856.

running the stock opencv framework python script points to any solutions

this build doesn't set c++11 flags

Is this the same error that was fixed by switching to ios-8-2-cxx98

I think yes

Which version of OS X and Xcode do you have installed?  I'm on OS X 10.9.5 and Xcode 6.2

I'm using Xcode 6.2 too, I don't think OS X version matter, but I have 10.10.3

I don't see anything that would seem to be specific to c++11 in those few lines of code

I think some conversion policies are just more pedantic. I've used NSApplicationActivationPolicyRegular instead of 0 and it works. I'm applying hunterize patches anyway, so I will apply this one too.

I noticed I still have these configurations in my CMakeLists.txt.  I'm
assuming your original ios-8-2 was similar

list(APPEND CMAKE_CXX_FLAGS "-std=c++11")
list(APPEND CMAKE_CXX_FLAGS "-stdlib=libc++")

Does it work for you? If this is toolchain file then this flags will be ignored, you need to set to CACHE. Also CMAKE_CXX_FLAGS is not a list but a string, so you need to set it like this:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

@headupinclouds OpenCV 3.0.0 added: https://github.com/ruslo/hunter/commit/eb7658b101ba9f0c7f80227fde8196a5363cd2c0 please pull branch develop. c++11 patches applied too, so must work fine with ios-8-2 toolchain.

@headupinclouds Hi David. So OpenCV 3.0.0 works for you and this bug can be closed?

Yes.


Update timescale enums and functions with trailing_year

For:

https://github.com/hypothesis/report/issues/169

Requires:

https://github.com/hypothesis/lms/pull/4947

Yeah, I don't know. This was a bit of an "it works" solution so I didn't come back to it.
It sounds like something that might be wise to investigate at some point?

A quick google seems to suggest you can't do this, only tables / views. Some people suggest wrapping functions in views to execute them remotely.


fix unfold

Can you explain why you want to change the signature of the iterator function?

Sorry, my mistake. I confused unfold with smth like unchain.
However current version fails on unfold. Because TS doesn't recognize [a:T,b:T] as [a:T,b:T], but T[]
It can be work around by using R.pair(a,b) instead of [a,b]


nano: 2.9.3 -> 2.9.4

See https://lists.gnu.org/archive/html/info-gnu/2018-03/msg00001.html
for release announcement
Motivation for this change
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

Success on aarch64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/q9whaylp40ha9gz7w1f027jwxkf4k7mb-nano-2.9.4/bin/nano
gzipping man pages under /nix/store/q9whaylp40ha9gz7w1f027jwxkf4k7mb-nano-2.9.4/share/man/
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/q9whaylp40ha9gz7w1f027jwxkf4k7mb-nano-2.9.4/bin
patching script interpreter paths in /nix/store/q9whaylp40ha9gz7w1f027jwxkf4k7mb-nano-2.9.4
checking for references to /build in /nix/store/q9whaylp40ha9gz7w1f027jwxkf4k7mb-nano-2.9.4...
shrinking RPATHs of ELF executables and libraries in /nix/store/bn6a8p42fa6xpsa3nq72c2fmcz2wrqmv-nano-2.9.4-info
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
patching script interpreter paths in /nix/store/bn6a8p42fa6xpsa3nq72c2fmcz2wrqmv-nano-2.9.4-info
checking for references to /build in /nix/store/bn6a8p42fa6xpsa3nq72c2fmcz2wrqmv-nano-2.9.4-info...

Success on x86_64-linux (full log)
Partial log (click to expand)
gzipping man pages under /nix/store/iqx0vv7h29a7ybcn36f9mw04c76mpgvz-nano-2.9.4/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/iqx0vv7h29a7ybcn36f9mw04c76mpgvz-nano-2.9.4/bin
patching script interpreter paths in /nix/store/iqx0vv7h29a7ybcn36f9mw04c76mpgvz-nano-2.9.4
checking for references to /tmp/nix-build-nano-2.9.4.drv-0 in /nix/store/iqx0vv7h29a7ybcn36f9mw04c76mpgvz-nano-2.9.4...
shrinking RPATHs of ELF executables and libraries in /nix/store/64v4w5x6iapr0hxc6mdc5f827x26llv6-nano-2.9.4-info
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
patching script interpreter paths in /nix/store/64v4w5x6iapr0hxc6mdc5f827x26llv6-nano-2.9.4-info
checking for references to /tmp/nix-build-nano-2.9.4.drv-0 in /nix/store/64v4w5x6iapr0hxc6mdc5f827x26llv6-nano-2.9.4-info...
/nix/store/iqx0vv7h29a7ybcn36f9mw04c76mpgvz-nano-2.9.4

already bumped to 2.9.4 in 532bd714bac656e38c3ef5f6d447efb9ffd6792d


initialData option support

like:
const { data, error } = useSWRV(key, fetcher, {
  initialData: []
})

see comment here: https://github.com/Kong/swrv/issues/18#issuecomment-600770690

the composition api supports onServerPrefetch, which swrv takes advantage of and allows users to not have to change their client side code. We even added some specific nuxt code to take advantage of nuxt's hydration. If you are trying to prefill/warm the cache client side, you can call mutate directly.


[Ethereum] [Bitcoin.com] [VERSE] Add support for VERSE token

If this is your first time integrating, the following information is required

A short introduction about your project/ your team:
Since 2015, Bitcoin.com has been a global leader in introducing newcomers to crypto. We make it easy for anyone to buy, spend, trade, invest, earn, and stay up-to-date on cryptocurrency and the future of finance. VERSE, which launched in December 2022, is Bitcoin.com’s rewards and utility token. VERSE is fueling the growth and expansion of Bitcoin.com’s ecosystem, which includes over 39 million self-custody wallets created in its multi-chain DeFi-ready mobile app, the Bitcoin.com Wallet.
Whitepaper: https://www.getverse.com/verse-whitepaper.pdf
Social media links (telegram, discord, website, LinkedIn,...)
Website: https://www.bitcoin.com/
Twitter: https://twitter.com/bitcoincom
Telegram: https://t.me/www_Bitcoin_com
Discord: https://discord.com/invite/bitcoincom
Github: https://github.com/bitcoin-portal

If you want to integrate an asset (fungible token/ NFT), you would need to provide

Name of the asset:
VERSE
Origin blockchain of the asset:
Ethereum
Is it available on other blockchains?
Metadata of the asset (symbol, decimals, smart contract address, on-chain metadata like assetId,...)
0x249cA82617eC3DfB2589c4c17ab7EC9765350a18
Logo of the token
https://www.figma.com/file/PxPvXw5woBernBu3BtwxkX/SubWallet-Project-Logo?type=design&node-id=840-31&t=AjMJ5BGh9vVyZRhM-0
Is your asset transferable?
Yes

Documents and references:
https://etherscan.io/token/0x249cA82617eC3DfB2589c4c17ab7EC9765350a18

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./master-pr-1520-build-1.0.8-2023-06-12T02-42-40UTC.zip
Validation passed for cases:

Show token

Show balance

Transfer


[core] Change package manager to pnpm

Since the question came up in Slack. Just to see what a migration looks like. This PR mostly to see how the @mui/monorepo dependency will behave in X/Toolpad
Migrated the repo up until pnpm docs:dev works. None of the other commands have been tested or migrated. Nothing in the CI pipeline has been migrated.
Some quick notes

https://dev.to/andreychernykh/yarn-npm-to-pnpm-migration-guide-2n04

pnpm import
 ERR_PNPM_INVALID_OVERRIDE_SELECTOR  Cannot parse the "**/@babel/core" selector in the overrides

=> remove **/ everywhere?

added .npmrc with
auto-install-peers = true

replace workspace dependencies versions in package.json files with workspace:*

scripts:

yarn workspace docs dev => pnpm --dir ./docs dev

I would be curious to see if it speed-up the CI, and by how much. It might be the biggest selling point.

Yep, it already feels quite fast locally. I think there's two roads to continue with this

first try to migrate CI in this repo, to see the impact on build time to see if we should even bother porting to the other repos
first try to make the docs work on Toolpad or X to see if we should even bother spending time migrating CI

I've made all the CI steps pass, but there's more to do, specifically around publishing.
I found two problems so far:

when running pnpm release:publish, we're experiencing the issue described in https://github.com/lerna/lerna/issues/3803
even after patching lerna and working around the first issue, the built packages contain package.json files with "workspace:" protocol in version specifiers. This is caused by lerna using npm (not pnpm) to publish packages. We'll likely need to change our build and publish process to overcome this.

Additionally, some of the tools complain about circular dependencies we have in our packages. It's not a blocker, but we'll have to solve this at some point, especially if we'd like to speed up type-checking by using project references.
I need to take a break from this to handle current issues in Core. I'll get back to it next week.

even after patching lerna and working around the first issue, the built packages contain package.json files with "workspace:" protocol in version specifiers. This is caused by lerna using npm (not pnpm) to publish packages. We'll likely need to change our build and publish process to overcome this.

As far as I understand, lerna should use pnpm under the hood for all commands, including publishing. Which should rewrite these workspace:* specifiers to the version of the respective workspace.
IIUC, MUI builds its production output into a build* folder nested in the package, then publishes from there? If so then I guess they aren't real workspaces anymore (because not defined in pnp-workspaces.yml). Perhaps that causes it to not rewrite the version specifiers?
* I guess this is done to prevent polluting the package folder with top-level folders for each subpath export for commonjs? There is no real way around this (afaik) if we want to stay compatible with commonjs. It is causing more problems than just publishing. e.g. It's not really possible to build a package, and turn off aliasing to try it out straight in the docs, or in another workspace. We should benchmark how other libraries deal with this that have lots of subpath exports.

As far as I understand, lerna should use pnpm under the hood for all commands, including publishing.

Unfortunately, no. It's stated explicitly it uses npm for publishing: https://github.com/lerna/lerna/tree/main/libs/commands/publish#important-notes

@Janpot, the CI is green and I was also able to work around the publishing issue. I added a script that goes through the built package.json files and replaces the workspace: version specifiers with proper version numbers.

Great, before I deep dive into reviewing this, are there any fixes that apply to yarn as well and can be extracted and merged to master? Just to reduce some of the noise.

I added a script that goes through the built package.json files and replaces the workspace: version specifiers with proper version numbers.

Just for my understanding about what's happening here? Is this caused by our published packages being in subfolders, and not being part of the pnpm workspace? I'm not 100% sure, but if that's the case, I think the  publishConfig.directory setting could help us?

Are there any fixes that apply to yarn as well and can be extracted and merged to master

Explicitly defined dependencies could also work on the current master, but I can't simply copy package.json files from this PR as they also contain the workspace: specifiers not supported by yarn, so it would be additional effort (not sure if it's worth it).
I can extract the ESLint fixes for sure.

are we still using lerna for publishing

Yes, we are. I haven't changed the publishing pipeline.
By the way, I tested the publishing using locally set up Verdaccio and it seems to work well.

(not sure if it's worth it).

My only concern was in case we run into blockers with X/Toolpad and need more time. Just to reduce the surface of merge conflicts in this PR. But may as well not be worth it indeed.

By the way, I tested the publishing using locally set up Verdaccio and it seems to work well.

Nice 👍. If you still have that set up, it could be interesting to try out pnpm -r publish to see what are the blockers to replace the release:publish script with it. As an alternative to rewriting the workspace:* specifiers ourselves.

it could be interesting to try out pnpm -r publish to see what are the blockers to replace the release:publish script with it. As an alternative to rewriting the workspace:* specifiers ourselves.

It seems to be working well, although it's slower than publishing using lerna (especially the icons-material package).

My only concern was in case we run into blockers with X/Toolpad and need more time. Just to reduce the surface of merge conflicts in this PR.

All right, I extracted all the relevant changes to #38859

I would be curious to see if it speed-up the CI, and by how much. It might be the biggest selling point. https://mui-org.notion.site/Migrate-to-pnpm-2a4f2e9869cf496eae183eff2aeef9a9

I collected some numbers on the Toolpad version of this PR.  Could be worth doing the same exercise for this PR.

"preinstall": "npx only-allow pnpm",

Awesome, love to see this.

I think I found a regression with pnpm:
https://github.com/mui/material-ui/blob/9e0af1b4ed040bd1917c99b64a6da4f72cc65fc7/packages/mui-base/package.json#L43-L47
As far as I can read this: we can no longer control the minimum version dependency, we are forced to force every developers to update all their dependencies even if there are no breaking changes or reliance of new feature, leading to a higher chance of package duplication in the bundle (good for our npm downloads stats, not good for end-users)

How is this different from the workflow we had with Yarn? We used to update the versions of internal dependencies each release to the most current one. Now it's done automatically by pnpm.
Anyway, if you want to allow earlier versions, pnpm does allow to do it (for example workspace:^5.0.0)

it's not necessary to increase the range.

I thought we kept versioning in lerna, if lerna wasn't increasing the range before pnpm migration, it won't increase it after. Or am I missing something?

I thought we kept versioning in lerna, if lerna wasn't increasing the range before pnpm migration, it won't increase it after. Or am I missing something?

@Janpot This indeed didn't change. The conclusion for me is:

https://github.com/mui/material-ui/pull/23793 came with the cons of making it hard to granular control version. It's not great, but the alternative is worse.
pnpm makes it harder for developers who check the source to know what's the actual version dependency (there is an indirection) but make it clear that it's from the same workspace.

The benefit of the workspace:* version range is that it 100% guarantees that they are locally linked. During publishing pnpm does all the work filling in the correct versions.

pnpm makes it harder for developers who check the source to know what's the actual version dependency (there is an indirection) but make it clear that it's from the same workspace.

Those people should instead run
npm info @mui/material
# or
pnpm info @mui/material
# or
yarn info @mui/material

It's a much more reliable source for this information as it shows the actually published package. It's also much easier to find the dependencies of a specific version of a package by adding a version range pnpm info<EMAIL_ADDRESS>

I was curious about the CI metric impact of this PR:

Cost: https://docs.google.com/spreadsheets/d/1VQFM0bcX1oFrvt6tKjdqQDi5KJac_-HZcNavfvFk2tQ/edit#gid=0. I didn't see much conclusive evidence, maybe a bit more expensive but it is unclear.
CI speed: https://app.circleci.com/insights/github/mui/material-ui/workflows/pipeline/overview?reporting-window=last-90-days median duration seems also about the same.


no message update

Describe the bug
After initializing and init of the Xplora class I run a loop:
while True:
        print(xplora.getWatchChats(TheRealWuid,0,1))
        time.sleep(30)

running the code works fine. I get the last message of the watch.
When the watch sends a message while running the code the newer message is not printed. after a restart of the program the new message is displayed.
To Reproduce
Regardless how long the code runs, new message is not displayed.
Expected behavior
messages should be refreshed with every getWatchChats call like the getWatchLocate call.
Hope I am using it right.

from time import sleep

from src.pyxplora_api import pyxplora_api as PXA

def main():
    start_time = time()
    xplora = PXA.PyXploraApi("+49", "1234567890", "PASSWORD", "de-DE", "Europe/Berlin")
    xplora.init()
    while True:
        print(xplora.getWatchChatsRaw("011012345678901234567890123456", 0, 1)
        sleep(30)

for me it will be updated after time has expired.


Add tests

Codecov Report

Merging #8 into master will increase coverage by 1.14%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
+ Coverage   27.58%   28.73%   +1.14%
==========================================
  Files           8        8
  Lines          87       87
==========================================
+ Hits           24       25       +1
+ Misses         63       62       -1

Impacted Files
Coverage Δ

toofz.TestsShared/Record.cs
0% <0%> (-33.34%)
:arrow_down:

toofz.TestsShared/AssertHelper.cs
100% <0%> (+100%)
:arrow_up:

Continue to review full report at Codecov.

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


X axis range

Hi, first of all thanks for a wonderful card! I have one small question/request. Is there a way to dynamically enforce (initial) limits on the graph time axis?
My use case: torque integration collecting drive data. I would like to plot graphs for the last drive. I would be able to write sensors storing the start and ending times of the drive, I would love to use these as limits of the time axis.
Many thanks!

If you mean initial limits as in showing the relevant range by default, check out the defaultTimeRange and defaultTimeOffset settings. If you mean hard limits preventing the user from scrolling out of boundary, then no, I'm afraid there is no such feature.

Thanks. In a sense, this is what I need. Now, is there a possibility to set defaultTimeRange and defaultTimeOffset dynamically, i.e., based on a sensor value/javascript function, e.g., something like this (does not work)?
defaultTimeRange: |
[[[
return (parseFloat(states['sensor.trip_time_since_journey_start'].state)/60).toFixed(0) + 'm';
]]]
defaultTimeOffset: |
[[[
var now = new Date();
var old = (new Date(states['sensor.trip_time_since_journey_start'].last_changed));
var rem = Math.floor((old.getTime() - now.getTime()) / 60000);
return rem + 'm';
]]]

They're fixed parameters, I'm afraid. At least for now.
I wonder if you could use something like card-mod to generate the YAML on the fly ? Not too sure if it can do that.

Many thanks. I have some progress by combining your card with custom-buttom-card. It works almost as expected but there is still one issue I need to solve - some elements in the history-explorer card do not (line)-break as they do in the standalone card. If I fix this, I will also post this here for future reference.

Test YAML
type: custom:button-card
tap-action: none
custom_fields:
graph:
card:
type: custom:history-explorer-card
header: hide
combineSameUnits: true
refresh:
automatic: true
showCurrentValues: true
uiLayout:
selector: hide
toolbar: bottom
interval: hide
graphs:
- type: line
entities:
- entity: sensor.speed_obd
name: Rychlost
defaultTimeRange: |
[[[
return (parseFloat(states['sensor.trip_time_since_journey_start'].state)/60).toFixed(0) + 'm';
]]]
defaultTimeOffset: |
[[[
var now = new Date();
var old = (new Date(states['sensor.trip_time_since_journey_start'].last_changed));
var rem = Math.floor((old.getTime() - now.getTime()) / 60000);
return rem + 'm';
]]]
style: |
ha-card {
box-shadow: none;
}
styles:
custom_fields:
graph:
- overflow: auto
- padding: 0%
card:
- overflow: auto
- padding: 0%
- position: relative


haskellPackages.haskell-language-server: Fix build

In preparation of the upcoming 0.6.0 release I wanted to fix hls.
It introduces two new plugin packages, which are not on hackage yet.
I remove apply-refact overrides, because current apply-refact versions
are compatible with all ghcs we support, according to their changelog.
I override more of the hls dependencies globally on the whole package
set, to avoid a lot of duplicate compilations. And because @peti changed
my mind about this being a good practice.
hls now uses a released version of ghcide

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build haskell-language-server
@GrahamcOfBorg build haskellPackages.ghcide
@GrahamcOfBorg build haskellPackages.brittany

@ofBorg eval

Okay, then I'll merge now and monitor hydra closely until friday, to see if it had any unintended side-effects.

Everything builds fine. We now have hls 0.6.0 which was released a few hours ago. Can‘t wait to have it in unstable.


Code Review 2

Try to decompose the file into components:
https://github.com/LLumisS/Procedural-Map-Generation-Project/blob/b0a82a25a2b12bdcc88be9ba3b9b7f98efa5d684/client/src/pages/Generator.js#L12-L78
Delete unused file if you won't use it later:
https://github.com/LLumisS/Procedural-Map-Generation-Project/blob/b0a82a25a2b12bdcc88be9ba3b9b7f98efa5d684/client/src/pages/Saves.js
Decompose the element:
https://github.com/LLumisS/Procedural-Map-Generation-Project/blob/b0a82a25a2b12bdcc88be9ba3b9b7f98efa5d684/client/src/pages/Showing.js#L19-L96

Thanks for the help dear comrade 🤝


Updating GetDate mechanism from Workspace DoneDrive

Added Workspace OneDrive Get Data mechanism.

Docs Build status updates of commit 9a8ad7e:
:warning: Validation status: warnings

File
Status
Preview URL
Details

powerbi-docs/collaborate-share/service-create-the-new-workspaces.md
:warning:Warning

Details

powerbi-docs/collaborate-share/service-create-the-new-workspaces.md

Line 98, Column 1: [Warning: duplicate-alt-text - See documentation] Alt text 'image' is duplicated. Within an article, alt text must be unique.
Line 102, Column 1: [Warning: duplicate-alt-text - See documentation] Alt text 'image' is duplicated. Within an article, alt text must be unique.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 430fd74:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerbi-docs/collaborate-share/service-create-the-new-workspaces.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@maggiesMSFT

Can you review this PR?

Keep in mind that images hosted outside the repo aren't allowed.
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@Jak-MS I tried to upload the images into the repo but I couldn't find the related folder to do so.

@soheildataviz - this is the folder for the article you're modifying:  /powerbi-docs/powerbi-docs/collaborate-share/media/service-create-the-new-workspaces/

@soheildataviz - this is the media folder for the article you're modifying:  /powerbi-docs/powerbi-docs/collaborate-share/media/service-create-the-new-workspaces/

Thank you @Jak-MS. But uploading file is disabled on this folder.

@soheildataviz - understood. I can't fix that issue.
We'll wait for the review from @maggiesMSFT ... and if your changes are approved, she'll need to upload the images files.

Docs Build status updates of commit bad970a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerbi-docs/collaborate-share/service-create-the-new-workspaces.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

add these back:

#sign-off


Solid-state NFTs

[ ] Finalize the NFT spec
[ ] Finish the wallet NFT minting and sending functionality
[ ] Sart minting degenerate NFTs on mainnet
[ ] Talk to people like https://twitter.com/fulldecent about spec

Putting this off for now.


Create basic scaffolding for collections

This issue should cover the following points:

[x] Add a way to define collections. Being able to the define the following parameters

[x] Collection name.
[x] Wether or not to expose metadata.
[x] Indexes definition.

[x] Add basic operations.

[x] Write entries.
[x] Read entries.
[x] Delete entries.

Commit has been merged.
Closing the issue.


Get rid of operator-sdk generate

PR #580 replaced operator-sdk generate crds with a controller-gen command (plus some hacks to make it match up with what operator-sdk did). This commit similarly replaces operator-sdk generate k8s with a controller-gen command, reducing our dependency on operator-sdk to just go imports.
While I was in here, I noticed that some framework-generated comments were making their way into the Description of some of the CRD fields and corresponding generated openapi. Nixed those.
Also cleaned up the redundant parts of generate_crds.sh which were running go and openapi generators. These were already part of the boilerplate-provided generate target as go-generate and openapi-generate.
Note that regenerating deepcopy code under controller-gen results in a trivial delta to each method whereby the implicit no-op return statement is removed.
TODO: Some of the "make compatible with operator-sdk" parts of generate_crds.sh are definitely not necessary (e.g. nothing cares whether the CRD files are named with _crd) and some are probably not necessary (I doubt anything breaks if things like annotations, creationTimestamp, status, and list type fields are included). If we can get rid of these, it should be easy enough to collapse this script back into one or two lines in the Makefile.

Superseded by #588


Using multivariatenormal as the guide

Hello:
I'm new to pytorch and pyro. It sure rocks, but we're trying to migrate some code form other projects and there was one show stopper.
Using a sequence of univariate normals as the guides is too restricting, isn't it?: we are imposing that the variables are not correlated a posteriori, whatever the data says.
Fortunately there is now on the dev branch a multivariatenormal, but it requires a semidefinite matrix, so in order to use it as a guide we need the equivalent of the softplus in the tutorial, if I got the Bayesian Regression tutorial right. I'm thinking of the matrix exponential (even the matrix softplus makes perfect sense), but I can't find an implementation of matrix exponentials in pytorch.
There might be other blockers also ...
Can anybody help?
Thanks
#166

theano does have matrix exponentials:
http://deeplearning.net/software/theano/library/tensor/slinalg.html
looking closely, they simply call scipy:
https://github.com/Theano/theano/blob/d395439aec5a6ddde8ef5c266fd976412a5c5695/theano/tensor/slinalg.py#L487-L515
So maybe it is just a matter of creating a pytorch module around that :-/ ???

Hi, there is a multivariate normal distribution with a reparameterized sampler in dev.  If you want to use it in a guide you'll need to follow the instructions in the README for installing the dev version of Pyro.  If you want to parametrize the covariance directly, you can use torch.distributions.transforms.LowerCholeskyTransform to construct a Cholesky factor and compute a covariance matrix from that.  These features are not yet in the release versions of Pyro and PyTorch, so the documentation is a bit sparse.

Thanks a lot, eb8680! Hadn't noticed the "reparameterized sampler". Will test it tomorrow...


Transition to Equinox as a backend

haiku won't be improved in the future, but will be maintained to be compatible with newer JAX releases. It would be great to consider switching to equinox as a backend for JAXspec, since it is much lighter and would lead to less spaghetti code in the engine.

After some tryouts, I figured out a nice code architecture which doesn't rely on weird metaclass as it is done right now. Equinox modules are great and can be instantiated unlike haiku modules. However I can't get it to work right now since I'm not familiar yet with this library.
UML diagram

Here, the natural model building SpectralModel = Phabs() * ( Powerlaw() + Blackbody()) is handled by the compositions defined in the Spectral model class. Individual components are built with a single node graph in the ModelComponent class constructor. I'll dive into this later!

I recently came across this library.
I'd love to see Equinox used as the backend :)

Wow, hi Patrick, I am very honoured to see you there. This project has been in the pipeline for a while, I've been playing around with equinox some time ago and it clearly seems feasible to transpose the internal logic of model building based on it. I just need to practise with it a bit more to get used to it, and that should be no problem!

Hey @patrick-kidger
I am slowly writing the backend transition, and I have a design question. I have many models that requires interpolation on "known in advance" tables. I am passing them as attribute of the eqx modules I am writing and force them to be static and numpy arrays, but in this situation Equinox yell at me saying that JAX array shouldn't be set as static field, while they are 100% numpy arrays. I find it handy to load them as module attributes during instanciation, but don't want gradient computed on them. Is it bad practice to store these tables as attributes for eqx modules ?
Demo stuff :
class Tbabs(MultiplicativeComponent):

    nh = 1.0
    energy :np.array = eqx.field(static=True)
    sigma:np.array = eqx.field(static=True)

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        table = Table.read(table_manager.fetch("xsect_tbabs_wilm.fits"))
        self.energy = np.asarray(table["ENERGY"], dtype=np.float64)
        self.sigma = np.asarray(table["SIGMA"], dtype=np.float64)

    def continuum(self, energy):

        sigma = jnp.interp(energy, self.energy, self.sigma, left=1e9, right=0.0)

        return jnp.exp(-self.nh * sigma)

JAX treats numpy arrays and JAX arrays pretty much interchangeably, so the warning is correct here -- they shouldn't be static fields either. (This is all a JAX thing, not an Equinox thing, and here Equinox is just trying to prevent you from footgunning yourself.)
If you want these values to be traced arguments to the computation graph then leave them as normal fields. If you want these values to be compiled-in constants then make them global values.
If you don't want gradiens then use jax.lax.stop_gradient.


When Opening file of Javascript no code is colored?

This is a small part of my code and none of the var or function words are colored. In the Top left of my visual studio window it has script1.js and the first line of my code (javascript source code) appeared when i opened a new java script file. I'm on the latest update of visual studio.
Thanks for the help in advance.

Please file this issue against regular Visual studio: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio-2017


local message are not available in asyncData using i18n.t() using vue-i18n-loader

Version
@nuxtjs/i18n:
nuxt:
Nuxt configuration
Please change to [x] if relevant for this issue:

[x] Applies to a site deployed to a static server (site generated with nuxt generate)
[x] Applies to a site deployed to a server with a Node backend

@nuxtjs/i18n configuration

Reproduction Link

Coming soon
Steps to reproduce

Create a component
Add local message using vue-i18n-loader or the option API
In your asyncData, using i18n.t or app.i18n.t, the message is not found
If you use global message, it work

What is Expected?

Local message should also be available as they dont need the instance to be mounted to work since they have no dependancy

What is actually happening?

Only global message are available

I need to send my translation to layout component using Vuex.
<script>
export default {
    layout: 'onboarding',
    asyncData({ store, app }) {
        store.commit('onboarding/setOnboardingDetails', {
            title: app.i18n.t('page_title'),
        });
    },
    head() {
        return {
            title: this.$t('page_title'),
        };
    },
};
</script>

<i18n lang="json">
{
    "fr": {
        "page_title": "Introduction",
    },
    "en": {
        "page_title": "Onboarding",
    }
}
</i18n>

Oh wow. That's one obvious bug that took forever to find :)
@kazupon not sure how familiar you are with Nuxt already but maybe you have some ideas here.

vue-i18n-loader stores component locales inside the component - https://github.com/intlify/vue-i18n-loader/blob/d1814dae9986088fd4d4d159d88c36f14bd5dbd0/src/index.ts#L45-L46
it only merges the locales and creates local vue-i18n instance once the component is created so after asyncData invocation
We could find the component and the related data one way or another (maybe not in a pretty way) but then there is a challenge of creating a local (extended) vue-i18n instance just for asyncData and then figuring out when to forget it again.
This all seems like quite a challenge unless I'm missing something (could be since I thought about it for only few minutes).

Alright we are not crazy 😝 We ki da found out a year ago but we were not too familiar with the plugin and we were using local message inside the option API. We ended up moving all these message as global message and didn't think much about it.
But now we moved to vue-i18n-loader and I was refactoring some code on another project and I was hopping the move the text inside the relevant component so that it's easier to find and I figured out it can't be right that local message aren't available inside asyncData.

+1 here. Feels like this should already be baked in especially with this being a Nuxt.js specific implementation of vue-i18n.
Does anyone have any workarounds for the moment? Main use case here is error messages (inside of error).

Closing this as v7 is not being actively worked on (critical hotfixes only), if this still applies to v8 and later please open a new issue!


Selection of Renderer

I tried to collected several svg2png-render on SVG-renderer
ImageMagick, svgexport, PhatomJs are imho often used, but SVG.NET, QtSvg, wxSvg are hardly listed
Is there a reason why you choose those you listed in #svg-support, e.g. do they use a backed which is already tested?

ImageMagick

Just a librsvg wrapper. They can do some basic rendering manually, but it doesn't worth considering.

svgexport

This is Chrome. Same as resvg-test-suite/tree/master/tools/chrome-svgrender, but more user-friendly.

PhatomJs

WebKit wrapper. The same as Chrome.

Is there a reason why you choose those you listed

The libs and apps I've chose test rendering backends. There is no point in testing wrappers. The list you provide on wiki is a bit pointless, because there are like 5 decent SVG implementations (Chrome/WebKit, Firefox/Gecko, resvg, batik, rsvg and Inkscape). Everything else is either useless or just a wrapper.

Svg-explorer-extension

This is just QtSvg

cairosvg

Extremely primitive.

svglib

Extremely primitive.

aspose.svg

Proprietary.

Trident

Dead? Proprietary?

Presto

Dead. Proprietary.

KSVG

Dead?

Prince

Proprietary.

Amaya

Dead

Renesis Player

Dead

Thanks for clarifying, that's exactly the information I was looking for. (Sorry for bugging you, I was unable to find/understand the backend-information.)

No problem.


Improve build system integration

Hi Paul
I recently upstreamed a change for nRF52 that enabled FPU support (and it immediately broke the uPy build as a result due to incompatible float ABIs).
This is the patch series I wrote to fix it. Tested with qemu_x86 and qemu_cortex_m3 (although in the later case I did have to turn off mbedssl). Older version of this patchset was also tested on Nitrogen but now all the network code is turned on uPy doesn't fit in the nitrogen's tiny, tiny flash.
Daniel.

Funny thing, but I have just booted uPy on frdm_k64f for the first time since it was switched to hardfloat in zephyr. My changes are along the lines of yours - include Z's .config, etc. However, if you compared uPy's build system with JrS', JrS currently duplicates cflags and their selection, parallel to Z. But Z already has those flags and those selection, and all the way with uPy port, I'm trying to actually plug into Z config/build system to reuse its settings. As you saw, pulling setting on C level already worked, and with the changes I just made, it also pulls cflags for the board. It's somewhat fragile, yes. All that should be input to Z team on how to improve integration with 3rd-party projects.
So, I'm continuing with networking bring-up on frdm_k64f, and a bit later I'll review your changes in more detail and see how to integrate them with mine.

Cherry-picked "zephyr: Switch sub-makes to use proper environment variables", will probably squash it if you don't mind.

Previous comment was wrong (removed).
Cherry-picked "zephyr: Use ?= for BOARD", will probably squash it if you don't mind.

A bit concerned about "zephyr: Support extra make targets", main makefile should provide MicroPython's, not Zephyr's targets (at least so I think now). But there doesn't seem to be conflict so far, merging.

That "initconfig" target is neat. I initially wanted to "reverse engineer" Z makefiles to see if I can find suitable partial targets. But then I thought: "If I find some internal target, there's no guarantee it won't change in the future. So, maybe not so pretty, but more robust approach is to make Z build as much possible, but eventually fail. Then build libmicropython.a, and restart Z build". Well, getting rid of need to set ARCH is a very good thing, so you patch is cool improvement. But autoconf.h is still needed, so my "build, fail, build completely" approach stays too.

Except I rename DOTCONFIG to Z_DOTCONFIG for consistency with Z_AUTOCONF_H.

Unfortunately, your change for automatic ARCH broke my cute hack for automatic target CFLAGS. I figure, make doesn't honor dependencies on include files (i.e. you can't tell it - before including that file, make sure its dependencies are satisfied). I'll see if I can workaround that with recursive make...

make doesn't honor dependencies on include files

I worked that around by including non-existent proxy file, which forces make to honor dependencies ;-).

Ok, I pushed my part. Please rebase (sorry for conflicts) and test how it works for you. If you look, there're still some hardcoded hacks, but that's very close to supporting any board supported by Zephyr.

And we should add ability to have multiple prf*.conf files...

If you look, there're still some hardcoded hacks

Ok, now even these are gone.

And nope, it either broke, or include order by make is non-deterministic.

Reworked again, seems to work.

Regarding the "build, fail, build again" approach, personally I think it better to see tools integrate better with the Zephyr build system. The third-party-build is an obvious use case (and one they acknowledge) so exploring good ways to integrate with the Zephyr build system is part of nudging a very young project in the right direction.
If you find that at all convincing then you might want the "outputmakefile" target for the build-that-currently-fails!


Use hosted CI runners for building docker images

What does this PR do?
Github lowered the cache/space runners can use. As a result our GPU image (which takes ~6-8gb to build) winds up hitting a storage issue when trying to deploy/build the latest nightly versions for our CI.
This PR uses our self-hosted runner to do this instead, and clears any old caches that the cron already in the system may have missed, to help with storage.
Fixes # (issue)

Last side-effect of the docker runner/action failing

Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[x] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a Github issue or the forum? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines, and
here are tips on formatting docstrings.
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.
@BenjaminBossan

@BenjaminBossan I did wind up having to use the gh action workflow, simply because some things with self-hosted runners get mucky

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


Design a way to update the readme without having to push a new version

Chore
Describe the chore
I accidentally pushed a package without a readme:
https://database.dev/kiwicopple/countries
I wanted to update just the readme, so I edited the file on my computer then ran dbdev publish --path .
I got this back: Nothing to publish
This makes sense, but it could be nice to have a way to update the readme without needing to bump the version (i don't know if NPM allows this though)

NPM or crates.io do not allow updating the README without publishing a new version:

NPM: https://docs.npmjs.com/about-package-readme-files#updating-an-existing-package-readme-file.
Cargo: https://github.com/rust-lang/crates.io/issues/1750

I'd like to keep it simple like this. I'd definitely update the docs though, and improve the message Nothing to publish to include a hint about how to update the readme: by bumping the version.

I was in agreement with you until I just pushed a typo in a link in my README and now I'm on @kiwicopple side 😂

What's the concern with fixing README and publishing the changes with a patch version bump? Is it that in your mental model README is thought of as something separate from a versioned release of the extension? Does it feel like too much hassle to release a new version just to fix README?
I'd let you guys go through the motions of releasing a new version with fixed README and if it still feels off, then reconsider this design.

+1 for deployed versions not being editable
there's not much downside to cutting a new patch version & users should be able to trust that nothing can change out from under existing releases (including docs/readme)

I'm fine with that  - will close this. I've documented the decision here: https://github.com/supabase/dbdev/discussions/136


Error: TypeError: trackerFn is not a function at new e (tf-core.esm.js:17)

Hi, I'm getting the following error when I tried to load a loadFaceLandmarkModel. I don't believe that is an error that is directly associated with face-api.js but an incompatibility of packages versions.
I already created a question on stackoverflow to seek help for the comunity:
https://stackoverflow.com/questions/55326589/error-typeerror-trackerfn-is-not-a-function-at-new-e-tf-core-esm-js17
Can you please help me solve this problem?
Thank you!

I don't believe that is an error that is directly associated with face-api.js but an incompatibility of packages versions.

That's my guess as well. Which version of tfjs-core are you using?

I have a similar problem! I have use tfjs version >1.0.0

same problem here

I was having the same problem. I resolved by inverting the package installation order: npm i @tensorflow/tfjs-node canvas face-api.js
Thus, the version of tensorflow-core installed inside face-api is now 1.4.0. Otherwise version 1.2.9 had been installed.


fix: add type MapFunction back

Initial checklist

[x] I read the support docs
[x] I read the contributing guide
[x] I agree to follow the code of conduct
[x] I searched issues and couldn’t find anything (or linked relevant results below)
[x] If applicable, I’ve added docs and tests

Description of changes
close #6

For later, optional improvements

I'm not familiar with that part, so another PR can be raised for it.
The asIs mapper with import('./index.js').MapFunction<Root> alreay tested that?

@remcohaszing i was thinking that first, but without skipLibCheck, I was thinking maybe they'd get checked anyway?
Maybe you're right, and if that's the case then it's especially fine!

Nope, TypeScript only looks at the .d.ts files. It's the whole reason we build them 😅


Change connection string for updated bitnami/mongodb

issue ref:- #23

Changes tested and patch proposed here
Kindly review @NikhilM98
https://user-images.githubusercontent.com/50985033/126566951-28c3e71e-4dc2-4124-9fa8-953823e509fb.mp4


alphabetize some stuff, remove duplicates

List any issues that this PR fixes: fixes # , etc...

This pull request proposes the following changes:

Known issues/To do:

sure


Polyfill JS features missing from older browsers

Polyfill JS features missing from older browsers.
Fixes #112
Signed-off-by: Jarno Elovirta<EMAIL_ADDRESS>

Removed flatMap use and polyfilled Promise. @xephon2 are you able to test the latest modifications locally?

Git clone via HTTPS and SSH is blocked, can't do that unfortunately.

@robander @xephon2: I pushed the latest changes from e2a9587 & 7fefe57 to the staging server.
Please try again at https://infotexture.github.io/dita-ot-staging/plugins

Thanks @infotexture. Firefox works now, IE does not and throws:
DOM7011: Der Code auf dieser Seite hat die Zwischenspeicherung für das Vor- und Zurücknavigieren deaktiviert. Weitere Informationen dazu finden Sie unter: http://go.microsoft.com/fwlink/?LinkID=291337
Datei: plugins
HTML1300: Navigation wurde ausgeführt.
Datei: plugins
SEC7118: "XMLHttpRequest" für https://plugins.dita-ot.org/_all.json erforderte Cross Origin Resource Sharing (CORS).
 The CORS issue is to be expected because it's been deployed to different domain.

Note that as long as this is deployed into the staging repo's domain, the plugin page will not work due to CORS. So at some point we just need to stick this into the main repo and test there, unless you can't test locally.

Latest changes from 45f4fd9 are pushed to the staging server.
Should be deployed soon to https://infotexture.github.io/dita-ot-staging/plugins

Works on IE, too. Thanks a lot gentlemen. :+1: :bowing_man:

Since I'm probably the only one who can review my changes, I'll just merge this to get it out.

@xephon2 can you check https://www.dita-ot.org/plugins now?


Add permute_along_axis to BatchedArray

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (09f1c8b) 100.00% compared to head (caa9d03) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #591   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           28        28
  Lines         2374      2382    +8
  Branches       306       306
=========================================
+ Hits          2374      2382    +8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Inputs not doing anything in Home assistant (ZHA). Outputs work

Hi all,
I'm trying to create a simple 4x binary input zigbee device - basically like 4x door/window contacts.
I want them to show "closed" whenever they are shorted to the GND, but as soon as disconnected, it should show "open"
I configure 4 GPIO as inputs with internal Pull-up, however they are still showing as "closed" in Home assistant - regardless if I short them to GND or not.
If I link the inputs to outputs - then the outputs are switching on/off, but what is the point to have the "input" sensors?
What am I missing? Why is HA not showing the actual state of the INPUT?

@alfi666 Did you create and add a custom converter for this device (on the Experts tab)?

@alfi666 Did you create and add a custom converter for this device (on the Experts tab)?

Hello - I did not... not sure what it is and what it does :(
Do I need to "Save custom converter to Z2M"? What would I then used that *.js file for?

@alfi666 Yes, you should use this button. Please look here: https://ptvo.info/zigbee-configurable-firmware-features/expert/

OK, I read thru this, but this seems specific to Zigbee2MQTT - but I’m not using that.
I’m using the ZHA implementation in Home assistant.
Does it mean then the issue is with ZHA implementation and it is not recognizing the inputs correctly?

Fair enough - I’ll try and investigate on HA group if there’s any workaround

@alfi666 have you found any solution?
I'm in the same boat too, using ZHA, my device shows up but with neither output nor input dispalyed in HomeAssistant.
If you want we can join our efforts in investigating ;-)
My understanding (but I could be completely wrong) is that the Zigbee2MQTT custom converter  is the equivalent of the ZHA quirk : it could be that one have to write a custom quirk to allow Home Assistant to understand and display the sensors...
see, for example,

https://github.com/zigpy/zha-device-handlers/issues/416
https://github.com/zigpy/zha-device-handlers/issues/1851 (lot of informations, but I still have to digest them )

@garubi Hello, no I have not found a solution, but I think you're right - it probably could be fixed by ZHA quirk - however I have not had time to deep dive into it yet.
So far I have configured the PTVO firmware as on my screenshot and this way I have outputs which react to input. Given I only need 4 input and don't need output, it works for me like that - I just need to track the state of outputs in HA instead of inputs.

@alfi666 well done!
Maybe in the next weeks I'll try to understand the quirks syntax...
Inthe meantime, to solve my urgent need (lot of WAF factor here... ) I swiched to an ESP32 with EspHome... but really hate to have IOT devices on Wifi...


Appstudio update rhtap-demo-component-yjss

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: rhtap-demo-component-yjss-on-pull-request-
creating pipelinerun rhtap-demo-component-yjss-on-pull-request- in namespace rhtap-demo-dev-yprg-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request


Thermostat BHT-3000-GBLW does not work

Hello
Thermostat BHT-3000-GBLW was working but after latest updates thermostat has unavailable status.
I tried to add it again and ahs error below.

What can I do to connect thermostat?
PS Thermostat are working in Tuya v2 integration but with wrong values.

Did you re-pair the thermostat with the mobile app?  Re-pairing will cause a new local key to be generated, and the old one will no longer work.
Another possibility is that if the mobile app is running, it can block other connections from being made to the thermostat.

You are right. Thermostat is working now after repairing.
Thank you!


Update isLowEnd.ts to support ie11

converted to switch eliminated some code paths and removed dependency on includes
closes:
https://github.com/Zizzamia/perfume.js/issues/148

It seems the build failed, also what's the end coast in bytes of this change?

It seems the build failed, also what's the end coast in bytes of this change?

doesn't seem like the build failed because of the code change,
i've rewritten it to not use include. and refactored it to be sligthly more efficient, net Byte Change is an actual savings not increase :) 🎉

Nice!
Thank you @klh for make this fix happen, I will take care of publishing the next release this weekend. 🌕🚀🌲


Can I customize the ListBox Item text somehow ?

Hello, and thank you very much for this package.
I was wondering if there is a way I can costumize the way the text appears for each item of the ListBox ?
Like choose the font size and family ?
I want to use it on something that will run at Windows PCs, and the default text gets too blurry at PC resolutions unfortunately, because it uses smaller font size stretched up instead of using a larger one.

You can absolutely change the font in the list box.   You can modify the "ListBox Line Item Prefab" and change the font in the "Line Item Main Text"  and "Line Item Sub Text"  UI text fields to whatever you'd like.


wrong border when removeItemButton: true and dir is RTL

Describe the bug
When using the control in RTL and setting options removeItemButton: true
The button border is on the wrong side of the button
To Reproduce
Steps to reproduce the behavior:

Create minimal page.
set HTML dir="rtl"

Expected behavior
when on RTL everything should be mirrored
Screenshots

This bug is old but still valid, This is css code for fixing it. please add it to project :
            .choices[data-type*=select-multiple] .choices__button:dir(rtl),             .choices[data-type*=text] .choices__button:dir(rtl) {                 margin: 0 8px 0 -4px;                 border-right: 1px solid #003642;                 border-left : none;             }

Previous code using :dir() that is better but not completely supported
It wan be written as :
[dir=rtl] .choices[data-type*=select-multiple] .choices__button,
            [dir=rtl] .choices[data-type*=text] .choices__button {
                margin: 0 8px 0 -4px;
                border-right: 1px solid #003642;
                border-left : none;
            }


Move SQL Tests into Separate Module

Move SQL Tests into Separate Module

Seeing all the conflicts, I think it'd be better to open a new PR with these changes re-applied on the master branch.
@deusaquilus Can you maybe close this PR and open a new one with these changes, please?

Closing in favour of https://github.com/zio/zio-quill/pull/2938


File drop can ignore garbage files from PcapSplitter

Codecov Report

Merging #765 into master will decrease coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #765      +/-   ##
==========================================
- Coverage   80.19%   80.17%   -0.02%
==========================================
  Files          51       51
  Lines        4605     4606       +1
==========================================
  Hits         3693     3693
- Misses        912      913       +1

Impacted Files
Coverage Δ

vent/core/file_drop/file_drop.py
72.54% <100%> (+0.54%)
:arrow_up:

vent/api/plugin_helpers.py
73.19% <0%> (-0.23%)
:arrow_down:

Continue to review full report at Codecov.

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


Get param plugin

This PR adds the get_param command, which along with the existing setparam command can be used for manipulating the cell parameter values using TCL, e.g expr

It's still wip as the parameter value returned by the tcl interpreter is garbage.
The get_param command retrieves the value correctly.
get_param CLKIN1_PERIOD top/PLLE2_ADV
setparam -set CLKIN1_PERIOD {"20.0"} top/PLLE2_ADV
get_param CLKIN1_PERIOD top/PLLE2_ADV

returns
CLKIN1_PERIOD:10.000000
CLKIN1_PERIOD:20.0

CLKIN1_PERIOD:10.000000
CLKIN1_PERIOD:20.0

Why would you return the parameter name too?  Why not just return the value?

Why would you return the parameter name too? Why not just return the value?

The function's output and return value are separate things, so why not print out both?
However, currently I do this for debugging purposes.

Why would you return the parameter name too? Why not just return the value?

The function's output and return value are separate things, so why not print out both?
However, currently I do this for debugging purposes.

Sorry, I interpreted that output as the return value.  Once you finish debugging the TCL return value, I don't think the print is needed.

Still need to work on the test, but the command works.

The test has been updated and the plugins tests have been added to the list of all tests. Ready for review, provided the CI is green.

Random question -- Is it set_param and get_param or setparam and getparam -- hopefully not set_param and getparam?

Yosys provides setparam.  Looks like the current plugin is get_param.  @tmichalak, any reason we cannot match yosys's convention here?

any reason we cannot match yosys's convention here?

No other reason than that I think setparam is worse than set_param as in other EDA tools, Yosys included in case of other commands. But since we won't be able to change that it makes sense to make our command consistent, which in this case means equally bad.

Why is params-plugin/tests/xilinx/cells_xtra.v and params-plugin/tests/techmaps/cells_map.v being added? I don't believe it makes sense to add 38k lines of verilog to test this plugin.

Right, they are not needed, since they are supposed to be taken from the Yosys's share directory. I removed them.


Empty array stdout with --json flag

🔧 Changes
Previously, #736 was introduced to return an empty array when no results and the --json flag was passed. This addressed several commands but still missed some commands. There are certainly opportunities to refactor the code and abstract these empty state handlers but I mostly just want to get some implementation in and add test cases.
📚 References
Initial PR: #736
🔬 Testing
Added integration test cases wherever practically possible. Had to reorganize the test files to make them deterministic and independent from each other.
📝 Checklist

[x] All new/changed/fixed functionality is covered by tests (or N/A)
[x] I have added documentation for all new/changed functionality (or N/A)

Codecov Report
Patch coverage: 60.65% and project coverage change: -0.12 :warning:

Comparison is base (b31b615) 71.67% compared to head (e8b00b6) 71.56%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #747      +/-   ##
==========================================
- Coverage   71.67%   71.56%   -0.12%
==========================================
  Files          89       89
  Lines       11160    11207      +47
==========================================
+ Hits         7999     8020      +21
- Misses       2658     2682      +24
- Partials      503      505       +2

Impacted Files
Coverage Δ

internal/display/apis.go
84.89% <0.00%> (-3.83%)
:arrow_down:

internal/display/apps.go
75.15% <0.00%> (-1.40%)
:arrow_down:

internal/display/display.go
84.45% <0.00%> (-2.32%)
:arrow_down:

internal/display/logs.go
52.84% <0.00%> (-1.78%)
:arrow_down:

internal/display/users.go
77.77% <0.00%> (-7.73%)
:arrow_down:

internal/display/actions.go
80.64% <100.00%> (+0.64%)
:arrow_up:

internal/display/custom_domain.go
91.42% <100.00%> (+0.38%)
:arrow_up:

internal/display/log_streams.go
100.00% <100.00%> (ø)

internal/display/organizations.go
100.00% <100.00%> (ø)

internal/display/role_permissions.go
95.55% <100.00%> (+0.31%)
:arrow_up:

... and 3 more

... and 1 file with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Service Of Application CCD

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/PRL-4248
Change description
Documents being uploaded as part of Service of Application will be converted in to PDF
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

No longer needed, changes were released to prod as part of swansea golive


fix(module:notification): don't create new messageId for update

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
This PR is a fix for generating a new messageId for updating notification
[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?
When we update a notification, the service generate a new messageId
Issue Number: 7975
What is the new behavior?
When we update a notification, the service don't generate a new messageId
Does this PR introduce a breaking change?
[ ] Yes
[x] No

@simplejason could you check why the Pipeline is not trigger ? still in the same status Waiting for status to be reported

@simplejason could you check why the Pipeline is not trigger ? still in the same status Waiting for status to be reported

It’s fix ;)


Can not connect to server https://code.iconify.design/

Can you post results of traceroute?

Looks like a temporary outage at CloudFlare DNS in few regions. Website is up and working fine, issue is with CloudFlare.


add GA config

If you're adding Google analytics, it's worth double checking the GDPR implications + whether you are required to ask for cookie consent etc.

Hi @tcbegley, I've made a change to add a consent popup - we're discussing internally on the wording to use and how to configure GA.
When running locally, I've not been able to get any data to actually appear in GA (with any GA plugin), though with debug enabled the console log suggests it's doing the right thing. Probably there is something not quite configured right on my side.

Sounds good. I figured CDEI is under particular scrutiny when it comes to these sorts of things.
On the second point, in my experience analytics services like Google can generally tell when the site is running locally and don't count those visits towards the analytics. If you're not getting obvious errors the easiest thing might be to simply deploy and see what happens (since reverting it is easy enough).

Thanks Tom. Got it to send some data by tweaking some cookie properties to account for running on localhost, but should work as is when deployed proper.


feat: add opfs storage adapter

This adds a minimal implementation of a OPFS storage adapter.

Thanks, @openscript! I'll give it a proper review soon and let you know if I have any requests before merging. I don't suppose you've benched this against IndexedDB? I was thinking this morning I'm not sure which one to recommend to folks.

No I've never really benched it, not in the context of automerge but also not outside of that. Just before I was looking for a benchmark, but I didn't really find a general and current browser storage benchmark. Maybe a project for a rainy weekend :)

Hi! I'm catching up on PRs and spent a bit of time in here. I don't think it's ready to merge as-is. I'd like to make a few suggestions for improvement (which if time allows in the future I may take on myself.)
First: I suspect that passing in the root directory handle instead of sourcing it from the window directly would make this adapter compatible with the Chrome File System APIs as well -- this is quite a cool concept because it could allow sharing of a downloaded storage pool with processes running outside the browser.
That said, if that were going to work you'd need to align your file location / key mapping system with the nodefs implementation. This is probably a good idea anyway, as the current implementation will suffer quite badly from the cost of scanning large filesystem directories if the user has a heap of data.
I'm going to mark this as a draft for now but I suspect we should be able to show that this would be a better default implementation for the project than the nodefs implementation. In fact, it might be easier to port that over... hmmm...

Had a close look to consider landing this as part of the next release but I realized it's putting all the files into one flat directory. We have had reports that this approach leads to serious performance problems for large collections. In fact, it's the same reason that both git itself and the NodeFS implementation fragment the namespace by prefix.
Fixing this wouldn't be too hard -- we can probably crib from the NodeFS implementation -- but I don't think it's something I can sneak in at this hour of my work day. Are you still using it, @openscript? Any experience reports after a few months?


Adding headers to a redirect

This is a feature request to be able to add headers to the redirect within the CheckForRedirects middleware.
One way would be to have a config file for the addon that has a key of headers for example, that accepts an array. It can be an empty array ([]) by default.
Then in the middleware, get this array of headers and include it as the third parameter for the redirect calls at lines 46 and 57.
This would allow headers, such as Cache-Control, to be included with the redirect response.
That's my opinionated approach to it, and happy to PR it if you wanted to consider this.

I’ll get on to that in the morning, too easy!


Test docs deploy

Github Actions to publish documentation site to Netlify.
The actions also:

generate client/java javadoc
generate openapi spec
generate latest version spec definition to be put in static pages

Steps to reproduce test to verify the GitHub action behaviour.

Create branch from main repo and current OpenLineage/docs repo into website directory. Please mind deleting .github dir and .last_spec_commit_id file.
Create test-docs-deploy branch in your private repo from the previously created branch
Create netlify site and and into GitHub NETLIFY_SITE_ID and NETLIFY_TOKEN_SECRET secrets
To run some tests one can do the following modifications:
change version of some facet to non existing - to make sure that newly published site will contain the new version. This will also let verify if openapi got changed.
modify some java doc description of the client/java to make sure java doc gets modified

Pushing the test-docs-deploy branch will trigger the changes. Although normally they run on main branch when main is modified  or tag is created, for repositories other than Openlineage/Openlineage they're triggered on push to test-docs-deploy.

GitHub Actions runs:

https://github.com/pawel-big-lebowski/OpenLineage/actions/runs/10110060569
https://github.com/pawel-big-lebowski/OpenLineage/actions/runs/10110060512


Add SSL to initializer

Add property ssl to FixSessionSettingsProvider. If set to true for
client an ssl context will be added to the netty channel pipeline.

Any thoughts on this?

See https://github.com/kpavlov/fixio/issues/30


Error in delay() example from readme?

In a Jest test it says:
ReferenceError: Bar is not defined
it("injects a circular dep", () => {
  @injectable()
  class Foo {
    constructor(@inject(delay(() => Bar)) public bar: Bar) {}
  }

  @injectable()
  class Bar {
    constructor(@inject(delay(() => Foo)) public foo: Foo) {}
  }

  // construction of foo is possible
  const foo = container.resolve(Foo);
});

You must create these classes in different files to be able to run in the context of a jest test. That's the reason why we wrote tests cases for delay helpers using fixtures/*.ts folder.
Probably running the example without jest will work:
import "reflect-metadata";
import {injectable, inject, container, delay} from "tsyringe";

@injectable()
class Foo {
    constructor(@inject(delay(() => Bar)) public bar: Bar) {}
}

@injectable()
class Bar {
    constructor(@inject(delay(() => Foo)) public foo: Foo) {}
}

// construction of foo is possible
const foo = container.resolve(Foo);


[SPARK-39014][SQL] Respect ignoreMissingFiles from Data Source options in InMemoryFileIndex

What changes were proposed in this pull request?
Currently, InMemoryFileIndex still only get ignoreMissingFiles from SQL Conf, we should respect ignoreMissingFiles from data source options as well.
Why are the changes needed?
As a part of the effort #36069 here
Does this PR introduce any user-facing change?
No
How was this patch tested?
Modified the existing UT

@dongjoon-hyun @cloud-fan Seems like I missed this one. Could you please take a look whenever you have time? Thanks a lot! Have a good day!

Merged to master.


fix option in ready from --install_cypress_with to --install_with

Fixes the install_with option in the readme as it seems to have changed from install_cypress_with to install_with

Thank you


combining 2 arrays with xr.merge() causes temporary spike in memory usage ~3x the combined size of the arrays

What happened:
When attempting to combine two arrays of sizes b1 and b2 bytes: xr.merge([da1, da2]), I observe that memory usage temporarily increases by about ~3*(b1+b2) bytes. Once the operation finishes, the memory usage has a net increase of (b1+b2) bytes, which is what I would expect, since that's the size of the merged array I just created. What I did not expect was the temporary increase of ~3*(b1+b2) bytes.
For small arrays this temporary spike in memory is fine, but for larger arrays this means we are essentially limited to combining arrays  of total size below 1/3rd of an instance's memory limit. Anything above that and the temporary spike causes the instance to crash.
What you expected to happen:
I expected there to be only a memory increase of b1+b2 bytes, the amount needed to store the merged array. I did not expect memory increase to go higher than that during the merge operation.
Minimal Complete Verifiable Example:
# Put your MCVE code here
import numpy as np
import xarray as xr
import tracemalloc

tracemalloc.start()

print("(current, peak) memory at start:")
print(tracemalloc.get_traced_memory())

# create the test data (each is 100 by 100 by 10 array of random floats)
# Their A and B coordinates are completely matching. Their C coordinates are completely disjoint.

data1 = np.random.rand(100, 100, 10)
da1 = xr.DataArray(
    data1,
    dims=("A", "B", "C"),
    coords={
        "A": [f"A{i}" for i in range(100)],
        "B": [f"B{i}" for i in range(100)],
        "C": [f"C{i}" for i in range(10)]},
)
da1.name = "da"

data2 = np.random.rand(100, 100, 10)
da2 = xr.DataArray(
    data2,
    dims=("A", "B", "C"),
    coords={
        "A": [f"A{i}" for i in range(100)],
        "B": [f"B{i}" for i in range(100)],
        "C": [f"C{i+10}" for i in range(10)]},
)
da2.name = "da"

print("(current, peak) memory after creation of arrays to be combined:")
print(tracemalloc.get_traced_memory())
print(f"da1.nbytes = {da1.nbytes}")
print(f"da2.nbytes = {da2.nbytes}")

da_combined = xr.merge([da1, da2]).to_array()

print("(current, peak) memory after merging. You should observe that the peak memory usage is now much higher.")
print(tracemalloc.get_traced_memory())
print(f"da_combined.nbytes = {da_combined.nbytes}")

print(da_combined)

Anything else we need to know?:
Interestingly, when I try merging 3 arrays at once, (sizes b1, b2, b3) I observe temporary memory usage increase of about 5*(b1+b2+b3). I have a hunch that all arrays get aligned to the final merged coordinate space (which is much bigger), before they are combined, which means at some point in the middle of the process we have a bunch of arrays in memory that have been inflated to the size of the final output array.
If that's the case, it seems like it should be possible to make this operation more efficient by creating just one inflated array and adding the data from the input arrays to it in-place? Or is this an expected and unavoidable behavior with merging? (fwiw this also affects several other combination methods, presumably because they use merge() under the hood?)
Environment:
Output of xr.show_versions()

INSTALLED VERSIONS
commit: None
python: 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:39:48)
[GCC 9.3.0]
python-bits: 64
OS: Linux
OS-release: 4.19.121-linuxkit
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: None
LOCALE: en_US.UTF-8
libhdf5: 1.10.6
libnetcdf: 4.8.0
xarray: 0.17.0
pandas: 1.2.3
numpy: 1.19.5
scipy: 1.6.0
netCDF4: 1.5.6
pydap: None
h5netcdf: 0.11.0
h5py: 3.3.0
Nio: None
zarr: None
cftime: 1.5.0
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: 3.4.2
cartopy: None
seaborn: None
numbagg: None
pint: 0.16.1
setuptools: 57.4.0
pip: 21.2.4
conda: None
pytest: 6.2.2
IPython: 7.23.1
sphinx: 3.5.2

I'll let others respond, but temporary memory usage of 3X sounds within expectations, albeit towards the higher end.
If we can reduce it that would be great, but probably needs someone to work on this fairly methodically.

I have a hunch that all arrays get aligned to the final merged coordinate space (which is much bigger), before they are combined, which means at some point in the middle of the process we have a bunch of arrays in memory that have been inflated to the size of the final output array.

Yes, I'm pretty sure this is the case.

If that's the case, it seems like it should be possible to make this operation more efficient by creating just one inflated array and adding the data from the input arrays to it in-place? Or is this an expected and unavoidable behavior with merging? (fwiw this also affects several other combination methods, presumably because they use merge() under the hood?)

Yes, I imagine this could work.
But on the other hand, the implementation would get more complex. For example, it's nice to be able to use np.concatenate() so things automatically work with other array backends like Dask.
By the way, if you haven't tried Dask already I would recommend it for this use-case. It can do streaming operations that can result in significant memory savings.

You're using merge to concatenate along C That is indeed inefficient. Can you use xr.concat([da1, da2], dim="C") instead?

@dcherian Agreed -- I just used this example for the MVCE, but unfortunately we have no guarantees that our data will always fit nicely into this concat-friendly form :(

@shoyer Tried Dask as you suggested, and it helped significantly! Thanks for the suggestion!

@shoyer Tried Dask as you suggested, and it helped significantly! Thanks for the suggestion!

@zachglee, should we close this issue?


Add jupyter-scheduler 1.4.0

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

PR used for recipe testing as destination branch can't be created from the PR. 1.x created, please see https://github.com/conda-forge/jupyter_scheduler-feedstock/tree/1.x


Have an option to initialize collections class to empty collection class instead of null

Joshua Bloch seems to recommend empty collection class instead of null.
https://books.google.com.my/books?id=ka2VUBqHiWkC&pg=PA201&lpg=PA201&dq=josh+bloch+empty+list+instead+of+null&source=bl&ots=yZKmOfq-V4&sig=D3Nv2o2Ixp3uF769r0nBxqS3Vek&hl=en&sa=X&redir_esc=y#v=onepage&q=josh bloch empty list instead of null&f=false
Can we have an option, instead of initializing collections class as null
public class CreateSessionResponse {
    @SerializedName("accounts")
    @Expose
    private List<Account> accounts = null;

Can we have
public class CreateSessionResponse {
    @SerializedName("accounts")
    @Expose
    private List<Account> accounts = Collections.emptyList();

Collections.emptyList() can be problematic for some people because it returns an immutable list. This is often not what people expect when they come to use the list later.
We already have an option to initialize collections:
https://joelittlejohn.github.io/jsonschema2pojo/site/0.4.30/generate-mojo.html#initializeCollections
You can choose to either have them initialized to empty collections, or set to null. This option is present in version 0.4.4 and later.
Do you mean you want this option exposed at jsonschema2pojo.org?

Ya. I am referring to that web site. Thank u for your information!
On Feb 21, 2017 3:02 AM, "Joe Littlejohn"<EMAIL_ADDRESS>wrote:

Collections.emptyList() can be problematic for some people because it
returns an immutable list. This is often not what people expect when they
come to use the list later.
We already have an option to initialize collections:
https://joelittlejohn.github.io/jsonschema2pojo/site/0.4.
30/generate-mojo.html#initializeCollections
You can choose to either have them initialized to empty collections, or
set to null. This option is present in version 0.4.4 and later.
Do you mean you want this option exposed at jsonschema2pojo.org?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/joelittlejohn/jsonschema2pojo/issues/691#issuecomment-281158663,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAS0NIdcGivY09gQnV9jFhCVOIZgC-f7ks5reeNYgaJpZM4MGefa
.


Make ELK containers always restart.

add restart: always to each one.

What is the advantage of adding this configuration to the containers?
From the official doc:
Always restart the container regardless of the exit status. When you specify always, the Docker daemon will try to restart the container indefinitely. The container will also always start on daemon startup, regardless of the current state of the container.
Personally, I do not want the stack to boot up every time my docker-engine starts (OS startup).

What's your thoughts on using restart: unless-stopped instead?

The question is: do most people want their containers do be restarted behind their back?
I don't think so. Docker doesn't restart containers by default, neither should we. People expect a different behaviour can easily set the restart parameter, but forcing it on all users doesn't sound reasonable.

Yes, that's why I'm asking about using the 'unless-stopped' value.
If you have a running docker instance, I would expect it to be running again after the server is rebooted. If I have manually stopped it (or, indeed, never started it), then of course, I would not expect it to be running after a reboot.

I got it, and it may be indeed desirable for you, but again, the default behaviour of docker is to not restart stopped containers.
I'm not questioning whether the setting is safe to use, just trying to keep a consistent (but configurable) behaviour here.


add docs about 30.5GB HEAP limit suggestion

due to maximum heap size for Compressed Oops support

otherwise ack


About multiple-gpus

Hi, do you remember me. Sorry to bother you again. I am a beginner of stable diffusion model and have some problems when running your code. Did you use a single gpu? I encountered CUDA out of memory with a single 3090-24GB and I could not fit the code into 2 or more gpus due to a lack of multiple-gpus' experience. Thank you very much for answering my rookie questions both this and last time.

No worries, our experiments were primarily conducted on a single NVIDIA V100 32 GB GPU.   At the same time, we are actively working on adapting our codebase to support multi-GPU environments.


Select different default indicators for every CPs

At the moment I am not able to select different default indicators for different CPs.
For instance, I would like to select indicators from "Laodecide/Lao Agricultural Census" and display them by default only on the LAO CP, but not in other CPs, since these indicators are only populated for Lao.

now editable through the visualizations configuration field (in the node edit form)