2M PHY + DLE and timing calculations on an encrypted link are wrong

Describe the bug
We are seeing some issue regarding 2M PHY + DLE and timing calculations on an encrypted link.
We use DLE with 251 as maximum and have some internal test that tries to send 244 bytes via GATT with 7 bytes protocol overhead, so that becomes 251 bytes LL PDU Payload. When adding the 4 byte MIC, the LL PDU length becomes 255.
On the AIR this should become one LL packet, instead we are seeing two.
We see that when running 2M that struct lll_conn's max_tx_time is 1060 and when ull_conn_lll_max_tx_octets_get(struct lll_conn *lll) [subsys/bluetooth/controller/ll_sw/ull_conn.c] is called max_tx_octets becomes 1060/8 - 11 = 254 where it should be 255.
The correct max_tx_time should be 1064, with 4us extra for the missing byte.
We believe we have tracked the issue to PKT_US(octets, phy) [subsys/bluetooth/controller/ll_sw/ull_conn_internal.h] where the phy parameter is fixed to 1, when given to PREAMBLE_SIZE(phy) [subsys/bluetooth/controller/ll_sw/pdu.h].
Also we have noticed that in some calls to PKT_US a 0 is given as phy which doesn't make sense, so we guess it should be BIT(0).
Expected behavior
On the AIR the 244 bytes GATT operation should be one LL packet.
Impact
Throughput degradation.
Environment
Zephyr 2.2

CC @cvinayak @kruithofa

Same bug is present in the legacy controller


Fix a build failure with the micro-benchmarks

Since this is a trivial fix that only pertains to CircleCI, I'm pushing this w/o review.


[Tests-only] document how to use oC10 API tests for BDD in ocis

analog to https://github.com/owncloud/ocis-reva/pull/141
part of owncloud/ocis#211

can s.o. please click the approve button?


google storage: customer-supplied encryption keys

Output of restic version
restic 0.12.1 (v0.12.1-101-g78dac2fd-dirty) compiled with go1.16.8 on linux/amd64

What should restic do differently? Which functionality do you think we should add?
I would like to implement customer-supplied encryption keys in google storage backend.

What are you trying to do? What problem would this solve?
I believe that this would add another layer of security to cloud backups. GCP do not allow to download encrypted files without providing key even if user authenticate correctly.
It should be noted that customer-supplied keys are not zero-knowledge encryption because user sends encryption key with request and data are encrypted or decrypted in the cloud. Encryption key is stored in memory and removed after operation.
I made simple implementation based on https://cloud.google.com/storage/docs/encryption/using-customer-supplied-keys and it works. There are still some problems unsolved such as: how user should provide encryption key or whether to check if repo uses customer-supplied encryption or just return error to user.

Did restic help you today? Did it make you happy in any way?
Restic is a very handy tool.

Closing based on https://github.com/restic/restic/pull/3612#issuecomment-1146869395


No mods

There are no mods here, but the original game does! Or I missed something ...

go to settings

On Dec 21, 2020, at 03:22, Mr-Zlob<EMAIL_ADDRESS>wrote:
There are no mods here, but the original game does! Or I missed something ...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/111116/webosu/issues/62, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET5RLGGV6U23N2ESU2WHNTSVZFIBANCNFSM4VDJ67FA.

Oh, I did not notice. Forgive me for being disturbed!


nwg-drawer: 0.3.0 -> 0.3.7

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: "Application drawer for sway Wayland compositor"
meta.homepage for nwg-drawer is: "https://github.com/nwg-piotr/nwg-drawer"
meta.changelog for nwg-drawer is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.1 with grep in /nix/store/1yh648lgaxn152xcabz4w7qgq41awl3h-nwg-drawer-0.3.1
found 0.3.1 in filename of file in /nix/store/1yh648lgaxn152xcabz4w7qgq41awl3h-nwg-drawer-0.3.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1yh648lgaxn152xcabz4w7qgq41awl3h-nwg-drawer-0.3.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/773bfaa05d1b0cc6887fae9e3873958481da4c42.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1yh648lgaxn152xcabz4w7qgq41awl3h-nwg-drawer-0.3.1
ls -la /nix/store/1yh648lgaxn152xcabz4w7qgq41awl3h-nwg-drawer-0.3.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: "Application drawer for sway Wayland compositor"
meta.homepage for nwg-drawer is: "https://github.com/nwg-piotr/nwg-drawer"
meta.changelog for nwg-drawer is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.2 with grep in /nix/store/3hnly2vi3dq34xbspafa25xndx0ww1ki-nwg-drawer-0.3.2
found 0.3.2 in filename of file in /nix/store/3hnly2vi3dq34xbspafa25xndx0ww1ki-nwg-drawer-0.3.2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3hnly2vi3dq34xbspafa25xndx0ww1ki-nwg-drawer-0.3.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/81793e841d618e230ff575917defbc3bf929857e.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3hnly2vi3dq34xbspafa25xndx0ww1ki-nwg-drawer-0.3.2
ls -la /nix/store/3hnly2vi3dq34xbspafa25xndx0ww1ki-nwg-drawer-0.3.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: "Application drawer for sway Wayland compositor"
meta.homepage for nwg-drawer is: "https://github.com/nwg-piotr/nwg-drawer"
meta.changelog for nwg-drawer is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.3 with grep in /nix/store/ws6f412wxsm13drv5y9gvgbagmwck2h1-nwg-drawer-0.3.3
found 0.3.3 in filename of file in /nix/store/ws6f412wxsm13drv5y9gvgbagmwck2h1-nwg-drawer-0.3.3

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ws6f412wxsm13drv5y9gvgbagmwck2h1-nwg-drawer-0.3.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/ce490f43d70a129b229e6c0e7ea12238db032513.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ws6f412wxsm13drv5y9gvgbagmwck2h1-nwg-drawer-0.3.3
ls -la /nix/store/ws6f412wxsm13drv5y9gvgbagmwck2h1-nwg-drawer-0.3.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: "Application drawer for sway Wayland compositor"
meta.homepage for nwg-drawer is: "https://github.com/nwg-piotr/nwg-drawer"
meta.changelog for nwg-drawer is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.4 with grep in /nix/store/mrxrvgigb86xbjikm4lxw2rjs9n6a6x5-nwg-drawer-0.3.4
found 0.3.4 in filename of file in /nix/store/mrxrvgigb86xbjikm4lxw2rjs9n6a6x5-nwg-drawer-0.3.4

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mrxrvgigb86xbjikm4lxw2rjs9n6a6x5-nwg-drawer-0.3.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/340b9e9033a8f2013be5a6a70d457d691a2a78a4.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mrxrvgigb86xbjikm4lxw2rjs9n6a6x5-nwg-drawer-0.3.4
ls -la /nix/store/mrxrvgigb86xbjikm4lxw2rjs9n6a6x5-nwg-drawer-0.3.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: "Application drawer for sway Wayland compositor"
meta.homepage for nwg-drawer is: "https://github.com/nwg-piotr/nwg-drawer"
meta.changelog for nwg-drawer is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.5 with grep in /nix/store/jpsr6jw8xvpl7yd0nqxaxzxcbg187070-nwg-drawer-0.3.5
found 0.3.5 in filename of file in /nix/store/jpsr6jw8xvpl7yd0nqxaxzxcbg187070-nwg-drawer-0.3.5

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/jpsr6jw8xvpl7yd0nqxaxzxcbg187070-nwg-drawer-0.3.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/560350b16631a6bc85a10117bf342b7a9a0b8adf.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/jpsr6jw8xvpl7yd0nqxaxzxcbg187070-nwg-drawer-0.3.5
ls -la /nix/store/jpsr6jw8xvpl7yd0nqxaxzxcbg187070-nwg-drawer-0.3.5/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: "Application drawer for sway Wayland compositor"
meta.homepage for nwg-drawer is: "https://github.com/nwg-piotr/nwg-drawer"
meta.changelog for nwg-drawer is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.6 with grep in /nix/store/gpzvdgsw9rrx99ws0wbbins3cvm5h4zd-nwg-drawer-0.3.6
found 0.3.6 in filename of file in /nix/store/gpzvdgsw9rrx99ws0wbbins3cvm5h4zd-nwg-drawer-0.3.6

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gpzvdgsw9rrx99ws0wbbins3cvm5h4zd-nwg-drawer-0.3.6 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/02c02e68c6e2cb5d1c3bba078e506bbeb763b181.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gpzvdgsw9rrx99ws0wbbins3cvm5h4zd-nwg-drawer-0.3.6
ls -la /nix/store/gpzvdgsw9rrx99ws0wbbins3cvm5h4zd-nwg-drawer-0.3.6/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nwg-piotr/nwg-drawer/releases.
meta.description for nwg-drawer is: Application drawer for sway Wayland compositor
meta.homepage for nwg-drawer is: https://github.com/nwg-piotr/nwg-drawer
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3.7 with grep in /nix/store/lvy6qqpmhb69ss349gqpnbbghg317nln-nwg-drawer-0.3.7
found 0.3.7 in filename of file in /nix/store/lvy6qqpmhb69ss349gqpnbbghg317nln-nwg-drawer-0.3.7

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nwg-drawer

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/lvy6qqpmhb69ss349gqpnbbghg317nln-nwg-drawer-0.3.7 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nwg-drawer https://github.com/r-ryantm/nixpkgs/archive/8b427b92778ba196ef41a4675df42249f2ff5511.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/lvy6qqpmhb69ss349gqpnbbghg317nln-nwg-drawer-0.3.7
ls -la /nix/store/lvy6qqpmhb69ss349gqpnbbghg317nln-nwg-drawer-0.3.7/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nwg-drawer

Maintainer pings
cc @plabadens for testing.

@ofborg build nwg-drawer nwg-drawer.passthru.tests


KAFKA-2370: kafka connect pause/resume API

Ping @ewencp @gwenshap @Ishiihara
Overview: this patch contains the pause/resume API which lets users suspend a connector's processing. The paused state is an instance of a connector "target state," which is stored in the config storage topic. the main reason to have it there is that it opens the door to considering the pause state when determining the task assignments for the workers (e.g. the leader can choose not to assign any paused connectors). However, at the moment, pausing the connector does not cause a rebalance. Instead, each worker reads from the config topic independently. When a target state change is observed by a worker, it pauses or resumes all tasks for that connector which it owns (if there are any). Since a connector's configuration may have changed while it was paused, we always check whether a rebalance is needed after resuming.
At the moment, there are only two implemented target states: "started" and "paused." When a connector is first configured, it is in the "started" state regardless whether any target states have been written to the config topic. As state changes occur, the new state is written to the topic. When a connector is deleted, we write null for the value to ensure cleanup.
Pause Behavior: the meaning of "pause" depends on the type of task:

Connector: pause means calling stop() on the connector.
Source task: pause means we stop calling task.poll() for new data.
Sink task: all assigned partitions are paused using KafkaConsumer.pause(). Significantly, the worker stays part of the consumer group.

Additional notes: I did some minor refactors here and there, but the most significant one was extracting an interface from KafkaConfigStorage and updating StandaloneHerder to use an in-memory implementation of it. This was a bit awkward since KafkaConfigStorage was designed around a snapshot which is recomputed on config updates, but hopefully it will allow us to move more common functionality into AbstractHerder down the road.
Known Gap: the main gap that comes to mind is additional unit/integration tests for the Herder implementations.

@hachikuji Can you rebase against trunk? KAFKA-3315 also modifies AbstractHerder and other related classes.

@Ishiihara Done. Thanks for taking a look. I'm adding some test cases for the Herder implementations and will update the patch shortly.

@ewencp Apologies for the delay. I've tried to fix the race condition with task shutdown, but the synchronization in WorkerTask is getting complex. If it seems OK now, maybe we can plan to revisit it later.

@Ishiihara @ewencp Rebased and updated according to KIP outcome and offline discussion. Would you mind taking another look?

@hachikuji Just made a pass. In general, this is really great. Left some comments for minor cleanup. As we discussed offline, some synchronization stuff in 'WorkerTaskandWorkerConnector` can be cleaned up a bit.

@Ishiihara @ewencp Thanks for the reviews. Have a look at the latest commit on handling connector initialization failures. It seemed convenient to handle failures similarly to how we handle them in the tasks: i.e. we treat initialization failures identically to startup failures and leave the connector in a persistent failed state. Otherwise, you need to invent a new "defunct" state which prohibits startup (since we wouldn't want to even try starting a connector if it failed to initialize). This means that the user must use /restart to restart a failed task, which is a little different from the initial patch which allowed the usage of /resume to restart a failed connector.

@hachikuji The exception handling looks good. This seems to fix the bug reported by C3 team. In case of errors during connector initialization or start, reconfiguration will not be invoked. The consequences of this is that the tasks for this connector will not be initialized and started. One question though, restart may not work in case of incorrect configs as it will fail again. We probably need to destroy the connector in this case and submit a new one with the correct configs.

@hachikuji Another question is that why do we use TARGET_STATE_KEY(connector) in removeConnectorConfig of in KafkaConfigBackingStore.java, shouldn't we use CONNECTOR_KEY instead?

@Ishiihara Thanks for taking another look. For removeConnectorConfig, there are two parts: removal of the connector's configuration and removal of the target state. The first is handled in updateConnectorConfig.

On connector failures, there are definitely cases where restarting won't help. In those cases, we hope the exception provides enough information for the user to fix the problem before trying to restart. However, I don't think the framework should necessarily try to detect this situation and attempt any cleanup itself. Does that make sense?

@hachikuji Thanks for the explanation. I missed the updateConnnectorConfig part.

LGTM. We have a few follow up items, we should file follow up JIRAs for anything that's not going to followed up on immediately. Thanks for all the work on this patch, @hachikuji, turned out to be slightly more involved than anticipated.


durack1 user tweaks

@bmusci3 this is what I had to tweak to get things working

Directed to wrong origin


DirectoryInfo objects retrieved from Get-Item and Get-ChildItem show different Extension properties when directory name includes period

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Have a directory that contains a period.  When a DirectoryInfo is retrieved from Get-Item, the BaseName property includes the period and text after while the Extension property is an empty string.  When a DirectoryInfo is retrieved from Get-ChildItem, both the BaseName and Extension properties both include the period and the text after.
$ pwsh.exe -noprofile
PowerShell 7.2.4
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS C:\Temp> mkdir 'C:\Temp\FileName.zip\'

	Directory: C:\Temp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          2022-05-26    16:48                FileName.zip

PS C:\Temp> pushd 'C:\Temp'
PS C:\Temp> $fromGetItem = Get-Item -Path '.\FileName.zip\'
PS C:\Temp> $fromGetChildItem = (Get-ChildItem -Path .)[0]
PS C:\Temp> $fromGetItem | Select-Object -Property Name,BaseName,Extension | Format-List

Name      : FileName.zip
BaseName  : FileName.zip
Extension :

PS C:\Temp> $fromGetChildItem | Select-Object -Property Name,BaseName,Extension | Format-List

Name      : FileName.zip
BaseName  : FileName.zip
Extension : .zip

PS C:\Temp> $fromGetItem.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    DirectoryInfo                            System.IO.FileSystemInfo

PS C:\Temp> $fromGetChildItem.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    DirectoryInfo                            System.IO.FileSystemInfo

Expected behavior
I'd expect objects retrieved from either Get-Item or Get-ChildItem cmdlets to have consistent Name, BaseName, and Extension properties.

Actual behavior
When a DirectoryInfo is retrieved from Get-Item, the BaseName property includes the period and text after while the Extension property is an empty string.  When a DirectoryInfo is retrieved from Get-ChildItem, both the BaseName and Extension properties both include the period and the text after.

Error details
No response
Environment data
PS C:\Temp> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.4
PSEdition                      Core
GitCommitId                    7.2.4
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

The bug that surfaces with Get-Item is actually a .NET bug when a [System.IO.DirectoryInfo] instances is constructed with a path having a trailing \ or /:

https://github.com/dotnet/runtime/issues/101730

Conceptually related:

#21553


fix(table): fix header row height to follow material guidelines

Change the header row height from 48px to 56dx, as per
https://material.io/guidelines/components/data-tables.html#data-tables-specs
In response to issue #8206

It looks like https://github.com/angular/material2/pull/8215 already accomplishes this

Oh darn, I completely missed that :/ Thanks!


the footer look different

Description
page job portal
currently-

but actually have to like this:

Screenshots
No response
Additional information
No response
Do you want to work on this issue?

[X] I want to work on this issue.

@AnirudhPanda

okay fix this in all the pages


underscored vs. model timestamps

Versions

sequelize: 5.12.3
sequelize-typescript: 0.6.11
typescript: 3.5.3

I'm submitting a ...

[X ] bug report
[ ] feature request
Actual behavior:

The typing for Model has camel case for the timestamps in Model.d.ts which makes a reference to the timestamp fields named using underscores an error.
Expected behavior:

If underscores is set on the sequelize instance, then timestamps should also be referenceable via underscore names.
Steps to reproduce:

Create a sequelize instance using underscores:true
Create a model using timestamps:true
Try to write code referring to created_at

Hey @cwhatley, thanks for reporting. First thing I've noticed: You are using<EMAIL_ADDRESS>together with<EMAIL_ADDRESS>which is not supported. For sequelize@>=5 sequelize-typescript@next is needed. Can you try it this way?

I did try updating and still have to refer to the dates via "createdAt", for example.

Hey @cwhatley, didn't get your issue in the first place, sry for that. The underscored option doesn't make access to underscored properties possible but just converts the field values to from camelCase to underscored. See official docs: https://sequelize.org/master/manual/models-definition.html#configuration
Closing this, since it is expected behaviour


fix comments from PR #894

There were some comments / suggestions not blocking merge in PR #894 ; fix these issues .

Closing this because we are moving to Ginkgo. Even then, the tests have changed considerably since I filed this.


added header-maintenance script, and headers to all sources

Adds headers to all .cs sources; and a script to keep them up to date (only checks 1st line, though)

Thanx for this pr, I'll fix the https://github.com/e-ucm/rage-analytics-realtime


Only run codegen at start of flutter_test

Description
Only run codegen once at the start of flutter test. allow initializing the codegen compiler to skip subsequent code generation and only configure to accept codegen. Add test to bots.dart that executes a test which requires code generation.
Related Issues
https://github.com/flutter/flutter/issues/27141
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes tests for all changed/updated/fixed behaviors (See Test Coverage).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes).
[x] No, this is not a breaking change.


[Bug] ray autoscaler keeping create and terminate worker nodes until the whole k8s cluster's resource has been occupied

Search before asking

[X] I searched the issues and found no similar issues.

KubeRay Component
ray-operator
What happened + What you expected to happen
I enable the autoscaler in our kuberay, but it ends up keeping create and terminate worker nodes (especially the large cpu worker 6cpu 32Gb)until the whole k8s cluster's resource has been occupied.

Reproduction script
---
# Source: ray-cluster/templates/raycluster-service.yaml
apiVersion: v1
kind: Service
metadata:
  # labels:
  #   app.kubernetes.io/name: kuberay-metrics
  #   ray.io/cluster: ray-cluster-kuberay
  name: ray-cluster-kuberay-metrics-svc
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/path: /metrics
    prometheus.io/port: "8080"
spec:
  ports:
  - name: metrics
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app.kubernetes.io/name: kuberay
    ray.io/cluster: ray-cluster-kuberay
  type: ClusterIP
---
# Source: ray-cluster/templates/raycluster-cluster.yaml
apiVersion: ray.io/v1alpha1
kind: RayCluster
metadata:
  labels:
    app.kubernetes.io/name: kuberay
    helm.sh/chart: ray-cluster-0.3.0
    app.kubernetes.io/instance: ray-cluster
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Helm
  name: ray-cluster-kuberay
spec:
  enableInTreeAutoscaling: true
  autoscalerOptions:
    # upscalingMode is "Default" or "Aggressive."
    # Conservative: Upscaling is rate-limited; the number of pending worker pods is at most the size of the Ray cluster.
    # Default: Upscaling is not rate-limited.
    # Aggressive: An alias for Default; upscaling is not rate-limited.
    upscalingMode: Default
    # idleTimeoutSeconds is the number of seconds to wait before scaling down a worker pod which is not using Ray resources.
    idleTimeoutSeconds: 60
    # image optionally overrides the autoscaler's container image.
    # If instance.spec.rayVersion is at least "2.0.0", the autoscaler will default to the same image as
    # the ray container. For older Ray versions, the autoscaler will default to using the Ray 2.0.0 image.
    ## image: "my-repo/my-custom-autoscaler-image:tag"
    # imagePullPolicy optionally overrides the autoscaler container's image pull policy.
    imagePullPolicy: Always
    # resources specifies optional resource request and limit overrides for the autoscaler container.
    # For large Ray clusters, we recommend monitoring container resource usage to determine if overriding the defaults is required.
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "500m"
        memory: "512Mi"

  headGroupSpec:
    serviceType: ClusterIP
    rayStartParams:
      block: "true"
      dashboard-host: "<IP_ADDRESS>"
      node-ip-address: "$MY_POD_IP"
      num-cpus: "1"
      port: "6379"
      redis-password: "LetMeInRay"
    replicas: 1
    template:
      spec:
        imagePullSecrets:
          - name: harbor-bybit
          - name: harbor-infra
        containers:
          - volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-head
            image: harbor.infra.ww5sawfyut0k.bitsvc.io/bigdata/ray:prod-2.0.1-py38-ai2.0
            imagePullPolicy: Always
            resources:
              limits:
                cpu: 4
                memory: 8Gi
              requests:
                cpu: 2
                memory: 2Gi
            env:
              - name: TYPE
                value: head
              - name: MY_POD_IP
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: MLFLOW_TRACKING_URI
                value: http://mlflow.niubit.io
              - name: PLATFORM_ENV
                value: prod
              - name: HDFS_CLUSTER_NAME
                value: victoria
              - name: RAY_OVERRIDE_RESOURCES
                value: '{"CPU":0, "GPU":0}'
        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}
        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          {}
        labels:
          groupName: headgroup
          rayNodeType: head
          rayCluster: ray-cluster-kuberay
          app.kubernetes.io/name: kuberay
          helm.sh/chart: ray-cluster-0.3.0
          app.kubernetes.io/instance: ray-cluster
          app.kubernetes.io/version: "1.0"
          app.kubernetes.io/managed-by: Helm

  workerGroupSpecs:
  - rayStartParams:
      block: "true"
      node-ip-address: "$MY_POD_IP"
      redis-password: "LetMeInRay"
    replicas: 0
    minReplicas: 0
    maxReplicas: 4
    groupName: cpu-only-large-group
    template:
      spec:
        imagePullSecrets:
          - name: harbor-bybit
          - name: harbor-infra
        initContainers:
          - name: init-myservice
            image: busybox:1.28
            command: ['sh', '-c', "until nslookup $RAY_IP.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        containers:
          - volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: harbor.infra.ww5sawfyut0k.bitsvc.io/bigdata/ray:prod-2.0.1-py38-ai2.0
            imagePullPolicy: Always
            resources:
              limits:
                cpu: 6
                memory: 32Gi
              requests:
                cpu: 1
                memory: 1Gi
            env:
              - name: TYPE
                value: worker
              - name: MY_POD_IP
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: RAY_DISABLE_DOCKER_CPU_WARNING
                value: "1"
              - name: CPU_REQUEST
                valueFrom:
                  resourceFieldRef:
                    containerName: ray-worker
                    resource: requests.cpu
              - name: MY_POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: MLFLOW_TRACKING_URI
                value: http://mlflow.test.niubit.io
              - name: PLATFORM_ENV
                value: test
              - name: HDFS_CLUSTER_NAME
                value: testcluster
            ports:
              - containerPort: 80
                protocol: TCP
        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}
        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          key: value
        labels:
          rayNodeType: worker
          groupName: cpu-only-large-group
          rayCluster: ray-cluster-kuberay
          app.kubernetes.io/name: kuberay
          helm.sh/chart: ray-cluster-0.3.0
          app.kubernetes.io/instance: ray-cluster
          app.kubernetes.io/version: "1.0"
          app.kubernetes.io/managed-by: Helm
  - rayStartParams:
      block: "true"
      node-ip-address: "$MY_POD_IP"
      redis-password: "LetMeInRay"
    replicas: 0
    minReplicas: 0
    maxReplicas: 6
    groupName: cpu-only-medium-group
    template:
      spec:
        imagePullSecrets:
          - name: harbor-bybit
          - name: harbor-infra
        initContainers:
          - name: init-myservice
            image: busybox:1.28
            command: ['sh', '-c', "until nslookup $RAY_IP.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        containers:
          - volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: harbor.infra.ww5sawfyut0k.bitsvc.io/bigdata/ray:prod-2.0.1-py38-ai2.0
            imagePullPolicy: Always
            resources:
              limits:
                cpu: 4
                memory: 16Gi
              requests:
                cpu: 1
                memory: 1Gi
            env:
              - name: TYPE
                value: worker
              - name: MY_POD_IP
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: RAY_DISABLE_DOCKER_CPU_WARNING
                value: "1"
              - name: CPU_REQUEST
                valueFrom:
                  resourceFieldRef:
                    containerName: ray-worker
                    resource: requests.cpu
              - name: MY_POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: MLFLOW_TRACKING_URI
                value: http://mlflow.test.niubit.io
              - name: PLATFORM_ENV
                value: test
              - name: HDFS_CLUSTER_NAME
                value: testcluster
            ports:
              - containerPort: 80
                protocol: TCP
        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}
        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          key: value
        labels:
          rayNodeType: worker
          groupName: cpu-only-medium-group
          rayCluster: ray-cluster-kuberay
          app.kubernetes.io/name: kuberay
          helm.sh/chart: ray-cluster-0.3.0
          app.kubernetes.io/instance: ray-cluster
          app.kubernetes.io/version: "1.0"
          app.kubernetes.io/managed-by: Helm
  - rayStartParams:
      block: "true"
      node-ip-address: "$MY_POD_IP"
      redis-password: "LetMeInRay"
    replicas: 1
    minReplicas: 1
    maxReplicas: 10
    groupName: cpu-only-small-group
    template:
      spec:
        imagePullSecrets:
          - name: harbor-bybit
          - name: harbor-infra
        initContainers:
          - name: init-myservice
            image: busybox:1.28
            command: ['sh', '-c', "until nslookup $RAY_IP.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        containers:
          - volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: harbor.infra.ww5sawfyut0k.bitsvc.io/bigdata/ray:prod-2.0.1-py38-ai2.0
            imagePullPolicy: Always
            resources:
              limits:
                cpu: 4
                memory: 8Gi
              requests:
                cpu: 1
                memory: 1Gi
            env:
              - name: TYPE
                value: worker
              - name: MY_POD_IP
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: RAY_DISABLE_DOCKER_CPU_WARNING
                value: "1"
              - name: CPU_REQUEST
                valueFrom:
                  resourceFieldRef:
                    containerName: ray-worker
                    resource: requests.cpu
              - name: MY_POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: MLFLOW_TRACKING_URI
                value: http://mlflow.test.niubit.io
              - name: PLATFORM_ENV
                value: test
              - name: HDFS_CLUSTER_NAME
                value: testcluster
            ports:
              - containerPort: 80
                protocol: TCP
        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          {}
        tolerations:
          []
        nodeSelector:
          {}
      metadata:
        annotations:
          key: value
        labels:
          rayNodeType: worker
          groupName: cpu-only-small-group
          rayCluster: ray-cluster-kuberay
          app.kubernetes.io/name: kuberay
          helm.sh/chart: ray-cluster-0.3.0
          app.kubernetes.io/instance: ray-cluster
          app.kubernetes.io/version: "1.0"
          app.kubernetes.io/managed-by: Helm
  - rayStartParams:
      block: "true"
      node-ip-address: "$MY_POD_IP"
      redis-password: "LetMeInRay"
    replicas: 2
    minReplicas: 2
    maxReplicas: 2
    groupName: workergroup
    template:
      spec:
        imagePullSecrets:
          - name: harbor-bybit
          - name: harbor-infra
        initContainers:
          - name: init-myservice
            image: busybox:1.28
            command: ['sh', '-c', "until nslookup $RAY_IP.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        containers:
          - volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: harbor.infra.ww5sawfyut0k.bitsvc.io/bigdata/ray:prod-2.0.1-py38-ai2.0
            imagePullPolicy: Always
            resources:
              limits:
                cpu: 8
                memory: 30Gi
                nvidia.com/gpu: 1
              requests:
                cpu: 7
                memory: 30Gi
                nvidia.com/gpu: 1
            env:
              - name: TYPE
                value: worker
              - name: MY_POD_IP
                valueFrom:
                  fieldRef:
                    fieldPath: status.podIP
              - name: RAY_DISABLE_DOCKER_CPU_WARNING
                value: "1"
              - name: CPU_REQUEST
                valueFrom:
                  resourceFieldRef:
                    containerName: ray-worker
                    resource: requests.cpu
              - name: MY_POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
              - name: MLFLOW_TRACKING_URI
                value: http://mlflow.niubit.io
              - name: PLATFORM_ENV
                value: prod
              - name: HDFS_CLUSTER_NAME
                value: victoria
            ports:
              - containerPort: 80
                protocol: TCP
        volumes:
          - emptyDir: {}
            name: log-volume
        affinity:
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - preference:
                matchExpressions:
                - key: instancetype
                  operator: In
                  values:
                  - g4dn.2xlarge
              weight: 1
        tolerations:
          - effect: NoSchedule
            key: instancetype
            operator: Equal
            value: g4dn.2xlarge
        nodeSelector:
          {}
      metadata:
        annotations:
          key: value
        labels:
          rayNodeType: worker
          groupName: workergroup
          rayCluster: ray-cluster-kuberay
          app.kubernetes.io/name: kuberay
          helm.sh/chart: ray-cluster-0.3.0
          app.kubernetes.io/instance: ray-cluster
          app.kubernetes.io/version: "1.0"
          app.kubernetes.io/managed-by: Helm

Anything else
I guess this issue may related with my autocale and worker's request and limit config.
Is it set too small so that the autoscale will request lots of worker nodes? if so what is the meaning for the requests and what is the best practices for this.
thanks a lot
autoscale
enableInTreeAutoscaling: true
  autoscalerOptions:
    upscalingMode: Default
   resources.
    idleTimeoutSeconds: 60
    imagePullPolicy: Always
 required.
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "500m"
        memory: "512Mi"

cpu-only-large-group
groupName: cpu-only-large-group
    template:
      spec:
        imagePullSecrets:
          - name: harbor-bybit
          - name: harbor-infra
        initContainers:
          - name: init-myservice
            image: busybox:1.28
            command: ['sh', '-c', "until nslookup $RAY_IP.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        containers:
          - volumeMounts:
            - mountPath: /tmp/ray
              name: log-volume
            name: ray-worker
            image: harbor.infra.ww5sawfyut0k.bitsvc.io/bigdata/ray:prod-2.0.1-py38-ai2.0
            imagePullPolicy: Always
            resources:
              limits:
                cpu: 6
                memory: 32Gi
              requests:
                cpu: 1
                memory: 1Gi

Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Thank you for opening this issue! It looks like you want to upload a figure in the "What happened + What you expected to happen" section, but the upload fails. Would you mind uploading the image again?
What's the reason for workers being terminated? You can use kubectl describe to check the Pods, and use kubectl logs to check the logs for Ray cluster's Pods and the operator Pod.

What version of Ray and KubeRay are you using?

We are experiencing the same issue.
To reproduce:

Start a new Ray Cluster.
Trigger autoscaling by deploying Ray Jobs.

Expected behavior:

The execution of the current Ray Jobs continues.

Observed behavior:

A new Ray Node (a pod) is started.
The old Ray Node gets terminated and the execution of the current Ray Jobs get terminated.
The execution of the new Ray Node continues.

The version of the KubeRay operator's chart is 0.5.1.
❯ ray --version
ray, version 2.4.0

Ray client version.

apiVersion: ray.io/v1alpha1
kind: RayCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: hpc-ray-cluster
spec:
  rayVersion: "2.4.0"
  # If enableInTreeAutoscaling is true, the autoscaler sidecar will be added to the Ray head pod.
  enableInTreeAutoscaling: true
  autoscalerOptions:
    # upscalingMode is "Default" or "Aggressive."
    # Conservative: Upscaling is rate-limited; the number of pending worker pods is at most the size of the Ray cluster.
    # Default: Upscaling is not rate-limited.
    # Aggressive: An alias for Default; upscaling is not rate-limited.
    upscalingMode: Conservative
    # idleTimeoutSeconds is the number of seconds to wait before scaling down a worker pod which is not using Ray resources.
    idleTimeoutSeconds: 60
    env: []
    envFrom: []
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "0.1"
        memory: "100Mi"
  # Ray head pod template.
  headGroupSpec:
    # The `rayStartParams` are used to configure the `ray start` command.
    # See https://github.com/ray-project/kuberay/blob/master/docs/guidance/rayStartParams.md for the default settings of `rayStartParams` in KubeRay.
    # See https://docs.ray.io/en/latest/cluster/cli.html#ray-start for all available options in `rayStartParams`.
    rayStartParams:
      dashboard-host: "<IP_ADDRESS>"
      num-cpus: "0"
      num-gpus: "0"
      memory: "0"
      # Use `resources` to optionally specify custom resource annotations for the Ray node.
      # The value of `resources` is a string-integer mapping.
      # Currently, `resources` must be provided in the specific format demonstrated below:
      # resources: '"{\"Custom1\": 1, \"Custom2\": 5}"'
    template:
      spec:
        containers:
        # The Ray head container
        - name: ray-head
          image: rayproject/ray:2.4.0-py310-cpu
          ports:
          - containerPort: 6379
            name: gcs
          - containerPort: 8265
            name: dashboard
          - containerPort: 10001
            name: client
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh","-c","ray stop"]
          resources:
            limits:
              cpu: "1"
              memory: "2G"
            requests:
              # For production use-cases, we recommend specifying integer CPU reqests and limits.
              # We also recommend setting requests equal to limits for both CPU and memory.
              # For this example, we use a 500m CPU request to accomodate resource-constrained local
              # Kubernetes testing environments such as KinD and minikube.
              cpu: "0.3"
              # The rest state memory usage of the Ray head node is around 1Gb. We do not
              # recommend allocating less than 2Gb memory for the Ray head pod.
              # For production use-cases, we recommend allocating at least 8Gb memory for each Ray container.
              memory: "2G"
  workerGroupSpecs:
  # the pod replicas in this group typed worker
  - replicas: 1
    minReplicas: 1
    maxReplicas: 10
    groupName: standard-group
    #scaleStrategy:
    #  workersToDelete:
    #  - raycluster-complete-worker-small-group-bdtwh
    #  - raycluster-complete-worker-small-group-hv457
    #  - raycluster-complete-worker-small-group-k8tj7
    # The `rayStartParams` are used to configure the `ray start` command.
    # See https://github.com/ray-project/kuberay/blob/master/docs/guidance/rayStartParams.md for the default settings of `rayStartParams` in KubeRay.
    # See https://docs.ray.io/en/latest/cluster/cli.html#ray-start for all available options in `rayStartParams`.
    rayStartParams:
      resources: '"{\"standard-unit\": 2}"'
    template:
      spec:
        containers:
        - name: ray-worker
          image: rayproject/ray:2.4.0-py310-cpu
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh","-c","ray stop"]
          # The limits will be automatically advertised to Ray. On the other hand the **requests will be ignored**.
          # It’s ideal to size each Ray pod to take up the **entire Kubernetes node** on which it is scheduled.
          resources:
            limits:
              # nvidia.com/gpu: "1"
              cpu: "1"
              memory: "1G"
            requests:
              # nvidia.com/gpu: "1"
              cpu: "0.1"
              memory: "100Mi"

Cluster resource.

import ray
import time

@ray.remote
def hello_world():
    return "hello world"

ray.init()
while True:
    print(ray.get(hello_world.remote()))
    time.sleep(1)

Ray Job used in the test.

Uploading 01-ray-autoscaling-issue.mp4…

In the case described above, Ray Dashboard displays incorrect information:

See the video.

The status of the terminated Ray Jobs is RUNNING even though Ray Node is correctly displayed as terminated. So are all JobSupervisor actors.
On the logs page for the jobs, URL points out to a new Ray Node, these jobs were never run on.

The same issue can be reproduced with Ray Workflows. The KubeRay keep creating and deleting new Ray Nodes, tasks get killed and started anew.
To reproduce:

Start a new Ray Cluster with idleTimeoutSeconds: 60.
Trigger autoscaling by deploying Ray Workflows that execute a 2min-job.

Expected behavior:

The execution of the current Ray Workflows continues.

Observed behavior:

See the video.

A new Ray Node (a pod) is started.
The old Ray Node gets terminated and the execution of the current Ray Workflows get terminated.
The execution of the new Ray Node continues and Ray Workflows started again.
The recursion continues.

from ray import workflow
import ray
import time

@ray.remote(resources={"standard-unit": 1, "num_cpus": 0})
def one() -> int:
    print("++++++++++ started")
    time.sleep(120)
    print("++++++++++ stopped")
    return 1

@ray.remote(resources={"standard-unit": 0, "num_cpus": 0})
def add(a: int, b: int) -> int:
    return a + b

ray.init("ray://<IP_ADDRESS>:10001")
dag = add.bind(100, one.bind())

workflow.run_async(dag, workflow_id="701")
workflow.run_async(dag, workflow_id="702")

Ray Workflow used in the test.

I've found the source of the issues above in my environment. It wasn't RayAutoscaler.
It was Flux CD that kept killing RayNods on every reconciliation, with the interval set to 1 minute.

Summarize my guess based on the available limitation information.

The value of idleTimeoutSeconds is set to 60 seconds. This means that an idle worker Pod will be scaled down after being inactive for 60 seconds. Worker nodes are considered idle when they have no active tasks, actors, or referenced objects (whether in-memory or spilled to disk). However, based on the screenshot, it appears that the worker Pods are being terminated even when they are younger than 60 seconds. Therefore, I speculate that the Pod terminations are not being caused by Ray Autoscaler. In my assumption, the terminations are occurring due to the cluster resources being depleted.

There is a significant difference between the resource limits and resource requests. In addition, KubeRay will set the memory parameter in rayStartParams to the value of the memory limit. In other words, Ray assumes that the Ray node has 32GB of memory, making it easy for the worker Pod to consume more than 1GB of memory (as specified in the resource request).
 resources:
    limits:
      cpu: 6
      memory: 32Gi
    requests:
      cpu: 1
      memory: 1Gi

Based on the screenshot, I noticed that some Pods are in a pending state for a few seconds. This leads me to believe that it is highly likely for the Kubernetes cluster is running out of resources. In Kubernetes, when a cluster is running out of resources, it will prioritize terminating Pods that exceed their resource requests but are still within their resource limits. In addition, the resource requests for worker Pods are extremely low, leading me to believe that nearly all worker Pods will consume resources beyond their specified resource requests.

If you have any further questions, please feel free to leave comments on this issue or reach out to us on Slack.


Merge doc into master (add some doc strings)

Add documentation to the Scan and Reporting classes, and lr_normalizer function.
Additionally, cleanup a bit, make sure no lines go over 80 characters, etc.

Didn't realize there was a dev branch. My bad. Should I close this and fix it, or is it ok since its really just some cleanup and addition of doc strings?
Also I'm curious, does Travis CI run automatically on every PR? Still new to this!

Pull Request Test Coverage Report for Build 92

19 of 20 (95.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.06%) to 88.812%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

talos/scan.py
6
7
85.71%

Totals

Change from base Build 90:
-0.06%

Covered Lines:
643

Relevant Lines:
724

💛  - Coveralls

Looks great! :) Thanks a lot.
Yes Travis CI runs for every PR. I will try to create CONTRIBUTE.md with minimal infos about the CI and deploy procedures so its clear. Basically the process would be personal branch > dev > master  (or better yet dev < master frequently) and then once it's used a while on master > production. Production deploys automatically to pypi as well.

Exactly what I was thinking. Also lets each user resolve merge conflicts locally before opening a PR. Makes sense regarding keeping a good workflow. Speaking of which, I'll comment on the CONTRIBUTE.md issue in a second about this.


Simpler two-click Create Pad dialog

Simplifies the Create Pad dialog by only requiring two steps:

Click New
Click Dart or Flutter (or optionally enable HTML and then Dart)

Today this is:

Click New
Click Dart or Flutter
Click Create


Add support for soft assertions

From<EMAIL_ADDRESS>on March 26, 2015 12:31:48
See http://joel-costigliola.github.io/assertj/assertj-core-news.html#assertj-core-2.0.0-bdd-soft-assertions For example:
@Rule
public final RestAssuredSoftAssertions rule = new RestAssuredSoftAssertions();
then().soft().
body()..
body()..
Original issue: http://code.google.com/p/rest-assured/issues/detail?id=395

This will not work since then REST Assured would be coupled to JUnit


CS:GO community server list

Hello,
How to get my CS:GO server to be on the public server list ?
Thanks

http://api.steampowered.com/ISteamApps/GetServersAtAddress/v0001?addr=<SERVER IP HERE>&format=json
If your server info shows up with that API request then it's being shown on the public server list.

Thanks !

BTW, do you know how can install a custom gamemode like 1vs1 arena ?

For that, use google or ask there : https://steamcommunity.com/groups/linuxgsm/discussions

Ok \o/


Add filters

Partially needs to be ported from xDEM: https://github.com/GlacioHack/xdem/blob/main/xdem/filters.py. Also some from: https://github.com/adehecq/kh9_glacier_global/blob/main/kh9_glacier_global/filtering.py
Could close this: https://github.com/GlacioHack/xdem/issues/69
Use generic filter logic of pyddem? https://github.com/iamdonovan/pyddem/blob/main/pyddem/fit_tools.py#L1649
Check inspiration from filters of pygeotools (brought up in #51): https://github.com/dshean/pygeotools/blob/master/pygeotools/lib/filtlib.py

See: https://github.com/GlacioHack/xdem/issues/300


refactor: Test refactor

Checklist:

[x] Tests for the changes have been added (for bug fixes / features / refactoring)

Codecov Report

Merging #186 (69c278e) into main (5500257) will increase coverage by 7.03%.
The diff coverage is 86.11%.

@@            Coverage Diff             @@
##             main     #186      +/-   ##
==========================================
+ Coverage   51.79%   58.82%   +7.03%
==========================================
  Files           8       10       +2
  Lines         251      340      +89
==========================================
+ Hits          130      200      +70
- Misses        117      132      +15
- Partials        4        8       +4

Impacted Files
Coverage Δ

internal/faker/uuid.go
100.00% <ø> (ø)

internal/server/server.go
0.00% <0.00%> (ø)

internal/server/handler.go
26.16% <16.66%> (-12.07%)
:arrow_down:

internal/faker/internet.go
85.71% <85.71%> (ø)

internal/faker/faker.go
95.60% <95.12%> (-0.63%)
:arrow_down:

internal/faker/person.go
95.65% <95.12%> (-4.35%)
:arrow_down:

internal/faker/boolean.go
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


fix(richtext-lexical): allow exiting the RTE with the keyboard in Firefox

Closes #8653.
Originally this PR was for making the IndentFeature opt-in instead of opt-out, which would have been a breaking change. After some discussion it was determined it would be better if we could keep the IndentFeature by default and instead come up with a custom escape key solution to prevent keyboard users from becoming trapped in the editor.
These changes are my interpretation of how we can solve this problem in a way that feels natural for a keyboard user. When a keyboard user becomes trapped, the usual approach is to press the escape key (e.g. modals) to be able to leave the current context and continue navigating. These changes allow that to happen while minimising the cognitive load by not needing to remember whether the IndentFeature is toggled on or off.
I've also ensured the IndentFeature can actually be turned off if consciously removed from the lexical editor features (previously it was still enabled even if it was removed).
Ideally this should be handled on the lexical side in the TabIndentationPlugin itself (I will begin to look into the feasibility of this), but for now this should be suitable to ensure the experience for keyboard users isn't completely blocked (there are a number of other improvements that could be made but I will create more specific issues for those).
Open to discussion and amendments. Once we're aligned on the approach I'm happy to implement tests as needed.
Before
https://github.com/user-attachments/assets/95183bb6-f36e-4b44-8c3b-d880c822d315
After
https://github.com/user-attachments/assets/d34be50a-8f31-4b81-83d1-236d5ce9d8b5

Moving this to draft for now as I will be exploring ways to improve keyboard accessibility without needing to disable indent feature by default.

This has been determined to be a Firefox specific issue. These changes bring the functionality in parity with other browsers such as Chrome and Edge.

Sorry for the delay, I thought it was still a WIP. I'll check the rest of the comments as soon as I can.

I found the reason. I was testing on the lexical-localized-fields collection. In lexical-fields which is the one you are testing it works fine, but it seems to have problems when after the focused paragraph there is a decoratorNode or block (upload, relation, etc). Could you take a look and see why?

There are three buttons rendered off-screen that are still focusable in the rich text editor (.add-block-menu, .link-edit and .link-trash). This means you need to tab 4 times before you get to the next field.
Since this issue is present in all browsers I have not addressed it here. Happy to do so in a separate PR.

you need to tab 4 times before you get to the next field.

That's not my experience. This is what I mean:
https://github.com/user-attachments/assets/5e786375-fad2-40bb-9f27-a5e0f2cc1191

Marked as draft for the moment.
As it may not be obvious from the video, I can't exit the editor forward using tab.
Please let me know if you have any problems reproducing my experience.

@GermanJablo good catch, I am also able to reproduce it.
The issue you've found can also be replicated without this PR on Chromium based browsers such as Chrome.
Since this PR is specific to getting Firefox in parity with Chrome, I think that issue should be tackled in a separate PR.
There are a number of improvements that still need to be made to keyboard access for lexical, I'd be happy to try and tackle them in a more broader PR soon.


[cherry-pick] more notary documentation

Signed-off-by: Viktor Stanchev<EMAIL_ADDRESS>(cherry picked from commit e869e8aa3d0671394f83d0b6ea7d90cb310e5b61)
Docker-DCO-1.1-Signed-off-by: Viktor Stanchev<EMAIL_ADDRESS>(github: )

This maybe should be part of a bigger docs cherry-pick,  - leaving to remind @moxiegirl :)

did this on another pr.


ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'requirements.txt'

don't know what to do
please help

Check if the pip command is executed in the correct directory

The pip command is being executed in the correct directory (I'm pretty sure anyway) and I'm still encountering this issue.)

Use absolute path of requirements.txt in the pip command. For example, pip install -r /home/username/Projects/DDSP-SVC/requirements.txt.


Fix resize events on BearLibTerminal

The recent changes to input broke terminal resize detection in the BLT backend. More specifically, after a resize event, the input currently hangs.
We need a better system for this resize detection.

This should now be fixed, all resize-specific handling is now internal to the backend code.


Button from other component link to my TabPane's

Issue description

components: a, TabPane
reactstrap version ^6.5.0
react version ^16.5.2
bootstrap version ^4.1.3

What is happening?
Basically i want to click on a tag a (in the picture it's the button) as the screenshot does

to one of my Tabpanes, inside my dropdowns:

And it's not working with the link. On the code I have this:
Services.js

...
<TabPane tabId="PLP">
     <PLP />
</TabPane>
<TabPane tabId="LA_1">
     <QuickLA />
</TabPane>
<TabPane tabId="LA_2">
     <AdvancedLA />
</TabPane>
<TabPane tabId="LA_3">
	<PremiumLA />
</TabPane>
<TabPane tabId="EMG_1">
	<EMG_1 />
</TabPane>
...

And i am currently added on my button (using data from an array) and it's correct, I can see on the button:

What should be happening?
The idea it's to use my slider, with Links inside of each textDescription of each slider image, and link to my tabPane containers to show it
So guys i need some help! It will be much appreciated
Many thanks
Pedro Cruz

You have to set the activeTab prop on TabContent to the value of the TabPane's tabId you want to be active. If you want to do that with an anchor tag, the anchor tag should have an onClick prop which is a function that sets that value within your state.


eiskaltdcpp: 2.4.1 -> 2.4.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/eiskaltdcpp/eiskaltdcpp/releases.
meta.description for eiskaltdcpp is: "A cross-platform program that uses the Direct Connect and ADC protocols"
meta.homepage for eiskaltdcpp is: "https://github.com/eiskaltdcpp/eiskaltdcpp"
meta.changelog for eiskaltdcpp is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.4.2 with grep in /nix/store/kn3gb4h56yfniijh6c80l6j2hlmh43nn-eiskaltdcpp-2.4.2

directory tree listing: https://gist.github.com/cd22ed7902d37c1e5aa016e85fb61e32

du listing: https://gist.github.com/b35f21235742e75765fe3350a29090bc

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
eiskaltdcpp

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/kn3gb4h56yfniijh6c80l6j2hlmh43nn-eiskaltdcpp-2.4.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A eiskaltdcpp https://github.com/r-ryantm/nixpkgs/archive/81229274503788c49668e5e51fcd7b8df7d7620d.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/kn3gb4h56yfniijh6c80l6j2hlmh43nn-eiskaltdcpp-2.4.2
ls -la /nix/store/kn3gb4h56yfniijh6c80l6j2hlmh43nn-eiskaltdcpp-2.4.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

eiskaltdcpp

Maintainer pings

Result of nixpkgs-review pr 115091 at 81229274 run on aarch64-linux 1

1 package built:

eiskaltdcpp

1 suggestion:

warning: maintainers-missing
Package does not have a maintainer. Consider adding yourself?
Near pkgs/applications/networking/p2p/eiskaltdcpp/default.nix:44:3:
   |
44 |   meta = with lib; {
   |   ^


Removing the old password mask

@duskpoet Please verify this change I guess if the old mask is removed, the password will be exposed in endpoints I think. Because there is no other mask.

I've verified this in the test app.
@saurabh-git-dev, why do you think it will be exposed? My understanding is that the mask will be applied to whole logs

the highlighted command dumps all API data. and it also contains the passwords in URIs.
So if you mask the password later I think this will be printed as normal text.
As cat branch_out command, dumps all data.
This will be I think only for newly created branches.
I am not 100% sure if masking order is important or not.
So If you think everything is fine. Then I don't think any other issue.

Please Check my 2 latest workflow runs with customized scripts.
Latest Run - old mask removed (https://github.com/saurabh-git-dev/neon-test/actions/runs/9193850475/job/25285878634)
Second Latest Run - old mask present (https://github.com/saurabh-git-dev/neon-test/actions/runs/9193813587/job/25285754562)

I guess reorganization of code is required or can keep masks in both places.

Yea, I will it as it is for now


[C] Add layout for Map type

Oops, this is what I get for not trying it locally. I'll fix that!

Ah, we need a local build of Arrow to use testing…I wonder if we could avoid ArrayFromJSON somehow and then we could build against the Arrow conda package or something like that

Fixed.
(Incidentally, it looks like we have a .clang-format, but no .pre-commit-config or CI pipeline?)

Codecov Report

Merging #41 (0bd59d5) into main (4a42e11) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #41   +/-   ##
=======================================
  Coverage   92.00%   92.00%
=======================================
  Files           6        6
  Lines        1301     1301
  Branches       47       47
=======================================
  Hits         1197     1197
  Misses         72       72
  Partials       32       32

Impacted Files
Coverage Δ

src/nanoarrow/utils.c
99.03% <ø> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Filed #42 for whenever somebody can get to it (though it isn't really a big deal)


Avoid potential NPEs on corrupted ISO9660 images.

OBE (our iso9660 fs impl was removed and replaced with 7zip)


Added ability to make shorter when calls

@casecode, @JBBryan, @glyyynn, @mona87, @tomhanlon - What do y'all think? This mod allows you to call When with a jQuery method to run on the selected element when it's found. For example:
when($('.this-div'), ['css', ['display', 'none']]);
Which will run
$('.this-div').css('display', 'none');
When '.this-div' is found.
We could use an object instead of an array, though I'm not sure why we would if the goal is to simplify short When calls.

Love the when PR! For some reason I still get those emails. What about detecting if second arg is a string and then using optional additional args after that. Aka
when('.foo', 'css', 'display', 'none')
-Tom (mobile) |<PHONE_NUMBER>
https://www.linkedin.com/in/tomfuertes

On Feb 1, 2016, at 12:29 PM, beaulm<EMAIL_ADDRESS>wrote:
@casecode, @JBBryan, @glyyynn, @mona87, @tomhanlon - What do y'all think? This mod allows you to call When with a jQuery method to run on the selected element when it's found. For example:
when($('.this-div'), ['css', ['display', 'none']]);
Which will run
$('.this-div').css('display', 'none');
When '.this-div' is found.
We could use an object instead of an array, though I'm not sure why we would if the goal is to simplify short When calls.
You can view, comment on, or merge this pull request online at:
https://github.com/clearhead/clearhead/pull/41
Commit Summary
Added ability to make shorter when calls
File Changes
M README.md (12)
M src/when.js (28)
Patch Links:
https://github.com/clearhead/clearhead/pull/41.patch
https://github.com/clearhead/clearhead/pull/41.diff
—
Reply to this email directly or view it on GitHub.

Love the when PR! What about detecting if second arg is a string and then using optional additional args after that. Aka
when('#foo', 'css', 'display', 'none'); // => $('#foo').css('display','none');

The only problem I see with that @tomfuertes is the other optional parameters.
Speaking of which: @JBBryan ~ What's the difference between optTimeout and optQuitPolling in the call?

In that case, we could/should consider passing the args as an object as Austin's very own Rebecca Murphy suggests: http://rmurphey.com/blog/2011/04/25/objects-as-arguments

You can still grab the arguments optionally splicing arguments
function when(arg1,arg2 /*optAdditionalArgs*/) {
  if (typeof arg === 'string'){
    var optionalArgs = [].splice(arguments, 2);
    // if ($(arg1).length) {
      $.fn.[arg2].apply($(arg1), optionalArgs);
    // }
  }
}

On Mon, Feb 1, 2016 at 1:35 PM, Tom Hanlon<EMAIL_ADDRESS>wrote:

In that case, we could/should consider passing the args as an object as
Austin's very own Rebecca Murphy suggests:
http://rmurphey.com/blog/2011/04/25/objects-as-arguments
—
Reply to this email directly or view it on GitHub
https://github.com/clearhead/clearhead/pull/41#issuecomment-178144789.

--
Tom Fuertes |<PHONE_NUMBER>
http://www.linkedin.com/in/tomfuertes

That would work well with another When upgrade I'm thinking about: https://github.com/clearhead/clearhead/blob/efficient-when/src/when.js
The "efficient when" will start one loop to check for elements when initially called, then just use that same loop to check for elements until it's found everything, instead of starting a new loop for each element. The only downside to that approach that I can think of is that then you can't set optTimeout or optQuitPolling for each element. To solve that, I've added the ability to stop the When loop by calling when('stop'); which you could do in a timeout or whenever you want.
One thing we have to consider is that if we change the list of parameters that When accepts, it will break old code if we rebuild it with the new module.


Create local table representation in SQL for checkin

May be handled by TypeORM

This cite may be useful
https://typeorm.io/

@Konolo read this https://typeorm.io/migrations


Fix .app.src env and applications, and hostname typo

host instead of hostname is what epgsql uses to connect
add epgsql and poolboy to pgapp .app.src
add default empty pools env to pgapp .app.src

Thank you!


[RL4j]Output from network is not a probability distribution

Issue Description
There is an exception sometimes when calling ACPolicy.nextAction(), such as this:
Exception in thread "Thread-10" java.lang.RuntimeException: Output from network is not a probability distribution: [[    0.4998,    0.5002]]
	at org.deeplearning4j.rl4j.policy.ACPolicy.nextAction(ACPolicy.java:88)
	at org.deeplearning4j.rl4j.policy.ACPolicy.nextAction(ACPolicy.java:71)
	at org.deeplearning4j.rl4j.policy.ACPolicy.nextAction(ACPolicy.java:38)
	at org.deeplearning4j.rl4j.learning.async.AsyncThreadDiscrete.trainSubEpoch(AsyncThreadDiscrete.java:104)
	at org.deeplearning4j.rl4j.learning.async.AsyncThread.handleTraining(AsyncThread.java:192)
	at org.deeplearning4j.rl4j.learning.async.AsyncThread.run(AsyncThread.java:168)

[[    0.4998,    0.5002]] clearly is a probability distribution. I checked the source code. The function is quite simple and self-explained. I think the problem could occur if the random value is very close to 1.0. The comparing sign '<' on line 82 maybe should be changed to '<=' .
Version Information
1.0.0-beta7

That should be fixed with 1.0.0-SNAPSHOT.

Duplicate of #8800


Cross-Package Coverage not Measured

Go coverage does not include coverage of tests across package boundaries:
https://github.com/golang/go/issues/6909
In our code, one example is that the coverage for models.WorkItemRepository.Create is shown as 0%. However, it is clearly called from ./workitemrepository_test.go
The problem is that you can either run coverage for tests in a single package but with coverage for multiple packages or coverage for tests in multiple packages but showing only coverage in a single package, but not both at the same time.
Since we can't expect to get a fix for this any time soon, we need to put in place a workaround that combines multiple coverage files into single one that includes cross-pka coverage.
The issue referenced above has pointers to workarounds.

@tsmaeder I couldn't locate the file named ./workitemrepository_test.go. I can see another file named ./workitem_blackbox_test.go, is that you are referring?

@tsmaeder It looks like we already have a function in Makefile which combines multiple cover profiles.
https://github.com/almighty/almighty-core/blob/master/.make/test.mk#L176
When you run make coverage-all-html you can see the coverage of all the files.
Without the "go test" tool fixing the "Cross-Package Coverage" issue which you mentioned in your description, we cannot really address this issue.

I have a solution for this that I can implement hopefully very quickly.

@kwk Please go ahead.

@baijum no, combining the files will not get you the correct coverage...explanation in the related golang bug.

The solution doesn't work out of the box. Need more time, so I've unassigned myself as there are more pressing things to do.


add sql 'OR' op on PrismaSqlFilter by using array

Hi!
That's the solution i referenced in my issue.
The idea is to be able to filter documents by many values of a field by passing an array with the opts.
Fixes #2290

@jacoblee93 working on it!

@jacoblee93 here's the yarn lint output:
• Packages in scope: docs, examples, langchain, test-exports-cf, test-exports-cjs, test-exports-esbuild, test-exports-esm, test-exports-vercel, test-exports-vite
• Running lint in 9 packages
• Remote caching disabled
langchain:lint: Failed to check if we can skip restoring outputs for langchain#lint: rpc error: code = Unknown desc = failed adding watch to /home/dell/.local/share/turborepo/cookies/ce4b5b478c573d4e/51.cookie: no space left on device. Proceeding to check cache
langchain:lint: cache miss, executing 0a7f222f6bac74ef
examples:lint: Failed to check if we can skip restoring outputs for examples#lint: rpc error: code = Unknown desc = failed adding watch to /home/dell/.local/share/turborepo/cookies/ce4b5b478c573d4e/51.cookie: no space left on device. Proceeding to check cache
examples:lint: Failed to mark outputs as cached for examples#lint: rpc error: code = Unknown desc = failed adding watch to /home/dell/.local/share/turborepo/cookies/ce4b5b478c573d4e/53.cookie: no space left on device
examples:lint: cache hit, replaying output a21fcaf588abe6e4
langchain:lint: - Start analyzing dependencies...
langchain:lint: ✔ [631/631] Analyze done!
langchain:lint: • Circular Dependencies
langchain:lint:   ✅ Congratulations, no circular dependency was found in your project.
langchain:lint:
langchain:lint: Failed to mark outputs as cached for langchain#lint: rpc error: code = Unknown desc = failed adding watch to /home/dell/.local/share/turborepo/cookies/ce4b5b478c573d4e/54.cookie: no space left on device

 Tasks:    2 successful, 2 total
Cached:    1 cached, 2 total
  Time:    1m30.318s

I ran yarn format and commited the changes (check this PR commits).
There was a error that i missed earlier related to typing that i fixed on that same commit.
On writing the integration test i'm a bit lost on how to do it. I'll look into it a bit more by this thursday, so if you could give some direction on how to write it i would be grateful!

Ah I see there isn't one - we should have one.
If you're up for it, look at one of the other vector store tests for inspiration - you'll need to set up a test instance and run commands end to end. Then you can run yarn test:single path/to/test to just run that test individually.
Let me know!


Jupyter support ??

Probably good for a Gsoc project ;)
Meta-kernel doc of Jupyter here: http://jupyter-client.readthedocs.io/en/latest/kernels.html

JupyterTalk : https://github.com/jmari/JupyterTalk


Bump API v2 comprehensively

Try to Fix part of https://github.com/megaease/easegress/issues/715 https://github.com/megaease/easegress/issues/716 https://github.com/megaease/easegress/issues/717

Switch api to v2 in all acpects
Not break compatibility of external APIs (support both yaml and json), but the json became the default Open API format[1], and yaml remains the user interface format
Store data in Etcd in json format (for consistency, performance and standardization)
Standard json encode would not use null value to cover the default spec like third-party yaml codec tool
Use unified spectool to make all serialization/deserialization consitent in low-level utility
Fix some broken unit tests alongside the changes
Upgrade vendors of validation package

[1] https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/#h-accept-and-respond-with-json

Codecov Report

Merging #743 (dae3392) into main (cd73ce5) will decrease coverage by 0.26%.
The diff coverage is 75.86%.

@@            Coverage Diff             @@
##             main     #743      +/-   ##
==========================================
- Coverage   80.44%   80.17%   -0.27%
==========================================
  Files          98       97       -1
  Lines       10702    10664      -38
==========================================
- Hits         8609     8550      -59
- Misses       1604     1628      +24
+ Partials      489      486       -3

Impacted Files
Coverage Δ

pkg/filters/builder/requestbuilder.go
69.09% <ø> (ø)

pkg/filters/builder/responsebuilder.go
69.09% <ø> (ø)

pkg/filters/certextractor/certextractor.go
85.91% <ø> (ø)

pkg/filters/connectcontrol/connectcontrol.go
90.90% <ø> (ø)

pkg/filters/corsadaptor/corsadaptor.go
88.88% <ø> (ø)

pkg/filters/fallback/fallback.go
82.50% <ø> (ø)

pkg/filters/mock/mock.go
83.00% <ø> (ø)

pkg/filters/mqttclientauth/mqttauth.go
82.14% <ø> (ø)

pkg/filters/proxy/compression.go
84.61% <ø> (ø)

pkg/filters/proxy/loadbalance.go
98.86% <ø> (ø)

... and 46 more

Continue to review full report at Codecov.

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


Update application-gateway-limits.md

updating AppGW listener limits doc

@greg-lindsay

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#Sign-Off

#sign-off

@vhorne
PRMerger will accept sign-off from the listed author (@greg-lindsay) only. However, if you are a Microsoft employee authorized to update this content, you can send a request to<EMAIL_ADDRESS>for this PR to be merged. Include your role and an explanation of why the PR should be merged without approval from the listed author.

doc updated via a different PR. Closing this as a duplicate.
https://github.com/MicrosoftDocs/azure-docs-pr/pull/225917


docs: ChatMessageAvatar

:tada: This issue has been resolved in version 7.26.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Improve] Change UI Phonebook

Change UI Phonebook Screen
Change UI Detail Phonebook Screen

[S14] Pembaruan halaman nomor darurat

Review kang @anandarh @gaganugraha33 @aldiiii


Augment integration test story: check deployed app runs after CRC stop-start

General information

OS: Linux / macOS / Windows
Hypervisor: KVM / Hyper-V / VirtualBox / hyperkit

In test/integration/features/story_health.feature, we should add a scenario where we stop CRC after deploying an app, then start it and check if app is OK.

Resolved by #604


Stats return inconsistent information

Version: 0.21.0-alpha.4
Dataset: movies.json
The stats of the index movies returns the following information:
{"numberOfDocuments":19546,"isIndexing":false,"fieldsDistribution":{"genres":19457,"id":19547,"overview":19547,"poster":19547,"release_date":19547,"title":19547}}
As you can see numberOfDocuments: 19546
But the fields distribution show 19547
In version 0.20.0, the returned information is coherent:
{"numberOfDocuments":19546,"isIndexing":false,"fieldsDistribution":{"genres":19456,"id":19546,"overview":19546,"poster":19546,"release_date":19546,"title":19546}}

Hey @shekhirin, if you got time again, can you take a look at this one, please? If not no worries 😃

@Kerollmops yeah, I think so. I've worked on this one previously, so I suppose it would be easy one to figure out.


change LoadBalancedCall to be InternallyRefCounted

This ensures that the CallTracer's RecordEnd() method is invoked at the right time.

Known issues: #26595

/easycla


Implement tracing for TiKV

Development Task

[x] https://github.com/tikv/minitrace-rust/pull/67
[x] https://github.com/tikv/minitrace-rust/pull/71
[x] https://github.com/tikv/minitrace-rust/pull/74
[x] https://github.com/pingcap/kvproto/pull/846
[ ] https://github.com/tikv/tikv/pull/11824
[ ] Allow Java client to send trace context in the request

Useful material

https://github.com/zhongzc/tikv/commit/db76b66a2ea3cb23e0cab4e043500e5a31c16fbc
https://pingcap.feishu.cn/docs/doccnessOsvm9waxwPqt5h7CMXl
https://docs.google.com/presentation/d/1Tb0amFbuB9IDNMhh5x9Sujujes2lXrg1GqdGv5HkNck/edit?usp=sharing

Hi! I'm a senior CS student from Zhejiang University and I'm really interested in contributing to TiKV with this idea. In the process of learning distributed databases, I learned about and became interested in tikv and i'm eager to and passionate about contributing my code to this project.
Would you mind offer me some advise on how to start my journey in tikv community as well as preparing for solving this idea during GSoC 2022?

@andylokandy  (and other experts)
Hi! My name is Shota. I'm preparing to apply for the GSoC. There are a few confirmations and requests.

Goal of this issue
I recognized that the goal of this issue is to be able to see TiKV trace graphs, slow query logs, etc. from the Jaeger UI and Datadog dashboard when the TiUP or TiDB Operator trace switch is turned on. To achieve it, we will implement features to send reports to Jaeger or Datadog by using minitrace-rust.
For each query (trace id), we will collect the following information

Counts of parses, executions, and fetches
CPU time and elapsed time (latency)
Number of rows processed
Each commit and rollback
Summary of wait events for each SQL statement
Row operations showing the actual execution plan for each SQL statement
Number of physical reads, physical writes, and elapsed time for each row operation

Please advise me if I make a mistake or have anything to add.

status of this issue
I interpreted that most of the design & policy-making are finished, but implementation is not yet complete.
(I saw this PR .)
Please point out if my interpretation is wrong. Also, if you have any advice, please let me know.

what I need to research
List any uncertainties as you make policy decisions and design the project.

If you have any other resources that would be helpful for implementation, please share them with me.

ping gsoc mentors @breeswish @zhongzc

Thanks!!


SCM status bar contribution missing under some condition

I am not sure what cause the issue but the SCM status bar entry was missing. I went to check for updates and saw the entry for check for updates was also missing. Perhaps these share a condition that can hint at why the status bar entry was missing. A reload fixed the issue.

Could the SCM bar be this? https://github.com/microsoft/vscode/issues/67670
Now sure what the check for updates missing would mean. They share nothing in common. :think

my case was single root/single folder

Oops, I actually meant this https://github.com/microsoft/vscode/issues/83464 which seems remote related but it's not, notice the steps at the end of the thread.

I can't be certain, but I was convinced that the contribution actually disappeared. Additionally, this happened in today's latest insiders. So, shouldn't it have been resolved?

Yup. Then, let me know if it comes back. Since this is the first report I've ever gotten like this, I'm taking it with some salt. :green_salad:

The exact same issue happened to me again today. I was working in one folder, then opened a second window from an external terminal. Check for updates + SCM Status bar contrib were both missing.

only console errors seem unrelated but not sure.


List of Databases: DBMS Type is not shown (floating bug)

Sometimes when I do:

Login to Arachne Data Node
Go to Administration → Databases

I get '-'s instead of database types in the list of databases. When I sort the list of databases or navigate to another page of Arachne Data Node and go back to the list of databases, the types are shown correctly.

I tested, and everything work fine


Lower Chopping Block Wood Output chance to 1/4 instead of 1/5

https://github.com/gigaherz/Survivalist/issues/88


Raspbian Stretch install script

Implement a bash script for easy installation on Raspbian Stretch. This requires downloading the upcoming v3 from Github releases, disabling dhcpcd and installing and activating NetworkManager.

Running either install script fails. Is there a fresh install script? Thank you.

I guess this can be closed now?

Implemented in #117.


Cannot add or edit calendars via UI

In both our development version (v5.1.2) and the most recent "vanilla" version of uPortal and uPortal-start (v5.2.3), I can't add or edit calendars in the Calendar portlet (v2.6.0).
Steps to reproduce after deploying locally with uPortal-start:

log in as staff or student
click on Calendar portlet name to maximize portlet and reveal Preferences link
click on Preferences
click on + Add a calendar
fill in Calendar name and Calendar URL
click on "Save calendar" button

No new calendar.
Does this happen for you? Could you see if others report the same behavior? It's easy to check if you have uPortal 5 running.
After much debugging I think I know what the problem is but I don't know how to resolve it.
On the "Edit calendar" page (editCalendarUrl.jsp), after entering a Calendar name and Calendar URL, when I click the "Save calendar" button, it's supposed to redirect to Action "editUrl" but it's not getting there because the request looks like this:
http://localhost:8080/uPortal/f/welcome/p/calendar.u25l1n13/max/action.uP?_csrf=403fcb62-9a79-4a32-8874-3a09a1af64f0&pP_action=editUrl
The _csrf parameter is encoding the ampersand as "&" instead of an "&" before the next parameter, "pP_action=editUrl" so in the browser (Chrome), the Query String Parameters list ends up looking like:
_csrf: 403fcb62-9a79-4a32-8874-3a09a1af64f0
amp;pP_action: editUrll
It looks like the "&" isn't getting decoded back to "&" so the second query parameter ends up being "&pP_action" which is likely not being recognized by Spring Portlet or uPortal or whatever processes "pP_action" as an action request.
I've put debug statements in EditUserHttpICalController on the showHttpCalendarForm and updateHttpCalendar methods and it never gets to the updateHttpCalendar method, suggesting that uPortal or the CalendarPortlet isn't decoding the "&" properly. I noticed that this is using Spring Web MVC 3.1.3.RELEASE which is pretty old.
I tried it with uPortal 5.2.3 and CalendarPortlet 2.6.0 using uPortal-start (./gradlew portalInit, ./gradlew tomcatDeploy, ./gradlew tomcatStart) as both admin and staff. Click on Calendar name in portlet header to expand to full screen and display Preferences (and Administration for admin user).

This is the same issue reported by Julien Gribonvald. The fix suggested by Drew is to add escapeXml="false" in the portlet:actionURL tag. For example:
<form:form name="calendar" cssClass="form-horizontal" commandName="userHttpIcalCalendarForm" action="${postUrl}">
I'll create a pull request when I've got this resolved and tested.


fix(docker): Trim Docker Image

Attemps to remove unused files from the docker image such as the .git folder.

Here's an overview over the different docker image size:

v3.0.1-nano: 2.76 GB
development-nano: 2.79 GB
vsawdoteu/development-nano: 2.74 GB

More interesting than the total image size the diff as the images share the darknet base and therefore cache a lot of images.
I have not yet tested the images fully to ensure that all required files made it into the image.

Here's an overview over the different docker image size:

v3.0.1-nano: 2.76 GB
development-nano: 2.79 GB
vsawdoteu/development-nano: 2.74 GB

More interesting than the total image size the diff as the images share the darknet base and therefore cache a lot of images.
I have not yet tested the images fully to ensure that all required files made it into the image.

With https://github.com/opendatacam/opendatacam/pull/370/commits/c7bb1d08b3c2370c84230b55ca2af37ef8cb7be8 in place we should now be able to cache node_modules in a safe way which will bring down the download size even further as only source-code changes need to be downloaded for clients that are already running opendatacam

I have not yet tested the images fully to ensure that all required files made it into the image.

I could finally verify and run this successfully on a Jetson Nano.


SNOW-1445536: Remove StringMethods and DatetimeProperties

Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

Fixes SNOW-1445536

Fill out the following pre-review checklist:

[ ] I am adding a new automated test(s) to verify correctness of my new code

[ ] If this test skips Local Testing mode, I'm requesting review from @snowflakedb/local-testing

[ ] I am adding new logging messages
[ ] I am adding a new telemetry message
[ ] I am adding new credentials
[ ] I am adding a new dependency
[ ] If this is a new feature/behavior, I'm adding the Local Testing parity changes.

Please describe how your code solves the related issue.

This PR removes the StringMethods and DatetimeProperties classes and pushes appropriate NotImplementedErrors to the query compiler. The only class remaining in series_utils.py is CategoryMethods, which we leave behind since some methods in the modin implementation do not use the query compiler. We could remove this by overriding Series.cat to error out immediately instead of returning the CategoryMethods proxy object.

It turns out I had to add some extra boilerplate to get the Modin classes to use the Snowpark pandas Series instead of the OSS version, and I also had to stub dt_* methods in the query compiler to get the proper error message (I must've missed this in CI prior).
You can see the changes in the last commit: https://github.com/snowflakedb/snowpark-python/commit/02b9e488c8a0d21e84bb4bc52984eb642ee7f241