[wip] meson: fix cross compilation of systemd

Motivation for this change
Fixes: #48239

@GrahamcOfBorg build pkgsCross.armv7l-hf-multiplatform.systemd

@GrahamcOfBorg build pkgsCross.aarch64-multiplatform.systemd

Success on aarch64-linux (full log)
Attempted: pkgsCross.armv7l-hf-multiplatform.systemd
Partial log (click to expand)
gzipping man pages under /nix/store/wyx7d6clgny1z8hjx9mx62fwf4pnncg9-systemd-239-armv7l-unknown-linux-gnueabihf-man/share/man/
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
patching script interpreter paths in /nix/store/wyx7d6clgny1z8hjx9mx62fwf4pnncg9-systemd-239-armv7l-unknown-linux-gnueabihf-man
checking for references to /build in /nix/store/wyx7d6clgny1z8hjx9mx62fwf4pnncg9-systemd-239-armv7l-unknown-linux-gnueabihf-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/lyp3rvyzhkmrh000hbanw9dfbmsygzni-systemd-239-armv7l-unknown-linux-gnueabihf-dev
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
stripping (with command armv7l-unknown-linux-gnueabihf-strip and flags -S) in /nix/store/lyp3rvyzhkmrh000hbanw9dfbmsygzni-systemd-239-armv7l-unknown-linux-gnueabihf-dev/lib
patching script interpreter paths in /nix/store/lyp3rvyzhkmrh000hbanw9dfbmsygzni-systemd-239-armv7l-unknown-linux-gnueabihf-dev
checking for references to /build in /nix/store/lyp3rvyzhkmrh000hbanw9dfbmsygzni-systemd-239-armv7l-unknown-linux-gnueabihf-dev...
/nix/store/gw3nmjrkcwjandq9mbk549zyl21pn31l-systemd-239-armv7l-unknown-linux-gnueabihf

Success on aarch64-linux (full log)
Attempted: pkgsCross.aarch64-multiplatform.systemd
Partial log (click to expand)
gzipping man pages under /nix/store/v2p6chfj6ig5x6996d7y2z38qxz7bnl7-systemd-239-man/share/man/
strip is /nix/store/428gs2z4b8f9byvghzlpbjwjb3a7jwxx-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/v2p6chfj6ig5x6996d7y2z38qxz7bnl7-systemd-239-man
checking for references to /build in /nix/store/v2p6chfj6ig5x6996d7y2z38qxz7bnl7-systemd-239-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/mhr4wnxx345y7a864hcg7si5lmjh2sgq-systemd-239-dev
strip is /nix/store/428gs2z4b8f9byvghzlpbjwjb3a7jwxx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/mhr4wnxx345y7a864hcg7si5lmjh2sgq-systemd-239-dev/lib
patching script interpreter paths in /nix/store/mhr4wnxx345y7a864hcg7si5lmjh2sgq-systemd-239-dev
checking for references to /build in /nix/store/mhr4wnxx345y7a864hcg7si5lmjh2sgq-systemd-239-dev...
/nix/store/9jp06gm7086ksccbpwg54qfvf7xih9xb-systemd-239

Success on aarch64-linux (full log)
Attempted: meson
Partial log (click to expand)
patching script interpreter paths in /nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1
checking for references to /build in /nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1...
wrapping `/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1/bin/meson'...
wrapping `/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1/bin/mesonconf'...
wrapping `/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1/bin/mesonintrospect'...
wrapping `/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1/bin/mesontest'...
wrapping `/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1/bin/wraptool'...
/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1/bin /build/meson-0.46.1
/build/meson-0.46.1
/nix/store/88z157hqi9j53hahs65q9sajm1n3kkw7-meson-0.46.1

Success on x86_64-linux (full log)
Attempted: meson
Partial log (click to expand)
patching script interpreter paths in /nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1
checking for references to /build in /nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1...
wrapping `/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1/bin/mesonconf'...
wrapping `/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1/bin/mesontest'...
wrapping `/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1/bin/meson'...
wrapping `/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1/bin/wraptool'...
wrapping `/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1/bin/mesonintrospect'...
/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1/bin /build/meson-0.46.1
/build/meson-0.46.1
/nix/store/v9451gzc0v9yjwrr2iwjxd4f9xfk92k9-meson-0.46.1

Success on aarch64-linux (full log)
Attempted: meson
Partial log (click to expand)
/nix/store/ffa8ds9868ix3kxgll1kv301c3cwhijj-meson-0.46.1

Success on x86_64-linux (full log)
Attempted: meson
Partial log (click to expand)
patching script interpreter paths in /nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1
checking for references to /build in /nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1...
wrapping `/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1/bin/mesonconf'...
wrapping `/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1/bin/mesontest'...
wrapping `/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1/bin/meson'...
wrapping `/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1/bin/wraptool'...
wrapping `/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1/bin/mesonintrospect'...
/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1/bin /build/meson-0.46.1
/build/meson-0.46.1
/nix/store/zdmnqks5fs95bd4rmfp084d07a2718nm-meson-0.46.1

Success on x86_64-linux (full log)
Attempted: pkgsCross.armv7l-hf-multiplatform.systemd
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/5fnxqip5dpnci44cy2dkbc933s6w4cgv-systemd-239-armv7l-unknown-linux-gnueabihf-man
gzipping man pages under /nix/store/5fnxqip5dpnci44cy2dkbc933s6w4cgv-systemd-239-armv7l-unknown-linux-gnueabihf-man/share/man/
armv7l-unknown-linux-gnueabihf-strip is /nix/store/4rvcfng3ficml932m928w9mbfqhvn54z-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
patching script interpreter paths in /nix/store/5fnxqip5dpnci44cy2dkbc933s6w4cgv-systemd-239-armv7l-unknown-linux-gnueabihf-man
checking for references to /build in /nix/store/5fnxqip5dpnci44cy2dkbc933s6w4cgv-systemd-239-armv7l-unknown-linux-gnueabihf-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/pri50z2ynmjwmzn4y6wfvyr1ipc3fc2m-systemd-239-armv7l-unknown-linux-gnueabihf-dev
armv7l-unknown-linux-gnueabihf-strip is /nix/store/4rvcfng3ficml932m928w9mbfqhvn54z-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
stripping (with command armv7l-unknown-linux-gnueabihf-strip and flags -S) in /nix/store/pri50z2ynmjwmzn4y6wfvyr1ipc3fc2m-systemd-239-armv7l-unknown-linux-gnueabihf-dev/lib
patching script interpreter paths in /nix/store/pri50z2ynmjwmzn4y6wfvyr1ipc3fc2m-systemd-239-armv7l-unknown-linux-gnueabihf-dev
checking for references to /build in /nix/store/pri50z2ynmjwmzn4y6wfvyr1ipc3fc2m-systemd-239-armv7l-unknown-linux-gnueabihf-dev...

Indeed this works for me.

Waiting for approvals before merging.

@GrahamcOfBorg build pkgsCross.aarch64-multiplatform.systemd

@GrahamcOfBorg build systemd

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: systemd
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: systemd
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/hi6wlkxb8kqwjcgynv0754xfv9n02dnm-systemd-239-man
gzipping man pages under /nix/store/hi6wlkxb8kqwjcgynv0754xfv9n02dnm-systemd-239-man/share/man/
strip is /nix/store/rpbg8gmqxhz8g61p1plz5d2srs84pvmv-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/hi6wlkxb8kqwjcgynv0754xfv9n02dnm-systemd-239-man
checking for references to /build in /nix/store/hi6wlkxb8kqwjcgynv0754xfv9n02dnm-systemd-239-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/4iwnmw64bnk8imvlazncis0xah38r2w0-systemd-239-dev
strip is /nix/store/rpbg8gmqxhz8g61p1plz5d2srs84pvmv-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4iwnmw64bnk8imvlazncis0xah38r2w0-systemd-239-dev/lib
patching script interpreter paths in /nix/store/4iwnmw64bnk8imvlazncis0xah38r2w0-systemd-239-dev
checking for references to /build in /nix/store/4iwnmw64bnk8imvlazncis0xah38r2w0-systemd-239-dev...

Success on aarch64-linux (full log)
Attempted: meson
Partial log (click to expand)
/nix/store/irms51yq440wsi5ak7fbhbs1m5i27y3x-meson-0.46.1

Success on x86_64-linux (full log)
Attempted: meson
Partial log (click to expand)
wrapping `/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1/bin/mesonconf'...
wrapping `/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1/bin/mesontest'...
wrapping `/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1/bin/meson'...
wrapping `/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1/bin/wraptool'...
wrapping `/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1/bin/mesonintrospect'...
/nix/store/bdnq9v3i00m4y4qsic9in4j4zq8fvvng-python3.7-setuptools-40.4.3/lib/python3.7/site-packages/site.py:26: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp  # Avoid import loop in Python 3
/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1/bin /build/meson-0.46.1
/build/meson-0.46.1
/nix/store/qw8cra68m5kh4jnv3pwqjfnd44klhska-meson-0.46.1

Success on aarch64-linux (full log)
Attempted: pkgsCross.aarch64-multiplatform.systemd
Partial log (click to expand)
gzipping man pages under /nix/store/c0dzq5aa9v86n0z6xvmyp9kkav5kl5pa-systemd-239-man/share/man/
strip is /nix/store/6dpnd5aniypn8124mmy8f88s4mq2zl07-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/c0dzq5aa9v86n0z6xvmyp9kkav5kl5pa-systemd-239-man
checking for references to /build in /nix/store/c0dzq5aa9v86n0z6xvmyp9kkav5kl5pa-systemd-239-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/2g7c1m7yldyyp5dq6j6wpy7pdwjxnynd-systemd-239-dev
strip is /nix/store/6dpnd5aniypn8124mmy8f88s4mq2zl07-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/2g7c1m7yldyyp5dq6j6wpy7pdwjxnynd-systemd-239-dev/lib
patching script interpreter paths in /nix/store/2g7c1m7yldyyp5dq6j6wpy7pdwjxnynd-systemd-239-dev
checking for references to /build in /nix/store/2g7c1m7yldyyp5dq6j6wpy7pdwjxnynd-systemd-239-dev...
/nix/store/shiqgxxlv2j85bma17f1hyd3sszqbdqv-systemd-239

Failure on x86_64-darwin (full log)
Attempted: pkgsCross.aarch64-multiplatform.systemd
Partial log (click to expand)
cannot build derivation '/nix/store/z5f3xscbkvg829pb77w039rmryb9h0qc-gnu-efi-3.0.8-aarch64-unknown-linux-gnu.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/78h9gra07rxhn56prxv0xgzi5jd12w9q-kbd-2.0.4-aarch64-unknown-linux-gnu.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/f38y575ixazn1hakhgd3nlkzjin0xdaj-libcap-2.25-aarch64-unknown-linux-gnu.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/3jzfy7n5jppg6qlna75i1n316b1srqwl-shadow-4.6-aarch64-unknown-linux-gnu.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/d04l8limygw27g7d3kagb5j32hgirzrq-gnutls-3.6.2-aarch64-unknown-linux-gnu.drv': 15 dependencies couldn't be built
cannot build derivation '/nix/store/3q07pg37l9klv3gw626di6q0scjjph8j-util-linux-2.32.1-aarch64-unknown-linux-gnu.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/n5q31nwgi03kgsrm3p3rrpvrvvgcjgr5-glib-2.56.0-aarch64-unknown-linux-gnu.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/zhsg336bx52d1vv5k17daby7y9ail159-libmicrohttpd-0.9.59-aarch64-unknown-linux-gnu.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/gkxa8r8ny5x87ng273v8cd95xg8zm1d5-systemd-239-aarch64-unknown-linux-gnu.drv': 25 dependencies couldn't be built
error: build of '/nix/store/gkxa8r8ny5x87ng273v8cd95xg8zm1d5-systemd-239-aarch64-unknown-linux-gnu.drv' failed

@ericson2314: here is how I would recommend avoiding rebuilding meson for every target:
https://github.com/matthewbauer/nixpkgs/commit/36fed28d8923f516917479bd8ef825b5e2e1760d
It would be nice if meson gave us flags or environment variables to control this like CMake and Autotools does.

Unexpected error: command failed with exit code 1 on x86_64-linux (full log)
Attempted: pkgsCross.aarch64-multiplatform.systemd
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/769a48dkb562awjx81s9imlhcwr1bgdi-gnu-efi-3.0.8-aarch64-unknown-linux-gnu
shrinking /nix/store/769a48dkb562awjx81s9imlhcwr1bgdi-gnu-efi-3.0.8-aarch64-unknown-linux-gnu/lib/crt0-efi-aarch64.o
wrong ELF type
aarch64-unknown-linux-gnu-strip is /nix/store/spkgb1j8yhnj1k6hqvqd4plbh7p39a1a-aarch64-unknown-linux-gnu-binutils-2.30/bin/aarch64-unknown-linux-gnu-strip
stripping (with command aarch64-unknown-linux-gnu-strip and flags -S) in /nix/store/769a48dkb562awjx81s9imlhcwr1bgdi-gnu-efi-3.0.8-aarch64-unknown-linux-gnu/lib
patching script interpreter paths in /nix/store/769a48dkb562awjx81s9imlhcwr1bgdi-gnu-efi-3.0.8-aarch64-unknown-linux-gnu
checking for references to /build in /nix/store/769a48dkb562awjx81s9imlhcwr1bgdi-gnu-efi-3.0.8-aarch64-unknown-linux-gnu...
wrong ELF type
cannot build derivation '/nix/store/n6v073y4s1bm1xcpppy9ihpz7a0a57gx-systemd-239-aarch64-unknown-linux-gnu.drv': 3 dependencies couldn't be built
error: build of '/nix/store/n6v073y4s1bm1xcpppy9ihpz7a0a57gx-systemd-239-aarch64-unknown-linux-gnu.drv' failed

On second thought maybe I'm being a little too harsh on this. If it fixes the systemd issue, maybe it is okay for now. I just wanted to point out it's not exactly a long term solution to this issue.
I can't believe systemd got rid of autotools! If it aint broke, don't fix it.

@matthewbauer I'm going to make this a non-mass-rebuild by skipping the colon thing. Then we can do the colon on your stuff in a staging PR.

Success on aarch64-linux (full log)
Attempted: meson
Partial log (click to expand)
/nix/store/zlhq1mhipva99b3nzki934660pcan14y-meson-0.46.1

Success on x86_64-linux (full log)
Attempted: meson
Partial log (click to expand)
/nix/store/xncfspawp84pnsqvpgycjd48wshspqmn-meson-0.46.1


Always update status bar

Originally when adding files the 'index:' and 'working:' values in the status
bar would be updated reflecting the current branch status. However when using
reset the changes to the branch would not be immediately reflected in the
status bar. The branch status would then be updated in the status bar after
saving the file. This change makes it so that after any git command is run the
branch status is updated in the status bar.

Are the show_in changes related to the statusbar changes?

Simplified a little bit.

Ugh, there is a bug.

show_in needs to be an attribute of the GitRawCommand so that it can be referenced in GenericDone.

Made another change, this might be simpler.


ref: split fetcher and parser functionality

Well, this fails with an error:
2024-03-21T15:22:01.850900Z  INFO Found snapshot, starting from L1 block 19410933
2024-03-21T15:22:01.850958Z  INFO PROGRESS: [ - ] CUR BLOCK L1: 19410933 L2: 459580 TOTAL BLOCKS PROCESSED L1: 0 L2: 0
2024-03-21T15:22:03.167689Z ERROR Failed to parse calldata: invalid Calldata: Invalid data
2024-03-21T15:22:03.180971Z  WARN No new blocks were processed

Admittedly the https://github.com/eqlabs/zksync-state-reconstruct/pull/75 also fails with an error, but a different error (hopefully due to https://github.com/Blobscan/blobscan/issues/327 )... Really, I'd prefer to postpone all refactoring until we have a functioning system...


feat: Add vModelId to PayloadProcessor Payload

Motivation
Currently the payloads passed to PayloadProcessors only contain the modelId, which in the case of vModels will be a "resolved" modelId corresponding to a particular model revision (in particular this will be true when used in KServe modelmesh-serving). It would be useful to include the vModelId too.
Modifications
Add a vModelId field to the Payload class and correspondingly update built-in PayloadProcessor implementations where applicable.
It may be null if the request was directed at a concrete modelId rather than a vModelId.
Result
Both modelId and vModelId are available to PayloadProcessors

FYI @RobGeada

@ckadner yes, ideally we should add such unit tests.

Do I remember you mentioned adding a unit test could be done using some existing helper functions without the overhead of setting up an extensive end-to-end test environment. If it could be done with reasonable effort, should we create an issue to track it where you could add some pointers?

/lgtm

@njhill -- could you resolve the conflicts after merging #120

I see @njhill gave his +1 on the conflict resolution so I will merge this one


Incorrect controller bindings on console

Played this on an Xbox controller and while everything worked fine, including the skip shortcut, I was a bit disappointed to see that both "choose move" and "overhead view" had both defaulted to X, meaning that the game was unplayable without building a whole new bindings setup for this mini game. Wanted to let you guys know in case it gets updated. It was neat to play as far as I did, and it's nice to spend time with the big P

Shoot - I hadn't noticed this since I mostly use mouse+keyboard. I'll look into moving the interact bind to something else in a new version. Thanks for letting me know and glad you enjoyed the mod despite this issue!


Master

Accidently created "master" branch.  Merging back to "main" branch

Merge completed.  "master" branch deleted.


Add Lighthouse CI gitignore

Reasons for making this change:
Adds gitignore for the lighthouse CI report folder.
Links to documentation supporting these rule changes:
https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md#collect
If this is a new template:

Link to application or project’s homepage: https://github.com/GoogleChrome/lighthouse-ci

Can you expand on why this is needed and if this should instead be placed in the Node.gitignore instead.
https://www.brianperry.dev/til/2021/running-lighthouse-ci-server-locally/
Per the contribution guidelines, this file should be placed in the community folder. Please edit the location of the file.
https://github.com/github/gitignore#specialized-templates


Issue with --outFile module 1.8

Hi,
I'm not sure if I'm doing something wrong however I'm trying to use Concatenate amd (or system) modules when using ES6 modules as per https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#concatenate-amd-and-system-modules-with---outfile
What I'm trying to do is to be able to create a library, publish it, installed with JSPM and used as following:
import {StringService, MathService} from "ssv-core";

new MathService().add(1, 3); // for sake of example

However I have 2 issues, one with bundled d.ts files and another with amd/system at runtime not working.
DTS
All d.ts are bundled within 1 file, however they have different modules e.g.
What is generated
declare module "string.svc" {
    export class StringService {
        interpolateUrl(url: string, data: any): string;
    }
}
declare module "math.svc" {
     export class MathService {
        add(value: number, valueB: number): number;
    }
}

What is expected
declare module "ssv-core" {
    export class StringService {
        interpolateUrl(url: string, data: any): string;
    }
export class MathService {
        add(value: number, valueB: number): number;
    }
}

bundled js file
They are within one file however they seem to be still as different modules which is causing me issues when loading them from SystemJS.
Within systemjs this is what I expect to do
map: {
    "ssv-core": "libs/ssv-core",
}

However as it is, I have to create one for string.svc e.g.
map: {
    "string-svc": "libs/ssv-core",
}

On top of that if I do the same for math.svc it won't load unless I comment the string-svc map.
Using typescript 1.8.0

target es5
module amd (tried also system)
SystemJS 0.19.9

Am I doing something wrong or? its not working correctly? Is there a very small example in order to create a library e.g. compiled with d.ts file and js bundled?
if needed the project I have is on github: https://github.com/sketch7/ssv-core/tree/develop its quite small and simple.

Judging by your output, your input must look somewhat like this:
string.svc.ts:
    export class StringService {
        interpolateUrl(url: string, data: any): string { /*implementation*/ };
    }

math.svc.ts
     export class MathService {
        add(value: number, valueB: number): number { /*implementation*/ };
    }

To get the shape it looks like you want, add another file which looks like this:
ssv-core.ts:
export * from "./string.svc.ts"
export * from "./math.svc.ts"

Which is simply collecting the exports you've made into a top-level public API. Additionally, you shouldn't need to use the map field of the systemjs configuration, as we output named modules into the bundle (unless you want to rename them, ofc).

Thanks @weswigham, its quite similar how I have it (or had it at a point) I will try this out again. Thanks.


updated webprotege.json with user-management service account. updated…

… version for api-gateway

maybe merge after https://github.com/protegeproject/webprotege-user-management-service/pull/4 and https://github.com/protegeproject/webprotege-gwt-api-gateway/pull/16 so we can bump versions for user-management-service and api-gateway

i will need to come back here and update gwt-ui, backend-service, api-gateway, user-management, auth-service. please don't merge until update.


Add Wallabag/Read-it-later and Shaarli

Is it possible to add Wallabag/Read-it-later and Shaalit in the sharing choices?
It could be great!

Wallabag done

Shaarli done

Very fast! And it works :)
Thanks!

Thanks for adding the Shaarli share :+1: !


Cannot install WinSetView

Hello LesFerch ... I am not able to install this tool on win 11 ... also not sure I'm doing the install correctly. 1st)  I ran the powershell file, then 2nd) I opened the .hta file with internet explorer (or Edge ... not recalling which) ... 3rd) nothing hapens ... I'm not seeing this use case in your documentation.

There is no "install". This is a portable app. Simply download, extract, and run the HTA. The PowerShell script is run automatically by the HTA. Just follow the instructions.

Hi Les ... thank you for quick response ... I've read the instructions more than once, they're really very good, but looks like I've accidentally created an edge case ... I've checked the .hta default app ... it is Microsoft HTML Application Host ... I just rebooted and clicked the .hta file ... still nothing happens ... would you describe what I should see if it opens correctly?

You should see the interface as shown in the documentation. Your anti-virus/anti-malware software may be blocking or quarantining the HTA, but it should display a message if that's the case. The HTA is designed to run from any drive, including network drives, but you never know. What drive and folder are you trying to run it from? I suggest trying from something like C:\Test and see if that makes a difference. Do also reboot if you just reassociated HTAs to MSHTA. Also I've seen issues where NotePad++ was configured to open HTAs. In that case,, clearing those associations fixed it

If it still doesn't open, try running it with a different user account (create another local account. if you don't already have one set up).

Also, after double-clicking the HTA, does a copy of Microsoft HTML Application Host remain running (i.e. is it listed in Task Manager)?

Please try resetting the Internet Properties Security settings to the default values:

Open Control Panel
Open Internet Options
If not grayed out, click the button Reset all zones to default level
Click OK
Try to run WinSetView.hta

@gmax51 What's the status?

Cannot recreate issue. No further communication from issuer.


Getting Started README page has broken quote formatting when viewed on github

What did you expect to happen?
Copying and pasting the export PATH="$HOME/.emacs.d/bin:$PATH" line in the getting started readme file should work
What actually happened?
Instead, the ~ characters intended to turn it into an inline code block do not work, and so it renders U+201D (right double quotation mark (and it's left version to close)) instead of U+0022 (quotation mark). Because of this, and because most terminals etc. render them the same way, everything will look correct -- even your path variable will seem like it's updated correctly -- but:
❯ doom
zsh: command not found: doom

Describe your attempts to resolve the issue
I tried various ways to reformat that part of the readme, but I don't think it's using standard github markdown (ReST or something?) and I can't find a way to make it work while keeping it in a block quote. I'm happy to figure out a way that works and submit a PR, but wanted to ask what the formatting language is and whether it's ok to do things like not have that bit in a block quote.
Steps to reproduce
Copy and paste the line in question into a unicode character decoder and/or a zsh rc file.
System Information
https://pastebin.com/sHUzYP29

To quote https://github.com/hlissner/doom-emacs/pull/4709#issuecomment-788068213, our in-repo docs are being rewritten, and this will be indirectly fixed in that change. Also, I am not currently accepting PRs to our in-repo docs (docs/*) (see our do-not-PR list). In any case, thanks for bringing it to my attention.

Ah, sounds good! Might be worth putting a note at the top of the README mentioning this, and that (it sounds like?) discourse is more up to date. I did search through the issues, but didn't find this specific one mentioned and also managed to miss #4709 and the do-not-PR list (🙄 @ me). May or may not be worth the trouble, either way I appreciate the quick response!


Caching issues, possibly Vuex related

While trying electron-vue, I saw that old store modules remain, even if I removed the file manually, and even if I restarted npm run dev.
How do I clear the dev cache to make things less messy, at least?
Reproducing the issue
Add this code to App.vue to see old store modules:
async created () {
  console.log(this.$store.state)
},

Remove the Counter from /renderer/store/modules/.
See if Counter is displayed in the list on the next launch of npm run dev.
That is what I see in an app I'm debugging after 3 restarts:

store/modules only contains standard index.js and Common.js file.
Development environment

Node version: v16.1.0
NPM version: 7.16.0
Operating System: Ubuntu 18.04.5 LTS

Deps:
{
  "dependencies": {
    "core-js": "^3.16.0",
    "uuid": "^8.3.2",
    "vue": "^2.5.16",
    "vue-electron": "^1.0.6",
    "vue-router": "^3.0.1",
    "vuex": "^3.0.1",
    "vuex-electron": "^1.0.0"
  },
  "devDependencies": {
    "ajv": "^6.5.0",
    "babel-core": "^6.26.3",
    "babel-eslint": "^8.2.3",
    "babel-loader": "^7.1.4",
    "babel-minify-webpack-plugin": "^0.3.1",
    "babel-plugin-transform-runtime": "^6.23.0",
    "babel-preset-env": "^1.7.0",
    "babel-preset-stage-0": "^6.24.1",
    "babel-register": "^6.26.0",
    "cfonts": "^2.1.2",
    "chalk": "^2.4.1",
    "copy-webpack-plugin": "^4.5.1",
    "cross-env": "^5.1.6",
    "css-loader": "^0.28.11",
    "del": "^3.0.0",
    "devtron": "^1.4.0",
    "electron": "^2.0.4",
    "electron-builder": "^20.19.2",
    "electron-debug": "^1.5.0",
    "electron-devtools-installer": "^2.2.4",
    "eslint": "^4.19.1",
    "eslint-config-standard": "^11.0.0",
    "eslint-friendly-formatter": "^4.0.1",
    "eslint-loader": "^2.0.0",
    "eslint-plugin-html": "^4.0.3",
    "eslint-plugin-import": "^2.12.0",
    "eslint-plugin-node": "^6.0.1",
    "eslint-plugin-promise": "^3.8.0",
    "eslint-plugin-standard": "^3.1.0",
    "file-loader": "^1.1.11",
    "html-webpack-plugin": "^3.2.0",
    "listr": "^0.14.3",
    "mini-css-extract-plugin": "0.4.0",
    "node-loader": "^0.6.0",
    "node-sass": "^6.0.1",
    "sass-loader": "^7.0.3",
    "style-loader": "^0.21.0",
    "url-loader": "^1.0.1",
    "vue-devtools": "^5.1.4",
    "vue-html-loader": "^1.2.4",
    "vue-loader": "^15.2.4",
    "vue-style-loader": "^4.1.0",
    "vue-template-compiler": "^2.5.16",
    "webpack": "^4.15.1",
    "webpack-cli": "^3.0.8",
    "webpack-dev-server": "^3.1.4",
    "webpack-hot-middleware": "^2.22.2",
    "webpack-merge": "^4.1.3"
  }
}

Have you solved this problem?

By deleting this line, cache problem has been dealed

Thanks, this helped.
I'm surprised this part exists, but seems like it has its uses.

Have you solved this problem?

Only now, really.


Bump/electron-29

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

:exclamation: No coverage uploaded for pull request base (develop@2644418). Click here to learn what that means.

Additional details and impacted files
@@            Coverage Diff             @@
##             develop      #34   +/-   ##
==========================================
  Coverage           ?   93.51%
==========================================
  Files              ?       44
  Lines              ?      940
  Branches           ?       97
==========================================
  Hits               ?      879
  Misses             ?       41
  Partials           ?       20

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


Console output rendering issue

I noticed weird rendering issue with the new console in 4.0 RC1:
Sometimes the status line is mixed with task status:

Sometimes task status completely replaces the status line (the following is displayed instead of EXECUTING etc):

This is very similar to #2210. Can you think of any particular interaction or thing about your project that might make this issue distinct from others?

I can't think of anything special. I'll try again on nightly once https://github.com/gradle/gradle/pull/2234 is merged.

I'm almost positively sure it's related to #2234.

@pioterj Ben has merged a fix. Can you please verify by trying what's on release?

@pioterj Please make sure to build a local installation. The wrapper has not been updated yet.

I checked on installation from release branch and I don't see it anymore.

Actually, I can't reproduce on 4.0-rc-1 either. Looks like it wasn't deterministic. I think it's fine to close it.


RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

This commit contains an RFC proposal to promote the aarch64-unknown-linux-gnu Rust target to Tier-1.
Rendered

I’m in broad support of this RFC.

cc @joshtriplett, who has been working on the general Tier RFC, and @rust-lang/compiler more generally.

Should stack probes be required for all tier-1 platforms?  See rust-lang/rust#43241 and rust-lang/rust#49355.

I'd really love to see more non-x86 arches become Tier 2 targets!

I’m in support of this RFC.

Hi again @nagisa. Thank you for your support! :)

Should stack probes be required for all tier-1 platforms? See rust-lang/rust#43241 and rust-lang/rust#49355.

Hi and thanks for your comment.
As it happens, @alexcrichton recently reached out to highlight this gap. There is work pencilled in in Q3 to address this. There is an element of uncertainty involved though (the work is planned to be done as a part of the Linaro Toolchain Working Group and there is a vote involved). However stack probing support in LLVM for AArch64 Linux is understood to be a key requirement so servicing it is an inevitability.
Whether stack probing needs to be a gating feature for Tier-1 attainment is debatable. Given the ultra complex (to the point of being pathologically hard!) synthetic scenarios that need to be arranged in order to get an exploitable stack clash, I would state that the feature should be a high priority ask and not a gate.
Happy to discuss further.
Thanks.

I'd really love to see more non-x86 targets become Tier 1!

Me too! :)

@mbrubeck What do you think of the following requirement (for addition to the target tier policy):

The code generation backend for the target should not have deficiencies that
invalidate Rust safety properties, as evaluated by the Rust compiler team.
For example, if Rust relies on a specific code generation feature to support
a memory safety property, the code generation for the target should support
that feature. If this requirement does not hold, the target must clearly and
prominently document any such limitations, such as via a footnote in the
target tier list.

As someone installing servers on raspberry pi's new 64 bit images, this seems useful!

I'd really love to see more non-x86 targets become Tier 1!

Me too! :)

tbh I'd also love to see RISC-V targets gain a decent status, but as it's rather hard/expensive to get a RV64GC workstation right now, that'd be a bit hard

All tests now pass reliably for aarch64-unknown-linux-gnu! :)
Updated the PR to reflect this.

Should stack probes be required for all tier-1 platforms? See rust-lang/rust#43241 and rust-lang/rust#49355.

@mbrubeck, @alexcrichton : For the record, here's a link to the official ticket tracking this work: https://projects.linaro.org/browse/LLVM-618
There is now a high certainty of this being progressed in Q4 this year. I'll update as and when events occur.

@Lokathor - please could you contact me (somehow! Sorry wasn't exactly sure how else!) ? I'd like to follow-up on the NEON SIMD intrinsics work! Thanks!

You can PM me on the Rust Zulip, that's probably the simplest way.

I'm throwing a link to https://github.com/rust-lang/rust/issues/74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

Hi @pnkfelix

I'm throwing a link to rust-lang/rust#74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

Sure I'll have a look. You probably already know this but just in case: That bug appears to be an armv7 related one and this RFC is for AArch64.

It looks like there hasn't been much discussion here in a while.
It seems like the one outstanding question is the one about stack probes. I like @joshtriplett's suggestion about the policy, and I think that with the lack of stack probe support appropriately noted, there isn't a good reason to avoid promoting aarch64 to tier-1 over that issue; there was a while in which all of the other tier-1 platforms also lacked stack probes, and especially if there is a commitment for work on this issue in the near future, it seems like there's no real reason to hold this up.
With an update to the RFC with the caveat about stack probes, would it be appropriate to send this to FCP, or are there any other outstanding concerns? Is this waiting on the Target Tier Policy RFC, #2803?

With an update to the RFC with the caveat about stack probes, would it be appropriate to send this to FCP, or are there any other outstanding concerns? Is this waiting on the Target Tier Policy RFC, #2803?

I think the stack probes question is indeed the last unresolved one. I don't think we need to wait for the target tier policy RFC, this was an ad-hoc thing from the start. I'm raising the question to the compiler team to see what they think about this before starting FCP.

The compiler team briefly discussed this in their meeting, and we're ready to move into FCP! If someone on the compiler team feels like blocking the merge on addressing the stack probes question please add a concern!
@rfcbot fcp merge

Does merging this without addressing the stack probes question mean that we'll promote this to tier 1 despite lack of stack probes, or will that be decided separately?

@jonas-schievink merging this means promoting aarch64-unknown-linux-gnu to Tier 1 as-is. If you think stack probes are a requirement a concern should be registered by the compiler team.

@rfcbot concern should stack probes be implemented before this target is promoted

The compiler team briefly discussed this in their meeting, and we're ready to move into FCP! If someone on the compiler team feels like blocking the merge on addressing the stack probes question please add a concern!

The relevant discussion is here.
I am adding the concern as I believe we should strive to not regress the soundness properties across our T1 targets now that this particular hole has been patched up, regardless of however long it was open in the past before it got fixed. Or at very least we should make a conscious decision and figure out our policy wrt this question.

The future of stack probes in LLVM 11 is "probe-stack"="inline-asm", and I still intend to switch us over, but AFAICS that's only implemented in the PowerPC, SystemZ, and X86, not ARM or AArch64 yet. Still, that's more than __rust_probestack.

I opened #77071 to track stack probing on arm64 specifically so people have an issue to watch. This is something I'd very much like to see.
As for whether it should block Tier 1: I think there's value in holding all of our Tier 1 targets to the safety guarantees of the others. It would create less confusion and less risk for Rust's brand. That said, I don't necessarily think stack probing itself should be required. I think it really hinges on the bad things that could actually happen for a particular target.
Apologies if I'm being sensationalist: Is it accurate to say that if we move to Tier 1 without stack probing support, we are effectively relaxing the guarantee of no UB without unsafe? Is there a more bounded statement we could make about what's possible in practice that's less scary?

Is it accurate to say that if we move to Tier 1 without stack probing support, we are effectively relaxing the guarantee of no UB without unsafe? Is there a more bounded statement we could make about what's possible in practice that's less scary?

At most, I'd call it a known soundness issue, of which there are many even on Tier 1. "Relaxing the guarantee" sounds like we would never intend to fix this, but really it would just be a pragmatic choice to say that this is not a hard blocker.

Hi @cuviper , @tmandry , @nagisa , @jonas-schievink and others on the approvals list: RFC author here. Thanks for the comments. All insightful and on point.
There's a couple of things I wanted to say by-the-by, in the spirit of this discussion and the broader RFC:

The guideline we used for structuring all the work done ahead of making this RFC submission was the existing target tier policy document and unfortunately in all the discussions we had, the stack probing aspect did not bubble up either directly or indirectly. It's clearly a gap that needs to be filled without doubt.

As mentioned earlier here: At present, work to add support for stack probing for AArch64 in LLVM is slated to begin in Q4 this year as a part of the Linaro Toolchain Working Group activities (link provided earlier). This unfortunately isn't a guarantee though (it involves a vote etc) so given the narrative here, we will now try to find alternative ways to fill this gap. I'm personally pretty confident that we will resolve this in a reasonable time frame. However it is not possible at present to state exactly when. From past experience, compiler mods of this sort do tend to drag on for a fair bit before landing in mainline repos given the potential implications for multiple triplets associated with the processor target in question.

As also mentioned earlier here: Stack clashing - the primary scenario for which stack probing is the mitigation - is an arguably pathological scenario to exploit. Not meaning to trivialise that scenario of course but I wanted to put that on the table as a fact that I feel should be considered when such decisions are made. I do realise that some of the argumentation that is being used around the lack of stack probing here is oriented somewhat differently - as in - it raises concerns about UB implications from a Rust PoV and not the stack clashing reality more directly. Still thought it best to bring it up. Completely agree that a clear problem has been presented irrespective and we would like to see the right solution happen - even if that means the RFC's merge is delayed.

About delay: This is a slightly unusual one to articulate in such a forum but I feel it is important to do so. Note that this is my personal opinion. It has taken a fair amount of engineering: actual, social and strategic, to get the right folks in an organisation such as Arm to recognise the value proposition that Rust presents for the Arm ecosystem. As is inevitably the case for any such organisation, perception and optics play a strong role in shaping the trajectory of long term strategic plays - especially around relatively new technology.  Today, we know that Rust on AArch64 Linux is already being productised despite this target triplet not having the Tier-1 'badge' (for want of a better phrase). That bodes well already, which is neat. However, not having the badge does limit the rate of pervasive uptake of the language, especially on AArch64 based Linux systems - which are hugely popular across an astonishing spectrum of market domains - most of which are a perfect fit for Rust.

Would getting the badge in a hurry change that in a meaningful way ? Hard to say. That said, my experience in speaking with relevant parties in the Arm ecosystem leads me to maintain that the sooner we get the badge, the sooner we can usher in a lot of interest in Rust more generally and Rust on AArch64 Linux, more specifically.
We will of course respect the outcome of your decision, either which way. If you decide that the RFC merge needs to gate on stack probing availability in LLVM and it's coupling to Rust for AArch64 Linux, that's the direction we will move in. I felt it important to share the above points, all the same.
Thanks!

I do agree with @cuviper's point that the absence of a desired feature should be filed as a bug instead of being considered a blocker to policy. Especially if a root issue is LLVM support.
Personally speaking, I would rather not have this promotion blocked on known technical details, as I see tier-labels rather as a statement of support and quality levels.

At most, I'd call it a known soundness issue, of which there are many even on Tier 1.

Yes, but I would wager that most of those (at least, the ones that have been open for awhile) are fairly limited in scope. If not, they'd be P-critical and we'd be fixing it immediately.
What's the scope of this? Stack overflows can happen in many programs, and I've seen Rust functions with some very large stack frames. It's not uncommon for programs to have a recursion level dictated by user input (e.g. parsers). So my question is about whether that can be exploited in the wild.

"Relaxing the guarantee" sounds like we would never intend to fix this, but really it would just be a pragmatic choice to say that this is not a hard blocker.

Fair enough. What I was trying to get across is that Rust programmers on Tier 1 targets enjoy freedom in practice from memory exploits when writing safe code. I'm just trying to make sure that remains the case.

Stack clashing - the primary scenario for which stack probing is the mitigation - is an arguably pathological scenario to exploit.

This may be true and I think it's an important point. Despite some of my earlier phrasing, my concern isn't about UB existing in the abstract, but about UB that can lead to high-severity exploits in reality. If it matters, I think it's also fair to consider any mitigations (like ASLR) that Linux enables by default, since this RFC is about Linux.
I'm not a security expert and I'd be happy to learn that this is pretty much impossible to exploit in practice :)

Personally speaking, I would rather not have this promotion blocked on known technical details, as I see tier-labels rather as a statement of support and quality levels.

I tend to agree with this. A statement of support I have no problem with, and I personally would like to see arm64 get promoted as soon as possible. It's clear that this is a platform of significant interest to Rust users and I count myself as one of them!
It's the quality level that I'm double checking here. I'd note that users' expectations around quality are shaped by the state of other Tier 1 targets. Even if they used to have this problem, most people have probably forgotten this, and Rust is more mature and stable overall than it was 3 years ago.

I tend to agree with this. A statement of support I have no problem with, and I personally would like to see arm64 get promoted as soon as possible. It's clear that this is a platform of significant interest to Rust users and I count myself as one of them!

It's the quality level that I'm double checking here. I'd note that users' expectations around quality are shaped by the state of other Tier 1 targets. Even if they used to have this problem, most people have probably forgotten this, and Rust is more mature and stable overall than it was 3 years ago.

I think this is an important question! I think the main problem is that this question would not come up as a blocking question on a purely technical RFC like an API: it is clear that the API is not yet implemented. If this RFC is merged, is aarch64-unknown-linux-gnu immediately tier1 or is there an implementation issue that lists a number of things that need to be fixed before this RFC is considered "implemented"?
Also, statements of quality are also a statement about future issues, that we will care for them, that there's eyes and that issues may be release-blocking.

Hi @skade, @tmandry, @cuviper, @jonas-schievink, @pietroalbini, @nikomatsakis, others on the approvals list: I wanted to share that this commentary helped prioritise things. :)
I can now confirm that work to add probe-stack support to LLVM for AArch64 will officially begin from October 1st (so next week) with a dedicated expert assigned to implement this feature. The implementation will be funded by Arm and done up through Linaro (a not for profit alliance of Arm ecosystem partners).
This link which I've shared previously has some details (not all of them openly available sadly).
The relevant change is that the 'Fix/version(s)' attribute, which was previously empty has now been changed to 'LLVM 12'.
This means that the feature is now intended to be a part of the LLVM 12 release. Extrapolating from LLVM's release history, that is likely to be around Q2/Q3 next year. The Rust linkage can be developed in tandem, I suppose. I expect that the actual implementations will be available sooner in RCs etc but we should assume the release as the end-point for feature availability.

Hi folks.
I note from the commentary here that the general view on the topic at hand has oriented around the caveat posited in @joshtriplett's proposed upcoming draft of the Target Tier policy, and I quote:
The code generation backend for the target should not have deficiencies that
invalidate Rust safety properties, as evaluated by the Rust compiler team.
For example, if Rust relies on a specific code generation feature to support
a memory safety property, the code generation for the target should support
that feature. If this requirement does not hold, the target must clearly and
prominently document any such limitations, such as via a footnote in the
target tier list, and the Rust compiler team must be satisfied with the
balance between these limitations and the difficulty of implementing the
necessary features.

On that basis, I'd like to request @aidanhs, @estebank, @jonas-schievink, @nagisa, @nellshamrell and @pnkfelix to please either follow through with casting their vote in favour of this RFC here or to please share their counters so we can proceeed accordingly. Thanks!

With stack probing being scheduled for implementation, my remaining concern is mismatched expectations. I think we could solve that with clear and explicit documentation.

@rfcbot resolve should stack probes be implemented before this target is promoted
After some discussion we did not reach anything very conclusive but:

There's a person working on an RFC to better define the requirements for targets;
There were no objections to promoting the target and just filing an issue for lack of safeguards like stack probes.

hence resolving.

Huzzah! The @rust-lang/compiler @rust-lang/infra @rust-lang/release teams have decided to accept this RFC.
To track further discussion, subscribe to the tracking issue here: https://github.com/rust-lang/rust/issues/78251

Awesome! :) Thanks everyone for all the feedback and support! :)

Would it be possible to update the link in the first post? Currently it's broken unfortunately.

Updated the rendered link!


Ran instructions in readme, get error

Is error I got on npx expo run:ios. Latest commit.
In terminal:
› Installing on iPhone 15 Pro Max
› Opening on iPhone 15 Pro Max (com.reactconf.app)
› Opening exp+react-conf-app://expo-development-client/?url=http%3A%2F%2F<IP_ADDRESS>%3A8081 on iPhone 15 Pro Max

› Logs for your project will appear below. Press Ctrl+C to exit.
iOS Bundled 4726ms node_modules/expo-router/entry.js (1868 modules)
 ERROR  ReferenceError: Property 'React' doesn't exist

This error is located at:
    in Layout
    in Unknown (created by Route())
    in Suspense (created by Route())
    in Route (created by Route())
    in Route() (created by ContextNavigator)
    in RNCSafeAreaProvider (created by SafeAreaProvider)
    in SafeAreaProvider (created by wrapper)
    in wrapper (created by ContextNavigator)
    in EnsureSingleNavigator
    in BaseNavigationContainer
    in ThemeProvider
    in NavigationContainerInner (created by ContextNavigator)
    in ContextNavigator (created by ExpoRoot)
    in ExpoRoot (created by App)
    in App (created by ErrorOverlay)
    in ErrorToastContainer (created by ErrorOverlay)
    in ErrorOverlay (created by withDevTools(ErrorOverlay))
    in withDevTools(ErrorOverlay)
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer
    in main(RootComponent), js engine: hermes
 ERROR  ReferenceError: Property 'React' doesn't exist

This error is located at:
    in Layout
    in Unknown (created by Route())
    in Suspense (created by Route())
    in Route (created by Route())
    in Route() (created by ContextNavigator)
    in RNCSafeAreaProvider (created by SafeAreaProvider)
    in SafeAreaProvider (created by wrapper)
    in wrapper (created by ContextNavigator)
    in EnsureSingleNavigator
    in BaseNavigationContainer
    in ThemeProvider
    in NavigationContainerInner (created by ContextNavigator)
    in ContextNavigator (created by ExpoRoot)
    in ExpoRoot (created by App)
    in App (created by ErrorOverlay)
    in ErrorToastContainer (created by ErrorOverlay)
    in ErrorOverlay (created by withDevTools(ErrorOverlay))
    in withDevTools(ErrorOverlay)
    in RCTView (created by View)
    in View (created by AppContainer)
    in RCTView (created by View)
    in View (created by AppContainer)
    in AppContainer
    in main(RootComponent), js engine: hermes
    ```

    Thanks a lot.

Sorry about that. This should be fixed now. After pulling latest, re-install node-modules and clear the cache, and it should all work.
rm -rf node_modules
yarn
npx expo start --reset-cache

Sorry about that. This should be fixed now. After pulling latest, re-install node-modules and clear the cache, and it should all work.
rm -rf node_modules
yarn
npx expo start --reset-cache

I face the same issue. But your solution didn't work for me.
After importing const React = require('react'), it fixed issue.

@kadikraman
sorry, I saw the merged request now. I   pulled it again. and it is fixed


Error about "alfworld-play-tw" in the terminal

Hello, I successfully download the ALFWorld, but when I type "alfworld-play-tw" in the terminal, an error occured. Here is the output:
/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/torch/cuda/init.py:619: UserWarning: Can't initialize NVML
warnings.warn("Can't initialize NVML")
/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/torch/cuda/init.py:749: UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 9010). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at ../c10/cuda/CUDAFunctions.cpp:108.)
return torch._C._cuda_getDeviceCount() if nvml_count < 0 else nvml_count
Playing '/XXXX/json_2.1.1/train/pick_and_place_with_movable_recep-AppleSliced-Bowl-Fridge-21/trial_T20190919_030237_944406'.
Traceback (most recent call last):
File "/XXXX/PythonVenv/ALFWorld/bin/alfworld-play-tw", line 92, in
main(args)
File "/XXXX/PythonVenv/ALFWorld/bin/alfworld-play-tw", line 51, in main
obs, infos = env.reset()
^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/gym/envs/textworld.py", line 48, in reset
obs, infos = super().reset()
^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/gym/envs/textworld_batch.py", line 118, in reset
self.batch_env.load(gamefiles)
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/batch/batch_env.py", line 217, in load
env.load(game_file)
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/core.py", line 336, in load
return self._wrapped_env.load(path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/alfworld/agents/environment/alfred_tw_env.py", line 93, in load
super().load(gamefile)
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/core.py", line 336, in load
return self._wrapped_env.load(path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/alfworld/agents/environment/alfred_tw_env.py", line 31, in load
super().load(*args, **kwargs)
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/core.py", line 336, in load
return self._wrapped_env.load(path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/core.py", line 336, in load
return self._wrapped_env.load(path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/wrappers/generic.py", line 22, in load
self._wrap(textworld.start(gamefile, self.request_infos))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/helpers.py", line 52, in start
env.load(path)
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/pddl/pddl.py", line 61, in load
self._pddl_state = pddl_logic.PddlState(self.downward_lib, self._game_data["pddl_problem"], self._logic)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/pddl/logic/init.py", line 213, in init
facts = [atom.get_fact(self.name2type) for atom in atoms]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/pddl/logic/init.py", line 213, in
facts = [atom.get_fact(self.name2type) for atom in atoms]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/pddl/logic/init.py", line 135, in get_fact
arguments = [Variable(self._get_var_name(arg), name2type[arg]) for arg in args if arg]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/XXXX/PythonVenv/ALFWorld/lib/python3.11/site-packages/textworld/envs/pddl/logic/init.py", line 135, in
arguments = [Variable(self._get_var_name(arg), name2type[arg]) for arg in args if arg]
~~~~~~~~~^^^^^
KeyError: 'val1'
What confused me is that this error does not always occur if I type "alfworld-play-tw" in the terminal, sometimes (maybe 1 in 5) this game can run successfully. It seems that the error is about NVIDIA drive version and the Pytorch version, but my workstation does not have a GPU, how can I modify the configuration so that the game could run purely on CPU? I think since I have a small chance to run it successfully, it means my workstation has met the requirement to run "alfworld-play-tw", and maybe there is such a configuration to avoid this game to use GPU?

The KeyError: 'val1' error has nothing to do with Nvidia. Some games from the ALFRED dataset are not supported by ALFworld. By default, alfworld-play-tw randomly pick a game from the whole ALFRED dataset (see note on https://github.com/alfworld/alfworld/tree/master/scripts#play).
I believe this PR https://github.com/alfworld/alfworld/pull/61 would avoid sampling those games in the first place. I still need to review it and merge though.

The KeyError: 'val1' error has nothing to do with Nvidia. Some games from the ALFRED dataset are not supported by ALFworld. By default, alfworld-play-tw randomly pick a game from the whole ALFRED dataset (see note on https://github.com/alfworld/alfworld/tree/master/scripts#play).
I believe this PR #61 would avoid sampling those games in the first place. I still need to review it and merge though.

Got it! Thanks to your reply!

alfworld-play-thor
I get the error:
xdpyinfo:  unable to open display ":0".
subprocess.call("xdpyinfo", stdout=dn, env=env, shell=True) == 0
AssertionError: Invalid DISPLAY :0 - cannot find X server with xdpyinfo

Are you running ALFWorld on a remote machine by any chance?

Are you running ALFWorld on a remote machine by any chance?

right!!
My environment is a cluster environment where we are unable to install an X server. I planned to simulate the X server using xvfb-run during startup. However, in ai2thor/controller.py at line 1182
self.last_event = self.server.receive(),
I am unable to receive any messages and it gets stuck at this point.
Is it not possible to execute commands on the cluster?
My versions are: ai2thor==3.1.0 alfworld==0.3.4
The command I executed is as follows:
xvfb-run -s "-screen 0 300x300x24" accelerate launch --config_file config_zero2.yaml --main_process_port 29330 ../main_alf.py
The main_alf.py code is as follows:
import other packages
from alfworld.agents.environment.alfred_thor_env import AlfredThorEnv
env = AlfredThorEnv(config, train_eval='train')
env.init_env(batch_size=1)

This seems to be an issue with your cluster. It is hard for me to troubleshoot.
That said, the ai2thor version should be ai2thor==2.1.0 and do make sure you have werkzeug==2.0.3 installed.


add Duration to kube-core

Motivation
Some objects contain strings which represent durations. These strings are often parsed in the format implemented by the Go standard library's time.Duration type. For example,
https://github.com/kubernetes-sigs/gateway-api/pull/1997 adds duration fields to the Gateway API's HTTPRoute type, and explicitly specifies that they are formatted according to the Go time.Duration format:

// Timeout values are formatted like 1h/1m/1s/1ms as parsed by Golang time.ParseDuration
// and MUST BE >= 1ms or 0 to disable (no timeout).

(ref: https://github.com/kubernetes-sigs/gateway-api/blob/659d478ec039271a95429b133a999d1593808e96/geps/gep-1742.md?plain=1#L336-L337)

In the Go apimachinery's meta package, there is a v1.Duration struct for representing durations, whose JSON representation is a string in the Go time.ParseDuration/time.Duration format:
https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration.
That type is used in the Go bindings for Kubernetes objects that include durations in this format, such as in the Gateway API proposal I mentioned above:

       // +kubebuilder:validation:Format=duration
       Request *metav1.Duration `json:"request,omitempty"`

(ref: https://github.com/kubernetes-sigs/gateway-api/blob/659d478ec039271a95429b133a999d1593808e96/geps/gep-1742.md?plain=1#L353-L354)

Solution
This branch adds a new Duration type to kube-core, which is essentially an equivalent to metav1.Duration. This is a wrapper around a Rust std::time::Duration which can be serialized and deserialized using the same format as the Go metav1.Duration type. In addition, because Go time.Durations are represented by a signed number, Durations can also be negative if the provided duration string is negative, and implement the correct ordering properties when compared to each other and to std::time::Durations. A parsed Duration can be converted into a std::time::Duration by discarding its sign.
Closes #1222

Do you think this would also fit in the metadata module?

I wasn't sure about this --- the Go apimachinery type is in the meta package, but AFAICT the metadata module here doesn't contain all the types found in apimachinery's meta package --- most of those types are generated in k8s-openapi AFAICT. Perhaps @clux has an opinion on where this ought to go?

This looks all great to me now. Thanks a lot for this very clean contribution. Will merge and do a release tomorrow.

Thanks! <3
Looks like CodeCov is a bit upset that total coverage went down a bit...does that matter to you enough to justify writing tests for the equality and ordering implementations?

Looks like CodeCov is a bit upset that total coverage went down a bit...does that matter to you enough to justify writing tests for the equality and ordering implementations?

Ah, that is true. There are some slightly hairy cases in there around sign change comparisons where it would be nice to have a few short tests to lock the behaviour down and have verification.
If you have it in you, it would be appreciated 👍

Looks like CodeCov is a bit upset that total coverage went down a bit...does that matter to you enough to justify writing tests for the equality and ordering implementations?

Ah, that is true. There are some slightly hairy cases in there around sign change comparisons where it would be nice to have a few short tests to lock the behaviour down and have verification.
If you have it in you, it would be appreciated +1

I'm going to be traveling for the next several days, so I can't promises I can get to it any time soon..

I'm going to be traveling for the next several days, so I can't promises I can get to it any time soon..

Hehe, ok, don't worry, it's a minor nice-to-have. I'll send this in and get a long-delayed release in :-)


feat(FX-3670): Enable the "save alert" button whenever the "Create Alert" screen has pending updates

The type of this PR is: Feature

This PR resolves FX-3670
Description
At the moment, the "save alert" button is blocked on the "Create Alert" screen if the user already has a previously saved alert with the same criteria. We need to make changes and make the button enable whenever the screen has pending updates
Demo
https://user-images.githubusercontent.com/3513494/147357267-cd2526f6-588a-40ce-ac49-dbe4bb0f48df.mp4

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[x] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Enable the "save alert" button whenever the "Create Alert" screen has pending updates - dimatretyak

iOS user-facing changes

Android user-facing changes

Dev changes

This PR contains the following changes:

Cross-platform user-facing changes (Enable the "save alert" button whenever the "Create Alert" screen has pending updates - dimatretyak)

  Generated by :no_entry_sign: dangerJS against a3d29e7e88565a98abe3d2942d8194d701b58ee2


how to modify the model to support 512 resolution?

I'm experimenting other super resolution models instead of the pix2pix. However, this extra step is not necessary if the output is 512 resolution. Did anyone try to modify the model to output HD photos?
The HD training dataset is available, VGGface2HD, just like the simswap which support 512 resolution.

any news on this?

any news on this?


fix the reference error due to extra $ in default variable

This PR fixes #12522
PR in main : https://github.com/microsoft/azuredatastudio/pull/12523

Will wait on sign off for Main and Pr validation build t compete before merge.

Pull Request Test Coverage Report for Build 264540962

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 38.914%

Totals

Change from base Build 264469286:
0.009%

Covered Lines:
19242

Relevant Lines:
45114

💛  - Coveralls


Add Swift 3 support

Lets create a separate branch so we can add Swift 3 support

@Alua-Kinzhebayeva If you create a swift3 branch on this repo, I can add support for it from my branch in my fork

@ranunez good idea. will do

done 😄

This issue was fixed with #7


Patches updates for RHOSP 16.1 Z6 release

Hi,
This PR covers,

raid.patch update for Latest Z6 release
Added KernelArgs patch in case of NFV deployments on Z6
Modified <IP_ADDRESS> to <IP_ADDRESS> (private DNS) in checkpoints for avoiding failures in deployments when <IP_ADDRESS> is blocked
Updated image tag

FYI: This is fully tested on 14 G stamps with Z6, will test on 15G after virt-customize issue is resolved.
@gaelrehault Kindly review the PR and let me know if you have any concerns/comments?  Thanks

Can you get rid of <IP_ADDRESS> ( that s an internal Dns ) , and replace with self.settings.name_server ?

Can you get rid of <IP_ADDRESS> ( that s an internal Dns ) , and replace with self.settings.name_server ?

Sure Gael, let me do that quickly and update. Thanks

Replaced and verified Checkpoints with name_server.


cx(0,1) gate.to_matrix()

Environment

Qiskit version: 1.2.4
Python version: 3.10
Operating system: Google Colab

What is happening?
The gate.to_matrix() function returns an erroneous matrix for the gate cx(0,1). It returns the same matrix as for gate cx(1,0).
How can we reproduce the issue?
qc = QuantumCircuit(2)
qc.cx(1, 0)
qc.cx(0, 1)
Iterate through each gate in the quantum circuit
for gate_data in qc.data:
gate = gate_data.operation  # Get the gate object
matrix = gate.to_matrix()  # Get the matrix representation of the gate
print(matrix)
What should happen?
should answer different matrices for cx(0,1) and for cx(1,0). This is for cx(0,1)
[[1.+0.j 0.+0.j 0.+0.j 0.+0.j]
[0.+0.j 1.+0.j 0.+0.j 0.+0.j]
[0.+0.j 0.+0.j 0.+0.j 1.+0.j]
[0.+0.j 0.+0.j 1.+0.j 0.+0.j]]
This would be for cx(1,0).
[[1.+0.j 0.+0.j 0.+0.j 0.+0.j]
[0.+0.j 0.+0.j 0.+0.j 1.+0.j]
[0.+0.j 0.+0.j 1.+0.j 0.+0.j]
[0.+0.j 1.+0.j 0.+0.j 0.+0.j]]
Translated with DeepL.com (free version)
Any suggestions?
No response

but if you want the matrix form of a (small) circuit, you can do
from qiskit.quantum_info import Operator

Operator(my_circuit)

operator = Operator(gate)

matriz = operator.data
display(array_to_latex(matriz))

for the gate cx(0, 1) and for the gate cx(1, 0) gives the same matrix. Mathematically this is not the case

Yes, a circuit instruction is a combination of the gate object and the qubits it's applied to. Your examples keep asking for the matrix of the gate object alone, though - you can see as you do instruction, qubits, clbits = gate_data that you're separating the gate object from the qubits it acts on.
A circuit is a full context that contains gates applied to qubits. If you want this, the easiest way is to use the Operator constructor on a circuit, like I showed above.

It is clearly a bug. You can easily distinguish if it is cx(0, 1) from cx(1, 0). And the gate.to_matrix() method should return the correct matrix.
Gate: cx, Qubits: [Qubit(QuantumRegister(2, ‘q’), 0), Qubit(QuantumRegister(2, ‘q’), 1)], Clbits: []
Gate: cx, Qubits: [Qubit(QuantumRegister(2, ‘q’), 1), Qubit(QuantumRegister(2, ‘q’), 0)], Clbits: []

For one further explanation: you are calling the method Gate.to_matrix.  The qubits are not part of a Gate.  The qubits are attached part of a CircuitInstruction, which is what you get when you iterate through QuantumCircuit.  You can read more in the documentation: https://docs.quantum.ibm.com/api/qiskit/circuit#module-qiskit.circuit.
If you have further queries about the basic data model, I'd suggest you take them to a help forum like the Qiskit slack rather than the bug tracker.  I'll close this issue now, because there's no bug here, but please feel free to ask for help in the Slack workspace.

Do what you want. For me it's a bug.
Create this circuit and see what matrix responds to it.
qc = QuantumCircuit(2)
qc.cx(0, 1)
In the same way you can do this
operator = Operator(gate)
matriz = operator.data
display(array_to_latex(matriz))
Thanks anyway


Issue with loading drop page

3am CET, one person (rubenzmart) had issue with loading page. This is what the page showed him:

Maybe it was because it was being released at that time. Work for me


re-encode chat files as UTF-8

Encode all chat files as UTF-8 instead of UTF-16. This should prevent issues with encoding detection and it has the nice side benefit of reducing the size of most of the files by nearly 50%.
I actually don't know off the top of my head whether the source engine cares or not and I don't have TF2 installed to test. However, this way the files are consistent with the rest of the hud which we already know works encoded as UTF-8.

NB: github will always show these files as binary because of the non-printable control characters they contain, which the source engine uses to control text color in the chat box. Would be nice if VDF had escape sequences for arbitrary bytes. Oh well.

Just because I don't have too much familiarity when it comes to encoding-- is there anything I should do on my end to ensure this sticks when I'm working on the hud locally?
I suppose short of not changing the encoding of the files back myself, I imagine there aren't any other ways they could unintentionally be reverted to UTF-16, but I figured it couldn't hurt to ask since I know little in this area.

ty for spotting this btw :D

ah wait a sec, right after committing I remembered these chat files need to be encoded in Little Endian or they won't work (as far as I remember). let me double-check

yeah, setting encoding to UTF-8 breaks the language tokens unfortunately


Incorrect handling of ranges

First off, thanks for such an awesome project, has been super useful.
I been getting weird failures with s3manager.Downloader. Attempting to download a small file (700 odd-bytes) always returns 0 length content and no error.
This occurs with both directfs and memory backends (only two that I tested).
It turns out func (g *GoFakeS3) getObject() is always returns an ErrInvalidRange. Unfortunately this error appears to silently ignored by s3manager so it returns 0-length files.
Tracing through the code, it appears the problem is triggered by this logic because s3manager.Downloader defaults to using PartSize of 5M.
Ignoring this unexpected behaviour of s3manager, I think the logic should, rather than being:
	if start < 0 || length < 0 || start > size || start+length > size {
		return nil, ErrInvalidRange
	}

	return &ObjectRange{Start: start, Length: length}, nil

probably be something along the lines of:
	if start < 0 || length < 0 || start > size {
		return nil, ErrInvalidRange
	}

	if start+length > size {
		return &ObjectRange{Start: start, Length: size - start}, nil
	}

	return &ObjectRange{Start: start, Length: length}, nil

If you're okay with this I can raise a PR.
Thanks!

Great find @jwoffindin! Thank you! It looks like I didn't read the spec properly. From https://tools.ietf.org/html/rfc7233#section-2.1:
   A client can limit the number of bytes requested without knowing the
   size of the selected representation.  If the last-byte-pos value is
   absent, or if the value is greater than or equal to the current
   length of the representation data, the byte range is interpreted as
   the remainder of the representation (i.e., the server replaces the
   value of last-byte-pos with a value that is one less than the current
   length of the selected representation).

If you'd like to submit a PR, that'd be great! There's a half-decent test case in range_test.go for this that'll also need an update.

A PR would be awesome! And as @shabbyrobe wrote, great finding.

Pretty sure #37 got this all sewn up, so I'll close.


qutebrowser: update pdfjs to 3.9.179

Description of changes
Bump pdfjs used inside of qutebrowser.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 250176 run on x86_64-linux 1

4 packages built:

qutebrowser
qutebrowser-qt6
qutebrowser-qt6.dist
qutebrowser.dist


export as PDF

[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Is your feature request related to a problem? Please describe.
After the update, draw.io no longer allows exporting to PDF from the 'Export as -> Advanced' option. The direct 'Export as PDF' option always has issues with sizing.
Describe the solution you'd like
Is it possible to restore the previous method of exporting to PDF from the 'Advanced' option?
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

The previous method can not be restored. What are the issues with sizing?

The issue with sizing is that, in the previous 'Export as -> Advanced' method, the PDF would automatically adjust the size of the content, eliminating any unnecessary whitespace. The current 'Export as PDF' option, however, does not have this feature. Instead, it exports the image as if it were pasted onto an A4-sized sheet, leaving a lot of extra whitespace around the content.

Try "Crop":


Add new doclet properties to capture new ES 2015 features

We need to define new doclet properties to capture new language features in ES 2015. We also need to update the doclet schema accordingly.
A few features to consider (not an exhaustive list):

[ ] Iterators (need a way to document how iteration occurs)
[ ] Generators
[ ] Module/class syntax?
[ ] Block-scoped variables?

On further reflection, I don't think it's useful to track this as its own issue. Closing.


Add average module with average_shape

Pull Request Checklist:

[x] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes issue #38, at least in part?

[x] Tests for the changes have been added (for bug fixes / features)
[ ] Documentation has been added / updated (for bug fixes / features)
[ ] HISTORY.rst has been updated (with summary of main changes)
[ ] bumpversion minor has been called on this branch
[ ] I have added my relevant user information to AUTHORS.md

What kind of change does this PR introduce?:
Adds clisops/core/average.py with a first method average_shape that uses the power of xESMF to perform averages over polygons. As discussed in the slack channel,  I might have had a different idea of what the average submodule was supposed to be, this is why I only implemented the method I needed and only the computational pare (not the clisops.ops.average part).

My understanding at first was that most methods in average would be no more than a call to the related  subset_* followed by a mean over the appropriate dimensions. The use of xESMF for polygon averaging adds complexity but also precision as it considers partial overlaps, grid cell sizes and holes, while subset_shape does not (it is a simple "contains" test).
On the other hand, it restricts the inputs:

Input as datasets is still fragile because of pangeo-data/xESMF#53
Inputs must follow the CF conventions in the naming and attributes of the coordinates.

Because of that, we could also choose to
a. not implement a xESMF-backed shape-averaging method, but this would break our relatively clean "clisops->finch" pipeline.
b. implement average_shape_simple and/or  average_shape_exact (or other name alternatives). The "simple" version would be something like subet_shape(ds, shape).mean(['lat', 'lon']).
c. implement a switch in the function itself, either with a keyword or a try..except. I do not like this alternative, because I feel like that is the job of the clisops.ops.average version.
This is a draft PR. I plan to add documentation, fix all requirements and maybe implement a create_weight_masks helper, that returns the weight mask for each polygon in a given GeoDataFrame, giving more control on the average to the user, similar to subset.create_mask.
If my understanding for the base average method (subset + mean on dims) is correct, I could also add them here.

Does this PR introduce a breaking change?:
This will add a new dependency : xESMF (and thus ESMF), which is not light and makes pip installs difficult.

Hi @aulemahal, thanks for putting the PR together. I think that our requirements for average are very limited in scope compared to the larger requirements that you are looking at.
I think that our (C3S) requirements could be summed up by implementing something like:
In: clisops.core.average:

from roocs_utils.xarray_utils.xarray_utils import get_coord_type, known_coord_types

def average_over_dims(ds, dims=None, ignore_unfound_dims=False):
    if not dims: return ds
    if not set(dims).issubset(set(known_coord_types)):
         raise Exception(f'Unknown dimension requested for averaging, must be within: {known_coord_types}.')

    found_dims = []

    # Work out real coordinate types for each dimension
    for coord in ds.coords:
          coord_type = get_coord_type(coord)
          if coord_type:
               found_dims.append(coord.name)

    if ignore_unfound_dims == False and set(found_dims) != set(dims):
        raise Exception(f'Requested dimensions were not found in input dataset: {set(dims) - set(found_dims)}.')

    da = ...cast dataset to DataArray...
    ds_averaged_over_dims = da.mean(dim=found_dims, skip_na=???, keep_attrs=???)

    return ...

What do think? If it is really that easy for us create the functionality we need for C3S work then the real issue here is making sure that we structure the code so that the various layers work together properly.

Hi @aulemahal, thanks for putting the PR together. I think that our requirements for average are very limited in scope compared to the larger requirements that you are looking at.
I think that our (C3S) requirements could be summed up by implementing something like:
In: clisops.core.average:

from roocs_utils.xarray_utils.xarray_utils import get_coord_type, known_coord_types

def average_over_dims(ds, dims=None, ignore_unfound_dims=False):
    if not dims: return ds
    if not set(dims).issubset(set(known_coord_types)):
         raise Exception(f'Unknown dimension requested for averaging, must be within: {known_coord_types}.')

    found_dims = []

    # Work out real coordinate types for each dimension
    for coord in ds.coords:
          coord_type = get_coord_type(coord)
          if coord_type:
               found_dims.append(coord.name)

    if ignore_unfound_dims == False and set(found_dims) != set(dims):
        raise Exception(f'Requested dimensions were not found in input dataset: {set(dims) - set(found_dims)}.')

    da = ...cast dataset to DataArray...
    ds_averaged_over_dims = da.mean(dim=found_dims, skip_na=???, keep_attrs=???)

    return ...

What do think? If it is really that easy for us create the functionality we need for C3S work then the real issue here is making sure that we structure the code so that the various layers work together properly.

Hi Ag,
Let's say a use case is to compute the tropical average (averaged over both lon and lat, between lat=[-23, 23]).
One option would be to do
sub = subset_bbox(lat_bnds=[-23, 23])
out = average_over_dims(sub, dims=["lat", "lon"]

I think what we are proposing (not in this PR but in general), is to have a average_bbox function where we could do:
out = average_bbox(lat_bnds=[-23, 23], lon_bnds=[0, 360])
In other words, I think trying to pack everything in one average function is going  to be difficult as users require additional features. We suggest there should be a number of average_* functions similar to subset_*. I think your very simple use case can essentially be met with average_bbox that would look very similar to subset_bbox but with a mean operation on  each dimension that is not None.

Hi Ag,
Let's say a use case is to compute the tropical average (averaged over both lon and lat, between lat=[-23, 23]).
One option would be to do
sub = subset_bbox(lat_bnds=[-23, 23])
out = average_over_dims(sub, dims=["lat", "lon"]

I think what we are proposing (not in this PR but in general), is to have a average_bbox function where we could do:
out = average_bbox(lat_bnds=[-23, 23], lon_bnds=[0, 360])
In other words, I think trying to pack everything in one average function is going  to be difficult as users require additional features. We suggest there should be a number of average_* functions similar to subset_*. I think your very simple use case can essentially be met with average_bbox that would look very similar to subset_bbox but with a mean operation on  each dimension that is not None.

Hi Ag,
Let's say a use case is to compute the tropical average (averaged over both lon and lat, between lat=[-23, 23]).
One option would be to do
sub = subset_bbox(lat_bnds=[-23, 23])
out = average_over_dims(sub, dims=["lat", "lon"]

I think what we are proposing (not in this PR but in general), is to have a average_bbox function where we could do:
out = average_bbox(lat_bnds=[-23, 23], lon_bnds=[0, 360])
In other words, I think trying to pack everything in one average function is going to be difficult as users require additional features. We suggest there should be a number of average_* functions similar to subset_*. I think your very simple use case can essentially be met with average_bbox that would look very similar to subset_bbox but with a mean operation on each dimension that is not None.

@huard, @aulemahal: I agree that your general approach of matching average_* functions to similar subset_* functions keeps our core module structure nice and clear. We also have the clisops.ops.<module> route which our WPS uses as its entry point. We could put multiple functions in that module to meet different use cases, and call them what we like.

Hi Ag,
Let's say a use case is to compute the tropical average (averaged over both lon and lat, between lat=[-23, 23]).
One option would be to do
sub = subset_bbox(lat_bnds=[-23, 23])
out = average_over_dims(sub, dims=["lat", "lon"]

I think what we are proposing (not in this PR but in general), is to have a average_bbox function where we could do:
out = average_bbox(lat_bnds=[-23, 23], lon_bnds=[0, 360])
In other words, I think trying to pack everything in one average function is going to be difficult as users require additional features. We suggest there should be a number of average_* functions similar to subset_*. I think your very simple use case can essentially be met with average_bbox that would look very similar to subset_bbox but with a mean operation on each dimension that is not None.

@huard, @aulemahal: I agree that your general approach of matching average_* functions to similar subset_* functions keeps our core module structure nice and clear. We also have the clisops.ops.<module> route which our WPS uses as its entry point. We could put multiple functions in that module to meet different use cases, and call them what we like.

@huard and @aulemahal: Thinking in more detail, there is one part of the function signature to average_bbox() that I am struggling with. I think we want to the user to call it with the standard arguments:
    da: Union[xarray.DataArray, xarray.Dataset],
    lon_bnds: Union[np.array, Tuple[Optional[float], Optional[float]]] = None,
    lat_bnds: Union[np.array, Tuple[Optional[float], Optional[float]]] = None,
    start_date: Optional[str] = None,
    end_date: Optional[str] = None,
    first_level: Optional[Union[float, int]] = None,
    last_level: Optional[Union[float, int]] = None

But we also want to allow the user to say:

average over all longitudes
average over all latitudes
average over all levels
average over all times

Do you have a proposal for a function interface that allows all these options? I am struggling to come up with something elegant that copes with the two different approaches.

@huard and @aulemahal: Thinking in more detail, there is one part of the function signature to average_bbox() that I am struggling with. I think we want to the user to call it with the standard arguments:
    da: Union[xarray.DataArray, xarray.Dataset],
    lon_bnds: Union[np.array, Tuple[Optional[float], Optional[float]]] = None,
    lat_bnds: Union[np.array, Tuple[Optional[float], Optional[float]]] = None,
    start_date: Optional[str] = None,
    end_date: Optional[str] = None,
    first_level: Optional[Union[float, int]] = None,
    last_level: Optional[Union[float, int]] = None

But we also want to allow the user to say:

average over all longitudes
average over all latitudes
average over all levels
average over all times

Do you have a proposal for a function interface that allows all these options? I am struggling to come up with something elegant that copes with the two different approaches.

Thought about the same thing yesterday.
One option could be slice(None).

Thought about the same thing yesterday.
One option could be slice(None).

@huard: I think the problem is that we have a single argument for latitude, a single argument for longitude, and then a pair of arguments for each of level and time. That makes the slice approach is still quite inelegant.

@huard: I think the problem is that we have a single argument for latitude, a single argument for longitude, and then a pair of arguments for each of level and time. That makes the slice approach is still quite inelegant.

@agstephens Agreed.
I must confess that I'm a bit confused by the fact that core functions call each other. I think a better design would be for core to have low-level functionality (subset_bbox operating only on lon, lat, not time and level, which are left to subset_time and subset_level). It is the job of ops to combine there various low-level interfaces.

@agstephens Agreed.
I must confess that I'm a bit confused by the fact that core functions call each other. I think a better design would be for core to have low-level functionality (subset_bbox operating only on lon, lat, not time and level, which are left to subset_time and subset_level). It is the job of ops to combine there various low-level interfaces.

I think I share the perspective of @huard : We could have the computational side of things in core, where functions are as simple as possible and the more user-friendly all-encompassing methods in ops?
To be completely coherent with that idea, functions in  core.subset could be modified to remove time- and level-subsetting options from the spatial-subsetting functions. Thus, in core.average we could have only the cases where da.mean(dims) is not sufficient. All the simpler cases could be handled in ops.average, which would basically be a stronger ds.cf.mean(dims), AFAIU.
Thus I am suggesting here to have things in core that are not wrapped in any of the ops, in a perspective of using clisops as a dependency elsewhere, like in finch.

I think I share the perspective of @huard : We could have the computational side of things in core, where functions are as simple as possible and the more user-friendly all-encompassing methods in ops?
To be completely coherent with that idea, functions in  core.subset could be modified to remove time- and level-subsetting options from the spatial-subsetting functions. Thus, in core.average we could have only the cases where da.mean(dims) is not sufficient. All the simpler cases could be handled in ops.average, which would basically be a stronger ds.cf.mean(dims), AFAIU.
Thus I am suggesting here to have things in core that are not wrapped in any of the ops, in a perspective of using clisops as a dependency elsewhere, like in finch.

This PR is consistent with this vision. So if @agstephens agrees, I suggest we go with this and defer the refactoring of core processes to another PR.

This PR is consistent with this vision. So if @agstephens agrees, I suggest we go with this and defer the refactoring of core processes to another PR.

@aulemahal and @huard: Yes, I agree. Let's go ahead with this approach.

@aulemahal and @huard: Yes, I agree. Let's go ahead with this approach.

Cool! Now this leaves another issue I raised above : the use of xESMF is powerful for "exact" shape-averaging, but it has 1 more restriction then the previous "contains" (as in subset.create_mask) approach : it will not work with 2D lat / lon coordinates unless "lat/lon_bounds" are provided.
AFAIU, the 2D lat/lon case is out of scope for now in clisops?
Moreover, there is a plan to implement automatic computation of those bounds in cf_xarray, so this will eventually be fixed downstream.
If, however, this is a problem, we could write a average_shape_simple method that uses  subset.create_mask. It would also be faster (I think).

Cool! Now this leaves another issue I raised above : the use of xESMF is powerful for "exact" shape-averaging, but it has 1 more restriction then the previous "contains" (as in subset.create_mask) approach : it will not work with 2D lat / lon coordinates unless "lat/lon_bounds" are provided.
AFAIU, the 2D lat/lon case is out of scope for now in clisops?
Moreover, there is a plan to implement automatic computation of those bounds in cf_xarray, so this will eventually be fixed downstream.
If, however, this is a problem, we could write a average_shape_simple method that uses  subset.create_mask. It would also be faster (I think).

@aulemahal: From the perspective of what we are required to do for the C3S service:

we only need a simple average_over_dims(ds, dims=['time', 'latitude']) function
it does not have to cope with 2D coordinates
it only needs to support averaging over the four coordinates:

time
level
latitude
longitude

So, I think that we can implement that quickly, and it leaves space for Ouranos to add in a range of more sophisticated averaging functions within clisops/core/average.py.
I propose that we will propagate the functionality through to our WPS, with:

clisops.core.average::average_over_dims(), is called by
clisops.ops.average::average_over_dims(), is called by
daops.ops.average::average_over_dims(), is called by
rook.processes.wps_average::Average() - is exposed as a WPS process

Tagging @ellesmith88

@aulemahal: From the perspective of what we are required to do for the C3S service:

we only need a simple average_over_dims(ds, dims=['time', 'latitude']) function
it does not have to cope with 2D coordinates
it only needs to support averaging over the four coordinates:

time
level
latitude
longitude

So, I think that we can implement that quickly, and it leaves space for Ouranos to add in a range of more sophisticated averaging functions within clisops/core/average.py.
I propose that we will propagate the functionality through to our WPS, with:

clisops.core.average::average_over_dims(), is called by
clisops.ops.average::average_over_dims(), is called by
daops.ops.average::average_over_dims(), is called by
rook.processes.wps_average::Average() - is exposed as a WPS process

Tagging @ellesmith88

Hi! So this last push:

adds the xESMF >= 0.5.0 requirement where needed. Pypi stops at 0.3.1, which is quite unfortunate. I create an "extra" pip extra requirements and made average_shape optional : error if xESMF is too old/doesn't exist and skip tests. xESMf has to be installed through conda or from source, it has been made clear in the docs.
adds a new notebook core_average with only one section for now.
fixes a small error in create_mask : when the given geodataframe had a non-integer index the function would crash. It nows resets the index if needed.

Hi! So this last push:

adds the xESMF >= 0.5.0 requirement where needed. Pypi stops at 0.3.1, which is quite unfortunate. I create an "extra" pip extra requirements and made average_shape optional : error if xESMF is too old/doesn't exist and skip tests. xESMf has to be installed through conda or from source, it has been made clear in the docs.
adds a new notebook core_average with only one section for now.
fixes a small error in create_mask : when the given geodataframe had a non-integer index the function would crash. It nows resets the index if needed.

Update doc and new method:
clisops.core.subset.create_weight_masks to use the power of xESMF in creating weight masks instead of integer masks. For elegant output it required use of xESMF 0.5.2, so I bumped that everywhere I had added it.
I think this is ready for review!

Update doc and new method:
clisops.core.subset.create_weight_masks to use the power of xESMF in creating weight masks instead of integer masks. For elegant output it required use of xESMF 0.5.2, so I bumped that everywhere I had added it.
I think this is ready for review!

I had a chat with @aulemahal. We will await the release of xesmf:0.5.2 on conda-forge before merging this PR.

Added a comment on the non-installability of xESMF on windows + fixed a conflict in history.
And woups I just realized that all patch version are noted in the HISTORY, should I not have run bumpversion?

Hi @agstephens , is there a (tentative) schedule for the release of clisops 0.6 (or 0.5.2) ?
My goal is to use the work of this PR in finch, somewhere in the next month or two. Thanks!

Hi @agstephens , is there a (tentative) schedule for the release of clisops 0.6 (or 0.5.2) ?
My goal is to use the work of this PR in finch, somewhere in the next month or two. Thanks!

@aulemahal: @ellesmith88 will be in touch to discuss a new release :-)

Hi @aulemahal We plan to release v0.6.0 when the averaging work is all merged in, so within the next few weeks hopefully. We've been working on average_over_dims as mentioned above and would like that to go in as well.
I've opened our average as a separate PR to be reviewed - once we're happy that the 2 average PRs line up I'll go about merging and releasing.
I couldn't do the PR to your branch as its on a fork so it's to master but we can merge them so that you are able to resolve any conflicts how you would like. Let me know what you think of this plan.

Sounds good to me! Thanks.

All done!

I was wrong, xESMF's SpatialAverager is broken with the usual NaN-skipping solution (passing a mask). I'll leave this improvement for a future release. pangeo-data/xESMF#77 must be fixed before.
Even if the functionality of average_shape is not perfect, most improvements are to be made in xESMF and I think this is good to merge.

This all looks good. 👍


There are several models,  how can I make the polyline fit on the specified model while under another model?

I set the clampToGround attribute to true, but I just want the polyline to fit on one model and under the other.

Hi @fatcatkk, would you be able to provide more details around your use case so we can understand why this may be needed? Maybe including a Sandcastle example may help illustrate?

I'm closing this issue due to inactivity. If you believe this is still an issue, please feel free to re-open. Thanks!


High contrast icons

Make SVG icons adjust to High Contrast. This will make all icons monochrome and displayed in the text colour.
Description
#1115
How and where has this been tested?

How this was tested: Using steps in #1115
Browser(s) and OS(s) this was tested with: dge 88.0.705.56 on Win 10

Screenshots

To-do list

[x] If my change impacts other components, I have tested to make sure they don't break.
[ ] If my change impacts documentation, I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] This pull request is ready to merge.

Changes already merged with #1170