WASM remote loading always fails for the first time

While I was using Istio 1.6.0, I deployed an Nginx as a file server to serve the WASM filter. However, every time I deployed an EnvoyFilter to insert WASM filter into the HTTP filter chain, it always fails for the first time, but delete the EnvoyFilter and re-deploy make sidecar load the WASM filter without any problem. I can see the access log from Nginx, but sidecar shows that the remote loading fails.
Reproduce steps:
after Istio 1.6.0 and the book info example are installed with the demo profile, deploy the Nginx deployment and enabled HTTP 2:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasm-store
  labels:
    app: wasm-store
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wasm-store
  template:
    metadata:
      labels:
        app: wasm-store
    spec:
      containers:
      - name: wasm-store
        image: nginx:1.15.8
        imagePullPolicy: IfNotPresent
        lifecycle:
          postStart:
            exec:
              command:
              - "/bin/bash"
              - "-c"
              - |
                sed -i '2s/.*/    listen    80 http2;/' /etc/nginx/conf.d/default.conf &&
                /etc/init.d/nginx reload;
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: wasm-store
  labels:
    app: wasm-store
spec:
  selector:
    app: wasm-store
  ports:
  - port: 80
    targetPort: 80
    name: http
---
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: add-cluster-def
  namespace: istio-system
spec:
  configPatches:
    - applyTo: CLUSTER
      match:
        cluster:
          service: wasm-store.default.svc.cluster.local
      patch:
        operation: ADD
        value:
          name: wasm-store
          type: STRICT_DNS
          connect_timeout: 10s
          lb_policy: ROUND_ROBIN
          http2_protocol_options: {}
          hosts:
          - socket_address:
              address: wasm-store.default.svc.cluster.local
              port_value: 80

, then copy WASM filters into /usr/share/nginx/html/filter.wasm in the Nginx.
Next, deploy the EnvoyFilter:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-add-header
  namespace: istio-system
spec:
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: ANY # inbound, outbound, and gateway
        listener:
          filterChain:
            filter:
              name: "envoy.http_connection_manager"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.wasm
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.config.filter.http.wasm.v2.Wasm
            value:
              config:
                vm_config:
                  runtime: envoy.wasm.runtime.v8
                  code:
                    remote:
                      sha256: ce5ef3036233334716baff1da2042b33622bee6cb5d05bb1169aab2a928539ad
                      http_uri:
                        uri: http://wasm-store.default.svc.cluster.local/filterwasm
                        cluster: wasm-store
                        timeout:
                          seconds: 3

After the EnvoyFilter deployed, logs in Nginx shows the file fetching is ok:
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"
<IP_ADDRESS> - - [25/May/2020:08:04:50 +0000] "GET /filter.wasm HTTP/2.0" 200 47097 "-" "-" "<IP_ADDRESS>"

, but the logs from sidecars shows the remote loading fails:
2020-05-25T08:10:32.317234Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.321769Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.326996Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.331387Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.333945Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.337031Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.340929Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.344321Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.347573Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.351441Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.355242Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.359247Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.363004Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.366772Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.369907Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.372640Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.381624Z	warning	envoy wasm	[external/envoy/source/extensions/common/wasm/wasm.cc:643] createWasm: failed to load (in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
2020-05-25T08:10:32.382287Z	warning	envoy config	[external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) <IP_ADDRESS>_15010: Failed to load WASM code (fetching) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_3000: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_14267: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_9080: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_443: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_80: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_15020: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_14250: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_16686: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_20001: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_9153: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_14268: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_853: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_14250: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_9090: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_9411: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
<IP_ADDRESS>_15014: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm
virtualInbound: Failed to load WASM code (fetch in progress) from http://wasm-store.default.svc.cluster.local/filter.wasm

Delete the EnvoyFilter and redeploy again, sidecars shows no error, and the WASM filter is working as expected.

This works as expected as of Istio 1.6. Envoy xds currently does not allow async response, so Wasm module downloading has to happen after Envoy nack the configuration push and it expects control plane to push again after module is downloaded. We don't put the listener in warming state so that plugin configuration could be validated on the second config push. See https://github.com/istio/istio/issues/23836 which tracks this in Istio.
In the future we might want to make it possible to put listener/cluster with Wasm plugin into Warming state so that the second push is not needed, but that would be less reliable than the current implementation (e.g. listener might not work as expected, or envoy might crash if plugin cannot be loaded correctly)

As I recall @bianpengyuan is writing a doc about this.


use latest infra.leapp and lvm_snapshots

Everything tested successfully using RHDP workshop environment.

Tested locally as well, worked through RHEL7-8 and RHEL8-9 IPU plus snapshot rollbacks, LGTM. Merging...


--sdk no longer works in latest Ubuntu PPA

Xmake Version
v2.9.6+20241030
Operating System Version and Architecture
Ubuntu (x86-64 and AArch64)
Describe Bug
Out dev container build does a smoke test to make sure that it can build the RTOS.  The builds from yesterday bring a new version of xmake from the Ubuntu PPA and now we see compile failures.
It appears that the latest xmake no longer finds our clang.  This was working with versions of our dev container built three days ago.  Those included xmake v2.9.5+20240914.
Expected Behavior
We run xmake f --sdk=/cheriot-tools/, where /cheriot-tools/bin contains the toolchain files (clang, lld, and so on).  This should then compile with the clang that we have found there.
Project Configuration
https://github.com/CHERIoT-Platform/cheriot-rtos/blob/main/tests/xmake.lua
Most of the rules come from here, including the toolchain definition:
https://github.com/CHERIoT-Platform/cheriot-rtos/blob/main/sdk/xmake.lua
The dev container image with the toolchain installed is available here:
https://github.com/orgs/CHERIoT-Platform/packages/container/package/devcontainer
The smoke-test build is done as:
cd /tmp
git clone --recurse http://github.com/Microsoft/cheriot-rtos
xmake f --sdk=/cheriot-tools/
xmake
xmake run

This works, but if you install a new xmake it does not (unfortunately, changes to the Ubuntu base layer broke sudo - I can fix that once I have a working xmake package).
Additional Information and Error Logs
$ xmake f --sdk=/cheriot-tools/ -v
checking for platform ... cheriot
checking for architecture ... cheriot
generating /tmp/cheriot-rtos/sdk/firmware.ldscript.in to build/test-suite-firmware.ldscript ..
checking for git ... /usr/bin/git
generating /tmp/cheriot-rtos/sdk/firmware.ldscript.in ... ok
configure
{
    debug-locks = false
    board = sail
    host = linux
    mode = release
    stack-usage-check-allocator = false
    debug-loader = false
    debug-allocator = false
    ndk_stdcxx = true
    stack-usage-check-scheduler = false
    arch = cheriot
    debug-scheduler = false
    kind = static
    debug-cxxrt = false
    sdk = /cheriot-tools/
    target_os = linux
    plat = cheriot
    scheduler-accounting = false
    debug-token_library = false
    buildir = build
    ccache = true
}
$ xmake -v
checking for clang++ ... no
checking for the c++ compiler (cxx: clang++) ... no
checking for clang ... no
checking for the assember (as: clang) ... no
checking for clang ... no
checking for the c compiler (cc: clang) ... no
checking for gcc ... /usr/bin/gcc
checking for the c++ compiler (cxx) ... gcc
checking for gcc ... /usr/bin/gcc
checking for the assember (as) ... gcc
checking for gcc ... /usr/bin/gcc
checking for the c compiler (cc) ... gcc
checking for /usr/bin/gcc ... ok
checking for flags (-fPIC) ... no
[ 29%]: cache compiling.release allocator-test.cc
/usr/bin/gcc -c -std=c++20 -target riscv32-unknown-unknown -mcpu=cheriot -mabi=cheriot -mxcheri-rvc -mrelax -fshort-wchar -nostdinc -Oz -g -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -fno-exceptions -fno-asynchronous-unwind-tables -fno-c++-static-destructors -fno-rtti -Werror -I/tmp/cheriot-rtos/sdk/include/c++-config -I/tmp/cheriot-rtos/sdk/include/libc++ -I/tmp/cheriot-rtos/sdk/include -I/tmp/cheriot-rtos/sdk/boards/../include/platform/generic-riscv -DTEMPORAL_SAFETY -DSOFTWARE_REVOKER -DSAIL -DCPU_TIMER_HZ=2000 -DTICK_RATE_HZ=10 -DSIMULATION -DCONFIG_MSHWM -DDEVICE_EXISTS_clint -DDEVICE_EXISTS_shadow -DDEVICE_EXISTS_uart -DREVOKABLE_MEMORY_START=0x80000000 "-DCHERIOT_INTERRUPT_NAMES=FakeInterrupt=4, " -cheri-compartment=allocator_test -o build/.objs/allocator_test/cheriot/cheriot/release/allocator-test.cc.o allocator-test.cc

For comparison, with v2.9.5+20240914, we see this:
$ xmake f --sdk=/cheriot-tools/ -v
checking for platform ... cheriot
checking for architecture ... cheriot
generating /tmp/cheriot-rtos/sdk/firmware.ldscript.in to build/test-suite-firmware.ldscript ..
checking for git ... /usr/bin/git
generating /tmp/cheriot-rtos/sdk/firmware.ldscript.in ... ok
configure
{
    board = sail
    debug-locks = false
    debug-cxxrt = false
    kind = static
    stack-usage-check-scheduler = false
    arch = cheriot
    scheduler-accounting = false
    mode = release
    ndk_stdcxx = true
    sdk = /cheriot-tools/
    debug-loader = false
    ccache = true
    target_os = linux
    debug-token_library = false
    debug-allocator = false
    stack-usage-check-allocator = false
    debug-scheduler = false
    plat = cheriot
    buildir = build
    host = linux
}
$ xmake -v
checking for clang++ ... /cheriot-tools/bin/clang++
checking for the c++ compiler (cxx) ... clang++
checking for clang ... /cheriot-tools/bin/clang
checking for the c compiler (cc) ... clang

And then the build works, because it's using the correct compiler.

Bisecting in the devcontainer suggests that 7af1ca50e38a7cf21048be7a62bd30103421cceb is the first bad commit.
Automated reproducer
For the curious or perhaps future me...
Setup
cd /tmp
git clone --recurse https://github.com/xmake-io/xmake/
git clone --recurse http://github.com/Microsoft/cheriot-rtos
(cd cheriot-rtos; git reset --hard 6f3b7d9; git submodule update)

cat >/tmp/build.sh <<HERE
#!/bin/sh

set -e -u

rm -rf /tmp/xmake.inst
rm -rf /tmp/tmp.*
rm -rf /tmp/.xmake*

cd /tmp/xmake
git clean -xfd
git submodule update
./configure --prefix=/tmp/xmake.inst
make -j4 build
make install

export PATH=/tmp/xmake.inst/bin:$PATH
cd /tmp/cheriot-rtos/tests
git clean -xfd
xmake f --sdk=/cheriot-tools
xmake || exit 1
HERE
chmod +x /tmp/build.sh

Run
cd /tmp/xmake
git bisect start
git bisect good v2.9.5
git bisect bad v2.9.6
git bisect run /tmp/build.sh

try this patch. https://github.com/xmake-io/xmake/pull/5780
xmake update -s dev

Yes, testing with eada026c1e27728861f76449b77726b3ebe8bff0, which includes the merge of #5780 (1c689fd23324695a9256b6d0ed5187f0c9f0c692), works.  Thank you!

Would it be possible to include this fix in the PPA package?  We can't update our dev container currently.

Would it be possible to include this fix in the PPA package? We can't update our dev container currently.

I don't know how to update it without updating the version?

I don't know how to update it without updating the version?

Maybe do a point release?  Or bump the date suffix?  Or keep the old version available so that we can pin the version and have one that can still build any of things?

to update to dev on container.

This isn't easy to integrate with a dev container.

try 2.9.6+2

That works, thanks! I’ll try to set up a nightly CI job to test xmake head and catch things like this prior to release in the future.

FYI: I've set up a nightly job for us to test with the latest xmake:
https://github.com/CHERIoT-Platform/cheriot-rtos/actions/workflows/test-new-xmake-nightly.yml
It's currently failing because the sudo config is broken in our dev container, but that will be fixed as soon as the dev container is rebuilt (20-30 minutes).


[5.9 🍒] Miscellaneous Dependency Scanner and Explicit Modules Improvements

Cherry-pick of https://github.com/apple/swift/pull/65869 and https://github.com/apple/swift/pull/66031
• Release: Swift 5.9
• Explanation: Cherry-picks of a handful of changes to the dependency scanner, in order to facilitate early experimental adoption of explicit module loading in release compilers.
• Scope of Issue: This issue impacts only users who opt-in to Explicit Module Builds with the driver's -experimental-explicit-module-build.
• Origination: Development of Explicit Module loading
• Risk: The risk of this change is low, affected code-paths are not triggered during Implicit Module builds (default)
• Reviewed By: @nkcsgexi, @cachemeifyoucan

@swift-ci test

@swift-ci test


ROS2 foxy support

Is there a plan to support ROS2 foxy in the near future? Thanks!

I would also be interested if this library were to be ported to ROS2 Foxy.

Hi @5567655
A release date has not yet been set, but support for ROS2 is being planned.


[Bug] workers failed to connect to head node

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 am trying to run command mentioned in documentation here.
The raycluster has been started but workers are unable to connect to ray head node:
[asmalvan@learn-ray-2 ray-operator]$ kubectl get rayclusters
NAME                       AGE
raycluster-heterogeneous   42s
(base) [asmalvan@learn-ray-2 ray-operator]$ kubectl get pods
NAME                                                 READY   STATUS    RESTARTS   AGE
raycluster-heterogeneous-head-m7qlk                  1/1     Running   0          50s
raycluster-heterogeneous-worker-medium-group-k92qt   1/1     Running   0          50s
raycluster-heterogeneous-worker-small-group-47gmf    1/1     Running   0          50s
raycluster-heterogeneous-worker-small-group-58lhs    1/1     Running   0          50s
raycluster-heterogeneous-worker-small-group-z5726    1/1     Running   0          50s
(base) [asmalvan@learn-ray-2 ray-operator]$ kubectl get services
NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                       AGE
kubernetes                          ClusterIP   <IP_ADDRESS>        <none>        443/TCP                       28h
raycluster-heterogeneous-head-svc   ClusterIP   <IP_ADDRESS>   <none>        6379/TCP,8265/TCP,10001/TCP   58s
(base) [asmalvan@learn-ray-2 ray-operator]$ kubectl logs raycluster-heterogeneous-head-m7qlk
2022-01-26 09:01:10,683 INFO services.py:1272 -- View the Ray dashboard at http://<IP_ADDRESS>:8265
(base) [asmalvan@learn-ray-2 ray-operator]$ kubectl logs raycluster-heterogeneous-head-m7qlk
2022-01-26 09:01:10,683 INFO services.py:1272 -- View the Ray dashboard at http://<IP_ADDRESS>:8265
(base) [asmalvan@learn-ray-2 ray-operator]$ kubectl logs raycluster-heterogeneous-worker-small-group-47gmf
[2022-01-26 09:01:11,820 W 8 8] global_state_accessor.cc:427: Some processes that the driver needs to connect to have not registered with Redis, so retrying. Have you run 'ray start' on this node?

minikube was started using the command:
 minikube start --cpus 16 --memory 32768
Can you please suggest any steps on how to get the sample deployment in the documentation running?
Reproduction script

Start minikube using command minikube start --cpus 16 --memory 32768
Follow documentation mentioned here , please skip delete operator step

Anything else
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

@asm582 Thanks for reporting the issue.  could you describe the worker pod and we can see your configurations? BTW, I would suggest you to update title to clearly describe the problem. Seems ray-operator  works fine on your side but the worker are not up.

Could you do something like below to see if all nodes joined the cluster. I think the logs might be misleading and they should be already ready.
kubectl port-forward svc/raycluster-heterogeneous-head-svc 8265:8265
I didn't use minikube but docker for desktop. The example works fine for me

Thanks, @Jeffwan I have changed the issue description, let me know if you think this is apt.
Please see the screenshot below, I can see the workers:

Can you help in understanding why the head node has 100% CPU utilization?
I think a test program is supposed to be running as defined in the config map but I am not sure if it ran on any of the worker nodes as there are no raylet logs, is that assumption correct?

FYI, Sharing a snippet of my log file, should we reduce the logging level on the head node, maybe we are logging status every 5 seconds which is consuming a lot of CPU?

Can you help in understanding why the head node has 100% CPU utilization?

since head node runs monitor process and gcs etc, the usage is a little bit high. there's only 0.6 cpu allocated there. Seems your resource allocation is different from what I expected.  can you help describe one worker pod spec and share with us?

I think a test program is supposed to be running as defined in the config map but I am not sure if it ran on any of the worker nodes as there are no raylet logs, is that assumption correct?

If you use exact same one as this, I would say the code is not running. We remove startup entrypoint since we may deprecate this way and use job submission instead later.
https://github.com/ray-project/kuberay/blob/master/ray-operator/config/samples/ray-cluster.heterogeneous.yaml
You can kubectl exec -it headpod bash and run this code snippet manually
https://github.com/ray-project/kuberay/blob/master/ray-operator/config/samples/config-map-ray-code.yaml

FYI, Sharing a snippet of my log file, should we reduce the logging level on the head node, maybe we are logging status every 5 seconds which is consuming a lot of CPU?

yeah, I think the major reason is monitor process keep running periodically which consumes CPU.  Using a large template would be helpful for head node

Closing this issue


Proper Time Zones Conversions

Problem Explained
Currently, we are storingDateTime based on the location of the device the application is hosted on, but we don't take into account that if someone accesses this website from another timezone it doesn't show up properly.
We should store all the DateTime's as DateTime.UtcNow in the database, and convert the time back to a user his local time on request.
I would recommend reading this very interesting article by Shay Rojansky, who is a member of the entity framework team at Microsoft, and lead developer of the PostgreSQL entity framework provider.
For example currently, because I'm using PostgreSQL I had to enable AppContext.SetSwitch("Npgsql.EnableLegacyTimestampBehavior", true);, which results in all the timestamps being converted to UTC now when writing to the Database, but because we are only showing the end user the local saved timezone for me all the timestamps are not converted properly, which is also a problem for people who are outside of the timezone the application is hosted on.
I suggest we start working on a proper conversion for timezones to boost this project in terms of professionalism, and production readiness.
Problem Example
Local console log time:

Website log time:

As you can see my current time was 14:20, but since the DateTime is being saved in UTC the website will show up in UTC 12:20.
As I said earlier this isn't only a problem when using PostgreSQL, but also when someone would be outside of the timezone the application is hosted on, which would make it impossible to use worldwide.

Thank you for your message. It's great that you are aware of the timezone issue in your project. It's true that the DateTimeService.cs file with the Now => DateTime.UtcNow code is a step in the right direction. To convert between local time and UTC time, you can use the TimeZoneInfo class in C#. This class provides methods to convert between different time zones and can be used to convert the UTC time to the local time of the user. You can also use the DateTimeOffset structure, which includes both the UTC time and the local time offset. I hope this helps! Let me know if you have any further questions.

Well, this isn't necessarily an issue with "my" project, but with the whole project in general. This is because as far as I can see we don't do any conversion, which means everybody always sees the time stored based on the device location the project is hosted on. Switching from DateTime.Now to DateTime.UtcNow in the DateTimeService.cs file is just a really small step since only saving the utc now times isn't necessarily a solution. We need to properly save the UTC times as an example explained in the earlier mentioned article, so we can also properly convert it back. Otherwise, everyone will end up with UTC timestamps, rather than the converted timestamp based on their own location.

@Bram1903
I think it would be simpler to create two extension methods directly on the DateTime class, such as ToLocal() or ToUtc().


Adding autocomplete attribute in docs input search

The autocomplete input attribute generates a "bug" when docs autocomplete is triggered. Look the change below:
Before

After

Is that really a bug or a feature to match more stuff?

@XhmikosR, IMHO, it's a UX fault when you're using an input suggestion without a [autocomplete="false"], but feel free to close this pull request if you define that's a "nice to have feature".

Well, it's a search after all.
Anyway, I'll let the others chime in too.

Yeah it should be disabled. :shipit:


(BKR-579) rpm calls to respect package_proxy opt

Without this patch applied, the call to rpm in Beaker::DSL::InstallUtils ignores the package_proxy option.
We add two new methods, extract_rpm_proxy_options and install_package_with_rpm.
The extract_rpm_proxy_options method is needed as the rpm command expects command line options --httpproxy and --httpport.
The install_package_with_rpm method is needed in order to install rpms from a remote URL address.  The existing install_package method uses yum and yum can't install an rpm from a remote URL.
Spec tests are provided for the extract_rpm_proxy_options method.  A redundant spec test is deleted.

Can one of the admins verify this patch?

@anodelman Any chance someone can look at this?

Hi @alexharv074. Since these changes are specifically for handling the details of RPM, I think the appropriate place for them would be in unix/pkg.rb.
Let me know if you have any questions or comments about this.
Thanks,
KI

Hi @kevpl.  I think I understand, although involves a bit of refactoring.
There are quite a number of direct calls to rpm (not to mention dpkg etc) in Beaker::DSL::InstallUtils and Beaker::HostPrebuiltSteps:
alexs-mbp:beaker-2.23.0 alexharvey$ grep -r 'rpm ' lib/
lib//beaker/dsl/install_utils/foss_utils.rb:        # Installs Puppet and dependencies using rpm on provided host(s).
lib//beaker/dsl/install_utils/foss_utils.rb:              rpm = "puppetlabs-release%s-%s-%s.noarch.rpm" % [repo_name, variant, version]
lib//beaker/dsl/install_utils/foss_utils.rb:              remote = URI.join( opts[:release_yum_repo_url], rpm )
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "rpm --replacepkgs -ivh #{remote} #{proxy}"
lib//beaker/dsl/install_utils/foss_utils.rb:            find_command  = 'rpm -ivh'
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "rpm -ivh #{onhost_copied_file}"
lib//beaker/dsl/install_utils/foss_utils.rb:              # that the desired rpm has been mirrored to the 'repos' location.
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "rpm -ivh #{onhost_copied_tar_file}"
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "rpm -ivh #{onhost_copied_file}"
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "rpm -ihv #{onhost_copied_file}"
lib//beaker/host/unix/pkg.rb:        result = execute("rpm -q #{name}", opts) { |result| result }
lib//beaker/host_prebuilt_steps.rb:    # @option opts [Boolean] :debug If true, print verbose rpm information when installing EPEL
lib//beaker/host_prebuilt_steps.rb:          result = host.exec(Command.new('rpm -qa | grep epel-release'), :acceptable_exit_codes => [0,1])
lib//beaker/host_prebuilt_steps.rb:              host.exec(Command.new("rpm -i#{debug_opt} #{url}/#{arch}/e/#{pkg}"))
lib//beaker/host_prebuilt_steps.rb:              host.exec(Command.new("rpm -i#{debug_opt} #{url}/#{arch}/#{pkg}"))

And then dpkg:
alexs-mbp:beaker-2.23.0 alexharvey$ grep -r 'dpkg ' lib/
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "dpkg -i --force-all /tmp/puppet.deb"
lib//beaker/dsl/install_utils/foss_utils.rb:            find_command  = 'dpkg -i'
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "dpkg -i --force-all #{onhost_copied_file}"
lib//beaker/dsl/install_utils/foss_utils.rb:              on host, "dpkg -i --force-all #{onhost_copied_file}"
lib//beaker/host/unix/pkg.rb:        result = execute("dpkg -s #{name}", opts) { |result| result }

Now, ideally, we could just have a platform independent method 'install_package' but of course, we already do - but it uses yum on Redhat-based platforms.
The problem of rpm vs yum is itself an ugly legacy issue with the Redhat platform.
What if I provide a new method in unix/pkg.rb:
def rpm_install_package(package, additional_args = '')
  ...
end

If the package looks like a URL it will attempt to install remotely and automatically respect opts[:package_proxy].  An option like --replacepkgs could be passed in optionally in additional_args.
How does this sound?

@alexharv074, agreed, that stuff is spread everywhere.  It's an old pattern that was just copy-pasted to get things done quickly, I'm pretty sure.  It's definitely something I'd like to get away from going forward.
I think this is a good idea. My two caveats would be to make sure that people can pass in similar options to install_package like cmdline_args (the more general, the better), and it would be nice for review purposes if the added method & spec functionality were separate commits from any refactors
that you do for this.

@kevpl I am stuck on these spec tests.
Failed examples:

rspec ./spec/beaker/dsl/install_utils/foss_utils_spec.rb:398 # ClassMixedWithDSLInstallUtils#install_puppet on el-6 installs
rspec ./spec/beaker/dsl/install_utils/foss_utils_spec.rb:416 # ClassMixedWithDSLInstallUtils#install_puppet on el-5 installs
rspec ./spec/beaker/dsl/install_utils/foss_utils_spec.rb:424 # ClassMixedWithDSLInstallUtils#install_puppet on fedora installs
rspec ./spec/beaker/dsl/install_utils/foss_utils_spec.rb:591 # ClassMixedWithDSLInstallUtils#install_puppetlabs_release_repo When host is a redhat-like platform installs an rpm

I can't get my head around what these tests are trying to do; thus struggling to fix them.  Any help appreciated.

@kevpl I confirmed that my code works by the way; and I intend to rebase of course.

@alexharv074, to go through the test on line 398 to give you some idea of the tests:

line 399 really tests that install_puppetlabs_release_repo sets the right package format
line 400 tests that install_puppet_from_rpm_on calls install_package correctly

The other examples are all similar.  Let me know if you still have questions about this.

@kevpl It made more sense after sleeping. :)  Ok, let me know your thoughts on the updated PR.  Since I haven't really done any refactoring, it's all in one commit.  The issue with extensive refactoring to use my new method is that I found most of the calls to RPM are actually on the AIX platform and I can't test that here, so felt it better to leave it alone.

:+1:

@puppetlabs-jenkins test this please

Initially i was a bit confused by the extra PR's for the proxy parts, but now i understand its for the rpm commands directly.
I only used Yum so far and with the proxy part i already write the yum config for enabling proxy :-)

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1699/
Test FAILed.

I am not able to follow the link to Jenkins.  All the tests pass when I run them; are there really tests failing?

@kevpl Any chance you could have a look into what's wrong here?

My apologies, it could very well be the case that these are unrelated failures to your change. :crying_cat_face:
Unfortunately, I can't see the run due to history limits.  I'll kick off another one, & look at this later today for you (I'm also looking at increasing our limits, so that we don't have to have this delay in the future).
I'll let you know what I find.

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1720/
Test FAILed.

transient failures not related to your changes.  Will retest in a bit

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1729/
Test FAILed.

failures unrelated to change

@kevpl How long before this will be released in a new gem?

@alexharv074 the next scheduled Beaker release is for Nov 4th, so it should be then or earlier.

Thanks.


DnsNameResolver fails for some hostnames

The following test is failing for me as of Netty 4.1.9.Final. To be exact, it fails most of the time and succeeds once every dozen of runs. I've tested setting the DNS servers explicitly (e.g. just <IP_ADDRESS>:53) but that hasn't made a difference.
It seems to be specific to certain hostnames (a few examples are included in the test) and more "normal" hostnames such as netty.io, google.com, apple.com work just fine.
Netty version
Fails: 4.1.9.Final and later
Succeeds: versions prior to 4.1.9.Final
Steps to reproduce
public class ResolveTest {

  @Test
  public void testResolve() {

    EventLoopGroup group = new NioEventLoopGroup();
    try {
      DnsNameResolver resolver = new DnsNameResolverBuilder(group.next())
          .channelType(NioDatagramChannel.class)
          .build();
      try {
        // A few options that show the same result
        // msnbot-157-55-33-18.search.msn.com
        // b110352.yse.yahoo.net
        Future<InetAddress> future = resolver.resolve("crawl-66-249-64-1.googlebot.com");
        InetAddress address = future.syncUninterruptibly().getNow();

        assertNotNull(address);

      } finally {
        resolver.close();
      }
    } finally {
      group.shutdownGracefully();
    }
  }
}

java.net.UnknownHostException: failed to resolve 'crawl-66-249-64-1.googlebot.com' after 3 queries
	at io.netty.resolver.dns.DnsNameResolverContext.finishResolve(DnsNameResolverContext.java:648)
	at io.netty.resolver.dns.DnsNameResolverContext.tryToFinishResolve(DnsNameResolverContext.java:568)
	at io.netty.resolver.dns.DnsNameResolverContext$3.operationComplete(DnsNameResolverContext.java:278)
	at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
	at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:481)
	at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:420)
	at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:104)
	at io.netty.resolver.dns.DnsQueryContext.setSuccess(DnsQueryContext.java:194)
	at io.netty.resolver.dns.DnsQueryContext.finish(DnsQueryContext.java:177)
	at io.netty.resolver.dns.DnsNameResolver$DnsResponseHandler.channelRead(DnsNameResolver.java:929)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:624)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:559)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:476)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
	at java.lang.Thread.run(Thread.java:745)

$ dig crawl-66-249-64-1.googlebot.com

;; ANSWER SECTION:
crawl-66-249-64-1.googlebot.com. 59 IN	A	<IP_ADDRESS>

JVM version (e.g. java -version)
$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

Have you tried to increase some number of allowed queries ?

Am 22.03.2017 um 07:27 schrieb Roger<EMAIL_ADDRESS>The following test is failing for me as of Netty 4.1.9.Final. To be exact, it fails most of the time and succeeds once every dozen of runs. I've tested setting the DNS servers explicitly (e.g. just <IP_ADDRESS>:53) but that hasn't made a difference.
It seems to be specific to certain hostnames (a few examples are included in the test) and more "normal" hostnames such as netty.io, google.com, apple.com work just fine.
Netty version
Fails: 4.1.9.Final and later
Succeeds: versions prior to 4.1.9.Final
Steps to reproduce
public class ResolveTest {
@Test
public void testResolve() {
EventLoopGroup group = new NioEventLoopGroup();
try {
  DnsNameResolver resolver = new DnsNameResolverBuilder(group.next())
      .channelType(NioDatagramChannel.class)
      .build();
  try {
    // A few options that show the same result
    // msnbot-157-55-33-18.search.msn.com
    // b110352.yse.yahoo.net
    Future<InetAddress> future = resolver.resolve("crawl-66-249-64-1.googlebot.com");
    InetAddress address = future.syncUninterruptibly().getNow();

    assertNotNull(address);

  } finally {
    resolver.close();
  }
} finally {
  group.shutdownGracefully();
}

}
}
java.net.UnknownHostException: failed to resolve 'crawl-66-249-64-1.googlebot.com' after 3 queries
at io.netty.resolver.dns.DnsNameResolverContext.finishResolve(DnsNameResolverContext.java:648)
at io.netty.resolver.dns.DnsNameResolverContext.tryToFinishResolve(DnsNameResolverContext.java:568)
at io.netty.resolver.dns.DnsNameResolverContext$3.operationComplete(DnsNameResolverContext.java:278)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:481)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:420)
at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:104)
at io.netty.resolver.dns.DnsQueryContext.setSuccess(DnsQueryContext.java:194)
at io.netty.resolver.dns.DnsQueryContext.finish(DnsQueryContext.java:177)
at io.netty.resolver.dns.DnsNameResolver$DnsResponseHandler.channelRead(DnsNameResolver.java:929)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:624)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:559)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:476)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:745)
$ dig crawl-66-249-64-1.googlebot.com
;; ANSWER SECTION:
crawl-66-249-64-1.googlebot.com. 59 IN	A	<IP_ADDRESS>
JVM version (e.g. java -version)
$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@normanmaurer via maxQueriesPerResolve(...)? That had no effect but... I've just changed maxPayloadSize() from the default value of 4kb to 10kb and that seems to fix it.

Actually, I take that back. The results flip flop.

But setting resolvedAddressTypes(ResolvedAddressTypes.IPV4_ONLY) seems to fix it (default value is IPV4_PREFERRED)

interesting... I will have a look soon

@rkapsi - Also note that as of 4.1.9 we respect the system DNS configuration and use this over provided hostnames. The ambiguity will be resolved soon as part of https://github.com/netty/netty/issues/6573. However is it possible you are using unexpected DNS servers?

@normanmaurer @Scottmitch I have tried setting nameServerAddresses() explicitly to <IP_ADDRESS> but that didn't make a difference (unless that's what you mean with system DNS being used over provided).
Here's a more complete test. Notice that the IPv6 tests are expected to fail (the test doesn't check for it though). The IPv4 tests are supposed to succeed and most importantly... The testResolveDefault() will be flapping. I guess depending on whether IPv4 or 6 gets picket.
You maybe need to run it a few times to see the effect.
public class ResolveTest {

  @Test
  public void testResolveDefault() {
    doResolve(null);
  }

  @Test
  public void testResolveIPv4Only() {
    doResolve(ResolvedAddressTypes.IPV4_ONLY);
  }

  @Test
  public void testResolveIPv4Preferred() {
    doResolve(ResolvedAddressTypes.IPV4_PREFERRED);
  }

  @Test
  public void testResolveIPv6Only() {
    doResolve(ResolvedAddressTypes.IPV6_ONLY);
  }

  @Test
  public void testResolveIPv6Preferred() {
    doResolve(ResolvedAddressTypes.IPV6_PREFERRED);
  }

  private static void doResolve(ResolvedAddressTypes types) {
    EventLoopGroup group = new NioEventLoopGroup();
    try {
      DnsNameResolverBuilder builder = new DnsNameResolverBuilder(group.next())
          .channelType(NioDatagramChannel.class)
          .nameServerCache(NoopDnsServerAddressStreamProvider.INSTANCE);

      if (types != null) {
        builder.resolvedAddressTypes(types);
      }

      DnsNameResolver resolver = builder.build();
      try {
        // A few options that show the same result
        // msnbot-157-55-33-18.search.msn.com
        // b110352.yse.yahoo.net
        Future<InetAddress> future = resolver.resolve("crawl-66-249-64-1.googlebot.com");
        InetAddress address = future.syncUninterruptibly().getNow();

        Assert.assertNotNull(address);

      } finally {
        resolver.close();
      }
    } finally {
      group.shutdownGracefully();
    }
  }
}

I have tried setting nameServerAddresses() explicitly to <IP_ADDRESS> but that didn't make a difference (unless that's what you mean with system DNS being used over provided).

@rkapsi - https://github.com/netty/netty/issues/6573#issuecomment-289554271 communicates what I was getting after. Let me know if you accounted for this and we are on the same page. Note that this ambiguity has been resolved via PR https://github.com/netty/netty/pull/6588.

Can you clarify what your expectations are for this particular domain (crawl-66-249-64-1.googlebot.com) for an AAAA lookup? This lookup returns an SOA record, but using the name-server and treating it like a redirect provides the same results.
  Although it is unclear to me (based upon the above unit test in https://github.com/netty/netty/issues/6559#issuecomment-290713440) if the expectation is we should also some how obtain AAAA records.

@Scottmitch I'm expecting AAAA to fail and A to succeed for crawl-66-249-64-1.googlebot.com.
In the context of DnsNameResolver I'm expecting it to resolve to an IP address when I'm using a default configuration for it. That's how it used to be before ResolvedAddressTypes was introduced. To put it differently, I'm expecting it to behave like JDK's own InetAddress and resolve to a IP address. I don't care if it's IPv4 or IPv6 (figuratively speaking).
The observed behavior is that the default configuration will flap between failure and success.
I'm currently working around the problem by explicitly setting resolvedAddressTypes(IPV4_PREFERRED).

I think this and #6600 are the same

@rkapsi - Thanks for clarifying and confirming. Let me close this issue for now. Please reopen if PR https://github.com/netty/netty/pull/6601 doesn't resolve the issue.


Babel plugin for immer

🚀 Feature Proposal
Babel plugin for code generation instead of proxifying properties
Motivation
Current implementation is extremely slow on 1к update operations.
For my i7-5500 it takes 700ms.
For Object.assign it requires just 32 ms.
Dart implementation based on codegen requires 60ms for update similar shape object.
Immer can export API to create babel plugin which should be used for production environment at build phase.
It slightly overhead size of application, but it significally increase performance.
Can this be solved in user-land code?
Code like this:
  produce((draft) => draft.a = 10)

could be generated to:
produce((draftProxy) => draftProxy.set(['a'], 10))

etc.
So this will be reasonable trade off between public API simplicity and code performance.

Sounds like a cool idea that can be build as separate project? Feel free to
take a stab at it
On Sat, 5 Sep 2020, 11:59 Max<EMAIL_ADDRESS>wrote:

🚀 Feature Proposal
Babel plugin for code generation instead of proxifying properties
Motivation
Current implementation is extremely slow on 1к update operations.
For my i7-5500 it takes 700ms.
For Object.assign it requires just 32 ms.
Dart implementation https://pub.dev/packages/built_value based on
codegen requires 60ms for update similar shape object.
Immer can export API to create babel plugin which should be used for
production environment at build phase.
It slightly overhead size of application, but it significally increase
performance.
Can this be solved in user-land code?
No
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/issues/666, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBDYCKZZ2QTRIVGPT63SEIKZLANCNFSM4Q2YD45Q
.

Closing as this is a problem that can be solved outside the scope of this project


Merge refs/heads/master into alpha

Merge refs/heads/master into alpha

This PR has been merged into alpha and tagged as 1.7.0-alpha-202307081117. Thanks for your contribution!


getDoNotDisturb is not working anymore on os x v.11 (Big Sur)

getDoNotDisturb is not working anymore on os x v.11 (Big Sur) since they removed ~/Library/Preferences/ByHost/com.apple.notificationcenterui setting

@felixrieseberg  please checkout this PR: https://github.com/felixrieseberg/macos-notification-state/pull/14

This can be closed, right?  @RihardKrauz


Fix typos in README.md

Changed "Incoporate" to "Incorporate"
Changed "seperately" to "separately"
Changed "applicaiton" to "application"
Corrected two instances of "infomation" to "information"

WHy this was not approved yet?


Update QUICHE from c6efbc4f7 to 8b0d15bda

https://github.com/google/quiche/compare/c6efbc4f7..8b0d15bda
$ git log c6efbc4f7..8b0d15bda --date=short --no-merges --format="%ad %al %s"
2022-11-10 fayang Internal change
2022-11-10 wub Change QuicStreamSequencer's destructor to be a non-virtual. 2022-11-10 haoyuewang Use next_connection_id_sequence_number to validate retired CID number as retiring an active CID would not guarantee that a new CID is issued due to CID collision in dispatcher. 2022-11-08 haoyuewang Internal change
2022-11-07 bschneider Support padding of binary http request and response messages. 2022-11-06 quiche-dev Fix unused-result compile failure in masque_client_bin.cc 2022-11-06 achernya Fix build issues found by CC=clang bazel build ... in kokoro 2022-11-06 quiche-dev Remove unreachable return from masque_client_bin 2022-11-06 achernya Move QuicToyClient::ClientFactory to its own file 2022-11-06 achernya Trigger copybara
2022-11-06 achernya Apply BUILD.bazel patch from perryl@ to add masque client/server cc_binary rules 2022-11-06 dschinazi Improve capsule logging
2022-11-05 achernya IETF CONNECT-IP Hackathon: TUN device for masque_client 2022-11-05 dschinazi Allow masque_client to select IP address family for DNS 2022-11-04 wub Internal change
2022-11-04 quiche-dev window_manager: include stdint.h for int64_t 2022-11-04 rch Do not use a reference to a temporary object. (Caught by some additional warnings that @ellyjones was building with) 2022-11-04 rch Fix "Dead write" in quic_packet_creator_test.cc 2022-11-03 ianswett Add a connection option, BBPD, to set the PROBE_DOWN pacing gain to 0.91 instead of 0.75.  Not flag protecting because it's setting a constant to a slightly different value. 2022-11-03 haoyuewang Internal change
2022-11-03 ianswett Internal change
Signed-off-by: Renjie Tang<EMAIL_ADDRESS>Risk Level: Low
Testing: existing tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

/lgtm deps


[DO NOT MERGE] riff image load

Fixes https://github.com/projectriff/riff/issues/806

Flagged as DO NOT MERGE as this is currently stacked on another PR.


CS9192	Argument 1 should be passed with 'ref' or 'in' keyword - In generated code for struct

Hi
Is it possible to fix the generated code so in the output code the CS9192 warning won't show up?
This is the file that it happens in:

C:\MyProj\MemoryPack.Generator\MemoryPack.Generator.MemoryPackGenerator\MyProj.StructFile.MemoryPackFormatter.g.cs

I have exactly the same issue, when I find the solution, I'll post it here.

The following code can reproduce the warning:
[MemoryPackable]
public partial class Foo
{
    public List<Bar> Bars1; // Warning CS9192
    public List<Bar> Bars2 { get; set; } // Warning CS9193
}

[MemoryPackable]
public partial class Bar
{
    public int Id { get; set; }
}

Look at the generated code, it seems that we should add ref before the parameter of Unsafe.AsRef (eg: Unsafe.AsRef(ref value.@Bars1)) ?
[global::MemoryPack.Internal.Preserve]
static void IMemoryPackable<Foo>.Serialize<TBufferWriter>(ref MemoryPackWriter<TBufferWriter> writer, scoped ref Foo? value)
{
    if (value == null)
    {
        writer.WriteNullObjectHeader();
        goto END;
    }

    writer.WriteObjectHeader(2);
    global::MemoryPack.Formatters.ListFormatter.SerializePackable(ref writer,
        ref System.Runtime.CompilerServices.Unsafe.AsRef(value.@Bars1));
    global::MemoryPack.Formatters.ListFormatter.SerializePackable(ref writer,
        ref System.Runtime.CompilerServices.Unsafe.AsRef(value.@Bars2));

END:
    return;
}

I think it's not too hard to fix, just add two more checks to the generator, one for checking if it's a property, and the other for checking if it's a class type.
Or maybe we can just remove the ref, since it seems like that SerializePackable does not modify the variable itself.

The following code can reproduce the warning in .NET 8:
[MemoryPackable]
public partial class Foo
{
    public List<Bar> Bars1; // Warning CS9192
    public List<Bar> Bars2 { get; set; } // Warning CS9193
}

[MemoryPackable]
public partial class Bar
{
    public int Id { get; set; }
}

Look at the generated code, it seems that we should add ref before the parameter of Unsafe.AsRef (eg: Unsafe.AsRef(ref value.@Bars1)) ?
[global::MemoryPack.Internal.Preserve]
static void IMemoryPackable<Foo>.Serialize<TBufferWriter>(ref MemoryPackWriter<TBufferWriter> writer, scoped ref Foo? value)
{
    if (value == null)
    {
        writer.WriteNullObjectHeader();
        goto END;
    }

    writer.WriteObjectHeader(2);
    global::MemoryPack.Formatters.ListFormatter.SerializePackable(ref writer,
        ref System.Runtime.CompilerServices.Unsafe.AsRef(value.@Bars1));
    global::MemoryPack.Formatters.ListFormatter.SerializePackable(ref writer,
        ref System.Runtime.CompilerServices.Unsafe.AsRef(value.@Bars2));

END:
    return;
}

I found the above code compiles without warnings in .NET 7 because the signature of Unsafe.AsRef is:
public static ref T AsRef<T> (scoped in T source);
while in .NET 8 it is:
public static ref T AsRef<T> (scoped ref T source);
So there is a breaking change in .NET 8.

There is no need for ref in ListFormatter.SerializePackable while serialization will not (and should not) change the list reference.
I suggest changing
void SerializePackable<T, TBufferWriter>(ref MemoryPackWriter<TBufferWriter> writer, scoped ref List<T?>? value)
to
void SerializePackable<T, TBufferWriter>(ref MemoryPackWriter<TBufferWriter> writer, List<T?>? value)

Hi. Thanks for the suggestions.
I fixed in #232.


FHIRPath constant value null casting bug fix

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #2011
Description
Use safe casting
Alternative(s) considered
N/A
Type
Bug fix
Screenshots (if applicable)
N/A
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

@santosh-pingle can you merge the PR as well? I don't have write access to do that

@santosh-pingle can you merge the PR as well? I don't have write access to do that

@jingtang10 Can you please review it


Error in post-command-hook (ivy--queue-exhibit): (wrong-type-argument sequencep 24)

Hi,
I really enjoyed using ivy-prescient.el but since a while I get the error above if I use swiper or swiper-isearch in a buffer.
I could condense it down to this minimal.el to reproduce the error on my system (GNU Emacs 26.3 on macOS, ivy-20200319.1247 and ivy-prescient-20200407.1906)
(require 'package)
(setq package-enable-at-startup nil)
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
                         ("melpa" . "https://melpa.org/packages/")))
(package-initialize)

;; Bootstrap `use-package`
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))
(require 'use-package)

;;; Counsel
(use-package counsel)

;;; Swiper
(use-package swiper)

;;; Ivy
(use-package ivy
  :bind
  (("C-s" . swiper-isearch)
   ("C-r" . swiper))
  :config
  (ivy-mode 1)
  (setq ivy-use-virtual-buffers t
	ivy-use-selectable-prompt t))

(use-package ivy-prescient
  :demand t
  :config
  (ivy-prescient-mode t)
  (prescient-persist-mode t))

I don't see any other errors etc. toggle-debug-on-error does nothing. Could you please confirm if this is a bug in ivy-prescient.el`?
Thanks!

I encounter the same problem as @MartinBuchmann under Emacs 26.3 on Arch Linux.
Relevant parts of init.el:
;; Ivy
(use-package counsel
  :diminish ivy-mode counsel-mode
  :bind ("C-s" . swiper-isearch)
  :hook ((after-init . ivy-mode)
         (ivy-mode . counsel-mode))
  :init
  (setq ivy-use-selectable-prompt t
        ivy-use-virtual-buffers t
        ivy-height 10
        ivy-fixed-height-minibuffer t
        ivy-count-format "(%d/%d) "
        ivy-on-del-error-function nil
        ivy-initial-inputs-alist nil))

[...]

;; Prescient
(use-package prescient
  :init
  (setq prescient-history-length 200
        prescient-save-file (expand-file-name  "prescient-items" my/user-data-directory))
  :config
  (prescient-persist-mode))

;; Ivy prescient
(use-package ivy-prescient
  :after (counsel prescient)
  :config
  (setq ivy-prescient-retain-classic-highlighting t)
  (ivy-prescient-mode))

;; Company prescient
(use-package company-prescient
  :after (company prescient)
  :config
  (company-prescient-mode))

If you receive the message
Error in post-command-hook (ivy--queue-exhibit): (wrong-type-argument sequencep 199014)

then you can obtain a backtrace by defining the function
(defun force-debug (func &rest args)
  (condition-case e
      (apply func args)
    ((debug error) (signal (car e) (cdr e)))))

and adding it as advice on the offending post-command-hook entry
(advice-add #'ivy--queue-exhibit :around #'force-debug)

Using this technique, I determined the cause of the problem:

I removed support from prescient.el for sorting candidates which are not strings.
Internally, Swiper uses candidates which are not strings (it uses the line numbers).
Although I would argue this is not a great design (candidates are "usually" strings, but not always, and some features won't work if they aren't?), normally it doesn't cause any problem because sorting is not enabled for Swiper.
ivy-prescient.el enables sorting for all commands by default, but it has a blacklist which includes Swiper.
It seems that nowadays C-s is bound to swiper-isearch instead of swiper, and swiper-isearch was not in the blacklist used by ivy-prescient.el.

Labeling the issue to reflect my feelings about having ivy-prescient.el broken yet again by a weird internal quirk of Ivy.

Let me know if this fixes the problem for you.

Fixed it for me! -)
Thank you for your quick reply and greetings from Hamburg Germany!.

Thank you for the explanation. I had copied the config from somewhere that included swiper, swiper-multi on the blacklist and yet I was wondering why my swiper searches were out of order from the buffer I was searching. I prefer the ivy "quirk" in my workflow, so I added swiper-isearch as suggested to the blacklist. I am glad to have prescient working with counsel-M-x though.

Thanks! It is working for me also. Great job 👍

I prefer the ivy "quirk" in my workflow

By "quirk" I don't mean Swiper results not being sorted; that's obviously desired. I mean non-string candidates being used internally in Ivy in clear violation of Ivy's API, just because sorting happens to be disabled for those commands typically. If Ivy didn't do this, then this bug report would have been trivial to sort out, because it would have been obvious what had happened (why aren't the candidates in order? -- must be something wrong with the configuration to disable sorting for Swiper).
Anyway, glad to hear it works for you. Closing.


TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'

I've been getting this error randomly while using RoboBrowser. RoboBrowser installs with requests 2.7.0 but I checked line 166 of current version (2.8) of retry.py and it's the same.
I should add that I made a small modification to a file in RoboBrowser as described here: https://github.com/jmcarp/robobrowser/issues/52#issuecomment-144929550
Traceback (most recent call last):
  File "fetch.py", line 139, in <module>
    go()
  File "fetch.py", line 120, in go
    result = fetch(url)
  File "fetch.py", line 29, in fetch
    browser.open(url)
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\robobrowser\browser.py", line 205, in open
    response = self.session.request(method, url, **self._build_send_args(**kwargs))
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\adapters.py", line 370, in send
    timeout=timeout
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\packages\urllib3\connectionpool.py", line 617, in urlopen
    release_conn=release_conn, **response_kw)
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\packages\urllib3\connectionpool.py", line 598, in urlopen
    retries.sleep()
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\packages\urllib3\util\retry.py", line 175, in sleep
    backoff = self.get_backoff_time()
  File "C:\Users\Vidpe\Desktop\mpb\venv\lib\site-packages\requests\packages\urllib3\util\retry.py", line 166, in get_backoff_time
    backoff_value = self.backoff_factor * (2 ** (self._observed_errors - 1))
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'

So a quick code read suggests that this is impossible using standard requests. The backoff_factor attribute is defaulted to 0 and never assigned to None by any code in requests, as far as I can see.
However, a quick search of RoboBrowser reveals that it sets the backoff_factor, here, and in the default case will set it to None. None is not an allowed value for the backoff factor: this is a bug in RoboBrowser.


Set methods for BaseSolver and BaseObjective

Codecov Report

Merging #8 (c89344f) into main (918c4f0) will decrease coverage by 0.64%.
The diff coverage is 85.54%.

@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
- Coverage   91.57%   90.92%   -0.65%
==========================================
  Files          32       32
  Lines        1424     1455      +31
==========================================
+ Hits         1304     1323      +19
- Misses        120      132      +12

Impacted Files
Coverage Δ

cofi/linear_reg/_python_solver.py
100.00% <ø> (ø)

cofi/cofi_objective/base_objective.py
92.00% <50.00%> (-8.00%)
:arrow_down:

cofi/base_solver.py
81.81% <66.66%> (-18.19%)
:arrow_down:

cofi/optimisers/_petsc_tao.py
65.02% <83.33%> (ø)

cofi/optimisers/_scipy_optimiser.py
97.82% <92.30%> (ø)

cofi/__init__.py
100.00% <100.00%> (ø)

cofi/cofi_objective/examples/exponential_decay.py
100.00% <100.00%> (ø)

cofi/cofi_objective/examples/rfc.py
100.00% <100.00%> (ø)

cofi/cofi_objective/examples/xrt.py
100.00% <100.00%> (ø)

cofi/cofi_objective/tests/test_rfc.py
100.00% <100.00%> (ø)

... and 6 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 918c4f0...c89344f. Read the comment docs.


fix search ch test

test_get_connection() failed. Instead of Zürich Altstetten, Zürich Altstetten, Bahnhof was returned. Not sure if the API has changed or Altstetten as parameter was not precise enough.

the response from the API seems to be the same as before again
E       AssertionError: assert 'Zürich Altstetten' == 'Zürich Altstetten, Bahnhof'
E         - Zürich Altstetten
E         + Zürich Altstetten, Bahnhof
E         ?                  +++++++++


Fixed unicode handling for Python 3.

Hi,
Python 3 does not have unicode() function.
So changed using str() instead of unicode() when Python3.
Best regards,
Signed-off-by: Kouhei Maeda<EMAIL_ADDRESS>

Just a friendly second to this pull request.

Thanks!


Palatial Estate

text: Can be equiped by a minion (e.g. Enkidu) that cannot have or use equipment as it is a location.
link: https://groups.google.com/g/rec.games.trading-cards.jyhad/c/COcJX2hHP-E/m/YLUW8FaGP0kJ

Ruling is on the vampires that have such a restriction.


Feature:

Feature description of Navbar
I want to make sticky navbar in required page to make it attractive.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

I am interested to work on it. Please assign me this issue under gssoc 23

plz assign me this issue to work on it.

assign me this issue to contribute under gssoc '23

Sure go ahead @Krishkumar2005


Daffodil 1923 - Allow use of the same character for escapeBlockEnd and escapeEscapeCharacter

This commit allows the same character(s) to be used for the escapeBlockEnd and escapeEscapeCharacter.
Prior to this the code would first check for the escapeBlockEnd without checking to see if it was also the escapeEscapeCharacter, and would think that it hit the end of the escapeBlock when it was just the escapeEscapeCharacter.

Closing pull request.  I think I confused github by deleting the branch I originally did this work on and then creating a new branch with the same name. Will open new pull request.


Add docker-native module for native docker support in NixOS

Addresses #59 by overlaying legacy iptables on the docker package.

This looks good to me code wise @nzbr but I haven't the means to test this currently - Are you able to test?

Fixes #59

It works (just tested it). I have a patch to rename the old docker option to docker-desktop. GitHub does not allow attaching .patch-Files for some reason, but if you want to apply my commit, just save the code block below to a file and run git am <filename>
From 4017d905d9c787400c1b4c6abb83d787dc0d69fa Mon Sep 17 00:00:00 2001
From: nzbr<EMAIL_ADDRESS>Date: Thu, 21 Apr 2022 10:29:22 +0200
Subject: [PATCH] rename existing docker option to docker-desktop

---
 configuration.nix          | 2 +-
 modules/docker-desktop.nix | 8 ++++++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/configuration.nix b/configuration.nix
index 8ecca30..26f1680 100644
--- a/configuration.nix
+++ b/configuration.nix
@@ -18,7 +18,7 @@ in
     startMenuLaunchers = true;

     # Enable integration with Docker Desktop (needs to be installed)
-    # docker.enable = true;
+    # docker-desktop.enable = true;

     # Enable native Docker support within NixOS
     # docker-native.enable = true;
diff --git a/modules/docker-desktop.nix b/modules/docker-desktop.nix
index 3e0d200..d822526 100644
--- a/modules/docker-desktop.nix
+++ b/modules/docker-desktop.nix
@@ -1,13 +1,17 @@
 { config, lib, pkgs, ... }:
 with builtins; with lib; {

-  options.wsl.docker = with types; {
+  imports = [
+    (mkRenamedOptionModule [ "wsl" "docker" ] [ "wsl" "docker-desktop" ])
+  ];
+
+  options.wsl.docker-desktop = with types; {
     enable = mkEnableOption "Docker Desktop integration";
   };

   config =
     let
-      cfg = config.wsl.docker;
+      cfg = config.wsl.docker-desktop;
     in
     mkIf (config.wsl.enable && cfg.enable) {

--
2.33.1

Renaming the new module to just docker conflicts with the mkRenamedOptionModule in docker-desktop.nix. Also, this would switch anyone who currently uses the docker desktop integration over to docker native, which may not be desired. I prefer we leave docker-desktop and docker-native as two equal options

Thanks, @nzbr, I also noticed that error with mkRenamedOptionModule when I made my push. Sorry about that.
Things should be resolved now, as I reverted to stick with the docker-native option. Let me know if you think there's a better name for this option, as I'm not in love with "docker-native."
I also made some misc. wording changes in configuration.nix to clarify things.

I think docker-native is fine, especially as it clearly differentiates the option from docker-desktop. I'll merge this now, if that's fine with you

I'll merge this now, if that's fine with you

Sounds great to me!


Feat/civ 4739 LD flag for H&L

JIRA link (if applicable)
CIV-4739
Change description
Added method to hide features for Hearing and Listings
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

We need specific toggles for SDO/DJ releases, we can create a generic H&L toggle when we need it in future time

Do not merge this, we don't need this flag anymore, created a new flag


Client API

#1011

Variant A:
query GetUser {
     user {
         ... User
     }
}

Results in:
public interface IUser
{
    .....
}

public class User : IUser
{
   .....
}

Variant B:
query GetUser {
     user {
         ... User
         ... SomethingElse
     }
}

Results in:
public interface IUser
{
    .....
}

public interface ISomethingElse
{
    .....
}

public class UserResponse : IUser, ISomethingElse
{
   .....
}

Variant C:
query GetUser {
     user @type(name: "User") {
         ... User
         ... SomethingElse
     }
}

Results in:
public interface IUser
{
    .....
}

public interface ISomethingElse
{
    .....
}

public class User : IUser, ISomethingElse
{
   .....
}

Case 1: return type is object type only fields
Case 2: return type is object type single fragment
case 3: return type is object type multiple fragments
Case 4: return type is object type fields and fragments
Case 5: return type is interface type only fields
Case 6: return type is interface type single fragment
case 7: return type is interface type multiple fragments
Case 8: return type is interface type fields and fragments
Case 9: return type is union type single fragment
case 10: return type is union type multiple fragments

[ ] Input Serializer List Handling
[ ] Output Deserialize Nested Lists


Bug in XamForms ViewModelViewHost

This line in the XamForms ViewModelViewHost (note: it appears twice in two separate places) causes an exception:
foreach (View v in this.Children) this.Children.Remove(v);

The exception:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
  at System.ThrowHelper.ThrowInvalidOperationException (ExceptionResource resource) [0x00000] in /Users/builder/data/lanes/1926/6916d0e3/source/mono/external/referencesource/mscorlib/system/throwhelper.cs:94
  at System.Collections.Generic.List`1+Enumerator[Xamarin.Forms.Element].MoveNextRare () [0x00016] in /Users/builder/data/lanes/1926/6916d0e3/source/mono/external/referencesource/mscorlib/system/collections/generic/list.cs:1232
  at System.Collections.Generic.List`1+Enumerator[Xamarin.Forms.Element].MoveNext () [0x00050] in /Users/builder/data/lanes/1926/6916d0e3/source/mono/external/referencesource/mscorlib/system/collections/generic/list.cs:1226
  at System.Linq.Enumerable+<CreateWhereIterator>c__Iterator1E`1[Xamarin.Forms.Element].MoveNext () [0x0006f] in //Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/src/mono/mcs/class/System.Core/System.Linq/Enumerable.cs:3115
  at System.Linq.Enumerable+<CreateOfTypeIterator>c__IteratorC`1[Xamarin.Forms.View].MoveNext () [0x00069] in //Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/src/mono/mcs/class/System.Core/System.Linq/Enumerable.cs:2154
  at ReactiveUI.XamForms.ViewModelViewHost+<ViewModelViewHost>c__AnonStorey0.<>m__4 (<>__AnonType0`2 x) [0x00131] in /Users/kent/Repository/ReactiveUI/ReactiveUI.XamForms/XamForms/ViewModelViewHost.cs:88
<snip>

I replaced with this and it worked (though I haven't taken the time to verify whether things could be better in general):
while (this.Children.Count > 0)
{
    this.Children.RemoveAt(0);
}

I also tried:
this.Children.Clear();

And that also worked. However, I suspect children were being removed one at a time for change notification reasons. Again, haven't bothered to verify at this point.
And another thing, the as View cast towards the end of the method should really be a regular cast. Otherwise one can get a NRE instead of a cast exception. The latter is slightly more decipherable, but even better would be to remove the need for the cast entirely (if possible).

A quick solution that won't modify whatever the intended behavior was would be a call to IEnumerable.ToArray on this.Children inside the loop declaration; C# doesn't seem to offer a great solution for mid-iteration removal, unlike Java.

Fixed by #919


Delta updates not working with @electron-forge/maker-squirrel

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
6.4.2
Electron version
27.1.0
Operating system
Windows 10
Last known working Electron Forge version
6.4.2
Expected behavior
When I provide a url where the generated files are (RELEASES, .exe and .nupkg) to the remoteReleases option, 'electron-forge make' should produce a delta file as well (from what I gather? there is little to no information about this online as far as I can tell)
Actual behavior
No delta file created
Steps to reproduce
add this to the config and run electron-forge make, and see if a delta file is generated
name: '@electron-forge/maker-squirrel',
config: {
remoteReleases: 'url_to_previous_build_files'
}
Note: I have also tried including noDelta: false to the config but it does not make a difference. Also, the url to the files is correct, it is the same url used for the autoUpdater, and the autoUpdater works
Additional information
No response

I managed to make it work, it was my fault, I apologize for cluttering up the issues section

How did you manage to make it work? I am running into the same issue.

If it is your first time running electron-forge publish to upload to your update server, delta will not be generated since there is no previous build to compare and diff. Set noDelta: true on first publish then subsequent publish with noDelta: false worked out for me.

Thank you for that answer


Added DeleteRepositorySubscription and ListWatched funcs

@0xf8f8ff can you take a look and see if you can integrate this, so that we can avoid subscriptions to everything... I have tested that this func works to remove my current subscriptions, but it would be nice to integrate it with the user/group creation process. Alternatively, if we can create user/group repos etc without subscription initially, perhaps we don't even need these funcs in the scm package.

But wouldn't integrating these methods with user, group, or repo creation process only remove subscriptions for the currently authorized user (will it just be the Autograder user in our case)? The point is to disable subscriptions/notifications coming from all the student and group repos for all organization owners, am I correct?

I think so.

Maybe this can be done more simply at the organization configuration level?

Maybe this can be done more simply at the organization configuration level?

This is what I was trying to find a way doing, but it looks like it is only allowed to change your own subscription/notification settings. Still looking for a possible solution to automate it for every organization owner at once, but alternatively we could just add some kind of a button ("Unsubscribe" or something) to the course UI for teachers that would remove all repo subscriptions or notifications for the current user.

@0xf8f8ff did you find a proper solution to this problem? I would prefer to close this PR.

I think the solution to this problem is simply to follow these instructions. I'll instead update some markdown file with the relevant information, and when I know that this stops the notifications, I'll close this PR.

I think the solution to this problem is simply to follow these instructions. I'll instead update some markdown file with the relevant information, and when I know that this stops the notifications, I'll close this PR.

Closing since this seems to have been fixed after following the instructions that I added to a new notifications section in doc/teacher.md.

Closing since this seems to have been fixed after following the instructions that I added to a new notifications section in doc/teacher.md.


[Chore]: Move pod_webhook and build_pod_webhook into korifi-controllers

Background
To ease implementation of alternative build and run reconcilers, we want to move as much logic as possible out of them and into the root korifi-controllers. Both the statefulset-runner/api/v1/pod_webhook.go and kpack-image-builder/api/v1alpha1/build_pod_webhook.go contain behavior that will be potentially be useful/required in any build or run reconciler. Furthermore, these webhooks only run on resources with a label in the korifi.cloudfoundry.org/ prefix, so they are safe to have installed cluster-wide.
Action to take
Take the webhooks in the following locations and move them into the korifi/controllers sub-project:

statefulset-runner/api/v1/pod_webhook.go
kpack-image-builder/api/v1alpha1/build_pod_webhook.go

After the move, ensure that these two webhooks behave as they did before, and that you are still able to push an app and see the health of all of its instances.
Impact
This chore will simplify the work of implementing alternative build and run reconcilers.
Dev Notes
No response

I think these responsibilities belong to the builders and runners, as only the specific implementation will now how these pods have been created, if any (e.g. pods might be created on different clusters). For example, STSPodDefaulter relies on the fact that pods have been created by a StatefulSet so that it can extract the instance index from the name.

Fair enough. I'll close this issue.


Translate /docs/concepts/workloads/controllers/job/ into Japanese

What this PR does / why we need it:
This page has not been translated.
Original file is as follows:
https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/workloads/controllers/job.md
Which issue(s) this PR fixes:
Close #21007 .
Special notes for your reviewer:
None.

/assign @nasa9084

/approve
/cc @bells17

/lgtm


[REQ] support other tools in installToolsCmd for rpm tooling image

What kind of request is this?
None
What is your request or suggestion?
Would it be possible to support other tools (yum, microdnf etc) for installing busybox to our tooling image in rpm? Currently, we use tdnf, but if the user changes the tooling image via source policies there is a chance tdnf is not supported in that image.
Are you willing to submit PRs to contribute to this feature request?

[ ] Yes, I am willing to implement it.

Hey is this issue still open?If so,  I would like to work on it

Let me know if any separate changes are to be made for this issue or if it is resolved from the above PR as stated in #652


⚠ Processors has degraded performance

In b322ddb, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 46 ms

Resolved: Processors performance has improved in c6d1933.


Include Sentry SDK in staging envs

This enables a feature called Session Replay, which in theory should give us a blow-by-blow list of user interactions that lead to an error. This could be useful for debugging.
This doesn't affect development/test/production, only the staging environments.

Closing this as while it works, it's only valid for JavaScript/frontend errors, and since we use progressive enhancement, those are rarely ever show stopping. It doesn't do anything for 500s.


Lord Of Apocalypse DEMO [PCSG90001]

App summary

App name: LORD of APOCALYPSE ロードの誘い
App serial: PCSG90001
App version: 1.00

Vita3K summary

Version: v0.1.6
Build number: 3031
Commit hash: https://github.com/vita3k/vita3k/commit/4e9fceeb
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: User 01
OS: Windows 10
CPU: AMD Ryzen 5 2600 Six-Core Processor
GPU: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2
RAM: 16 GB

Issues

Crashes on boot
Screenshots
Log
vita3k.log
Recommended labels

Ingame
Graphics bug

@othmanead seems the bot moved it back to broken. Needs fixing


Luakit Architecture

I fixed the bug which prevented to run Luakit on Macos 10.15.
Luakit runs now fine on

ios,
android
and macos.

I reorganised Luakit to be compliant with the architecture specifications

Now the third-party modules do not depend any more on Luakit. This is specially true with Lua-5.1.5.
The Luakit engine does not depend anymore on Luakit Extensions

Luakit Extensions are now real "Luakit Plugins". They are optionals. For example the project "notificationTest" is not linked any more with HTTP, curl and OpenSSL.
The user has to specify which Extension (Luakit Plugin) he wants his application to be linked with.
extern class LuakitExtension TheThreadExtension;
extern class LuakitExtension TheTimerExtension;

extern class LuakitExtension* ExtensionsList [] =
{
    &TheThreadExtension,
    &TheTimerExtension,
	0
};

The user can also add his own Extension (Luakit Plugin) without interfere with Luakit itself.

@Larpoux is your PR getting merged into master?


pmap: calculate & show total

This PR calculates the total and shows it on the latest line when running cargo run pmap <PID>.

Great job, thanks a lot!


m2m relations cause error while trying to update a model object

reproduce steps:

create two models with m2m relation with one another
include a resource for each of them
go to change view for any of them

exception:
 File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/uvicorn/protocols/http/httptools_impl.py", line 375, in run_asgi
    result = await app(self.scope, self.receive, self.send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/uvicorn/middleware/proxy_headers.py", line 75, in __call__
    return await self.app(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi/applications.py", line 208, in __call__
    await super().__call__(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/applications.py", line 112, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/errors.py", line 181, in __call__
    raise exc from None
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/errors.py", line 159, in __call__
    await self.app(scope, receive, _send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/cors.py", line 78, in __call__
    await self.app(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/exceptions.py", line 82, in __call__
    raise exc from None
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/exceptions.py", line 71, in __call__
    await self.app(scope, receive, sender)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/routing.py", line 580, in __call__
    await route.handle(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/routing.py", line 390, in handle
    await self.app(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi/applications.py", line 208, in __call__
    await super().__call__(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/applications.py", line 112, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/errors.py", line 181, in __call__
    raise exc from None
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/errors.py", line 159, in __call__
    await self.app(scope, receive, _send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/base.py", line 25, in __call__
    response = await self.dispatch_func(request, self.call_next)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi_admin/providers/login.py", line 135, in authenticate
    response = await call_next(request)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/base.py", line 45, in call_next
    task.result()
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/base.py", line 38, in coro
    await self.app(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/base.py", line 25, in __call__
    response = await self.dispatch_func(request, self.call_next)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi_admin/middlewares.py", line 19, in language_processor
    response = await call_next(request)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/base.py", line 45, in call_next
    task.result()
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/middleware/base.py", line 38, in coro
    await self.app(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/exceptions.py", line 82, in __call__
    raise exc from None
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/exceptions.py", line 71, in __call__
    await self.app(scope, receive, sender)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/routing.py", line 580, in __call__
    await route.handle(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/routing.py", line 241, in handle
    await self.app(scope, receive, send)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/starlette/routing.py", line 52, in app
    response = await func(request)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi/routing.py", line 219, in app
    raw_response = await run_endpoint_function(
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi/routing.py", line 152, in run_endpoint_function
    return await dependant.call(**values)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi_admin/routes/resources.py", line 145, in update_view
    inputs = await model_resource.get_inputs(request, obj)
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi_admin/resources.py", line 137, in get_inputs
    ret.append(await input_.render(request, getattr(obj, name, None)))
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/fastapi_admin/widgets/inputs.py", line 137, in render
    selected = list(map(lambda x: x.pk, value.related_objects if value else []))
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/tortoise/fields/relational.py", line 108, in __bool__
    self._raise_if_not_fetched()
  File "/home/godspell/.local/share/virtualenvs/profile_page_backend-4_NPa7oA/lib/python3.8/site-packages/tortoise/fields/relational.py", line 163, in _raise_if_not_fetched
    raise NoValuesFetched(
tortoise.exceptions.NoValuesFetched: No values were fetched for this relation, first use .fetch_related()

@long2ice this solution fixes the issue. Is there a chance you would include it in the following releases?


[QUESTION] Is it possible to disable resize and set expanded?

Hi, thanks for the wonderful package. I'd like to use it with a dynamic height. is it possible to set expanded and disable the resize bar?

Hi, were you able to solve this? I also don't like that annoying resizable feature.
Thank you


Remove hardcoded version

Issue: https://github.com/stolostron/backlog/issues/21972
Controller will read version from OPERATOR_VERSION environment variable or
panic if variable is missing. Replaced various locations where the version
was duplicated so it won't have to be maintained.
Signed-off-by: Jakob Gray<EMAIL_ADDRESS>

/lgtm

/unhold


Create clustering templates for active standby

@szakeri
What's this change do?
We are creating two new Heat templates here. One to create clusterable VEs (using a Heat ResourceGroup), and the other to build the cluster.
Any background context?
These templates should not be merged until clustering is available in the 0.1 branch of the f5-sdk. But we are still able to test these templates by pip install (from git) the development branch of f5-sdk.
The important thing to note is that the clustering test cannot be run without having two pre-existing devices ready to cluster. I think we could make this one template, but then we'd have to create a mechanism in Heat to determine when the devices were properly ready to cluster. This is not a straightforward task without booting some sentinel server that watches the devices and monitors a set of REST uris for the values we are looking for once the startup script has completed.
Where should the reviewer start?
Start at the functional test for ve/resource_group/test_f5_ve_resource_group.py. This creates two clusterable devices. Then move on to the clustering templates.

In resource_group templates remove reference to FW. It means nothing!

Closing, as this is addressed by PR #83


🧑💻 : SCROLL TOP BUTTON

:red_circle: Title : ADD A SCROLL TO TOP BUTTON
:red_circle: Enhancement Aim :ADDING A NEW FEATURE
Screenshots 📷

✅ Details to Include When Taking the Issue:
Name :Shriya dindi
Participant Role (Specify the Open Source Program name, e.g., GSSOC, Hacktoberfest, etc.):
GSSOC, Hacktoberfest

Happy Contributing! 🚀
Wishing you all the best on your open source journey. Enjoy! 😎

it is already there


Show correct error on wrong DNS response.

While #632 was not a direct problem with Prometheus, the wrong error logging was.

:+1:


Update toc.yml

Added a link to Knowledge Base.

@zhouwangzw, Would you review the proposed changes? Thanks.

#sign-off