Error pointing to keys in --keyring-backend file

Celestia Node version
v0.6.4
OS
macOS/Ubuntu
Install tools
Context
i’m working with Duality, one of our ecosystem projects, on securely mounting keys to Docker images. they’re attempting to use --keyring-backend file so that a password can be set on keys, and declared as an environment variable. however, they are unable to use it, and i can reproduce the same errors. The repo that they’re working out of is here: https://github.com/itamarreif/rollmint-wordle
Questions & Takeaways

why can I declare different keyring-backend, keyring-dir with cel-key, but can’t specify those arguments/locations when starting celestia node?
what are the differences in applying a different keyring-dir/node-store/node-type/p2p-network and which needs to be used when?
if using different backends, what do we need to update (on Docs and on celestia-node)? previously, keys were stored in: ~/.celestia-light-mocha/keys but now they are created in ~/.celestia-light-mocha/keys/keyring-test or ~/.celestia-light-mocha/keys/keyring-file
why is cel-key a different utility? cosmos-sdk chains come with key manager built-in
menus with flags that don’t work (or haven’t been tested) are confusing and misleading

Others
No response
Steps to reproduce it
Init Mocha node on v0.6.4
celestia light init --p2p.network mocha

2023-02-07T11:14:38.599-0500	INFO	node	nodebuilder/init.go:19	Initializing Light Node Store over '/Users/joshstein/.celestia-light-mocha'
2023-02-07T11:14:38.600-0500	INFO	node	nodebuilder/init.go:50	Saving config	{"path": "/Users/joshstein/.celestia-light-mocha/config.toml"}
2023-02-07T11:14:38.600-0500	INFO	node	nodebuilder/init.go:51	Node Store initialized

Attempt to create new key
./cel-key add new_key --keyring-backend file --node.type light --p2p.network mocha

using directory:  ~/.celestia-light-mocha/keys
Enter keyring passphrase:
Re-enter keyring passphrase:
Error: open ~/.celestia-light-mocha/keys/keyring-file/keyhash: no such file or directory
Usage:
  keys add <name> [flags]
Flags:
      --account uint32           Account number for HD derivation (less than equal<PHONE_NUMBER>)
      --algo string              Key signing algorithm to generate keys for (default "secp256k1")
      --coin-type uint32         coin type number for HD derivation (default 118)
      --dry-run                  Perform action, but don't add key to local keystore
      --hd-path string           Manual HD Path derivation (overrides BIP44 config)
  -h, --help                     help for add
      --index uint32             Address index number for HD derivation (less than equal<PHONE_NUMBER>)
  -i, --interactive              Interactively prompt user for BIP39 passphrase and mnemonic
      --ledger                   Store a local reference to a private key on a Ledger device
      --multisig strings         List of key names stored in keyring to construct a public legacy multisig key
      --multisig-threshold int   K out of N required signatures. For use in conjunction with --multisig (default 1)
      --no-backup                Don't print out seed phrase (if others are watching the terminal)
      --nosort                   Keys passed to --multisig are taken in the order they're supplied
      --pubkey string            Parse a public key in JSON format and saves key info to <name> file.
      --recover                  Provide seed phrase to recover existing key instead of creating
Global Flags:
      --home string              The application home directory (default "~")
      --keyring-backend string   Select keyring's backend (os|file|test) (default "os")
      --keyring-dir string       The client Keyring directory; if omitted, the default 'home' directory will be used
      --node.type string         Sets key utility to use the node type's directory (e.g. ~/.celestia-light-mocha if --node.type light is passed).
      --output string            Output format (text|json) (default "text")
      --p2p.network string       Sets key utility to use the node network's directory (e.g. ~/.celestia-light-mynetwork if --p2p.network MyNetwork is passed). (default "mocha")

Add key, specifying keyring-backend file and keyring-dir
./cel-key add new_key --keyring-backend file --keyring-dir ~/.celestia-light-mocha/keys

Enter keyring passphrase:
Re-enter keyring passphrase:
- address: celestia1xaluxl00jth0jfjfs9ukt4cznfknevks6487qu
  name: new_key
  pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A63Zr1AolcegOIJocqnYcMJB4c69PmQej1EQ6FjUy/yT"}'
  type: local
**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.
tell invest harvest knee liar salute satoshi suspect aerobic net display excess judge type tattoo chaos erode maple pave exit spend slice stadium world

start node specifying network, key name, and keyring-backend
I'm aware this should fail.
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --keyring-backend file --keyring.accname new_key --p2p.network mocha

Error: unknown flag: --keyring-backend

Run without keyring-backend (this should work)
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --keyring.accname new_key --p2p.network mocha

2023-02-07T11:22:32.567-0500	INFO	badger	v2@v2.2007.4/levels.go:183	All 0 tables opened in 0s
Error: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/rpc".registerEndpoints (/Users/joshstein/celestia-node/nodebuilder/rpc/constructors.go:17): failed to build state.Module: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/state".ConstructModule.func3 (/Users/joshstein/celestia-node/nodebuilder/state/module.go:38): failed to build *state.CoreAccessor: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/state".coreAccessor (/Users/joshstein/celestia-node/nodebuilder/state/core.go:13): failed to build *types.KeyringSigner: received non-nil error from function "github.com/celestiaorg/celestia-node/nodebuilder/state".keyring (/Users/joshstein/celestia-node/nodebuilder/state/keyring.go:18): new_key.info: key not found [celestiaorg/cosmos-sdk@v1.4.0-sdk-v0.46.0/crypto/keyring/keyring.go:489]

This starts, but makes a new key in keyring-backend test
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --p2p.network mocha

2023-02-07T11:23:19.309-0500	INFO	badger	v2@v2.2007.4/levels.go:183	All 0 tables opened in 0s
2023-02-07T11:23:19.315-0500	INFO	badger	v2@v2.2007.4/value.go:1158	Replaying file id: 0 at offset: 0
2023-02-07T11:23:19.315-0500	INFO	badger	v2@v2.2007.4/value.go:1178	Replay took: 24.417µs
2023-02-07T11:23:19.330-0500	INFO	module/state	state/keyring.go:46	NO KEY FOUND IN STORE, GENERATING NEW KEY...	"path": "/Users/joshstein/.celestia-light-mocha/keys"}
2023-02-07T11:23:19.339-0500	INFO	module/state	state/keyring.go:52	NEW KEY GENERATED...
NAME: my_celes_key
ADDRESS: celestia1955v4u8x6srwxnxs0vas3t4cprzs3kztw7hhl8
MNEMONIC (save this somewhere safe!!!):
[omitted for length]

Can't find keys, in theory this should work?
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --keyring.accname new_key --p2p.network mocha

2023-02-07T11:33:09.770-0500	INFO	badger	v2@v2.2007.4/levels.go:183	All 1 tables opened in 1ms
2023-02-07T11:33:09.781-0500	INFO	badger	v2@v2.2007.4/value.go:1158	Replaying file id: 0 at offset: 2363039
2023-02-07T11:33:09.781-0500	INFO	badger	v2@v2.2007.4/value.go:1178	Replay took: 3.583µs
Error: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/rpc".registerEndpoints (/Users/joshstein/celestia-node/nodebuilder/rpc/constructors.go:17): failed to build state.Module: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/state".ConstructModule.func3 (/Users/joshstein/celestia-node/nodebuilder/state/module.go:38): failed to build *state.CoreAccessor: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/state".coreAccessor (/Users/joshstein/celestia-node/nodebuilder/state/core.go:13): failed to build *types.KeyringSigner: received non-nil error from function "github.com/celestiaorg/celestia-node/nodebuilder/state".keyring (/Users/joshstein/celestia-node/nodebuilder/state/keyring.go:18): new_key.info: key not found [celestiaorg/cosmos-sdk@v1.4.0-sdk-v0.46.0/crypto/keyring/keyring.go:489]

Unknown flags (expected)
keyring-backend

keyring-dir
checking menu to be able to set keyring-backend/keyring.dir etc.
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --keyring.accname new_key --p2p.network mocha --help

Starts Node daemon. First stopping signal gracefully stops the Node and second terminates it.
Options passed on start override configuration options only on start and are not persisted in config.
Usage:
  celestia light start [flags]
Aliases:
  start, run, daemon
Flags:
      --core.grpc.port string           Set a custom gRPC port for the core node connection. The --core.ip flag must also be provided. (default "9090")
      --core.ip string                  Indicates node to connect to the given core node. Example: <ip>, <IP_ADDRESS>. Assumes RPC port 26657 and gRPC port 9090 as default unless otherwise specified.
      --core.rpc.port string            Set a custom RPC port for the core node connection. The --core.ip flag must also be provided. (default "26657")
      --gateway                         Enables the REST gateway
      --gateway.addr string             Set a custom gateway listen address (default: localhost)
      --gateway.port string             Set a custom gateway port (default: 26659)
      --headers.trusted-hash string     Hex encoded header hash. Used to subjectively initialize header synchronization
      --headers.trusted-peers strings   Multiaddresses of a reliable peers to fetch headers from. (Format: multiformats.io/multiaddr)
  -h, --help                            help for start
      --keyring.accname string          Directs node's keyring signer to use the key prefixed with the given string.
      --log.level string                DEBUG, INFO, WARN, ERROR, DPANIC, PANIC, FATAL
                                        and their lower-case forms (default "INFO")
      --log.level.module strings        <module>:<level>, e.g. pubsub:debug
      --metrics                         Enables OTLP metrics with HTTP exporter
      --metrics.endpoint string         Sets HTTP endpoint for OTLP metrics to be exported to. Depends on '--metrics' (default "localhost:4318")
      --metrics.tls                     Enable TLS connection to OTLP metric backend (default true)
      --node.config string              Path to a customized node config TOML file
      --node.store string               The path to root/home directory of your Celestia Node Store
      --p2p.mutual strings              Comma-separated multiaddresses of mutual peers to keep a prioritized connection with.
                                        Such connection is immune to peer scoring slashing and connection module trimming.
                                        Peers must bidirectionally point to each other. (Format: multiformats.io/multiaddr)
      --p2p.network string              The name of the network to connect to, e.g. arabica-3, mocha. Must be passed on both init and start to take effect.
      --pprof                           Enables standard profiling handler (pprof) and exposes the profiles on port 6000
      --rpc.addr string                 Set a custom RPC listen address (default: localhost)
      --rpc.port string                 Set a custom RPC port (default: 26658)
      --tracing                         Enables OTLP tracing with HTTP exporter
      --tracing.endpoint string         Sets HTTP endpoint for OTLP traces to be exported to. Depends on '--tracing' (default "localhost:4318")
      --tracing.tls                     Enable TLS connection to OTLP tracing backend (default true)

Try, specifying node-store
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --keyring.accname new_key --p2p.network mocha --node.store ~/.celestia-light-mocha/keys/keyring-file/

2023-02-07T11:38:54.114-0500	ERROR	node	nodebuilder/init.go:66	loading config	{"path": "/Users/joshstein/.celestia-light-mocha/keys/keyring-file", "err": "open /Users/joshstein/.celestia-light-mocha/keys/keyring-file/config.toml: no such file or directory"}
Error: node: store is not initialized

Try, specifying node-store with a shorter path
celestia light start --core.ip https://rpc-mocha.pops.one/ --core.grpc.port 9090 --gateway --gateway.addr <IP_ADDRESS> --gateway.port 26659 --keyring.accname new_key --p2p.network mocha --node.store ~/.celestia-light-mocha

2023-02-07T11:39:11.523-0500	INFO	badger	v2@v2.2007.4/levels.go:183	All 1 tables opened in 1ms
2023-02-07T11:39:11.528-0500	INFO	badger	v2@v2.2007.4/value.go:1158	Replaying file id: 0 at offset: 2363039
2023-02-07T11:39:11.528-0500	INFO	badger	v2@v2.2007.4/value.go:1178	Replay took: 2.542µs
Error: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/rpc".registerEndpoints (/Users/joshstein/celestia-node/nodebuilder/rpc/constructors.go:17): failed to build state.Module: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/state".ConstructModule.func3 (/Users/joshstein/celestia-node/nodebuilder/state/module.go:38): failed to build *state.CoreAccessor: could not build arguments for function "github.com/celestiaorg/celestia-node/nodebuilder/state".coreAccessor (/Users/joshstein/celestia-node/nodebuilder/state/core.go:13): failed to build *types.KeyringSigner: received non-nil error from function "github.com/celestiaorg/celestia-node/nodebuilder/state".keyring (/Users/joshstein/celestia-node/nodebuilder/state/keyring.go:18): new_key.info: key not found [celestiaorg/cosmos-sdk@v1.4.0-sdk-v0.46.0/crypto/keyring/keyring.go:489]

Expected result
Node starts
Actual result
Please see above
Relevant log output
No response
Notes
No response

and do these changes make sense? https://github.com/celestiaorg/docs/issues/413

Hey @jcstein yeah #1565 addresses this issue. I have not yet had time to look through docs for it as the PR is not done.

can review docs when merged 👍


Application crashed when pointed at localhost or <IP_ADDRESS>

I was trying to get this to work behind an Asus router with ddns enabled, but it appears the application crashes when it asks for the servers IP.

Try running with admin privileges.


swoole support

hi,
will you bring swoole support for laravel octane?
Thanks

@emreakay What would this entail, and are you willing to submit PRs, document them, etc? Tbh I'm not sure why one would use Swoole, nor how it would fit into Warden. The only thing I know about it is from a basic web search, skimming the project's README, where claims seem to boil down to it's faster than FPM because PHP has to load files on every request (something that is NOT true when PHP-FPM is used with OpCache properly enabled and configured). The benchmarks don't even make a mention of Opcache, or any other PHP configuration for that matter, making them impossible to reproduce. Value of Swoole aside, what advantage would it have to users of Warden? What would supporting it involve?

i want to use warden on production for my alaravel project and i want to run my project with swoole and octane.

+1 for Swoole support in Warden.
Swoole seems to solve many performance problems of PHP and Adobe commerce leveraging Swoole for GraphQL server also proves that.


Scorecards does not recognize Dependabot

Tracking issue for:

[ ] https://github.com/jenstroeger/python-package-template/security/code-scanning/1

I believe this is due to the recent change of .yml to .yaml files.

Dang… and sigh. Un-rename these files, then?

I've opened a PR in Scorecard. Let's see how that goes.

Scorecard will support .github/dependabot.yaml via this merged PR.


The image size reported by anchore-engine does not match the size reported by 'docker inspect' and/or ls

Is this a request for help?:
No.
Is this a BUG REPORT or a FEATURE REQUEST? (choose one):
BUG REPORT

Version of Anchore Engine and Anchore CLI if applicable:
I run anchor-cli via enginer-api container, i.e.,
$ /usr/local/bin/docker-compose exec engine-api anchore-cli --version
anchore-cli, version 0.4.1
$ docker-compose exec engine-api anchore-cli system status
Service policy_engine (anchore-quickstart, http://engine-policy-engine:8228): up
Service analyzer (anchore-quickstart, http://engine-analyzer:8228): up
Service simplequeue (anchore-quickstart, http://engine-simpleq:8228): up
Service catalog (anchore-quickstart, http://engine-catalog:8228): up
Service apiext (anchore-quickstart, http://engine-api:8228): up
Engine DB Version: 0.0.10
Engine Code Version: 0.4.1
Some more info of interest:
$ cat /etc/system-release
CentOS Linux release 7.4.1708 (Core)
$ docker --version
Docker version 18.03.0-ce, build 0520e24
$ docker-compose --version
docker-compose version 1.24.1, build 4667896b
What happened:
The (Docker) image size reported by anchore-engine is incorrect, i.e. it does not match the size reported  by 'docker inspect' and/or 'ls'.
What did you expect to happen:
The size reported by anchore-engine to match the actual size of the image file

Any relevant log output from /var/log/anchore:
Example 1:
a) Size reported by anchore-engine:
Image ID: ee603cc938cc6097cee34a051c20383f9ec3a19123c17eee0894b7ba0c0d0bff
Dockerfile Mode: Guessed
Distro: alpine
Distro Version: 3.9.2
Size: 20428800
Architecture: amd64
Layer Count: 5
b) Size reported by 'docker inspect...'
$ docker inspect ee603cc938cc6097cee34a051c20383f9ec3a19123c17eee0894b7ba0c0d0bff --format='{{.Size}}'
14708264    This is the correct size
Example 2:
a) Size reported by anchore-engine:
Analysis Status: analyzed
Image Type: docker
Analyzed At: 2019-08-06T21:16:32Z
Image ID: 8183b8cc935cdc77c502c4751804c364f7d235a9becbe8508f54fe963e39c752
Dockerfile Mode: Guessed
Distro: ubuntu
Distro Version: 18.04
Size: 82513920
Architecture: amd64
Layer Count: 6
Full Tag: localhost.localdomain:5000/my_second_image:latest
$ docker inspect  8183b8cc935cdc77c502c4751804c364f7d235a9becbe8508f54fe963e39c752  --format='{{.Size}}'
96352875   This is the correct size
What docker images are you using:
The two images that i used are simple/small Bash scripts
How to reproduce the issue:
check the  size reported by anchore-engine vs docker inspect ...
Anything else we need to know:

hi @dforouhari - appreciate your using anchore-engine and the detail of your report!
The core issue in general with 'image size' comes down to how anchore/docker/other tools are measuring the size of the image(s) - various techniques will yield different results (docker save, docker create/commit|export, skopeo copy, docker run du /, docker inspect, anchore-cli image get), but I can speak to why anchore and docker will be reporting different values.
Since anchore doesn't require docker on the system on which it is running, it never actually installs a downloaded image into a docker engine.  The size reported by docker is being derived, after the image is installed locally by a docker engine, from how much local storage is being allocated for the associated local layers (downloaded, unpacked, and installed using whatever docker storage driver is configured).  Since anchore doesn't 'install' docker images, it only has access to the image manifest data (which reports layer sized, but typically are compressed sizes), the layers themselves (also compressed).  The sum of all layers is an inaccurate measure of actual image size, since often layers will exist even though later layers will 'remove' content, etc, and thus only a final 'squashed' image after layer unpacking is performed is closer to what you'll actually see on disk for a given image.  Again, since anchore doesn't go through docker itself (thus the backend layer fs style layer unpack), we instead approximate the image size by evaluating the 'squashed' image that anchore constructs with its own docker-agnostic layer 'squashing' implementation.
Generally, we've seen that the image sizes are close to other reported sizes, but it will be different due to the above.
Let us know if this helps to clarify the discrepancy!

Thank you for detailed  explanation. No further actions is needed...closing the tkt.

I reopened to issue to provide an observation. No further action is required.
Based on my observations, depending on the image, the reported size by anchore-engine could be smaller, equal, or larger the actual size of the image.
HTH


Autostarting flatpak firefox sometimes doesn't spawn windows

Hyprland Version
 System/Version info
Hyprland, built from branch HEAD at commit 84ab8d11e8951a6551d1e1bf87796a8589da6d47  (props: bump ver to 0.35.0).
Date: Mon Feb 5 01:59:02 2024
Tag: v0.35.0

flags: (if any)

System Information:
System name: Linux
Node name: Lelou-FW
Release: 6.7.5-202.fsync.fc39.x86_64
Version: #1 SMP PREEMPT_DYNAMIC Thu Feb 22 16:05:38 UTC 2024

GPU information:
c1:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev c2) (prog-if 00 [VGA controller])

os-release: NAME="Fedora Linux"
VERSION="39.20240224.0 (Kinoite)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39.20240224.0 (Bazzite)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://kinoite.fedoraproject.org"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-kinoite/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://pagure.io/fedora-kde/SIG/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-11-12
VARIANT="Kinoite"
VARIANT_ID=kinoite
OSTREE_VERSION='39.20240224.0'

plugins:

Bug or Regression?
Bug
Description
I wanted to autostart firefox when starting Hyprland, so I added this line in my configuration
exec-once=[workspace 1 silent] flatpak run org.mozilla.firefox 2>&1 > /tmp/ff1.log
However sometimes firefox doesn't open on startup, but I can still see it when running flatpak ps or ps
hyprctl clients didn't show any firefox window.
I also tried autostarting another flatpak,  Vesktop (dev.vencord.Vesktop) and it starts fine everytime
How to reproduce
Install Firefox as a flatpak, add the exec-once to Hyprland config and log out and log back in a couple of times
Crash reports, logs, images, videos
 Firefox logs from a run when there wasn't any windows
```
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed GL context creation for hardware WebRender: true
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed GL context creation for hardware WebRender: true
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed GL context creation for hardware WebRender: true
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed GL context creation for hardware WebRender: true
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed[3] to create EGL library  display: FEATURE_FAILURE_NO_DISPLAY
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: FEATURE_FAILURE_WEBRENDER_INITIALIZE_UNSPECIFIED(Create)
[GFX1-]: Failed to connect WebRenderBridgeChild. isParent=true
[GFX1-]: Fallback WR to SW-WR
```

I tried adding a bit of delay and It seems to work consistently, so Hyprland isn't ready yet to accept windows when it runs exec-once scripts ?

it should be, idk why this happens

@LelouBil how do you add a delay?
I'm having the same issue with:
exec-once = [workspace 1 silent] flatpak run com.synology.SynologyDrive 2>&1

@LelouBil how do you add a delay?
I'm having the same issue with:
exec-once = [workspace 1 silent] flatpak run com.synology.SynologyDrive 2>&1

@guttermonk add a sleep
exec-once= [workspace 1 silent]sleep 1; flatpak run com.synology.SynologyDrive 2>&1

I tried adding that to my hyprland.conf file, but it didn't do anything.
Then I tried changing it to:
exec-once = [workspace 1 silent]sleep 2; flatpak run com.synology.SynologyDrive 2>&1 > ~/Test.log
After a reboot, it did generate a log file but it was empty and the program still didn't load. Any other suggestions?

Still a thing? I have flatpak firefox in my autostart and it works fine.

I ended up switching to the Synology Drive in the NUR, so not sure if this is an issue or not.

I think it's worth closing. Whoever faces the problem can open a new issue.


test: skip image polling test if running in a kind cluster

Signed-off-by: Daniel Sover<EMAIL_ADDRESS>
Description of the change:
This change skips the image polling test when running with a kind cluster. Previously this test was skipped on upstream CI only (which is also kind), but not locally, which caused the test to fail when running locally on a kind cluster.
The reason for the failure seems to be the context for the kubectl port-forward command to work is not properly configured in the test. It's worth exploring potentially trying to getting the right context at test execution time and seeing if the test works correctly, as it does on minikube and openshift.
Motivation for the change:
Closes #2420
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive

I assumed the name of the kind control plane node to be static across clusters but it can be different depending on the name of the cluster.
kind-8zcmr8sx8z49wkr5-control-plane
cat-control-plane
are valid names of the kind node depending on the name provided when creating the cluster. There also don't seem to be any obvious APIs or objects that are kind-specific to query for. Seems like listing nodes and running a regex will be a potential solution

Holding so the bot doesn't go crazy.
/hold

Closing as #2445 superseded this PR as there's merge conflicts and this is a real nice QoL improvement for running the e2e suite locally so I wanted to push it through. Thanks for tackling this work :tada:


[0.32] Commits to cherry pick into stable release

FYI we've bunch of regressions in latest release - https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+label%3ARegression

I haven't seen it mentioned yet, but I'm noticing big problems with image loading and caching in 0.32. In fact it seems like images are not cached at all, resulting in super slow image load times (especially for repeated images like avatars). It prompted me to look through the commit history, and the large image cache refactor could be the culprit: ddc70ff
Should I create a separate issue or is there already something out there covering it?

@sjmueller, please raise a separate issue with a video example if you can and cc people related to the change.
Also cc me, I'll link it internally.

Nothing explicitly listed so will release w/o cherry-picks.

@grabbou, we want to investigate the image caching issue internally a bit.
Can we delay stable forma day or two?

It's not yet deployed so it's up to you. Just let me know so I'll update interested ppl via twitter :)

Hey all, apologies for the delay regarding image cache / decoding issues. Would you still like me to submit an issue, or did your internal investigation yield the same findings?

Yes Sam, please submit one.
Also if you could help investigating it would be much appreciated
On Tuesday, 23 August 2016, Sam Mueller<EMAIL_ADDRESS>wrote:

Hey all, apologies for the delay regarding image cache / decoding issues.
Would you still like me to submit an issue, or did your internal
investigation yield the same findings?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/9431#issuecomment-241654278,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWOmCUzW96uiyufHiW4W25zb8sJ_0ks5qiqajgaJpZM4JlRQa
.

@sjmueller I've noticed that issue too, when i preview the loaded image, the image is loaded again, seems the cache doesn't work, I'm using RN0.32RC0

Let's cherry-pick b4999fca0d783bfaeb47200e434760aae8badb14

Let's cherry-pick b4999fca0d783bfaeb47200e434760aae8badb14

Yes please. This is the fix for Chrome debugger by @lexs, awesome!

Could someone provide some repro instructions for the caching issue? Does this happen on iOS or Android? What are example image URLs that are not cached?

Also bring back android command from rnpm - in the morning.
@javache @bestander @sjmueller shall we move to a separate issue so the cherry-pick thread is not polluted with unrelated comments?

shall we move to a separate issue

Yes, is there an issue for the image caching? If not just create one :)

Yes, we should definitely
On Wednesday, 24 August 2016, Mike Grabowski<EMAIL_ADDRESS>wrote:

Also bring back android command from rnpm - in the morning.
@javache https://github.com/javache @bestander
https://github.com/bestander @sjmueller https://github.com/sjmueller
shall we move to a separate issue so the cherry-pick thread is not polluted
with unrelated comments?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/9431#issuecomment-242144285,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWK_Z-Z0dl9wPchY06lh4rmoFkZjbks5qjH7KgaJpZM4JlRQa
.

Question: is this little note still in effect?

If this fix for building a framework version of React (with e.g. CocoaPods) gets merged before the release, I’d love to see that go in.

To pick into 0.32.1

[ ] https://github.com/facebook/react-native/pull/9544 CocoaPods + css-layout
[ ] https://github.com/facebook/react-native/issues/9581 - image caching bug

@alloy looks like it's not yet merged, but I'll do as a 0.32.1 as @bestander suggested.

I concor

@grabbou This can be closed.


firstDayOfWeek help!!

Subject of the issue
Describe your issue here.
He there.
I am trying to set the start date of the calendar to be Monday. I set the firstDayOfWeek={1} and no change at all.
I have used version 1.0.0-beta and 0.9.4
Any ideas.
Thanks
[BUG] Bug Reproduce Steps
Tell us how to reproduce this issue.
[BUG] Expected behaviour
Environment
Package Version: 1.0.0-beta and 0.9.4
React version: 16.5.0
Node version: v8.11.3
Browser: Chrome

Try 'startOfWeek' instead.

Thanks for your answer. I set startOfWeek={1} / startOfWeek="Monday" and other numbers and no luck. Thanks


fix: fix IP Failover resource

What does this fix or implement?
Rewrite some of the methods for IP Failover resource and data source since the functionality was not correct for them.

Checklist

[x] PR name added as appropriate (e.g. feat:/fix:/doc:/test:/refactor:)
[ ] Tests added or updated
[ ] Documentation updated
[ ] Changelog updated and version incremented (label: upcoming release)
[ ] Github Issue linked if any
[ ] Jira task updated

@cristiGuranIonos @cbeti-ionos this is not ready since it needs to be tested thoroughly but it is ready for a first review. Please take a look at the new changes and tell me what you think.

Changelog

Changelog

@cristiGuranIonos done


Internal server error

Hi everyone,
I'm currently playing with cadence, which comes bundled with hopsoft/graphite-statsd (which I was delighted to see btw). Launching the Grafana web UI on http://localhost:8080 works fine but now I'm facing a problem with adding Graphite as a datasource. Here are my settings:
name: graphite
default: checked
type: Graphite
url: http://locahost:81
access: proxy
basic auth: unchecked
with credentials: unchecked
If I then press "test connection" I get the following output from the statsd docker container:
2019/11/01 10:51:42 [I] Completed <IP_ADDRESS> - "GET /metrics/find HTTP/1.0" 500 Internal Server Error 0 bytes in 105644us
and in the Grafana interface get:
Test results
HTTP Error
Internal Server Error

Does anyone know if there is a problem with the way I'm configuring things or what the problem is?
Thanks and best regards

are you using grafana v6.x or the outdated one that comes with this docker?
this docker has an outdated copy of grafana dont use it
it seems there's a problem with using internal IP
try using your external IP (make sure it is accessible externally)
*this is pretty insecure and just "bad" but that's the only workaround i known of...

Hi @Thunder33345 thanks for your reply! Yes I'm indeed using this apparently outdated version. It is included in the docker-compose file of cadence. Which one should I use instead?
You were right with your suggestion to use the external IP btw, it works that way! The dashboard is still empty though, do you know how I can add my metrics to the dashboard?


Add alby to other parts of the site

In my previous PR #30 we decided to leave Alby out of all the parts of the site until we made it easier for users to get their @getalby.com ln address. We have improved this process so I am now adding it back in. Thanks!

+1


Search results contain items for organizations

Currently search results show list items for services, not organizations.
This is a stretch goal for the "organizations" release in December

[x] Modify algolia export tools to work with separate folders for working files for services and organizations, respectively
[x] Modify organization format to be of the form "organization"/"id" etc, rather than the current "organization_id" etc.

Organization data for upload to algolia contains

[ ] taxonomy terms taken from the corresponding services
[ ] lat/long taken from the corresponding service when there is only one
[ ] number of services for the organization

Acceptance Criteria

[ ]  Search results from Algolia, as rendered in the app, show separate list items for organizations, as per these mocks

This would probably just work(TM) if we moved to an all-algolia solution.


Cannot instantiate CanvasRenderer due to undefined initPlugins

A super simple test case with Pixi 3.07 coming from cdnjs:
http://jsfiddle.net/Lcxehrza/
Instantiating a CanvasRenderer seems to result in an undefined function error for initPlugins. Tested in Safari and Chrome on OS X.

Looks like you forgot new
http://jsfiddle.net/Lcxehrza/10/


(Python) Creating A Hand Gesture Volume Controller Using Python And Pycharm

Topic Suggestion
(Python) Creating A Hand Gesture Volume Controller Using Python And Pycharm
Writing sample(s):
Include any links or writing samples - to help our team better gauge your writing quality.
Proposal Submission
Proposed title of article
Creating a hand gesture volume controller using python and pycharm
Proposed article introduction
In this technological era, computers are crucial to our lives. We use them for working on documents, coding, entertainment, etc. These devices are also easily damaged by water and dust. We therefore cannot handle them with dirty or wet hands. When using them for entertainment, we wash or dry our hands before touching the computer e.g while increasing the volume of our favorite song. This interrupts us from whatever we were doing.
Python helps us solve this issue by enabling us to create a hand gesture volume controller. This software will enable us to control the volume level of our computer by using a hand gesture. We, therefore, do not need to be hands-on on our computers.
In this tutorial, we are going to learn how to use gesture control to change the volume of a computer. We are also going to explain in detail the python packages we will require. We will use the following packages:

numpy
cv2
mediapipe
math
time
ctypes
comtypes
pycaw

Key takeaways
The reader will be able to:

Have an in-depth understanding of how the above packages are used.
Use python to track hand gestures.
Create a hand gesture volume controller.

Article quality
Unlike other articles, the code will be well explained and not just copy-pasted. The article will also cover in detail the python packages used and why we are using them not just installing them in our project.
References
N/A

Sounds like a helpful topic - let's please be sure it adds value beyond what is in any official docs and/or what is covered in other blog sites. (the articles should go beyond a basic explanation - and it is always best to reference any EngEd article and build upon it). @leeseshawn
Please be attentive to grammar/readability and make sure that you put your article through a thorough editing review prior to submitting it for final approval. (There are some great free tools that we reference in EngEd resources.)
ANY ARTICLE SUBMITTED WITH GLARING ERRORS WILL BE IMMEDIATELY CLOSED.
Please be sure to double-check that it does not overlap with any existing EngEd articles, articles on other blog sites, or any incoming EngEd topic suggestions (if you haven't already) to avoid any potential article closure, please reference any relevant EngEd articles in yours. - Approved


Frontiers in Climate: Democratizing Data - Paper Revisions

We are still waiting for the reviews to come in from Frontiers.
In the meantime, noting so I don't forget that @koldunovn saw our preprint and helpfully pointed out that I'd used the wrong citation for the FESOM model. The output we have ingested into Pangeo Forge is in fact, FESOM2, for which the correct citation, per Nikolay, is

Danilov, S., Sidorenko, D., Wang, Q., and Jung, T.: The Finite-volumE Sea ice–Ocean Model (FESOM2), Geosci. Model Dev., 10, 765–789, https://doi.org/10.5194/gmd-10-765-2017, 2017.

I've just corrected this in Overleaf: https://www.overleaf.com/project/6103c3cb2cc6aad53b3bf81d
When the reviews land, I'll ping all of the paper co-authors here; but sparing everyone the @ for now.

Note to all co-authors: the editor has granted us an extension. Our review responses are now due three weeks from today, on Tuesday November 9.

👋 Paper team, I've now made Track Changes edits to our Overleaf which I believe address all of the review points enumerated in this Google Doc.
This is due this upcoming Tuesday, November 9. Sometime before Tuesday, I would appreciate if you could read through the document, and make any final edits (grammatical, content, etc.) using Track Changes. I will then do a final read-through and submission of our revised manuscript on Tuesday.
Thanks!

A few points of feedback on my last read through the paper:

I was confused about what "FAIR" data referred to.
I think the fsspec-reference-maker project was renamed to Kerchunk, though the former still appears in PyPi. I'm not sure what the most appropriate name would be – it's worth reviewing.

I have reviewed the paper and response document. I have added a few minor suggestions. It looks great! Excellent job on managing the whole process Charles!
You have my ✅  to submit whenever you're ready.

Line 276 reads parrelizable, it should be parallelizable.
Line 540: are be --> This sentence confuses me, is this a mistake?
In general, there is inconsistent capitalization for subsections.

Alex--given the tight timeline, the best thing you could do at this point would be to make the changes yourself.

I made one minor edit:

line 325 used to be "Pangeo Forge's initial algorithms produce of Zarr" - I took "of" out

looks great - I think it is also very "approachable" for users. I couldn't follow the more data engineering part, but I appreciated the clear explanation of the steps involved in the process, how some are meant to read only metadata and prepare the target, and when the actual heavy lifting happens. It also helps people like me - probably a typical user - to learn some important technical language and learn more about data engineering/cataloging  challenges.

Alex--given the tight timeline, the best thing you could do at this point would be to make the changes yourself.

Sorry about that -- I didn't think I had overleaf access (I do).

I've just submitted our revised manuscript. Thanks to all for your generous and helpful contributions.

"I am pleased to inform you that your manuscript 'Pangeo Forge: Crowdsourcing Analysis-Ready, Cloud Optimized Data Production' has been approved for production and accepted for publication in Frontiers in Climate, section Climate Services.
Proofs are being prepared for you to verify before publication."
😁 Great work everyone!

Nice work all, especially @cisaacstern!

Congratulations, all!
One minor issue: My last name is misspelled in the accepted manuscript. How can I get this changed?
The email reads "Melrose" when it should read Merose.

@alxmrs, yes I noticed that.
I'll correct it when Frontiers sends the proofs, along with any other typos (I'm know of at least one other).


MAINTAINERS: Add rugeGerritsen to BT host as collaborator

Add Rubin Gerritsen as collaborator to the BT host. He has been very active in this area.
See for more info:
https://github.com/zephyrproject-rtos/zephyr/issues/80233

@rugeGerritsen also knows ISO quite well, should we add him there too?

Yeps :)


fix(tests): Fixed tests, updated logo

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Threading] Add ConditionVariable support.

Swift Concurrency would like to be able to use condition variables. Add support to the threading packages.
rdar://100236038

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test


Added Dotgrid

https://www.producthunt.com/posts/dotgrid

Also added Left.
https://www.producthunt.com/posts/left

Ooops, accidentally merged in all the commits from master when I was trying to rename the files 😓. But the tests are actually expecting everything to be in lowercase with dash separator. We should investigate why the error messages from CI were so unhelpful, though; it should have shown up like this:
> mocha --reporter min test/human-data.js && standard --fix

  10060 passing (974ms)
  1 failing

  1) human-submitted app data Left is in a directory whose name is lowercase with dashes as a delimiter:

      AssertionError: expected 'left' to equal 'Left'
      + expected - actual

      -left
      +Left

Mhm, it's strange, when I change the case of the yml file, it's not detected as a file change.

@neauoire are you on a case insensitive system like mac os? If so, you'll need to use git mv to make git detect the change in casing.

I am! Okay, thanks :) I will give that a try.

bump :) @neauoire

AaaaaAahh @vanessayuenn!  I totally forgot it was still open.
Okay so I do I resolve this? I'm kind of a GitHub new and I'm seeing all these flags here.
What should I do :')

Thank you so much 👍
Let me know if you have ideas for Left and I will be happy to implement them!


TODO: Targeted SDK 34+ crashed app immediately when built successfully.

Recheck #63

Reference here

Skipped as not lib error, but rather than a React Native library error (https://github.com/facebook/react-native/commit/177d97d8ea962bdd4dad8fcf0efb04a307f25000)[Source] and has been resolved at ver 0.72.8.


proposal: os: File should be an interface

By analogy with #13473, os.File should also be an interface. That would permit a program to use files in the abstract sense, including implementations not provided by the os package.

Related: #5636 (VFS layer), in which we were never able to find a design that fit everybody's needs.

https://godoc.org/golang.org/x/net/webdav#FileSystem
This may be one of implementations.

I think I'd argue that io.File should be the interface but it's all moot now.

@rsc How about follow interface?
type FileV2 interface{
   io.ReadWriteCloser
   ....
}
func NewFileFromV2(v2 FileV2) *File{
}

No. Please see my reply to a similar suggestion in #13473. Having version
numbers in APIs is really ugly.

This is a long-term issue that we are not actively working on.

After several years of maintaining various Google filesystem implementations, I disagree strenuously with this proposal.
Go interfaces act as bounds on types. On function inputs, they are lower bounds: every implementation must provide at least the methods described in the interface. On function outputs, they are upper bounds: even if the implementation provides methods beyond those in the interface, they are not visible in the compile-time type system, and they are therefore also less visible in the documentation.
Because they act as bounds, interfaces work best on the consumer side of an API: for example, io.Reader belongs in the package that defines io.Copy, because Copy consumes the output of a passed‐in Reader. On the other hand, interfaces do not belong on the implementation side of the API: bytes.NewReader returns a *bytes.Reader, not an io.Reader, because a *bytes.Reader provides methods that are not required of every io.Reader.
Turning that observation back toward the os package, we see that the os package is clearly on the implementation side of os.File: there are several functions in the package that return a *File, but zero that accept one as an argument other than a method receiver (#13473 notwithstanding).
If we were to make os.File an interface, that would make every further addition to the os.File API either a breaking change (because existing implementations would no longer match the new method) or a second-class, under-documented feature (because the new method would not be in the method set of the exported interface). That is a high cost.
In exchange for that cost, we would get very little benefit. It is already possible today for any package to define and use an interface with an arbitrary subset of the methods provided by *os.File, and so it is already possible for programs to use “files in the abstract sense”, independent of the os package but including *os.File.

interfaces work best on the consumer side of an API

Would you agree with adding symbols to ioutil so that we can pass it filesystem implementations?

An alternative would be to split the implementation. Leave os.File in place, but also introduce an io.File interface that covers the methods generally associated with files. For example:
type File interface {
  Reader
  Writer
  Seeker
  ReaderAt
  WriterAt
  Syncer // Doesn't exist, but you never know. Maybe `Flusher` instead?
  Close
}

This is analogous to the difference between net.Conn and the various specific connection types. Go 2 could then decide what direct usages of *os.Fileto replace with io.File.
In this case, an extra io.Directory interface covering directory-specific os.File operations, such as Readdir(), might make sense as well, although that might be complicated by the reliance on os.FileInfo.

@aviau

Would you agree with adding symbols to ioutil so that we can pass it filesystem implementations?

Yes to adding symbols, no to ioutil. (I think ioutil should be specific to OS files; see https://github.com/golang/go/issues/19660. For specific alternatives, see https://github.com/golang/go/issues/13473#issuecomment-379946014.)

*os.File currently has 20 methods. I don't think we want to introduce an interface with 20 or even 15 or 10 methods.
And we don't want to go overkill on optional interfaces because experience with http.ResponseWriter and its optional interfaces show that wrappers too often hide methods that the wrapped value does implement. Or you have to have wrappers implement the world and define the each optional method to have a "Oh, nevermind, carry on as if I didn't implement this" return value.
Also, changing *os.File to be an interface would be pretty infectious, for better or worse.
Counterproposal
If one of the primary motivations for this is to implement VFS packages that return files, the real problem is there's no way to instantiate arbitrary *os.File values that aren't backed by the filesystem.
We could instead add constructor func(s) to return *os.File values given an interface value. For example,
// NewReaderAtFile returns an *os.File given the provided stat information and ReaderAt.
// The file is assumed to be a regular file with size fi.Size(), backed by the data in contents.
func NewReaderAtFile(fi FileInfo, contents io.ReaderAt) *os.File

You could imagine a few of those for various types (regular files, symlinks, directories).
For misc methods like File.Chdir or File.Truncate, you could return an error by default, or document that the content interface value is checked for matching names & signatures. That might avoid the composition problem with ResponseWriters because it wouldn't be interfaces all the way down and people would pass around an *os.File with a concrete set of methods that could grow over time.

I addition, this counterproposal would have a nice solution to #13473 too. Instead of that bug's:
os.Stdout = bufio.NewWriter(os.Stdout)
os.Stderr = bufio.NewWriter(os.Stderr)

You'd instead write something like:
os.Stdout = os.NewWritableFile(bufio.NewWriter(os.Stdout))
os.Stderr = os.NewWritableFile(bufio.NewWriter(os.Stderr))

So the type of os.Stdout and os.Stderr would remain *os.File, but it'd be easier to create custom implementations of *os.File`.

@bradfitz, what would the *os.File returned by NewReaderAtFile do for things like the Fd method that really do rely on having something that the OS recognizes as a file?

Either return -1 by default (in lieu of an error return value there) or delegate to the wrapped interface as described above.

I agree that that approach works around many of the maintainability problems of interfaces, but I still don't understand why it belongs in the os package (rather than, say, a subpackage in io).

Can we maybe start with making a overview of what is currently a interface and what is not?
Example
https://golang.org/src/os/types.go?s=369:411#L6
https://github.com/golang/go/blob/go1.11.2/src/net/http/fs.go#L93
Sure there is a perfect reason for why one is a struct and the other a interface. We only have one shot to make it so that everything get to be in harmony again that developers can predict with almost 100% accuracy if something going to be a struct or a interface without looking at the code.
I suggest we must first create a world map where we define interface or struct countries, but for me your proposal is already like a street name in a unknown country where you need to explain to the mail man to use the godoc stars to navigate his airplane
I think we are skipping a step here and need to zoom way out just to make sure we have this logic harmony now that we have the chance to finally fix the world map after 10 years.
So basically what I am trying to convince is that if A and B is a interface C must be too. Not saying your solution is bad I simply want a complete interface list that make sense first. Thanks

I just want to to be able to make them not be files at all. VFS is a different - important, but different - case.


How to reset the transcript/results?

Apologies in advance, this is more of a question than an issue. Is there a way to reset the transcript provided with the result event, or do I need to stop and restart the listener to get a new transcript? I need continuous transcription processing and want to retrieve a new transcript for each process. Additionally, it would be helpful if this library could offer a convenient hook, similar to what is available in react-speech-recognition. An additional resetTranscript functionality could be included with this hook. For example:
const {
  transcript,
  resetTranscript,
  isListening,
  isError,
  error,
} = useSpeechRecognition()

Thank you for your detailed response! I followed your suggestion and ended up writing a hook. Your tips were also helpful!
As for:

Or storing the "replaced" transcript in state and using transcript.replace(...) to reset the transcript.

That seems like the best approach for now, and I'll likely implement something as you suggested.
Thanks again!


Setting Up the Project

First, create a new Django project and app.
django-admin startproject ecommerce_project
cd ecommerce_project
django-admin startapp returns_exchanges

Successfully set up the project with the above commands.


utils: fix #842, always link stdc++fs if linux & gcc.

Try to fix #842 by always linking against stdc++fs on Linux&GCC combo.
Notes:

This might cause problems (later/now) on some system - if there is no stdc++fs known to GCC, linking against it will probably end up with error.
We could use CMAKE_CXX_COMPILER_VERSION to check for GCC 7/8, but I didn't want to complicate it.

@xkubov Please take a look and merge if ok.

I have tested this with GCC 8 with CMake unable to locate stdc++fs and RetDec built fine. This solution may create an error in the future, but right now, other approaches do more evil than good. So LGTM, merging.


Glossary page in KEEP token dashboard

Let's add a Glossary page according to Figma view

This has been updated:

The tooltips within the dapp also link to this page. Some examples:


[Improvement]: S3 Gateway should respond with real error messages

What happened?
When I call the CompleteMultiPartUpload API incorrectly, it always responds with a vague error message that doesn't help me, such as:
operation error S3: CompleteMultipartUpload, exceeded maximum number of attempts, 3, https response error StatusCode: 500, api error InternalError: We encountered an internal error, please try again.

But LakeFS actually logs the real error messages:
level=error msg="could not complete multipart upload" func="pkg/gateway/operations.(*PostObject).HandleCompleteMultipartUpload" file="build/pkg/gateway/operations/postobject.go:122" error="EntityTooSmall: Your proposed upload is smaller than the minimum allowed object size.\n\tstatus code: 400 method=POST operation_id=post_object service_name=s3_gateway upload_id=xxx

I think the S3 Gateway API should also respond with a real error messag when encountered an error to help the caller.
lakeFS Version
0.94.1

Ouch.  This is obviously painful, sorry about that.
⚠ Implementers please note!
In general it is NOT safe to pass errors messages from the block adaptor through to the external user: they might be (very) misleading, and possibly may even reveal some details that should not be visible to users.  Even worse, error messages can change with versions of the underlying object storage.
However for multipart upload the basic error messages -- without any parameters from the actual call that we performed -- should be safe: These messages should all come from a similar operation on a block adaptor, rather than something like a KV.  (We might get parameters from a non-S3 underlying store, of course -- but error messages will still be better than 500, api error InternalError: We encountered an internal error, please try again.)


Swift Overlays 4 and Objective-C

Right now it seems it's not possible to use SwiftOverlays 4.0.0 in Objective-C code. I believe this is because the public methods in Swift need to be marked with @objc in order to be made available to the Objective-C code (@objc inference was deprecated). Am I right or it's just me messing something? :)
Is this a natural evolution and we need to use v3.0.0 of Swift Overlays if we want to continue using it in Objective-C?
Thanks!

@joaocorreia my apologies. This was not intentional, but due to lack of testing for ObjC.
This will be fixed in the next release (meanwhile you can use v3.0.0 if you don't need support for notifications over status bar)

@peterprokop Thanks! Right now I'm adding support for iPhone X, so I need the v4. As I'm using CocoaPods I'm temporarily solving it by changing the configuration directly in the Podfile, just for reference:
post_install do |installer|
	  installer.pods_project.targets.each do |target|
		  if target.name == 'SwiftOverlays'
			  target.build_configurations.each do |config|
				  config.build_settings['SWIFT_SWIFT3_OBJC_INFERENCE'] = 'On'
			  end
		  end
	  end
  end


The ConfigDir should not be quoted in the command definition

As done in the PR this issue is closed!


meta: remove MSRV build from standard test matrix

Simplify the CI build matrices as suggested in #56.
This PR removes our MSRV build from the standard build matrix and creates a new job called msrv. The msrv job builds and tests our msrv with default features.
Additionally, @sighphyre suggested that we remove nightly and beta from the build matrix, so I've gone ahead and done that too, but we can discuss that further and discard it if it's not appropriate.
This PR also tentatively adds a cargo lock that was generated when building with 1.59.

The reason to have nightly and/or beta there is forward warning of changes that would impact us; that lets us engage upstream rather than only finding out after the fact. We can always disable if there is a persistent breakage, but I don't think we've seen that so far.


Tasks with target = TaskScope.Global as the scope do not show up in task picker UI

VSCode Version: Code 1.18.1 (929bacba01ef658b873545e26034d1a8067445e9, 2017-11-16T18:23:26.125Z)
OS Version: Darwin x64 17.3.0
Extensions:

Extension
Author (truncated)
Version

code-runner
for
0.8.4

cpptools
ms-
0.14.2

Ruby
reb
0.15.0

Steps to Reproduce:

Create a vscode.Task using the new API passing vscode.TaskScope.Global as the target

Reproduces without extensions: Yes
I am developing an extension that provides tasks for each folder in a multiroot project and a few tasks that are applicable to all folders. Maybe I am missing something but the tasks that have TaskScope.Global as the target do not show up in the task picker UI. Is this behavior intentional?

This is clearly a bug.

Bummer.. Where you able to reproduce?

I haven't looked into tracking down what causes this. But if your description is true then it is clearly a bug.

I was able to reproduce this but need to think about it a little more. The problem is how to resolve some variable like ${workspaceFolder} in the context of a global task. We should simply replace them the variable name to make clear what happens.

Yeah, I had a look into this myself and did not find any codepath that would make this work. Seems more like a lack of implementation than a bug. The task service skips definitions that are not associated with a workspaceFolder.
I am not sure I understand your point about the variable resolution though, if the task is global ${workspaceFolder} just doesn't exist in such context and resolving it to an empty string/undefined would make sense, wouldn't it?

As far as I can understand, this is what is causing global tasks to be skipped

Yes, minus that we decided to keep the ${workspaceFolder} as a string

The right fix would be:

have global task separate since they can't be modified using a tasks.json and we shouldn't try to do so.
variables that depend on a workspace folder should keep their value.

Leaving as a bug.

Do you have a plan/overview of what needs to be done? I could give this a try...

Not yet. It is not the best issue to start with a PR for tasks. I am not sure yet if we need to separate tasks into two buckets or if we filter them for certain actions. For example Tasks > Configure Task can not show a global task.

@dbaeumer any plans of fixing this? it's been almost an year... thanks!

@dbaeumer It's been 7 years... Any chance this will be fixed anytime soon?


Default parameters for Box algorithm are wrong

this code defines:
 "elkjs_box": {
                "algorithm": "org.eclipse.elk.box",
                "childAreaHeight": 3000,
                "childAreaWidth": 3000
            },

But looking at this page and from there, this page, it should be:
 "elkjs_box": {
                "algorithm": "org.eclipse.elk.box",
                "org.eclipse.elk.spacing.nodeNode": 20
            },

I tried this out and it worked as expected.
EDIT: I know this code actually came from me ;) I guess I didn't test back in the day!

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

I tried this out and it worked as expected

That is better than reading any documentation ;-)
I have committed your changes.  Will publish it later on.

Cheers @bartbutenaers - I was going to do PR but didn't get to it today - Thanks for the work 👍


deps: regenerating with new Protobuf (1.117.x)

To merge into 1.117.x branch. This PR was generated using Protobuf 3.19.6. Source-Link: https://github.com/googleapis/googleapis/commit/dc4ef314fecf1b00833e78288cf2eb4d2b165ad1

"Kokoro - Test: Integration" failed:
[INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.google.cloud.pubsub.v1.StreamingSubscriberConnectionTest
Oct 12, 2022 12:44:23 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Permanent error invalid ack id message, will not resend
Oct 12, 2022 12:44:23 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Unknown error message, will not resend
Oct 12, 2022 12:44:23 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Transient error message, will resend
Oct 12, 2022 12:44:23 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Transient error message, will resend
Oct 12, 2022 12:44:23 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection setResponseOutstandingMessages
WARNING: Setting response: PERMISSION_DENIED on outstanding messages
Oct 12, 2022 12:44:24 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Permanent error invalid ack id message, will not resend
Oct 12, 2022 12:44:24 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Unknown error message, will not resend
Oct 12, 2022 12:44:24 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Transient error message, will resend
Oct 12, 2022 12:44:24 PM com.google.cloud.pubsub.v1.StreamingSubscriberConnection$2 lambda$onFailure$0
WARNING: Transient error message, will resend
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.249 s - in com.google.cloud.pubsub.v1.StreamingSubscriberConnectionTest
[INFO] Running com.google.cloud.pubsub.v1.OpenCensusUtilTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.342 s - in com.google.cloud.pubsub.v1.OpenCensusUtilTest
[INFO] Running com.google.cloud.pubsub.v1.SchemaServiceClientTest
[INFO] Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.778 s - in com.google.cloud.pubsub.v1.SchemaServiceClientTest
[INFO] Running com.google.cloud.pubsub.v1.PublisherImplTest

ERROR: Aborting VM command due to timeout of 10800 seconds

Retrying.

"Kokoro - Test: Integration — Build successful"


Solved #307 in cpp

Solved issue #(your issue number)
In Language- (your used language)

[x] Updated README Link
[x] Added code with comments

Thanks for contributing!

Mention issue  number

Mention issue number

ig it's already mentioned #307

Mention it as in the PR template and not in the PR desription


Code coverage ES6

Hello,
You guys recommend to use NYC for coverage since it can handle spawned files. However, when testing since I have to transpile it first, it uses the transpiled code to test for coverage.
Is there a way to configure it so that it does not do this and so that it uses the ES6 code?

NYC relies on istanbul. See this issue: https://github.com/gotwarlost/istanbul/issues/212
istanbul has a source-map branch that looks like it is getting pretty close, but looks like it doesn't play well with some reporters.
I have been told that integrating istanbul-combine solves the issue, but I never got around to it.
If you can't wait for istanbul and NYC to release source map support, I recommend trying to fork NYC to use the istanbul source-map branch. If you run into issues combining coverage files checkout istanbul-combine

@jamestalmage
Interesting. I should of done a bit more research before asking but I was stuck in traffic and I had it in my head. I'll give it a spin and report back.

There's also https://github.com/SitePen/remap-istanbul. This seems to work for me:
nyc --reporter=json npm test
mv coverage/coverage-final.json coverage/coverage.json
remap-istanbul -i coverage/coverage.json -o coverage/coverage.json
istanbul report lcov

@novemberborn With https://github.com/sindresorhus/ava/commit/fb98d5dcff7ac4810efa5ef5ee42b0d041c89d13 merged where do we stand on this?
Can this be closed, or is this a different issue?

@jamestalmage it's a different issue. Code coverage is computed over the compiled output, so the stats will be wrong and it's hard to see which line in the original code was not covered. remap-istanbul uses source maps to compute the coverage of the original source.
The approach I mentioned above works for my project, which uses a watcher to transpile source files and write them to disk, with their source maps. That output is what's tested. It not quite a one-line though and it depends heavily on your project is set up.
This isn't an issue with AVA though.

This isn't an issue with AVA though.

By which I mean, since AVA isn't responsible for the coverage reports, it's not a bug with the project. Workarounds could be explained (maybe I should do so! :wink:) but it's fairly tricky.

Here's the writeup of my workaround: https://medium.com/@novemberborn/code-coverage-with-babel-istanbul-nyc-83b8c2f1093

I think the latest release of nyc now works out the box... (or at least it does for me!)

@bcoe,
I want to make sure AVA is able to take advantage of the latest nyc source-map goodness. We are doing a couple things that I suspect may interfere. I'm just going to list them; If you can tell me if anything sounds problematic, I'd appreciate it.

AVA transpiles test files only, and avoids babel-core/register by default. This allows users to write tests in ES2015, even when they prefer to keep their module code in ES5 (good for small modules where you don't want a build step). If users want transpile their main modules, they need to call the register hook themselves.

We want to allow "helper" files in the test folder (utilities that are shareable between tests). Currently that just means, any file with a _ prefix. We will be hooking require to automatically transpile these as well (all other files will pass through unmodified by default). I see https://github.com/bcoe/nyc/pull/58 hooks require as well. I also saw your discussion here: https://github.com/babel/babel/pull/3062. Any pointers as I implement AVA's require hook so I don't clobber nyc source-map support?

We also intend to implement transpilation caching. If a file has not changed since last run, we will reuse the old transpilation result. We will store cached results as files  in a temp folder, named according to the hash of their contents (with periodic deletion of least recently used items). This means the transpiled source (and attached sourcemap) will likely not be where nyc expects to find it. Assuming nyc instruments coverage on top of transpiled files, and then uses source-maps after the fact to generate coverage for the original source after the fact, we would probably need a way to tell nyc where to find source-map information for a given file.

I look forward to your response. Thanks for your time, and for making nyc awesome!

nyc executes first, so the logic that sets aside Babel's require hook using getters/setters should also work for AVA:

https://github.com/bcoe/nyc/blob/master/index.js#L138

here's the flow that nyc uses for Babel, I think we could probably use a similar approach:

nyc delegates to AVA's require hook which will return the transpiled code with a source-map appended.
nyc will, in turn, instrument this transpiled code with test coverage.
using the source maps, nyc will report coverage that references the original pre-transpiled code.

If we implement things like we've outlined in 2., I think that only AVA's require hook will need to know about the cache.
nyc will be collecting coverage that references the pre-transpiled files.

Let me know anything I can do to help you implement this, feel free to point me at any branches that are
works in progress.

Thanks for the quick response. We will follow up as we move those initiatives along.

We might find that the nyc -> AVA -> babel-core/register interaction is an issue (perhaps nyc will need to store a stack of require hooks).

https://github.com/bcoe/nyc/pull/65 takes care of that.

nyc delegates to AVA's require hook which will return the transpiled code with a source-map appended.

This might have to be documented better on nyc's side, I'll look into that.
That said, the test files don't need to be instrumented, the source files that are being tested do. It would help though if AVA's documentation could explain the requirements so users don't have to read up on nyc. I'll look into that when things settle with nyc.

I tried nyc with ava and failed...  :cry:   I feel like I'm doing something really simple wrong.
Here's a snippet of my run scripts:
"scripts": {
    "test": "ava src/test/**/*.js",
    "coverage": "nyc npm test"
}

Any chance someone on this thread could assist in some light guidance?  I'd be happy to follow up with some README updates.

"scripts": {
-    "test": "ava src/test/**/*.js",
+    "test": "nyc ava src/test/**/*.js",
    "coverage": "nyc npm test"
}

@jamestalmage with that change, running npm test   :
> nyc ava src/test/**/*.js

module.js:339
    throw err;
    ^

Error: Cannot find module '[ path to my package root ]\ava'
    at Function.Module._resolveFilename (module.js:337:15)
    at Function.Module._load (module.js:287:25)

have you installed ava locally?
npm install --save-dev ava

Yeah, ava runs just fine by itself.  Here is a snippet from my dev deps:
"devDependencies": {
    "ava": "^0.7.0",
    "nyc": "^4.0.1"
}

Huh,
Delete your node_modules folder then:
npm cache clean && npm install

Tried that, no dice.... same error as above....  :disappointed:

@sparty02 what Node and npm versions are you running?

node v4.2.0
npm v3.5.2

@sparty02 wait you're on Windows right? nyc's Windows support isn't quite there yet, we'll be tracking progress in https://github.com/bcoe/nyc/issues/81.

@novemberborn Ah, that must be it then.  I'll watch that issue for updates.... thanks!

@sparty02 we've added better support for Windows subprocesses in<EMAIL_ADDRESS>https://github.com/bcoe/nyc/blob/master/CHANGELOG.md
It might be worth giving this a shot. If you still run into problems, could you point me at a repo I can test against?

It might be worth giving this a shot. If you still run into problems, could you point me at a repo I can test against?

@sparty02 Did that solve your problem? If no, would you be able to provide something that reproduces it?

@bcoe @sindresorhus sorry guys, I spaced out on this.  I'll give it a shot tomorrow morning and circle back to let you know.

@bcoe I pushed a sample repo at https://github.com/sparty02/nyc-ava-demo.  I stripped it down to almost nothing, and am still hitting the issue, so it almost seems environmental?  Let me know if I can provide any more info!

@bcoe @sindresorhus Just a heads up that I saw some activity over on nyc that was done in the past few days that appeared to (at least loosely) be related to better spawn support on Windows.  Long story short, I just tried my use case again with<EMAIL_ADDRESS>and<EMAIL_ADDRESS>and it worked!

@sparty02 I just set this up on a windows machine and it works but I couldn't use nyc npm test in my scripts. nyc ava works just fine.


Bump minimum CMake version to 3.5

Compatibility with CMake < 3.5 will be removed in future versions of CMake, so this avoids the warning and the impending doom.
Description
Recent CMake versions are warning that compatibility with CMake < 3.5 will be removed in a future version. Building the project will yield a warning:
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

I dug around the changelogs from 3.1->3.5 to see if there's anything relevant policy-wise that changes but couldn't find much and the doctest CMakeLists.txt is already pretty simple. I also tested it locally, and everything can still build.
I only bumped it to 3.5, which came out in 2016 but most projects I've seen set it to somewhere around ~3.16. If this is too conservative, then I can bump it up higher.
GitHub Issues
Surprisingly, I couldn't find any!

Bump? Would be good to get this merged if possible please.

Bumping again. @redstrate's already done the legwork, would hate for it to go to waste.
Fixes #829.

@onqtam mind merging?


Implement statistics for physical plan

What type of enhancement is this?
Tech debt reduction
What does the enhancement do?
DataFusion has statistics() method in its physical plan:
/// Returns the global output statistics for this `ExecutionPlan` node.
fn statistics(&self) -> Statistics;

It's better we implement it, too.
Implementation challenges
No response

@waynexia I see some PhysicalPlans have implemented detailed statistics calculation, while others just return the default values. Can you verify that this issue is done?

@waynexia Please take a look at this issue.


Is iOS simulator (M1) supported?

Thanks for great job.
Is iOS simulator (M1) supported?

Not supported now. Also, currently, apps using this framework showing problem uploading to App Store due to the usage of private API. Will be fixed shortly. Not recommended till then.


When updating the userstore domain name of a disabled userstore, userstore is getting deleted.

Steps to reproduce:

Create a secondary userstore from the management console.

Disable the secondary userstore by clicking disable button

Click the edit button and try to update the Domain Name of the userstore.

Then an error will be shown in the management console and the userstore will get deleted.
Affected Versions
WUM updated IS-5.8.0, IS-5.7.0
Related To: https://github.com/wso2/product-is/issues/7012

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Error parsing Oauth properties in cncf spec using java sdk

Discussed in https://github.com/serverlessworkflow/specification/discussions/857

Originally posted by mahith2108 May 23, 2024
Hi,
we are using  Java sdk version "4.0.5.Final" and spec version: 0.8 as suggested (https://github.com/serverlessworkflow/sdk-java)
I am trying to define Oauth properties using "auth" field in my spec as follows based on https://github.com/serverlessworkflow/specification/discussions/675
 "auth":[
            { "name" : "serviceCloud",
            "scheme": "oauth2",
            "properties":{
               "scopes": ["$$$$XXXMMMMM"],
               "audiences":["%%%XXXXXXX"]
            }

        }]

while parsing the spec using Workflow.fromSource("") I am getting following error.
Could not convert markup to Workflow: Unrecognized field "scopes" (class io.serverlessworkflow.api.auth.BasicAuthDefinition), not marked as ignorable (3 known properties: "password", "username", "metadata"])
 at [Source: UNKNOWN; byte offset: #UNKNOWN] (through reference chain: io.serverlessworkflow.api.Workflow["auth"]->io.serverlessworkflow.api.auth.BasicAuthDefinition["scopes"])

we have tried following spec as well but the authDefinition.getOauth() is coming as null.
 "auth":[
            { "name" : "serviceCloud",
            "scheme": "oauth2",
            "oauth":{
               "scopes": ["%%%%%X"],
               "audiences":["%%%XXXXXX"]
            }
        }]

@JsonPropertyOrder({"name", "scheme", "basicauth", "bearerauth", "oauth"})
public class AuthDefinition implements Serializable {

@mahith2108, FYI grantType and clientId are required for OAuth: https://github.com/serverlessworkflow/specification/blob/0.8.x/schema/auth.json#L191
I'll fix this validation and make sure the object conforms with the spec, thou.

thanks


Error: Building package glibmm:x86-windows failed with: BUILD_FAILED

Environment

OS: Windows 10 Pro
Compiler: Visual Studio 2019

To Reproduce
Steps to reproduce the behavior:

./vcpkg install libxmlpp

See error
Computing installation plan...
The following packages will be built and installed:

glibmm[core]:x86-windows -> 2.68.0
libxmlpp[core]:x86-windows -> 5.0.0
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x86-windows...
Could not locate cached archive: C:\Users\Newcool.1230\AppData\Local\vcpkg\archives\4a\4ab7e32886afd5d226f57ff4687338088e160f09.zip
Could not locate cached archive: C:\Users\Newcool.1230\AppData\Local\vcpkg\archives\46\4693c72af9b33f062fb11d4d07628b8d77de4818.zip
Starting package 1/2: glibmm:x86-windows
Building package glibmm[core]:x86-windows...
-- Using cached D:/Users/Newcool.1230/Desktop/Code/c++/caplib/vcpkg/downloads/glibmm-2.68.0.tar.xz
-- Cleaning sources at D:/Users/Newcool.1230/Desktop/Code/c++/caplib/vcpkg/buildtrees/glibmm/src/glibmm-2-202c913ce3.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source D:/Users/Newcool.1230/Desktop/Code/c++/caplib/vcpkg/downloads/glibmm-2.68.0.tar.xz
-- Using source at D:/Users/Newcool.1230/Desktop/Code/c++/caplib/vcpkg/buildtrees/glibmm/src/glibmm-2-202c913ce3.clean
-- Found external ninja('1.10.2').
-- Configuring x86-windows
-- Using msys root at D:/Users/Newcool.1230/Desktop/Code/c++/caplib/vcpkg/downloads/tools/msys2/50864d9fae363d6e
-- Configuring x86-windows-dbg
-- Configuring x86-windows-dbg done
-- Configuring x86-windows-rel
-- Configuring x86-windows-rel done
-- Package x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:105 (message):
Command failed: "N:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe" install -v
Working Directory: D:/Users/Newcool.1230/Desktop/Code/c++/caplib/vcpkg/buildtrees/glibmm/x86-windows-dbg
Error code: 1
See logs for more information:
D:\Users\Newcool.1230\Desktop\Code\c++\caplib\vcpkg\buildtrees\glibmm\package-x86-windows-dbg-out.log

Call Stack (most recent call first):
scripts/cmake/vcpkg_install_meson.cmake:58 (vcpkg_execute_required_process)
ports/glibmm/portfile.cmake:21 (vcpkg_install_meson)
scripts/ports.cmake:142 (include)
Error: Building package glibmm:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: glibmm:x86-windows
Vcpkg version: 2021-01-13-d67989bce1043b98092ac45996a8230a059a2d7e
Additionally, attach any relevant sections from the log files above.
Failure logs
package-x86-windows-dbg-out.log

Hi @Newcool1230
Thanks for posting this issue.
Could you please help confirm which versions are the Visual Studio and Windows SDK you installed?

Hi @Newcool1230
Thanks for posting this issue.
Could you please help confirm which versions are the Visual Studio and Windows SDK you installed?

Visual Studio: 16.9.4
Windows SDK: 10.0.19041.0

Please set toolset to Visual Studio 2019 manually in your triplets, then try to rebuild.
set(VCPKG_PLATFORM_TOOLSET v142)


Missing escape

data_url/__init__.py:5: SyntaxWarning: invalid escape sequence '\w'
  "[data:(?P<MIME>[\w-]+\/[\w+-]+(;[\w-]+\=[\w-]+)?)(?P<encoded>;base64)?,(?P<data>[\w\d.~%\=\/\+]+](data:(?P%3CMIME%3E[\w-]+\/[\w+-]+(;[\w-]+\=[\w-]+)?)(?P%3Cencoded%3E;base64)?,(?P%3Cdata%3E[\w\d.~%\=\/\+]+))"

caused by https://github.com/telday/data_url/blob/master/data_url/init.py#L5
It seems like this should be a raw string (marked with r"").

Hi @Turakar, I was unable to reproduce the error you mentioned here in python3.10. Could you give more information on the python version you are using as well as the context in which the error occurs?

Hi, thanks for looking into this. You are right, this is related to the Python version. See here, for example:
https://stackoverflow.com/questions/52335970/how-to-fix-syntaxwarning-invalid-escape-sequence-in-python#52335971
And note that DeprecationWarning is not shown by default in current Python versions.

I'm going to add some additional tests to the library today and get it working with the current version of Python. Version 1.1.0 should be compatible with Python 3.12

This issue has been fixed in version 1.1.0 of the module. Please note updates in the API with this version.


Double animation on first render

Describe the bug
I updated my version of react-grid-layout from 1.3.4 to 1.4.1 and now I notice that on layout containing several "complex" components  the initial animation is weird, as if played twice.
I don't have the problem on the previous version, and it also doesn't appear when StrictMode is disabled.
I'm aware that StrictMode is only for dev, but it also exists to show potential problems. Something on v1.4.0 or v1.4.1 introduced this issue.
Your Example Website or App
I tried to reproduce the issue on CodeSandbox but it would be too much code to have the same components as I have inside my layout (it's mostly Slate editors). I also tried with heavy components such as Mui's tables, but it just freeze the UI instead of showing the animation. The CodeSanbox below is a base but doesn't show the issue as the blocks only contain text.
https://codesandbox.io/s/ff95g8
Steps to Reproduce the Bug or Issue
Try using complex components inside a layout.
Expected behavior
I expect to see the initial animation only once.
react-grid-layout library version
1.4.1
Operating System Version
Windows 10
Browser
Other (add additonal context)
Additional context
Electron 26 (chromium)
Screenshots or Videos
With StrictMode:
https://github.com/react-grid-layout/react-grid-layout/assets/32762018/9aa0905d-f003-4fbf-842c-0e1822851946
Without StrictMode (or with version 1.3.4):
https://github.com/react-grid-layout/react-grid-layout/assets/32762018/56174613-8f44-4ee0-a813-f2ae23857f24

I tested commit by commit and managed to pinpoint the problem was introduced with resizeObserver on commit https://github.com/react-grid-layout/react-grid-layout/commit/2d72f8b3327febd1eff9a3535ce5b2183a37a143.

Here is what I gatherer with logs:
With the previous system using the resize event:
Mount (first) -> setState -> Unmount -> Mount (strict) -> setState

With the new system using the resizeObserver:
Mount (first) -> Unmount -> Mount (strict) -> setState

If I manually trigger a setState on first mount on the resizeObserver version it fixes the issue. Triggering an extra render doesn't seem clever, but could this missing rerender messes up with the CSS transitions somehow?
@currents-jantu any insightson this since you made this change?

Didn't noticed it during tests since I'm not using StrictMode, let me check.

@currents-jantu I tried to replace resize-observer-polyfill with @juggle/resize-observer and it fixes the issue!
The flow stays the same, I don't see a setState on the first render, but no weird animation either. This library also seems more up-to-date, with its last update dating back to 2022, whereas the other library was last updated in 2018.
The only change to the code, apart from installing the library, is this:
- import ResizeObserver from 'resize-observer-polyfill';
+ import { ResizeObserver } from '@juggle/resize-observer';

What do you think? Could you test this please? I have not managed to start react-grid-layout in dev, I can only test it using a yarn portal on my app. Thanks.

Hi all, @Arkellys
À polyfill will return the native implementation if it's there, so replacing the polyfill by another one should not matter. Are you testing in a browser that's not supporting ResizeObserver? The support seems pretty wide: https://caniuse.com/resizeobserver
David

Hello @ddolcimascolo 👋
I'm testing on the latest version of Electron, which is on Chromium 118, so the ResizeObserver is supported. But replacing the library does fix the issue, I tried 3 times to be sure. I really can't explain why.
https://github.com/react-grid-layout/react-grid-layout/assets/32762018/a436a0c9-147c-4443-b6db-ff5397a276a5

Thx for the double check. I don't quite get it either...

@ddolcimascolo I found the difference, I tested with the native ResizeObserver without any polyfill library and I get the bug with it. On @juggle/resize-observer's  README it's mentioned that:

This will use the ponyfilled version of ResizeObserver, even if the browser supports ResizeObserver natively.

So the problem is not because of the library, but because of native ResizeObserver itself (the why is still a mystery). I don't know what's the best course of action is in this case... I would certainly be happy if we could replace the polyfill library with the ponyfill one, since it works the same and fixes the issue. But I can also understand why it's better to use the native API.
@STRML if you're still around, any thoughts on this?

Yes - this probably has something to do with this:

See https://react.dev/reference/react/StrictMode
Now, as for how we get around it - I'll investigate.

I'm inclined to think this is an issue with your implementation. I can't reproduce it in make dev even though we use <React.StrictMode> there. And your codesandbox is inconclusive. Can you provide a working reproduction?

@STRML Yes, the ScrictMode makes the component re-render after first mount. But it was not a problem with the resize event, and it's not a problem either with the ponyfill, but it is with the native ResizeObserver when the setState is not triggered on first mount.
I will try to see what I can do on the CodeSandbox this week end, hopefully I will be able to reproduce the bug. Otherwise I will have to use the ponyfill on my code to override the native API. At least If it's only a problem in dev, it's not catastrophic.

Okay, so after trying for hours to find where the problem might come from and trying to reproduce it on CodeSandbox, I think I will just give up.
My layout have a lot of nested components, Portal, Transitions, map... I was not able to pinpoint if there is a faulty component or line of code in particular because it's not the case. I tried to comment out parts of the code component by component and function by function, and the more I comment, the less the problem is visible, regardless of what I remove. For a moment, I also thought the problem had randomly disappeared, but it turns out that I had my console closed and the bug is more visible when it's open. I just can't reproduce this level of complexity on CodeSandbox.
I can confirm that in prod the bug is not here at all (because no StrictMode), so I think I will just close this issue and use the ponyfilled ResizeObserver when in dev for my own comfort.
if (isInDevelopment) {
  global.ResizeObserver = (await import("@juggle/resize-observer")).ResizeObserver;
}

Thank you all for taking a look at this.


Deploy and Configuration on INT

Issue Description
We need to configure and deploy all new information for our apps in the INT env.

Requirement:
Deploy and configuration of Frontend
Deploy and configuration of Backend
Deploy and configuration of EDC Provider
Deploy and configuration of EDC Consumer

Product Information

Product Name: vas-country-risk-backend
Repository Link: vas-country-risk-backend
Frontend Repository Link: vas-country-risk

Tasks

[x] Update User for app on vault so we can login from the frontend with Portal
[x] Create and Update new technical User for Country Risk connection to Gate and Pool
[x] Add Roles to be configured with Country Risk Dashboard
[x] Configure EDC with new bpnl and technical User
[x] Deploy everything with new configuration on INT

Hints for Resolution

Carefully update and test with EDC and with not EDC on Int
Both Users must function correctly

Additional Information

The frontend repo is the Main Source of helm charts but the logic of validation roles will be on backend
Main configurations can be also changed on vault

Quality Gate Done


https:///graphql returns 404

HI,
Another issue i have run in to is that when you go to /graphql it returns a 404.
Thanks

Hello!
Really everything points to an issue with your domain configuration, if you write dokku domains:report your-app what do you see? (fell free to change your domain name with something else in your response, I'm interested in seeing the subdomains though)
Thanks!

@howlrapp
=====> meowlr domains information
       Domains app enabled:           true
       Domains app vhosts:            <redacted>.xyz
       Domains global enabled:        true
       Domains global vhosts:         <redacted>.xyz
``` but the admin panel is fine.

Maybe you are using the GET method to query the API? Howlr only supports POST.

just made a graphql client and tested it and yea i was using GET. For the application iself what version of gradle are you using since when trying to compile the app the majority of it is deprecated?


remove attachChannelWallet method

The chain watcher does not need to know about the channel wallet API. Instead, it is sufficient to allow the channel wallet to subscribe to events emitted by the chain watcher.
Let's make an issue for this.
Originally posted by @andrewgordstewart in https://github.com/statechannels/statechannels/pull/2527#discussion_r485075604

This is done in the V1 chain watcher.


Support custom where filters

Currently there are some query that are not possible to make directly and the dataset needs to be filtered manually afterward.
For instance, there is no way to quey on null or dates:
const now = new Date()
db.entity.findMany({ where: {
  someNullableProperty: { equals: null },
  someDate: { lte: now },
  someNumber: { gte: 10 },
} })

The only way I found to do this is to filter the results afterward:
const now = new Date()
db.entity.findMany({ where: { someNumber: { gte: 10 }} }).filter(
  ({ someNullableProperty, someDate }) => (
    someNullableProperty === null &&
    someDate <= now
  )
)

But we can't use pagination then and we have to manually implement it as well.
Instead of implementing every possible missing feature, I suggest allowing custom filter function to be used in where queries:
const now = new Date()
db.entity.findMany({ where: {
  someNullableProperty: (value) => (value === null),
  someDate: (date) => (date <= now),
  someNumber: { gte: 10 },
} })

It would be great if it was also possible to specify it at the where level, as it would allow to compare properties of a single entity, in addition to be able to use the existing pagination:
const now = new Date()
db.entity.findMany({
  where: ({ someNullableProperty, someDate, someNumber, maxValue }) => (
    someNullableProperty === null &&
    someDate <= now &&
    someNumber >= maxValue
  )),
  take: 15,
  cursor: null,
})

Hey, @mesteche. Thanks for the suggestion.
I wonder what goes wrong with date querying in your case. Could you take a look at our Date test suite and see if you can spot any difference? As far as I know, querying by Date is supported and functional but I may be missing some scenarios.
Querying by null is indeed a bug and we have a test confirmation added for that in #187. If you feel interested, you can lend me a hand in solving it. Otherwise, I will address it when I have time.
Are there any other scenarios that the library does not satisfy apart from those two? If not, I'd close this issue. It should be possible to query data by its properties and their respective comparators.


Add possibility to disable slider after initialization.

Slider will check for disabled state on every event now rather than only at its initialization.
Fixes #8497.

Thanks. Should we check the [disabled=false] case ?

Yeah, you're absolutely right. It only makes sense if you can also enable a disabled slider... Did another commit for this.

I mean : should we consider the slider as enabled when it has a disabled="false" or disabled="enabled" attribute ?

I don't know if this.options.disabled care about this cases, or if it is only checking that a disabled attribute has been set, regardless of its value

I guess you mean data-disabled, since disabled is only for inputs. The options are only initialized once based on this attribute, so for now only checking the class is possible.

@Owlbertz this looks good.  Can you set up a unit test for this case in test/javascript/components/slider.js? You can use the tests in test/javascript/components/toggler.js as an example of how these can be structures. See: https://github.com/zurb/foundation-sites/blob/develop/test/javascript/components/toggler.js
Thanks!

Gonna move forward with this


Updated base Profile Inspectors.

Overview
Updated the base profile inspectors a bit so that third party users can copy/paste custom made MixedRealityProfiles with ease without having to know about MRTK specific inspector functionality.
Breaking Changes

Renamed MixedRealityBaseConfigurationProfileInspector to BaseMixedRealityToolkitConfigurationProfileInspector
Moved CheckMixedRealityConfigured to MixedRealityInspectorUtility.CheckMixedRealityConfigured

Did my comments get answered before this was check in?

@chrisfromwork I don't see any comments from you on this PR.

@keveleigh looks like I failed to understand the pending GitHub ux :)


Execution failed for task ':fluttertoast:compileDebugKotlin' after upgrading to Flutter 2.10.1

Having this issue after upgrading to Flutter 2.10.1
There are workarounds i have tried including flutter clean and rebuild, but seem didn't solve my case.
fluttertoast: ^8.0.8
Error messages:
...
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':fluttertoast:compileDebugKotlin'.
> Compilation error. See log for more details

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 8s

┌─ Flutter Fix ────────────────────────────────────────────────────────────────────────────────┐
│ [!] Your project requires a newer version of the Kotlin Gradle plugin.                       │
│ Find the latest version on https://kotlinlang.org/docs/gradle.html#plugin-and-versions, then │
│ update C:\Projects\kjb\android\build.gradle:                                                 │
│ ext.kotlin_version = '<latest-version>'                                                      │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
Exception: Gradle task assembleDebug failed with exit code 1

Flutter version:
Flutter 2.10.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision db747aa133 (6 days ago) • 2022-02-09 13:57:35 -0600
Engine • revision ab46186b24
Tools • Dart 2.16.1 • DevTools 2.9.2

Hi,
I am also getting same issue

Hi,
I am also getting the same issue

same issue for me also.

There is a code in the #370 pull request that can solve this issue.
If that Branch becomes Merge, we can solve this problem.

There is a code in the #370 pull request that can solve this issue. If that Branch becomes Merge, we can solve this problem.

Yes, I have tried this and it worked
What I did are:

Manually adding ext.kotlin_version = '1.6.10' in fluttertoast android\build.gradle

group 'com.example.FlutterToast'
version '1.0-SNAPSHOT'

buildscript {
    ext.kotlin_version = '1.6.10'
    repositories {
        google()
        jcenter()
    }
...

Changing gradle distributionUrl in android\gradle\wrapper\gradle-wrapper.properties from gradle-5.6.2-all.zip to gradle-6.1.1-all.zip

zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-6.1.1-all.zip

As it generated error like The current Gradle version 5.6.2 is not compatible with the Kotlin Gradle plugin. Please use Gradle 6.1.1 or newer, or the previous version of the Kotlin plugin in my case.

#370 now merged 🎉