python312Packages.scikit-hep-testdata: 0.4.48 -> 0.5.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.scikit-hep-testdata is: Common package to provide example files (e.g., ROOT) for testing and developing packages against
meta.homepage for python312Packages.scikit-hep-testdata is: https://github.com/scikit-hep/scikit-hep-testdata
meta.changelog for python312Packages.scikit-hep-testdata is: https://github.com/scikit-hep/scikit-hep-testdata/releases/tag/v0.5.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.5.0 with grep in /nix/store/bz36wsswgzbdsvvhqkpybvf0x79nzxlf-python3.12-scikit-hep-testdata-0.5.0
found 0.5.0 in filename of file in /nix/store/bz36wsswgzbdsvvhqkpybvf0x79nzxlf-python3.12-scikit-hep-testdata-0.5.0

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

13 total rebuild path(s)

13 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.coffea
python311Packages.dask-awkward
python311Packages.mplhep
python311Packages.scikit-hep-testdata
python311Packages.uproot
python311Packages.vector
python312Packages.coffea
python312Packages.dask-awkward
python312Packages.mplhep
python312Packages.scikit-hep-testdata
python312Packages.uproot
python312Packages.vector

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/bz36wsswgzbdsvvhqkpybvf0x79nzxlf-python3.12-scikit-hep-testdata-0.5.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/093c965dfd84e1a76004d6bf73cece16dd24c075#python312Packages.scikit-hep-testdata

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/bz36wsswgzbdsvvhqkpybvf0x79nzxlf-python3.12-scikit-hep-testdata-0.5.0
ls -la /nix/store/bz36wsswgzbdsvvhqkpybvf0x79nzxlf-python3.12-scikit-hep-testdata-0.5.0/bin

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

x86_64-linux

:x: 20 packages failed to build:

python311Packages.coffea
python311Packages.coffea.dist
python311Packages.dask-awkward
python311Packages.dask-awkward.dist
python311Packages.mplhep
python311Packages.mplhep.dist
python311Packages.uproot
python311Packages.uproot.dist
python311Packages.vector
python311Packages.vector.dist
python312Packages.coffea
python312Packages.coffea.dist
python312Packages.dask-awkward
python312Packages.dask-awkward.dist
python312Packages.mplhep
python312Packages.mplhep.dist
python312Packages.uproot
python312Packages.uproot.dist
python312Packages.vector
python312Packages.vector.dist

:white_check_mark: 4 packages built:

python311Packages.scikit-hep-testdata
python311Packages.scikit-hep-testdata.dist
python312Packages.scikit-hep-testdata
python312Packages.scikit-hep-testdata.dist

Maintainer pings
cc @veprbl for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@GrahamcOfBorg build python3Packages.uproot

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.scikit-hep-testdata is: Common package to provide example files (e.g., ROOT) for testing and developing packages against
meta.homepage for python312Packages.scikit-hep-testdata is: https://github.com/scikit-hep/scikit-hep-testdata
meta.changelog for python312Packages.scikit-hep-testdata is: https://github.com/scikit-hep/scikit-hep-testdata/releases/tag/v0.5.1
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.5.1 with grep in /nix/store/51a8h6xk8g2nidlv4ilpzckik31cav8f-python3.12-scikit-hep-testdata-0.5.1
found 0.5.1 in filename of file in /nix/store/51a8h6xk8g2nidlv4ilpzckik31cav8f-python3.12-scikit-hep-testdata-0.5.1

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

13 total rebuild path(s)

13 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.coffea
python311Packages.dask-awkward
python311Packages.mplhep
python311Packages.scikit-hep-testdata
python311Packages.uproot
python311Packages.vector
python312Packages.coffea
python312Packages.dask-awkward
python312Packages.mplhep
python312Packages.scikit-hep-testdata
python312Packages.uproot
python312Packages.vector

Instructions to test this update (click to expand)

Either download from the cache:
nix-store -r /nix/store/51a8h6xk8g2nidlv4ilpzckik31cav8f-python3.12-scikit-hep-testdata-0.5.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/5c8647a27d0adfc22a60dc17080ea878b210173d#python312Packages.scikit-hep-testdata

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/51a8h6xk8g2nidlv4ilpzckik31cav8f-python3.12-scikit-hep-testdata-0.5.1
ls -la /nix/store/51a8h6xk8g2nidlv4ilpzckik31cav8f-python3.12-scikit-hep-testdata-0.5.1/bin

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

x86_64-linux

:x: 2 packages failed to build:

python311Packages.coffea
python311Packages.coffea.dist

:white_check_mark: 22 packages built:

python311Packages.dask-awkward
python311Packages.dask-awkward.dist
python311Packages.mplhep
python311Packages.mplhep.dist
python311Packages.scikit-hep-testdata
python311Packages.scikit-hep-testdata.dist
python311Packages.uproot
python311Packages.uproot.dist
python311Packages.vector
python311Packages.vector.dist
python312Packages.coffea
python312Packages.coffea.dist
python312Packages.dask-awkward
python312Packages.dask-awkward.dist
python312Packages.mplhep
python312Packages.mplhep.dist
python312Packages.scikit-hep-testdata
python312Packages.scikit-hep-testdata.dist
python312Packages.uproot
python312Packages.uproot.dist
python312Packages.vector
python312Packages.vector.dist

Maintainer pings
cc @veprbl for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.


create variables inside Variable groups using VSTS Cli

Any way to create/update/list variables inside Variable groups using VSTS Cli?
Thank you for your feedback!
The issues in this repo are for documentation feedback.
If you are submitting your documentation feedback issue directly through GitHub, please provide the URL of the article so we can route the feedback to the correct author.
Please report Azure DevOps or TFS software bugs, feedback, or questions in the Azure DevOps Developer Community.

@abhiramani-iptiq Thank you for your feedback. I am forwarding this to the author of some of the variables articles to see if they can help.

Thank you for your feedback. I have passed this on to the product team for advice.

Please accept our apologies for the delay in getting to this issue. It looks like you were working through an issue with your scenario or implementation, rather than an issue with the documentation. Here are a few options where you might consider asking your question in the future:

Azure DevOps on Stack Overflow
Azure DevOps Support Bot


Error in Nuscenes data preprocess

When I run pointpillars or cbgs on nuscenes, I met following mistakes:
It happens at data preprocess, seems no point be sampled. If anyone meet this error before??
Original Traceback (most recent call last):
File "/home/xuhang/anaconda3/envs/pointpillars/lib/python3.6/site-packages/torch/utils/data/_utils/worker.py", line 178, in _worker_loop
data = fetcher.fetch(index)
File "/home/xuhang/anaconda3/envs/pointpillars/lib/python3.6/site-packages/torch/utils/data/_utils/fetch.py", line 44, in fetch
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/home/xuhang/anaconda3/envs/pointpillars/lib/python3.6/site-packages/torch/utils/data/_utils/fetch.py", line 44, in
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/home/xuhang/green_zone_code/Det3D-master/det3d/datasets/nuscenes/nuscenes.py", line 177, in getitem
return self.get_sensor_data(idx)
File "/home/xuhang/green_zone_code/Det3D-master/det3d/datasets/nuscenes/nuscenes.py", line 172, in get_sensor_data
data, _ = self.pipeline(res, info)
File "/home/xuhang/green_zone_code/Det3D-master/det3d/datasets/pipelines/compose.py", line 23, in call
res, info = t(res, info)
File "/home/xuhang/green_zone_code/Det3D-master/det3d/datasets/pipelines/preprocess.py", line 160, in call
calib=calib,
File "/home/xuhang/green_zone_code/Det3D-master/det3d/core/sampler/sample_ops.py", line 220, in sample_all
"points": np.concatenate(s_points_list, axis=0),
ValueError: need at least one array to concatenate

please insert a breakpoint to see what's going wrong at line 220.

Is it resolved? I also have this problem.

same problem, any solution?

Has anyone solved it? I had the same problem


Render was "Killed"

It reaches to 100% then kills everytime I try to render my multiview scene

hello there :)
did you find out what cause the problem ???


Add border for floaterm triggered by open_floaterm?

lua require('lspsaga.floaterm').open_float_terminal('',1 -- mean lspsaga border_style)

Hi @glepnir
There is still no border after setting the second argument.

hmm  i found there has a problem so I removed window height and width of border . fixed it later.

Thank you @glepnir


Provisioning of second Gateway fails

Current Behavior
We want to deploy two Gateways using the Gateway operator. While the first gateway is programmed successfully, the second gateway never comes up and seems to be stuck somewhere.
Expected Behavior
Both Gateways are programmed successfully.
Steps To Reproduce
We are following the Getting started documentation: https://docs.konghq.com/gateway-operator/latest/get-started/kic/install/
More precisely, this is the steps we run and which can be used to reproduce the problem:
helm repo add kong https://charts.konghq.com
helm repo update kong
helm upgrade --install kgo kong/gateway-operator -n kong-system --create-namespace --set image.tag=1.2

echo '
kind: GatewayConfiguration
apiVersion: gateway-operator.konghq.com/v1beta1
metadata:
  name: kong
  namespace: default
spec:
  dataPlaneOptions:
    deployment:
      podTemplateSpec:
        spec:
          containers:
          - name: proxy
            image: kong:3.6.1
            readinessProbe:
              initialDelaySeconds: 1
              periodSeconds: 1
  controlPlaneOptions:
    deployment:
      podTemplateSpec:
        spec:
          containers:
          - name: controller
            image: kong/kubernetes-ingress-controller:3.1.3
            env:
            - name: CONTROLLER_LOG_LEVEL
              value: debug
---
kind: GatewayClass
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: kong
spec:
  controllerName: konghq.com/gateway-operator
  parametersRef:
    group: gateway-operator.konghq.com
    kind: GatewayConfiguration
    name: kong
    namespace: default
' | kubectl apply -f -

Then, we create the first gateway:
echo '
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: gw1
  namespace: default
spec:
  gatewayClassName: kong
  listeners:
    - name: http
      protocol: HTTP
      port: 80
' | kubectl apply -f -

This gateway comes up successfully:
k get gateway -n default | grep gw1
gw1               kong     <IP_ADDRESS>   True         80s

k get all -n default | grep gw1
pod/controlplane-gw1-75vrb-cfdmz-6f4ff8fff7-t2hjf   1/1     Running   0          65s
pod/dataplane-gw1-fbh78-2nxfw-765b85d8bb-km4mv      1/1     Running   0          65s
service/controlplane-webhook-gw1-75vrb-m4nww   ClusterIP      <IP_ADDRESS>   <none>           8080/TCP                     65s
service/dataplane-admin-gw1-fbh78-zvvn9        ClusterIP      None           <none>           8444/TCP                     66s
service/dataplane-ingress-gw1-fbh78-2j498      LoadBalancer   <IP_ADDRESS>   <IP_ADDRESS>   80:32347/TCP                 66s
deployment.apps/controlplane-gw1-75vrb-cfdmz   1/1     1            1           65s
deployment.apps/dataplane-gw1-fbh78-2nxfw      1/1     1            1           65s
replicaset.apps/controlplane-gw1-75vrb-cfdmz-6f4ff8fff7   1         1         1       65s
replicaset.apps/dataplane-gw1-fbh78-2nxfw-765b85d8bb      1         1         1       65s
controlplane.gateway-operator.konghq.com/gw1-75vrb   True    True
dataplane.gateway-operator.konghq.com/gw1-fbh78   True

logs:
k logs kgo-gateway-operator-controller-manager-667f9444ff-k99c7 -n kong-system
...
{"level":"info","ts":"2024-04-24T08:35:49Z","logger":"controlplane","msg":"gateway accepted","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw1","namespace":"default"},"namespace":"default","name":"gw1","reconcileID":"4b18c160-3257-4605-99ff-1b4a32d30ec4","namespace":"default","name":"gw1"}
{"level":"info","ts":"2024-04-24T08:35:49Z","logger":"controlplane","msg":"no ingress services found for dataplane","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw1","namespace":"default"},"namespace":"default","name":"gw1","reconcileID":"e792c4ad-4a4f-48e9-8f79-9370ef758f68","namespace":"default","name":"gw1","dataplane":{"name":"gw1-fbh78","namespace":"default"}}
{"level":"info","ts":"2024-04-24T08:35:50Z","logger":"controlplane","msg":"no ingress services found for dataplane","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw1","namespace":"default"},"namespace":"default","name":"gw1","reconcileID":"55962592-cc0d-46f4-8464-4f297773a68c","namespace":"default","name":"gw1","dataplane":{"name":"gw1-fbh78","namespace":"default"}}

Then, we create the second gateway:
echo '
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: gw2
  namespace: default
spec:
  gatewayClassName: kong
  listeners:
    - name: http
      protocol: HTTP
      port: 80
' | kubectl apply -f -

However, this gateway never comes up:
k get gateway -n default | grep gw2
gw2               kong                      False        45s

The data plane and control plane object seem to be not provisioned properly:
k get all -n default | grep gw2
pod/dataplane-gw2-n5rw5-l6fn2-664fb588d5-bk2kt      0/1     Running   0          90s
service/controlplane-webhook-gw2-l4fh4-bx7f7   ClusterIP      <IP_ADDRESS>   <none>           8080/TCP                     89s
service/dataplane-admin-gw2-n5rw5-fjwzn        ClusterIP      None            <none>           8444/TCP                     91s
service/dataplane-ingress-gw2-n5rw5-j7bdx      LoadBalancer   <IP_ADDRESS>     <IP_ADDRESS>   80:30843/TCP                 90s
deployment.apps/dataplane-gw2-n5rw5-l6fn2      0/1     1            0           90s
replicaset.apps/dataplane-gw2-n5rw5-l6fn2-664fb588d5      1         1         0       90s
controlplane.gateway-operator.konghq.com/gw2-l4fh4   False   False
dataplane.gateway-operator.konghq.com/gw2-n5rw5   False

k get dataplane gw2-n5rw5 -o yaml -n default
apiVersion: gateway-operator.konghq.com/v1beta1
kind: DataPlane
metadata:
  creationTimestamp: "2024-04-24T08:38:29Z"
  generateName: gw2-
  generation: 1
  labels:
    gateway-operator.konghq.com/managed-by: gateway
  name: gw2-n5rw5
  namespace: default
  ownerReferences:
  - apiVersion: gateway.networking.k8s.io/v1
    controller: true
    kind: Gateway
    name: gw2
    uid: 82c7fc8d-83a1-46ee-9539-0d56c639db5c
  resourceVersion: "13624119"
  uid: 7f7f4e07-0512-49b1-bb5b-673339e2a531
spec:
  deployment:
    podTemplateSpec:
      metadata: {}
      spec:
        containers:
        - image: kong:3.6.1
          name: proxy
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /status/ready
              port: 8100
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          resources: {}
    replicas: 1
  network:
    services:
      ingress:
        ports:
        - name: http
          port: 80
          targetPort: 8000
        type: LoadBalancer
status:
  addresses:
  - sourceType: PublicLoadBalancer
    type: IPAddress
    value: <IP_ADDRESS>
  - sourceType: PrivateIP
    type: IPAddress
    value: <IP_ADDRESS>
  conditions:
  - lastTransitionTime: "2024-04-24T08:38:30Z"
    message: 'Waiting for the resource to become ready: Deployment dataplane-gw2-n5rw5-l6fn2
      is not ready yet'
    observedGeneration: 1
    reason: WaitingToBecomeReady
    status: "False"
    type: Ready
  readyReplicas: 0
  replicas: 1
  selector: 49dbbe2d-a081-4fcb-86f6-3ba3dc967c13
  service: dataplane-ingress-gw2-n5rw5-j7bdx

k get controlplane gw2-l4fh4 -n default -o yaml
apiVersion: gateway-operator.konghq.com/v1beta1
kind: ControlPlane
metadata:
  creationTimestamp: "2024-04-24T08:38:30Z"
  finalizers:
  - gateway-operator.konghq.com/cleanup-clusterrole
  - gateway-operator.konghq.com/cleanup-clusterrolebinding
  - gateway-operator.konghq.com/cleanup-validatingwebhookconfiguration
  generateName: gw2-
  generation: 2
  labels:
    gateway-operator.konghq.com/managed-by: gateway
  name: gw2-l4fh4
  namespace: default
  ownerReferences:
  - apiVersion: gateway.networking.k8s.io/v1
    controller: true
    kind: Gateway
    name: gw2
    uid: 82c7fc8d-83a1-46ee-9539-0d56c639db5c
  resourceVersion: "13623955"
  uid: fa12ae25-67de-453e-8b34-f9bf1bd7a5c6
spec:
  dataplane: gw2-n5rw5
  deployment:
    podTemplateSpec:
      metadata: {}
      spec:
        containers:
        - env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
          - name: CONTROLLER_ANONYMOUS_REPORTS
            value: "true"
          - name: POD_NAME
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.name
          - name: CONTROLLER_GATEWAY_API_CONTROLLER_NAME
            value: konghq.com/gateway-operator
          - name: CONTROLLER_PUBLISH_SERVICE
            value: default/dataplane-ingress-gw2-n5rw5-j7bdx
          - name: CONTROLLER_KONG_ADMIN_SVC
            value: default/dataplane-admin-gw2-n5rw5-fjwzn
          - name: CONTROLLER_KONG_ADMIN_SVC_PORT_NAMES
            value: admin
          - name: CONTROLLER_GATEWAY_DISCOVERY_DNS_STRATEGY
            value: service
          - name: CONTROLLER_KONG_ADMIN_INIT_RETRY_DELAY
            value: 5s
          - name: CONTROLLER_GATEWAY_TO_RECONCILE
            value: default/gw2
          - name: CONTROLLER_KONG_ADMIN_TLS_CLIENT_CERT_FILE
            value: /var/cluster-certificate/tls.crt
          - name: CONTROLLER_KONG_ADMIN_TLS_CLIENT_KEY_FILE
            value: /var/cluster-certificate/tls.key
          - name: CONTROLLER_KONG_ADMIN_CA_CERT_FILE
            value: /var/cluster-certificate/ca.crt
          - name: CONTROLLER_ELECTION_ID
            value: gw2-l4fh4.konghq.com
          - name: CONTROLLER_ADMISSION_WEBHOOK_LISTEN
            value: <IP_ADDRESS>:8080
          image: kong/kubernetes-ingress-controller:3.1.2
          imagePullPolicy: IfNotPresent
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          name: controller
          ports:
          - containerPort: 10254
            name: health
            protocol: TCP
          - containerPort: 8080
            name: webhook
            protocol: TCP
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /readyz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 5
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          resources:
            limits:
              cpu: 200m
              memory: 100Mi
            requests:
              cpu: 100m
              memory: 20Mi
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          volumeMounts:
          - mountPath: /var/cluster-certificate
            name: cluster-certificate
            readOnly: true
          - mountPath: /admission-webhook
            name: admission-webhook-certificate
            readOnly: true
    replicas: 1
  gatewayClass: kong
status:
  conditions:
  - lastTransitionTime: "2024-04-24T08:38:30Z"
    message: There are other conditions that are not yet ready
    observedGeneration: 2
    reason: DependenciesNotReady
    status: "False"
    type: Ready
  - lastTransitionTime: "2024-04-24T08:38:30Z"
    message: ControlPlane resource is scheduled for provisioning
    reason: PodsNotReady
    status: "False"
    type: Provisioned

The logs show the following:
k logs kgo-gateway-operator-controller-manager-667f9444ff-k99c7 -n kong-system | grep gw2
{"level":"info","ts":"2024-04-24T08:38:29Z","logger":"controlplane","msg":"gateway accepted","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw2","namespace":"default"},"namespace":"default","name":"gw2","reconcileID":"28ef9bd4-bddf-414a-afa8-de4157339c66","namespace":"default","name":"gw2"}
{"level":"info","ts":"2024-04-24T08:38:30Z","logger":"controlplane","msg":"no ingress services found for dataplane","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw2","namespace":"default"},"namespace":"default","name":"gw2","reconcileID":"f37d692d-e50b-4551-9a6b-a7d31d413244","namespace":"default","name":"gw2","dataplane":{"name":"gw2-n5rw5","namespace":"default"}}
{"level":"info","ts":"2024-04-24T08:38:30Z","logger":"controlplane","msg":"no ingress services found for dataplane","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw2","namespace":"default"},"namespace":"default","name":"gw2","reconcileID":"1dc9e337-2460-4e52-b85a-75b79416f3a6","namespace":"default","name":"gw2","dataplane":{"name":"gw2-n5rw5","namespace":"default"}}

It complains about not finding any ingress services, but it is clearly there - maybe some bug in the operator?
k get svc -n default | grep gw2 | grep ingress
dataplane-ingress-gw2-n5rw5-j7bdx      LoadBalancer   <IP_ADDRESS>     <IP_ADDRESS>   80:30843/TCP                 5m34s

Operator Version
Tried with image.tag=1.2 (as described in the getting started) and also tried the latest --set image.tag=1.2.3 --set image.repository=docker.io/kong/gateway-operator-oss but the issue remains the same.
kubectl version
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.3

We are running on AKS 1.28 with Cilium (which also provides a GW, maybe that interferes).

Hi @MatthiasWinzeler,
I've just tried to reproduce it and I couldn't with 1.2.3 using your GatewayClass and GatewayConfiguration with 2 Gateways.
echo '
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: gw1
  namespace: default
spec:
  gatewayClassName: kong
  listeners:
    - name: http
      protocol: HTTP
      port: 80
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: gw2
  namespace: default
spec:
  gatewayClassName: kong
  listeners:
    - name: http
      protocol: HTTP
      port: 80
' | kubectl apply -f -

One thing that stood out to me is that you define kong/kubernetes-ingress-controller:3.1.3 in GatewayConfiguration but the Gateway is running kong/kubernetes-ingress-controller:3.1.2 which for me didn't occur ( I did get the expected image ).
Can you try looking into DataPlane, ControlPlane and Gateway status fields and see if there's anything there that could suggest a culprit? You can use this guide https://docs.konghq.com/gateway-operator/latest/production/monitoring/status/gateway/.
Please also include KGO debug logs ( you can enable those by setting --set env.zap_log_level=2 or --set env.zap_log_level=debug, for latter is less verbose ).

We are running on AKS 1.28 with Cilium (which also provides a GW, maybe that interferes).

This shouldn't be relevant assuming that Cillium's controllers respect the GatewayClass's controllerName field.

@pmalek Thanks for getting back to me!

One thing that stood out to me is that you define kong/kubernetes-ingress-controller:3.1.3 in GatewayConfiguration but the Gateway is running kong/kubernetes-ingress-controller:3.1.2 which for me didn't occur ( I did get the expected image ).

You're right - in my debugging steps afterwards, I actually removed the whole controlPlaneOptions part, which causes it to fall back to 3.1.2, but the issue remains the same. I think that should not matter, right?
I turned on debug logs and I realized that the control plane deployment is actually created, just way later. Sometimes it takes around 20 minutes, sometimes a little bit less. I captured the logs of a try that takes around 13 minutes - I put the whole log here: https://gist.github.com/MatthiasWinzeler/69469600275264989ddc7f3db4e10b5a
What's interesting is one place where the operator seems to be stuck:
kgo-gateway-operator-controller-manager-89d754fc5-w6sdm manager {"level":"debug","ts":"2024-04-24T15:22:12Z","logger":"controlplane.dataplaneProvisioning","msg":"dataplane config updated","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw2","namespace":"default"},"namespace":"default","name":"gw2","reconcileID":"fbc7449a-b391-4039-b1c1-f816752b2e72","namespace":"default","name":"gw2"}
...
kgo-gateway-operator-controller-manager-89d754fc5-w6sdm manager {"level":"debug","ts":"2024-04-24T15:30:54Z","logger":"controlplane","msg":"deployment for ControlPlane created","controller":"controlplane","controllerGroup":"gateway-operator.konghq.com","controllerKind":"ControlPlane","ControlPlane":{"name":"gw2-b8z9d","namespace":"default"},"namespace":"default","name":"gw2-b8z9d","reconcileID":"52e8b757-a4e2-4369-89fe-b80b1008ad62","namespace":"default","name":"gw2-b8z9d","deployment":"controlplane-gw2-b8z9d-t22kl"}

It's waiting around 8 minutes before creating the deployment of the control plane. Any idea what could happen in this timeframe?
I can see lots of patching existing ValidatingWebhookConfiguration in the meantime.
There's another wait of around 4 minutes later down:
kgo-gateway-operator-controller-manager-89d754fc5-w6sdm manager {"level":"debug","ts":"2024-04-24T15:31:05Z","logger":"controlplane.dataplaneProvisioning","msg":"dataplane config updated","controller":"gateway","controllerGroup":"gateway.networking.k8s.io","controllerKind":"Gateway","Gateway":{"name":"gw2","namespace":"default"},"namespace":"default","name":"gw2","reconcileID":"e384ced3-1772-427e-9f5b-19eab59b9ea5","namespace":"default","name":"gw2"}
kgo-gateway-operator-controller-manager-89d754fc5-w6sdm manager {"level":"debug","ts":"2024-04-24T15:35:54Z","logger":"controlplane","msg":"patching ControlPlane status","controller":"controlplane","controllerGroup":"gateway-operator.konghq.com","controllerKind":"ControlPlane","ControlPlane":{"name":"gw2-b8z9d","namespace":"default"},"namespace":"default","name":"gw2-b8z9d","reconcileID":"3b8ed356-8f94-4696-b3d2-8130a048eb1f","namespace":"default","name":"gw2-b8z9d","status":{"conditions":[{"type":"Ready","status":"True","observedGeneration":2,"lastTransitionTime":"2024-04-24T15:35:54Z","reason":"Ready","message":""},{"type":"Provisioned","status":"True","observedGeneration":2,"lastTransitionTime":"2024-04-24T15:35:54Z","reason":"PodsReady","message":"pods for all Deployments are ready"}]}}

It's waiting almost 5 minutes here. I thought maybe the cluster is overloaded, but the nodes are pretty idle.
I'll also added the output/status of the kube resources to the gist. Many thanks already for your help!

I wonder if the patching existing ValidatingWebhookConfiguration could be due to some leftovers of the Kong Ingress Controller that was running in this cluster before...? maybe some webhook conf that's not properly cleaned up?

I wonder if the patching existing ValidatingWebhookConfiguration could be due to some leftovers of the Kong Ingress Controller that was running in this cluster before...? maybe some webhook conf that's not properly cleaned up?

Potentially but what's happening most likely is that something outside of KGO is updating ControlPlane's ValidatingWebhookConfiguration ObjectMeta which is not properly enforced.
#225 should fix that.

@MatthiasWinzeler You can test the fix using a nightly or a concrete sha based image: https://hub.docker.com/layers/kong/gateway-operator-oss/sha-9015ff6/images/sha256-9d85254612065a1f7ba702d8d595712c729db95cd8ac8d4f6441c3686497c826?context=explore.

@pmalek thanks!
I tried this image but the issue persists. For instance just now, I have a gateway that's stuck with Programmed = false for about 35 minutes.
To rule out any conflicts with older KIC versions that were on the cluster previously and Cilium, I deployed a vanilla, fresh AKS 1.28 cluster (without Cilium, but with the Azure CNI) and I get the same issue. Any idea how we could further investigate this?

I see. I don't have an Azure cluster readily available for testing but I'll see what I can do.
What you can do in meantime is try to find if the latest nightly image changed what's being logged and post if you've observed anything. You could also use something like https://github.com/ahmetb/kubectl-tree to print all the dependant objects of the Gateway to see where we're stuck (is it the DataPlane or ControlPlane ?).
I'd also look at the DataPlane Service, you can get it in the status:
kg dataplane -n default kong-dgw79   -o jsonpath-as-json='{.status}'
[
    {
        "addresses": [
            {
                "sourceType": "PrivateLoadBalancer",
                "type": "IPAddress",
                "value": "<IP_ADDRESS>"
            },
            {
                "sourceType": "PrivateIP",
                "type": "IPAddress",
                "value": "<IP_ADDRESS>"
            }
        ],
        "conditions": [
            {
                "lastTransitionTime": "2024-04-29T09:12:47Z",
                "message": "",
                "observedGeneration": 1,
                "reason": "Ready",
                "status": "True",
                "type": "Ready"
            }
        ],
        "readyReplicas": 2,
        "replicas": 2,
        "selector": "afbb8e60-996e-4f35-b733-ca743323da42",
        "service": "dataplane-ingress-kong-dgw79-5cgqt"
    }
]

and see if the Service has an LB created for it and ready. It might be that it takes a while for the cloud provider to create an LB and all the necessary resources along with it.

hi @pmalek
it seems that the control plane is not getting created (and since the data plane requires a control plane to come up, it is stuck too). you can find all the YAML output of the related objects in the gist above.
I just captured another try on a fresh AKS cluster with the latest nightly build (image tag sha-1b2f7ee-amd64) while it's stuck for 11 minutes and counting:
k get controlplane
NAME        READY   PROVISIONED
gw1-xtxhp   True    True
gw2-c6psk   False   False

k get deployment
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
controlplane-gw1-xtxhp-4ps99   1/1     1            1           44h
dataplane-gw1-5khtj-ksnp9      1/1     1            1           44h
dataplane-gw2-ffpn8-jn4xr      0/1     1            0           11m <-- stuck for 11m

k get controlplane -o wide
NAME        READY   PROVISIONED
gw1-xtxhp   True    True
gw2-c6psk   False   False <-- stuck

Please see the following gist for all output YAMLs and logs:
https://gist.github.com/MatthiasWinzeler/80769bde7c20b31a67f0f88b1c7b9510
If it makes it easier for you, I'm also available for pairing if that's easier for you - or try to give you access to our AKS cluster :)

the output of the kubectl tree for the stuck gateway is as follows (cool tool by the way!):
kubectl tree gateway gw2
NAMESPACE  NAME                                                            READY  REASON                AGE
default    Gateway/gw2                                                     False  DependenciesNotReady  62m
default    ├─ControlPlane/gw2-c6psk                                        False  DependenciesNotReady  62m
default    │ ├─Secret/controlplane-gw2-c6psk-4twpt                         -                            62m
default    │ ├─Secret/controlplane-gw2-c6psk-hxgph                         -                            62m
default    │ ├─Service/controlplane-webhook-gw2-c6psk-g4nmm                -                            62m
default    │ │ └─EndpointSlice/controlplane-webhook-gw2-c6psk-g4nmm-sfrxl  -                            62m
default    │ └─ServiceAccount/controlplane-gw2-c6psk-zf9dq                 -                            62m
default    └─DataPlane/gw2-ffpn8                                           False  WaitingToBecomeReady  62m
default      ├─Deployment/dataplane-gw2-ffpn8-jn4xr                        -                            62m
default      │ └─ReplicaSet/dataplane-gw2-ffpn8-jn4xr-76cc57c7df           -                            62m
default      │   └─Pod/dataplane-gw2-ffpn8-jn4xr-76cc57c7df-kgb8n          False  ContainersNotReady    62m
default      ├─Secret/dataplane-gw2-ffpn8-nvh94                            -                            62m
default      ├─Service/dataplane-admin-gw2-ffpn8-792c7                     -                            62m
default      │ └─EndpointSlice/dataplane-admin-gw2-ffpn8-792c7-d44j2       -                            62m
default      └─Service/dataplane-ingress-gw2-ffpn8-kwjmc                   -                            62m
default        └─EndpointSlice/dataplane-ingress-gw2-ffpn8-kwjmc-79lxz     -                            62m

It appears that we've been still pushing the images from our old repo (I've disabled that now) which is why you see:
kgo-gateway-operator-controller-manager-776ff5bb95-n5f78 manager {"level":"info","ts":"2024-04-30T08:36:42Z","logger":"setup","msg":"starting controller manager","release":"nightly-amd64","repo":"https://github.com/Kong/gateway-operator-archive.git","commit":"1b2f7ee305cdeb7e27bc66c990e8d32d36292f38"}

in the logs and not (exemplar output):
{"level":"info","ts":"2024-04-30T10:00:31Z","logger":"setup","msg":"starting controller manager","release":"1.2.3-arm64","repo":"https://github.com/Kong/gateway-operator.git","commit":"ab27c2e00e238b7efd6af674f3213da17d8dedb6"}

If you want to test nightly you can try:
https://hub.docker.com/layers/kong/gateway-operator-oss/sha-8f8c621/images/sha256-594550d922473f7c1da70c5abcf8c38f69b4581d9577e15c15f16e3bde594372?context=explore
which is the image for the latest commit in this repo: https://github.com/Kong/gateway-operator/commit/8f8c621c13db8165568df2c65f4a7ad0e11c4010

@pmalek good catch - I changed it and am using the image sha-8f8c621 now:
{"level":"info","ts":"2024-04-30T10:05:38Z","logger":"setup","msg":"starting controller manager","release":"nightly-amd64","repo":"https://github.com/Kong/gateway-operator.git","commit":"8f8c621c13db8165568df2c65f4a7ad0e11c4010"}

However, after deleting and creating the gateway again, it still is stuck:
kubectl tree gateway gw2
NAMESPACE  NAME                                                            READY  REASON                AGE
default    Gateway/gw2                                                     False  DependenciesNotReady  2m50s
default    ├─ControlPlane/gw2-t4vhv                                        False  DependenciesNotReady  2m50s
default    │ ├─Secret/controlplane-gw2-t4vhv-dr7w4                         -                            2m49s
default    │ ├─Secret/controlplane-gw2-t4vhv-nd97l                         -                            2m49s
default    │ ├─Service/controlplane-webhook-gw2-t4vhv-2xxxk                -                            2m49s
default    │ │ └─EndpointSlice/controlplane-webhook-gw2-t4vhv-2xxxk-6v52r  -                            2m49s
default    │ └─ServiceAccount/controlplane-gw2-t4vhv-8m8mh                 -                            2m50s
default    └─DataPlane/gw2-n6dx5                                           False  WaitingToBecomeReady  2m50s
default      ├─Deployment/dataplane-gw2-n6dx5-2b9z6                        -                            2m50s
default      │ └─ReplicaSet/dataplane-gw2-n6dx5-2b9z6-768b66c9f5           -                            2m50s
default      │   └─Pod/dataplane-gw2-n6dx5-2b9z6-768b66c9f5-mf7jw          False  ContainersNotReady    2m50s
default      ├─Secret/dataplane-gw2-n6dx5-p88wm                            -                            2m50s
default      ├─Service/dataplane-admin-gw2-n6dx5-2c6c4                     -                            2m50s
default      │ └─EndpointSlice/dataplane-admin-gw2-n6dx5-2c6c4-fxpb6       -                            2m50s
default      └─Service/dataplane-ingress-gw2-n6dx5-qlxtq                   -                            2m50s
default        └─EndpointSlice/dataplane-ingress-gw2-n6dx5-qlxtq-jqpll     -                            2m50s

Do you need any other debug info?

Not sure ATM.
What seems weird is that the Deployment for ControlPlane doesn't seem to get created.
The only way I was able to reproduce that was with setting too high resource request (which would be higher than the default limit) but even then this got logged
2024-04-30T14:40:45.464+0200 - ERROR - Reconciler error - {"controller": "controlplane", "controllerGroup": "gateway-operator.konghq.com", "controllerKind": "ControlPlane", "ControlPlane": {"name":"kong-psc94","namespace":"default"}, "namespace": "default", "name": "kong-psc94", "reconcileID": "f30d24e7-f068-4876-a11d-3076b0a79696", "error": "failed creating ControlPlane Deployment : Deployment.apps \"controlplane-kong-psc94-c92xc\" is invalid: spec.template.spec.containers[0].resources.requests: Invalid value: \"16000Mi\": must be less than or equal to memory limit of 100Mi"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/Users/patryk.malek@konghq.com/.gvm/pkgsets/go1.22.2/global/pkg/mod/sigs.k8s.io/controller-runtime@v0.17.3/pkg/internal/controller/controller.go:329
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/Users/patryk.malek@konghq.com/.gvm/pkgsets/go1.22.2/global/pkg/mod/sigs.k8s.io/controller-runtime@v0.17.3/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/Users/patryk.malek@konghq.com/.gvm/pkgsets/go1.22.2/global/pkg/mod/sigs.k8s.io/controller-runtime@v0.17.3/pkg/internal/controller/controller.go:227

Setting both limits and requests too high would still create the Deployment and then its Pods would get into a Pending state.
Can you look into

you node(s)' resources (but given my experiments above I doubt that would be it).
any related events that are created (not only related to Gateway, ControlPlane or DataPlane)
enabling the trace logs (with helm: --set env.zap_log_level=2) and resend those with failing to get created ControlPlane Deployment

?

For reference working objects hierarchy under Gateway:
NAMESPACE  NAME                                                             READY  REASON  AGE
default    Gateway/kong                                                     True   Ready   132m
default    ├─ControlPlane/kong-vs42s                                        True   Ready   130m
default    │ ├─Deployment/controlplane-kong-vs42s-9pj95                     -              130m
default    │ │ ├─ReplicaSet/controlplane-kong-vs42s-9pj95-64957d6f86        -              130m
default    │ │ └─ReplicaSet/controlplane-kong-vs42s-9pj95-7ccbd87d9         -              30s
default    │ │   └─Pod/controlplane-kong-vs42s-9pj95-7ccbd87d9-zltmk        True           30s
default    │ ├─Secret/controlplane-kong-vs42s-485pr                         -              130m
default    │ ├─Secret/controlplane-kong-vs42s-w2grp                         -              130m
default    │ ├─Service/controlplane-webhook-kong-vs42s-vzqbc                -              130m
default    │ │ └─EndpointSlice/controlplane-webhook-kong-vs42s-vzqbc-sbptb  -              130m
default    │ └─ServiceAccount/controlplane-kong-vs42s-929sj                 -              130m
default    ├─DataPlane/kong-58h4l                                           True   Ready   132m
default    │ ├─Deployment/dataplane-kong-58h4l-c4lpq                        -              132m
default    │ │ └─ReplicaSet/dataplane-kong-58h4l-c4lpq-55ddd75fc7           -              132m
default    │ │   ├─Pod/dataplane-kong-58h4l-c4lpq-55ddd75fc7-7tnmb          True           132m
default    │ │   └─Pod/dataplane-kong-58h4l-c4lpq-55ddd75fc7-swqk5          True           132m
default    │ ├─Secret/dataplane-kong-58h4l-rk5xh                            -              132m
default    │ ├─Service/dataplane-admin-kong-58h4l-ftrx5                     -              132m
default    │ │ └─EndpointSlice/dataplane-admin-kong-58h4l-ftrx5-g94wt       -              132m
default    │ └─Service/dataplane-ingress-kong-58h4l-wt2zk                   -              132m
default    │   └─EndpointSlice/dataplane-ingress-kong-58h4l-wt2zk-7jqb8     -              132m
default    └─NetworkPolicy/kong-58h4l-limit-admin-api-dlsll                 -              132m

@pmalek
There are some interesting warnings in the events:
61s         Normal    KongConfigurationSucceeded   pod/controlplane-gw1-xtxhp-4ps99-65864757d8-cj9z2   successfully applied Kong configuration to https://10-0-4-37.dataplane-admin-gw1-5khtj-n4cv4.default.svc:8444
55s         Normal    EnsuringLoadBalancer         service/dataplane-ingress-gw2-22pwd-7bj6m           Ensuring load balancer
55s         Normal    Scheduled                    pod/dataplane-gw2-22pwd-dvczf-f5948c849-t86ws       Successfully assigned default/dataplane-gw2-22pwd-dvczf-f5948c849-t86ws to aks-default-42903236-vmss000002
55s         Warning   FailedToCreateEndpoint       endpoints/dataplane-ingress-gw2-22pwd-7bj6m         Failed to create endpoint for service default/dataplane-ingress-gw2-22pwd-7bj6m: endpoints "dataplane-ingress-gw2-22pwd-7bj6m" already exists
55s         Normal    SuccessfulCreate             replicaset/dataplane-gw2-22pwd-dvczf-f5948c849      Created pod: dataplane-gw2-22pwd-dvczf-f5948c849-t86ws
55s         Normal    ScalingReplicaSet            deployment/dataplane-gw2-22pwd-dvczf                Scaled up replica set dataplane-gw2-22pwd-dvczf-f5948c849 to 1
54s         Normal    Created                      pod/dataplane-gw2-22pwd-dvczf-f5948c849-t86ws       Created container proxy
54s         Normal    Started                      pod/dataplane-gw2-22pwd-dvczf-f5948c849-t86ws       Started container proxy
54s         Normal    Pulled                       pod/dataplane-gw2-22pwd-dvczf-f5948c849-t86ws       Container image "kong:3.6.1" already present on machine
54s         Warning   OwnerRefInvalidNamespace     clusterrolebinding/controlplane-gw2-zwk5n-sktws     ownerRef [gateway-operator.konghq.com/v1beta1/ControlPlane, namespace: , name: gw2-zwk5n, uid: 3ec3d543-e2b4-46fa-a91b-1806b3473153] does not exist in namespace ""
54s         Warning   OwnerRefInvalidNamespace     clusterrole/gw2-zwk5n-5h7tn                         ownerRef [gateway-operator.konghq.com/v1beta1/ControlPlane, namespace: , name: gw2-zwk5n, uid: 3ec3d543-e2b4-46fa-a91b-1806b3473153] does not exist in namespace ""
53s         Warning   OwnerRefInvalidNamespace     validatingwebhookconfiguration/gw2-zwk5n            ownerRef [gateway-operator.konghq.com/v1beta1/ControlPlane, namespace: , name: gw2-zwk5n, uid: 3ec3d543-e2b4-46fa-a91b-1806b3473153] does not exist in namespace ""
45s         Normal    EnsuredLoadBalancer          service/dataplane-ingress-gw2-22pwd-7bj6m           Ensured load balancer
4s          Warning   Unhealthy                    pod/dataplane-gw2-22pwd-dvczf-f5948c849-t86ws       Readiness probe failed: HTTP probe failed with statuscode: 503

the nodes look like they have plenty of headroom:
k top nodes
NAME                              CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
aks-default-42903236-vmss000002   620m         32%    1534Mi          28%
aks-default-42903236-vmss000003   90m          4%     1839Mi          34%

Attached you find the trace logs of a gateway creation which is stuck.
kgo.txt

OwnerRefInvalidNamespace issue is tracked in #72. FailedToCreateEndpoint is interesting 🤔
In any case the logs indicate a similar problem as before: perpetual patch to ValidatingWebhookConfiguration. We've had issues in the past where operator code would not fill in the defaults which would cause this cycle (compare generate with already existing resource would always yield a non empty diff) but that is covered now in https://github.com/Kong/gateway-operator/blob/a81e1218cc5007a1d0bd2ac69244141200e51cee/pkg/utils/kubernetes/resources/zz_generated_kic_validatingwebhookconfig.go#L63.
If you have means to share the cluster with us that would most certainly help. When I find more time I can try spinning my own for testing.

@pmalek I am very glad to hear you found the issue. Let me know if I can test something!


enable treeshake analysis. move to lodash-es

[x] use lodash-es so we can just import {blah} from 'lodash-es'
[x] better output in prod webpack builds

@keybase/react-hackers


Argument of parseSimulcastStreamList()

Hi, the README tells that parseSimulcastStreamList() gets the attrs1 or attrs2 string of the a=simulcast line and shows the example
sdpTransform.parseSimulcastStreamList(res.media[1].simulcast.attrs1);

Do I get this right, that attrs1 and attrs2 should be replaced by list1 and list2 in the README (according to the grammar)? If yes, do you want me to provide a PR?

It does look like parseImageAttributes and parseSimulcastStreamList produces different names for their attrs, unlike what the readme says. Yeah, sure, a README pr is an easy merge here. Thank you!


Write for us

I'm sorry for writing here but it was the only way to contact you,
You are good in the cybersecurity field? Then you can write for us about your own tool on GitHub and the use of it.
Your article will be published with your name and a link to your website and social media accounts if you want. Please reply to us at Email: kalitutwrite @ gmail.com
Walid Salame
kalitut .com
Twitter:@xKaliSec

Hey, I'm interested to write a blog on your website, But I'm a bit busy right now, I will contact you soon

OK :)


[300 line limit] Refactor CounterfactualChart

This PR refactors CounterfactualChart, so line of code for CounterfactualChart is reduced from 938 lines to 249 lines.
Description
For CounterfactualList.tsx, this PR creates a few new components as children of CounterfactualList component. So each file now has less than 300 lines of code.
Checklist

[ ] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1624 (072b703) into main (c5d7319) will decrease coverage by 5.12%.
The diff coverage is n/a.

:exclamation: Current head 072b703 differs from pull request most recent head a2118fe. Consider uploading reports for the commit a2118fe to get more accurate results

@@            Coverage Diff             @@
##             main    #1624      +/-   ##
==========================================
- Coverage   88.86%   83.73%   -5.13%
==========================================
  Files         105       22      -83
  Lines        5449      418    -5031
==========================================
- Hits         4842      350    -4492
+ Misses        607       68     -539

Flag
Coverage Δ

unittests
83.73% <ø> (-5.13%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...onsibleai/responsibleai/serialization_utilities.py

...ponsibleai/responsibleai/modelanalysis/__init__.py

...i/responsibleai/managers/counterfactual_manager.py

...iwidgets/raiwidgets/explanation_dashboard_input.py

...eai/responsibleai/managers/data_balance_manager.py

...idgets/raiwidgets/responsibleai_dashboard_input.py

raiwidgets/raiwidgets/error_handling.py

erroranalysis/erroranalysis/_internal/utils.py

responsibleai/responsibleai/__init__.py

...sponsibleai/responsibleai/managers/base_manager.py

... and 73 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


When a part exists and then a copy is done, the part isn't replaced

Start download of a dataset
Interrupt the download
Download to another site
Copy from the other site
Any files that have the ".part" don't seem to be copied over.

The key is the "part" that is left over - it seems to think that the part is a complete file.

And it is the "copy" that has the failure... So... whatever code it is that determines what is already at the destination fails. And it is on a Linux guy, that is causing the problem.

We found a bunch of places where the copyTo would generate extra files. This might be ok if this is a low-level behavior. And the DataManager doesn't care about this.

Ok - according to the test code, it should already prevent extra files from being copied.

So that means... how the heck is this happening??

Ok - a corrupt database. NO IDEA how that happened. But same name on two different machines with different files in side.


Update eap-configuration.md

Improved readability of the EKU property requirements.

@manikadhiman The community contributed PR that introduces a minor Markdown styling fix is available for review. Thanks.


No 'init' file

Describe the bug
As there is no post about this, the 'init' section / file is no longer there since two months now. Is this just a problem for me or why does no one bother? I used Firefox and Chrome and with both browsers I cannot see the 'init' file anymore. I used the scraper for over a year now.

Just use something else.  It is the cookie information that you are after.  Here I used "me"

Anyone feel free to correct me if I am wrong ;)

yeah another onlyfans url should work


can you support three 116?

No. That's over four years old. N8AO is designed for the latest three.js release.


IntelliJ Plugin Aspect tests are failing with Bazel@HEAD on CI

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3149#01892e1b-b74b-41a1-834a-6a032d8314fe
Platform : Ubuntu  Aspect tests 18.04, 20.04
Logs :
//aspect/testing/tests/src/com/google/idea/blaze/aspect/java/javabinary:JavaBinaryTest FAILED
//aspect/testing/tests/src/com/google/idea/blaze/aspect/java/javatest:JavaTestTest FAILED

Steps :
git clone -v https://github.com/bazelbuild/intellij.git
git reset 023a786e711d47d1ce873ed0ad53b4ff25089ad5 --hard
export USE_BAZEL_VERSION=fcfefc15b17dd70ab249e3d8d09d1ccc5da7d347
bazel test --define=ij_product=intellij-latest --test_output=errors --notrim_test_configuration -- //aspect/testing/...

Culprit :https://github.com/bazelbuild/bazel/commit/67c31eedb189d0b320bd4b2a011f25e9c57548c6
CC Green team @Wyverald

culprit is reverted in https://github.com/bazelbuild/bazel/commit/9819a4029c786a13a2223a7a1869bd219f855053

Hi @mai93, We are still seeing this error in few of the Aspect tests in both stable and beta channels. Can you please check. https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3160#018947de-b33a-4a6e-85df-344ce5d61f7a
https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3160#01894849-354a-4ce7-b08f-4cdcee17316a

I think it is now failing with a different reason. I think this is related to https://github.com/bazelbuild/bazel/commit/d0e29582a2e788e8acdaf53fe30ab7f7dc592df3. @kotlaja can you please confirm and let rules_scala know what needs to be changed?

I confirm that this error is because of my change since any rule which uses java_common must register java toolchain type. This is needed because of migration of Automatic Exec Groups, but I'll not get into details here (unless you prefer otherwise).
In this case, we should just add toolchains = ['@bazel_tools//tools/jdk:toolchain_type'] inside _scala_import_impl and the error will be fixed.

Hi @mai93, We are still seeing this error in few of the Aspect tests in both stable and beta channels. Can you please check. https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3160#018947de-b33a-4a6e-85df-344ce5d61f7a https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3160#01894849-354a-4ce7-b08f-4cdcee17316a

I've added https://github.com/bazelbuild/rules_scala/pull/1505 which fixes the previously mentioned error. Please have a look.

Thanks @kotlaja! I think we also need to update scala_library_for_plugin_bootstrapping in rules_scala. Error: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3173#0189672c-e7dc-4de0-91a3-00a2999610c3

Created https://github.com/bazelbuild/rules_scala/issues/1507 to request a fix in rules_scala


Global transform for every icon

Clear and concise description of the problem
i've seen from the docs that the transform function only works on custom icons. why can't it work on all of them?
Suggested solution
make transform work on every icon, not just custom ones
Alternative
using compiler: "raw" and playing around with innerHTML
Additional context
this feature would be most useful for optimizations, since most of the icons look good with 1 or even 0 float numbers in the path element
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Well, sure, PR welcome


ACPERM should clear the tag if reserved bits are set

(This is the follow up I mentioned in https://github.com/riscv/riscv-cheri/issues/295)
We currently clear the tag if we try to do an SCBNDS on a cap with non-zero reserved bits. For consistency, we should do the same on an ACPERM.
Presumably the reason for the SCBNDS behaviour is to pave the way for those extra bits being used to change the bounds interpretation, while still being compatible. Since the bits are more likely to be used for permissions than for bounds, it seems odd to not have the same defence.
(Here's hoping this is the last malformed-related tweak!)

@tariqkurd-repo : Are you planning to create a PR for this one? Thanks!

(As said in the meeting, I'm happy to make the PR if we agree it should be done: it shouldn't be too tricky)

This sounds ok to me - @PRugg-Cap are you able to make the PR (if you haven't already)?


Sign Up directly navigates to the Home Page

Sign Up directly navigates to the Home Page which is a wrong behavior. User should get navigated to the Login page first after the sign up and the after Login only he should get navigated to the Home Page.
Steps:

Open the sign up page
Enter new credentials and click on sign up
You can see user gets navigated to the Home Page

This issue has been fixed


Add stand-up extension

Description

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi 👋
Thanks for your contribution 💪
I have now tested your extension, and I have some feedback ready for you:

What about having a title field as textfield and a Note field as textarea so, there is more space available?
Maybe you can add Draft support, but it might only work for Take Note
Add support for creating new labels
Add so it’s possible to edit a note
Add confirmAlert before deleting all items
use useSql instead of lowdb, this way we can also tweak useSql if something pops up (should be possible)

I'm looking forward to testing this extension again 🔥
Request a new review when you are ready. Feel free to contact me here or at Slack if you have any questions.

👋 Hi, thanks for feeding back
I've address some of your comments and have some comments for others:

[x] Added description field for more information
[ ] Draft support, I'm not sure this needs drafts as it's supposed to be very quick, like just a thought during the day that needs logging.
[ ] I'll iterate after first release for adding labels unless you think it's essential for first release
[x] Added edit functionality
[x] Added confirm for deleting all notes in a day
[ ] I'm not sure the overhead of adding sql and the implications it brings (migrations, potential ORM inclusion) is worth it

I'm happy to address the unchecked points if you think it's worth it 😃
Thanks very much

Hey, I've amended this to use the cached promise hook and removed the react-use dependency!
Thanks for your feedback 😃

Checking this out now 🙂


Influxdb 1.7.5 stops responding while ingesting data, 1.7.4 does not

While running InfluxDB 1.7.5, some time after start while ingesting data, the Influx daemon stops responding. Writes via the HTTP endpoint time out, can't run any SELECT queries and through the influx cli, any commands that perform reads (show measurements, show tag keys, etc...) hang. There are no log messages, no CPU usage, no memory exhaustion, etc... when this happens.
Stopping influxdb leads to a hard shutdown:
Mar 29 07:30:21 influx1 systemd: Stopping InfluxDB is an open-source, distributed, time series database...
Mar 29 07:30:21 influx1 influxd: ts=2019-03-29T07:30:21.179652Z lvl=info msg="Signal received, initializing clean shutdown..." log_id=0ESuf_v0000
Mar 29 07:30:21 influx1 influxd: ts=2019-03-29T07:30:21.179766Z lvl=info msg="Waiting for clean shutdown..." log_id=0ESuf_v0000
Mar 29 07:30:21 influx1 influxd: ts=2019-03-29T07:30:21.179892Z lvl=info msg="Listener closed" log_id=0ESuf_v0000 service=snapshot
Mar 29 07:30:51 influx1 influxd: ts=2019-03-29T07:30:51.179939Z lvl=info msg="Time limit reached, initializing hard shutdown" log_id=0ESuf_v0000
Mar 29 07:30:51 influx1 systemd: Stopped InfluxDB is an open-source, distributed, time series database.

Note that this instance is in the process of backfilling with out-of-order data. I've now downgraded to 1.7.4 and so far it has not hung.

I second this. When I upgraded Influx from 1.7.4-alpine to 1.7.5-alpine all of my writes gave a 500. Additionally, I saw a bunch of these logs when I was bringing things up and down a few times:
Mar 29 01:00:12 myhost docker[30915]: ts=2019-03-29T08:00:12.110995Z lvl=info msg="Write failed" log_id=0EU5vEvG000 service=write shard=748 error="store is closed"

I tried backing up my current Influx dir and starting fresh like I had never spun up Influx before. Even with that things broke in the same way. Downgrading to 1.7.4-alpine brings things back to a working state.

I had the same experience a couple of minutes after upgrading from 1.7.4 queries started hanging and data stopped being written, basically the entire service seemed to be blocked. Even internal stats stopped being written. I rolled back to 1.7.4, this is the second upgrade since 1.7.0 that failed me 😞 .

Ran into same issue here. Spin up an influx DB, set up some CQ and RPs on the database, and everything seems to work fine until a new host writes new data in (the tags contain host names). At that point everything hangs until I restart the service. Every new host will hang the system.

@RedShift1 @conet @jmurrayufo @aaronjwood could you please provide details of the index you're running, and if possible a stack dump of goroutines? You can SIGQUIT the process once it deadlocks.

Running the default index (did not change the default configuration file), I will try to make a stack dump of goroutines.

Update from out side.
We think we know which change introduced this deadlock. The best course of action if you encounter it would be to rollback to 1.7.4.
However, we would really appreciate seeing a stack trace from someone who is deadlocked on this issue. You can send the process a SIGQUIT via kill -s SIGQUIT <process_id> or if Influxd is in the foreground with ctrl \.

Here it is: influxdb-stacktace.log

@conet Thank you for the stack trace. Are you seeing any panics in your log before the SIGQUIT?

@benbjohnson I can't find any occurrences of the word panic in the logs preceding the deadlock. I can approximate the moment of the deadlock based on the fact that write request start to fail with a status of 500.

I've come across, what appears to be the same issue.
influx release: 1.7.5 data and meta
ts=2019-04-03T14:54:05.632738Z lvl=info msg="InfluxDB Meta starting" log_id=0E_vw1G0000 version=1.7.5-c1.7.5 branch=1.7 commit=dae1326b1dde5c36d1dfdb754787acbe8b7447f8 tags=unknown
...
ts=2019-04-03T14:54:07.875194Z lvl=info msg="InfluxDB starting" log_id=0E_vwA0l000 version=1.7.5-c1.7.5 branch=1.7 commit=dae1326b1dde5c36d1dfdb754787acbe8b7447f8

telegraf release: checked with both 1.9.4 and 1.10.2
Usecase
I'm updating the installation script to use 1.7.5. It creates a test cluster for influx enterprise using docker instances and adds the rest of the TICK stack.  Current script found here -
Local version attached.
setup_test_environment_enterprise_version.sh.txt
After seeing httpd responding with 204 to telegraf, I run the first basic selenium test - connection_wizard.
Roughly every second run at the end of the connection_wizard test httpd starts responding with 500 on telegraf writes.
Other Chronograf tests using data explorer or dashboards cannot be executed because queries to influxdb fail.
Console logs (taken from docker) attached.
console-tele-1_9_4.log
console-tele-1_10_2.log
Screenshots

I hit this when spinning up a new InfluxDB instance on a new machine using docker: docker run ... influxdb.  I managed to resolve by explicitly specifying the version tag influxdb:1.7.4.  However anyone running the InfluxDB docker container with tag latest (or no tag), 1.7, or 1.7-alpine will be liable to run into this.  You might want to consider changing these tags to refer to 1.7.4 rather than 1.7.5 until the issue is fixed.

@conet We added what we believe is a fix (#13150). Would you be able to build a369cf413e0b80c4ded1eab51fbd27be3cec4dd1 and verify that it fixes the issue?

@benbjohnson if you give me a rpm I can test that, building from sources... is too much to ask.

@conet No problem. I built an RPM for that commit and posted it here:
https://s3-us-west-1.amazonaws.com/support-sftp/home/influxdb13010/influxdb-v1.7.6_a369cf4.x86_64.rpm

@benbjohnson I'd say that the fix is good, running for an hour now without any issues, previously it would hang in the first couple of minutes, nevertheless I'll leave it running and get with another report tomorrow.

@conet Great, thanks for taking a look so quickly. I appreciate it.

The fix is still good after more than 10 hours, please go ahead and release it.

Thanks @conet!

When is 1.7.6 going to be released? 1.7.5 is still advertised as the latest stable and the issues about 1.7.5 keep piling up, some examples: #13256 and this comment.

At least remove 1.7.5 so that others will not be affected by this.

We just burned a lot of time debugging this in production. Please update your Dockerhub and Github releases with at least a disclaimer.

We did land a notification of this in the release notes here: https://docs.influxdata.com/influxdb/v1.7/about_the_project/releasenotes-changelog/
Happy to take feedback as to where "else" you would like to find this notification if the doc location is not somewhere you are visiting.

We are experiencing an error ERR: max-concurrent-queries limit exceeded(20, 20) in a prototype situation where it is highly unlikely that there are 20 concurrent queries running.
We have also configured INFLUXDB_COORDINATOR_QUERY_TIMEOUT=5s
Could this also be caused by this bug?

@DerMika Yes, it is likely that the lock issue is causing queries to block and back up.

Thanks, I don't seem to have the problem after downgrading to 1.7.4.

Please update your Dockerhub and Github releases with at least a disclaimer.

@timhallinflux

Thanks @bndw   1.7.6 is being published now.

@timhallinflux is there an ETA for this landing in Dockerhub?

should be there now.  There is usually a <24 hour delay once we create the build and releases appearing in Docker hub.

I see random "Internal server errors" while ingesting data with 1.7.7. If I retry writing points, the operation succeeds. /var/log/influxdb/ is empty.


No groups found using search

When searching for groups, using the search dialog, none are found.
To Reproduce
Launch moon locally with urbit binary
Open landscape via web interface
Search for groups to join, by host, e.g. ~bitbet-bolbel (hosts urbit-community)
None will be found.

@Urbposter Thanks for flagging. Do other known ships return results? e.g., ~middev's Forge, ~rondev's Group Discovery
Also, are you able to |hi any of the hosts from your dojo?

Thanks for the help.
Trying to get groups from ~middev, ~rondev:
peek bad result
/app/hark/hoon:<[109 40].[109 67]>
/app/hark/hoon:<[109 5].[109 68]>
/app/hark/hoon:<[98 3].[113 5]>
/app/hark/hoon:<[97 3].[113 5]>
/sys/vane/gall/hoon:<[1.151 26].[1.151 60]>
out=[acked=%.n path=/gangs/index/~middev]
subscribe wire not unique
%groups
/gangs/index/~middev
[p=~middev q=%groups]
error in %groups
%watch-not-unique
! subscribe wire not unique
! %groups
! /gangs/index/~middev
! [p=~middev q=%groups]
out=[acked=%.n path=/gangs/index/~rondev]
subscribe wire not unique
%groups
/gangs/index/~rondev
[p=~rondev q=%groups]
error in %groups
%watch-not-unique
! subscribe wire not unique
! %groups
! /gangs/index/~rondev
! [p=~rondev q=%groups]

Output of +vat %groups:
> +vat %groups
%groups
  /sys/kelvin:      [%zuse 417] [%zuse 416] [%zuse 415]
  base hash:        ~
  %cz hash:         0vf.qnl07.7d8ps.i8m1f.kbv18.kj270.37g0m.sl5eh.ktpkr.vd3t0.4emm0
  app status:       running
  force on:         ~
  force off:        ~
  publishing ship:  [~ ~sogryp-dister-dozzod-dozzod]
  updates:          remote
  source ship:      ~sogryp-dister-dozzod-dozzod
  source desk:      %groups
  source aeon:      0
  kids desk:        ~
  pending updates:  ~[[%zuse 415]]

::
And, it seems there are connectivity issues:
> |hi ~wet
>=
> |hi ~middev
>=
> |hi ~zod
>=

Update: fixed connectivity by creating a new moon. (I suspect the old moon was booted twice -- oops)
I can now reach sponsor planet, and ~wet, ~zod, etc.
Still cannot join any groups though.

Second update:
Groups now joinable. Had to wait approx minutes for that to work.

Closing as work as intended


[Breadth Coverage] Onboard Azure Import/Export Jobs Commands

Speclet Link:
https://microsoft.sharepoint.com/:w:/t/AzureManagementExperience/EaOb6MtSL1ROsAtnpAQEJe4B8mH93dth5G63ZdzYazbvfg?e=HhzJDb
ADO work item link:
https://dev.azure.com/azure-mgmt-ex/Onboarding/_boards/board/t/Onboarding Team/Features/?workitem=168
Swagger Link:
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/storageimportexport/resource-manager/Microsoft.ImportExport/stable/2016-11-01/storageimportexport.json

Import/Export

Code merged, and waiting for instructions to release it.


Cannot set any layout other than Priority Grid

Microsoft PowerToys version
0.37.2
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce

Open PowerToys Settings
Open FancyZones
Go to Launch layout editor
Set "No layout"
See preview of new layout applied
Close Layout editor

✔ Expected Behavior
Have set layout "No layout"
❌ Actual Behavior
At first on step 3 it is appears 2 pop up messages one-by-one:
1.

2.

Afterwards Layout editor opens and let me continue to steps 4 and 5. But the layout stays "Priority Grid"
Other Software
No response

tracked in #11717


Add blockquote component and variants

This adds the three blockquote variants provided by C&T – it currently requires classing of the blockquote element itself.
They will most likely need some responsive attention as well.

They will most likely need some responsive attention as well.

Are the mobile first?

They're built mobile-first, yes, but the designs are quite desktop-y. They'll display satisfactorily in all configurations at the moment, but e.g. font-sizing may need to be tweaked when we can see all components on the article page working in concert.

:shipit:


Sdv fix

Use modern SDV for Win 10 build of NetKvm
Do not build SDV for 8.1
Make SDV to do real checks on Win 10 (sacrifice crash callback in Win10 configuration)

Only build requires for all the drivers except NetKvm.
Only change in NetKvm is removal of crash callback


We have to handle 404 status

At this moment Express handles it itself but we can use a middleware to custom this handling.


Idea: use argus to notify about resources running

Currently we have problem that left instances created by 'QA' are not cleaned promptly (and not only for QA tag). This is due no real ownership or just user omission.
In Argus we have information about resources and tests and assignee (and who started the test). Idea is to notify appropriately in Argus responsible persons (in order: Assignee->who started->specific unfortunate user who will be the last resort for cleanup).
Especially now with 'clean resources' button in resources tab.

I think it would be better to avoid listing QA/timer as much as we can.
if Argus would have api to get the assignee, SCT would be able to switch the resources on creation
to be labeled on the assignee
A nice addition would be also ability to relabel resources, and then Argus can trigger a pipeline to assign the new assignee, when switching the investigation to someone else.
I would rather not add any background processes like that to Argus itself.

idea: make cleanup scripts to update machines labels based on Argus information

update also machines that are no eligible for cleanup - so, when someone reassigns running test to someone else, machines ownership will be transferred too.

The recent client update allows getting state of the run by id, so it can be used to retrieve assignee - what  we're missing is then some endpoint to resolve the assignee id to user information (aside from using /users endpoint, but that just gives you every user on the system that you would have to filter through)

@k0machi to clarify: we can get for each test-id an assignee id and  get a map assignee->name from /users endpoint (can be done once)
I'm correct?

@k0machi to clarify: we can get for each test-id an assignee id and get a map assignee->name from /users endpoint (can be done once) I'm correct?

Yes, that's what currently possible with the current master (I don't think I've pushed a specific version for it onto pypi, so you'll have to do that first)

@soyacz let's check if we have the users API now that can get users of a job


Reagents localization

About the PR
Localize all reagents including drinks, ingredients, chemicals, etc. Descriptions, names and physical descriptions are all localizable now.
Did it by automatic python script, would take ages to do this manually.

NGL it'd be nice if there was a line of whitespace between the name & desc of different items.

Maybe should use fluent attributes for this, like this:
reagent-ephedrine = ephedrine
        .desc = Increases stun resistance and movement speed, giving you hand cramps. Overdose deals toxin damage and inhibits breathing.
        .physical-desc = {reagent-physical-desc-odorless}

Maybe should use fluent attributes for this, like this:
reagent-ephedrine = ephedrine
        .desc = Increases stun resistance and movement speed, giving you hand cramps. Overdose deals toxin damage and inhibits breathing.
        .physical-desc = {reagent-physical-desc-odorless}

This'd help the russian translation, which does this for entities.

Looks good, but I'm not sure how to implement it. Can it be generalized for all prototypes?

NGL it'd be nice if there was a line of whitespace between the name & desc of different items.

Done


Increase timeout for CUDA 11.4 tests

It seems that SASS fix (#5097) increased the compilation time.
Previously, running all unit tests without cache took:

CUPY_TEST_FULL_COMBINATION=1 3h53m (https://ci.preferred.jp/cupy.linux.cuda114/75345/)
CUPY_TEST_FULL_COMBINATION=0 2h8m (https://ci.preferred.jp/cupy.linux.cuda114/75362/)

Now it takes more than 4h (CUPY_TEST_FULL_COMBINATION=1):
https://ci.preferred.jp/cupy.linux.cuda114/75868/

Let me self merge this to check how long it actually take.

https://ci.preferred.jp/cupy.linux.cuda114/75882/

The above test completed in 3h58m.


Targeting S+ (version 31 and above) requires that an explicit value for android:exported

Android Build Failed
 Failure [INSTALL_PARSE_FAILED_MANIFEST_MALFORMED: Failed parse during installPackageLI: /data/app/vmdl95462566.tmp/base.apk (at Binary XML file line #308): com.microsoft.appcenter.distribute.DeepLinkActivity: Targeting S+ (version 31 and above) requires that an explicit value for android:exported be defined when intent filters are present]

need upgrade to:
def appCenterSdkVersion = '4.4.5'


Loading times and memory usage are too high

---  Is your feature request related to a problem? Please describe.
I am using this library to show downloaded images from the internet and stored in /storage/emulated/0/Android/data/com.appname/files. If the images are less than 1mb they work mostly fine, but on images of 3-15mb it is taking a lot of time to show, and with 5-10 seconds of autoPlay they don't even appear sometimes.
Another issue is that having around 7 images to add to the carousel the memory usage according to the AndroidStudio Profiler went from 280mb to 1,7gb more or less which caused the app to crash. I have started to use windowSize to 2 and 3 and it tops at 800mb now, which is still a lot.
---   Describe the solution you'd like
Render the images where they all appear much faster so there are no empty spaces in the slides, and memory optimisation where it doesn't increase by 500mb or 1gb when loading them.
---   Describe alternatives you've considered
Using windowSize and it works for the memory usage although it is still quite high, but the loading issues are still there.
---   Additional context
Versions used:
    "react-native-gesture-handler": "^2.15.0",
    "react-native-reanimated": "^3.7.2",
    "react-native-reanimated-carousel": "^3.5.1",

Here are screenshots of the Android Studio Profiler. The app is also playing other videos in high res or displaying other static images, but that barely affects the memory. The spikes are when a carousel appears and is snapping to the next items.

With no carousel and with a carousel showing a logo icon which is a few kb only:

With the original carousel without windowSize. Images of 5-15mb:

Same but with different windowSize values and optimised images of 3mb max:

I have "solved" it by installing react-native-fast-image. The first time the images are shown it still goes high in memory, but the following times it barely changes and is around the 300-400mb mark.


Abstract attributes cannot have an initial value

class A
	var x = 10 is abstract # Error: `abstract` attributes cannot have an initial value.
end

It would be nice if x= would be called on instances construction with the default value.

There is a spec decision to make here.
Currently, initial value on attributes are set during the intern new (the allocate) and bypass the setter (the attribute is set directly).
class A
   var x = 10
end

var a = new A
# is equivalent with
var a = malloc_A
a._x = 10
a.init

Since there is no attribute on virtual attribute, there is noting to direct access. So two choices here:

initialize with the setter only on abstract attributes -> inconsistent
initialize with the setter on abstract and concrete attributes -> very slow path on most attributes

I lean towards option # 2. Considering that the setter is part of the construction it can be used to do more work. I came across this recently and I was "astonished" that it wasn't the case.

lets go with # 2 then

I'm still thinking: there will be no way for subclasses to avoid the call of the setter.

Is this really a problem? Looks like it ensures object construction in subclasses?


CI errors be gone

Docker build is failing because we need torch 2.0.1 for the LRScheduler bug fix on their end, and the Dockerfile starts with a base image of torch 2.0.0


Assertion failure when using C.Loops.while

When I attempt to typecheck the following F* program interactively in Emacs, I get the following error:
(Error) ASSERTION FAILURE: (<input>(33,4-33,17)) CheckNoUvars: Unexpected unification variable remains: (*?u305*) _
F* may be in an inconsistent state.
Please file a bug report, ideally with a minimized version of the program that triggered the error.

33,4-33,17 is exactly the string "C.Loops.while" preceding the test and body functions for the while loop.
I ran into this with whatever version of F* I happened to have built, but I updated and rebuilt the latest FStar master, and pulled the latest kremlin since that's where C.Loops lives.
$ fstar --version
F* <IP_ADDRESS>~dev
platform=Windows_x64
compiler=OCaml 4.05.0
date=2018-11-14T08:22:21-0800
commit=88c7053f9f70cfd991c1d9ac877dc60a234fef9d (dirty)

HEAD of FStar repo is 88c7053 commit noted above, and of kremlin is d94ac163. In addition to standard modules it depends on, it depends on a couple modules in HACL*, so hacl-star/lib needs to be in F*'s search path. HEAD of my hacl-star repo is 607807de, the current head of the _dev_qtesla branch.
Test program:
module Test

open FStar.HyperStack
open FStar.HyperStack.ST
open FStar.Mul

module UI32 = FStar.UInt32

open LowStar.Buffer

open Lib.IntTypes
open Lib.Buffer

open C.Loops

type elem = FStar.Int64.t
type poly = lbuffer elem 1024

let crypto_randombytes = size 32

val poly_uniform:
    a: poly
  -> seed: lbuffer uint8 (v crypto_randombytes)
  -> Stack unit
    (requires fun h -> live h a /\ live h seed /\ disjoint a seed)
    (ensures fun h0 _ h1 -> live h1 a /\ live h1 seed)// /\ modifies (loc_buffer a) h0 h1)

let poly_uniform a seed =
    push_frame();
    let i = create #size_t #1 1ul (size 0) in

    (* If this while loop is commented out, this checks. If present, assertion failure on the below line.
     * (Error) ASSERTION FAILURE: (<input>(33,4-33,17)) CheckNoUvars: Unexpected unification variable remains: (*?u305*) _ *)
    C.Loops.while
        ( fun _ -> (i.(0ul)) <. 10ul)
	( fun _ -> i.(0ul) <- UI32.((i.(0ul)) +^ 1ul) );

    pop_frame()

The test argument of C.Loops.while is tagged as $ (introducing an equality constraint for unification).
This suggests that the intention of the initial author of while (@protz: https://github.com/FStarLang/kremlin/commit/d5e9fe75a6a3edfe85d0202153afff6b99e86947) was to pass a fully annotated test argument from which F* could infer test_pre and test_post.
Unless test is fully annotated, it's unlikely that F* will be able to infer the implicit arguments #test_pre and #test_post. Passing these arguments explicitly works around the issue in this case:
module Test

open FStar.HyperStack
open FStar.HyperStack.ST
open FStar.Mul

open LowStar.Buffer

open Lib.IntTypes
open Lib.Buffer

open C.Loops

module ST = FStar.HyperStack.ST
module UI32 = FStar.UInt32

type elem = Int64.t
type poly = lbuffer elem 1024

let crypto_randombytes = size 32

val poly_uniform:
    a: poly
  -> seed: lbuffer uint8 (v crypto_randombytes)
  -> Stack unit
    (requires fun h -> live h a /\ live h seed /\ disjoint a seed)
    (ensures  fun h0 _ h1 -> live h1 a /\ live h1 seed /\ modifies0 h0 h1)
let poly_uniform a seed =
  push_frame();
  let i = create #_ #1 1ul (size 0) in
  let h0 = ST.get() in
  let test_pre h = live h i /\ modifies1 i h0 h in
  let test_post (b:bool) h = test_pre h /\ (b ==> get h i 0 <. 10ul) in
  let test () : Stack bool test_pre (fun h0 b h1 -> test_post b h1) = i.(0ul) <. 10ul in
  C.Loops.while #test_pre #test_post
    test
    (fun _ -> i.(0ul) <- UI32.(i.(0ul) +^ 1ul));
  pop_frame()

Unfortunately, omitting the implicits fails with Variable "h0#96148" not found pointing to the h0 argument in the post-condition of test:
let poly_uniform a seed =
  push_frame();
  let i = create #size_t #1 1ul (size 0) in
  let h0 = ST.get() in
  let test_pre h = live h i /\ modifies1 i h0 h in
  let test_post (b:bool) h = test_pre h /\ (b ==> get h i 0 <. 10ul) in
  let test () : Stack bool test_pre (fun h0 b h1 -> test_post b h1) = i.(0ul) <. 10ul
  in
  C.Loops.while
    test
    (fun _ -> i.(0ul) <- 1ul);
  pop_frame()

Minimizing this using a simpler context triggers other surprising errors.
module M

open FStar.HyperStack
open FStar.HyperStack.ST
open FStar.UInt32
open LowStar.Buffer
open LowStar.BufferOps
open C.Loops
open Lib.IntTypes

/// This fails with
/// (Error) ASSERTION FAILURE: Incompatible version for unification variable: current version is 1.36; got version 1.37
let f1 unit : Stack unit  (requires fun _ -> True) (ensures fun _ _ _ -> True) =
  push_frame();
  let i = alloca 0ul 1ul in
  C.Loops.while
    (fun _ -> i.(0ul) = i.(0ul))
    (fun _ -> i.(0ul) <- 0ul);
  pop_frame()

/// This triggers the original assertion failure:
/// (Error) ASSERTION FAILURE: (<input>(17,2-17,15)) CheckNoUvars: Unexpected unification variable remains: (*?u1372*) _
let f2 unit : Stack unit  (requires fun _ -> True) (ensures fun _ _ _ -> True) =
  push_frame();
  let i = alloca 0ul 1ul in
  C.Loops.while
    (fun _ -> i.(0ul) <. 1ul)
    (fun _ -> i.(0ul) <- size 0);
  pop_frame()

/// This (correctly) fails with
/// Failed to resolve implicit argument ?3171 of type _: bool -> _: mem -> Prims.GTot Type0 introduced for Instantiating implicit argument in application
let f3 unit : Stack unit  (requires fun _ -> True) (ensures fun _ _ _ -> True) =
  push_frame();
  let i = alloca 0ul 1ul in
  C.Loops.while
    (fun _ -> i.(0ul) <^ 1ul)
    (fun _ -> i.(0ul) <- 0ul);
  pop_frame()

Still present.

Part of this is caused by the unifer not starting a transaction for a backtracking point, to be fixed in 4b9bc0c3d4e0688c71e2b95b503bceb6527f31e3. The assertion failures will be fixed by PR #1970, oddly enough.
After that, everything fails with not being able to infer an implicit, except this example by Santiago:
 let f1 unit : Stack unit  (requires fun _ -> True) (ensures fun _ _ _ -> True) =
   push_frame();
   (* let i : lmbuffer UInt32.t _ _ 1 = alloca 0ul 1ul in *)
   let i = alloca 0ul 1ul in
   C.Loops.while
     (fun _ -> i.(0ul) = i.(0ul))
     (fun _ -> i.(0ul) <- 0ul);
   pop_frame()

Which somehow infers that the type of i is a buffer of bools, instead of UInt32.t. And we get different typing errors then:
M.fst(18,17-18,20): (Error 54) FStar.UInt32.t is not a subtype of the expected type Prims.bool
M.fst(21,25-21,28): (Error 12) Expected type "Prims.bool"; but "FStar.UInt32.__uint_to_t 0" has type "FStar.UInt32.t"

I don't know why this happens. I can look once we merge that PR so I don't diverge much from what's happening in master.
Using the annotation in the comment makes it fail by an unresolved implicit as the others.
Thanks for the examples and minimizations, they're really useful.

I'm changing this to an inference failure, which is tricky to diagnose (at least for me). I think it has something to do with the fact that while mentions test_post (a bool postcondition) in its own postcondtion, since I couldn't minimize that away.
Downgrading the priority too.


Do not disable Eslint provider

I have been trying to debug this issue for more than a week now until I found out that atom-ide-deno has disabled my Eslint through disabeldProviders settings of the Linter package, although I have disabled atom-ide-deno due to low performance (described separately in #45)

This extension also acts as a provider for deno_lint. I had to anyways disable ESLint when deno_lint was enabled.
However, as mentioned in #45, these features included in "Node.js mode" are buggy and I would like to remove them soon.


Migrate tosa tests to Linalg on tensors.

There are some issues in i1 cases. Rewrite some tests to unblock Linalg
on tensors migration.

IREE currently does not serialze i1 constants as expected. It widen
the i1 constants to i8 constants unconditionally.
Loading from or storing to i1 buffers is not common.

For more details, see https://github.com/google/iree/issues/5153 and
https://llvm.discourse.group/t/cant-create-op-with-replaced-op-in-dialect-conversion/3176/3

I think it works on SPIR-V side. @antiagainst thank you so much!


createDevTools  and addComponentAsRefTo

I am not sure if it's the fact it's the beta or I am doing something wrong. I have:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
and then I have DevTools.js
import React from 'react';
import { createDevTools } from 'redux-devtools';
import LogMonitor from 'redux-devtools-log-monitor';
import DockMonitor from 'redux-devtools-dock-monitor';

export default createDevTools(
  <DockMonitor toggleVisibilityKey='H' changePositionKey='Q'>
    <LogMonitor />
  </DockMonitor>
);

but as soon as I include like this
import DevTools from './DevTools';

export default class Root extends Component {
  render() {
    return (
      <div>
        <DevTools />
      </div>
    );
  }
}

I am getting

Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's render method, or you have multiple copies of React loaded (details: https://fb.me/react-refs-must-have-owner).

This means you have two Reacts somewhere in node_modules.

Probably because your react and react-dom versions don't match, you got<EMAIL_ADDRESS>installed inside react-dom.


ContactUs Form added and UI enhanced

Fixed #221
Kindly add the required tags while merging too and attach the level badge too. I would really appreciate if you could add level2 or level3 badge in the PR.
Thank you

@maniyaom Please have a look

@Bhum-ika Contact Us page has become unresponsive.

Can i raise another issue for this or should I fix in this only?

@Bhum-ika you have not used this contact form details.

If you are talking about functionality, i can implement email.js for that, it will work easily, but for that I should be needing credentials of an account

@Bhum-ika please create a temporary account. After completing the task, I will change it to my account's credentials.

Okay

@Bhum-ika and don't raise another PR. just do commits and push it, that will be added to this PR.

okay

@maniyaom Please check

I would really appreciate it if you could attach level 3 to my PR. Also, please add other badges such as gssoc-ext and hacktoberfest-accepted. I have made it responsive and fully functional.


IRI/LDEO OPeNDAP endpoint for NOAA ESSRT errors in NetCDF >= 4.7.3

Hi NetCDF developers!
A MATLAB customer reported the following NOAA ESSRT OPeNDAP endpoint fails with a NetCDF error as of MATLAB R2020b.   This is the version in which we upgraded from NetCDF version 4.6.1 to 4.7.3.  I confirmed that we can read the data fine in MATLAB R2020a (NetCDF 4.6.1), but we get the error in MATLAB versions 20b and  21a (NetCDF 4.7.3).  It also errors in our current development branch using NetCDF 4.7.4.
I can reproduce this using ncdump in 4.7.4 on Linux:
Dataset:
http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCDC/.ERSST/.version5/.sst/
OPeNDAP URL:
http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCDC/.ERSST/.version5/.sst/X/(80W)(0)RANGEEDGES/T/(Jul 1993)(Jun 2019)RANGEEDGES/Y/(20S)(80N)RANGEEDGES/T/(Jul-Jun)seasonalAverage/dods
Using:
ncdump -h "http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCDC/.ERSST/.version5/.sst/X/%2880W%29%280%29RANGEEDGES/T/%28Jul%201993%29%28Jun%202019%29RANGEEDGES/Y/%2820S%29%2880N%29RANGEEDGES/T/%28Jul-Jun%29seasonalAverage/dods"
Results in:
syntax error, unexpected WORD_WORD, expecting '=' context: Dataset { Grid { ARRAY: Float32 T[ Float32 T^[T = 2008]; = 2008]; MAPS: Float32 T[T = 2008]; } T;} T; Illegal dimension declaration context: Dataset { Grid { ARRAY: Float32 T[ Float32 T^[T = 2008]; = 2008]; MAPS: Float32 T[T = 2008]; } T;} T; ./ncdump: http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCDC/.ERSST/.version5/.sst/X/%2880W%29%280%29RANGEEDGES/T/%28Jul%201993%29%28Jun%202019%29RANGEEDGES/Y/%2820S%29%2880N%29RANGEEDGES/T/%28Jul-Jun%29seasonalAverage/dods: http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCDC/.ERSST/.version5/.sst/X/%2880W%29%280%29RANGEEDGES/T/%28Jul%201993%29%28Jun%202019%29RANGEEDGES/Y/%2820S%29%2880N%29RANGEEDGES/T/%28Jul-Jun%29seasonalAverage/dods: NetCDF: Malformed or inaccessible DAP DDS
This looks kinda similar to https://github.com/Unidata/netcdf-c/issues/569 but looks like that was fixed in 4.6.0.
Hopefully this is an easy fix?  Fingers crossed!

This URL worked in the current master, so something we did already apparently fixed the problem. Attached is the output I got with ncdump. If you can, you might verify.
ireo.txt

Thanks Dennis.  Sorry for the delayed response.  I'll add your info about it working in master branch to our bug ticket for whomever on our team will be taking up the bug.  Thanks!

I can track down the fix if you need it, although it may take a while.

I would greatly appreciate it, otherwise it will be a lot of detective work for us to sift through the issues/PRs/commits, etc.

I forgot to ask; does it fail with 4.8.0?

Hi Dennis - Thank for checking!  We do have plans to upgrade to 4.8.0 but even so there will be a delay in customers getting it because of our dev cycle.  I was hoping maybe the fix would be a small patch we could put on top of our 4.7.4 version, like only affecting several files.  But you said it would be non-trivial to down the exact change that fixed this?  Can you confirm that it won't be easy to find it?  Thanks!

So it turns out that the problem is that in 4.7.4, you need to not use the %xx encodings.
This command, for example, works for me (note the that the url needs to be single or double quoted.
../ncdump/ncdump -h 'http://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCDC/.ERSST/.version5/.sst/X/(80W)(0)RANGEEDGES/T/(Jul 1993)(Jun 2019)RANGEEDGES/Y/(20S)(80N)RANGEEDGES/T/(Jul-Jun)seasonalAverage/dods'

Thanks -- indeed this also works in MATLAB (without the %xx URL encodings)!
Do you know if '%xx' URL encodings are allowed in an OPeNDAP endpoint?  I can't recall if I've seen them in DAP URLs before.
I'm trying to figure out if the Columbia University website is listing an incorrect DAP URL (with the URL encodings), or if they are allowed.   Not sure of why it works in 4.8.0 unless you guys either added logic to handle an edge case of a DAP endpoint containing URL encodings, or if it was never working in netcdf and you guys fixed a bug?

Sort of. There is a change in 4.8.0 (see this PR https://github.com/Unidata/netcdf-c/pull/1884) specifically because of the problem that different serves handle escaping of URL differently.

Thanks for the PR link.  And thanks for making my day with your "sort of" comment (made me laugh).  We'll provide the workaround to our customer (to use the link with URL encodings replaced with character equivalents) until we release new MATLAB with 4.8.0.


Additional Filteroperator(isNull, isNotNull, isNot, ...)

Currently the following operators for filtering/searching is supported.
EQ('equal'),
NE('not equal'),
LT('less'),
LE('less or equal'),
GT('greater'),
GE('greater or equal'),
BW('begins with'),
BN('does not begin with'),
IN('is in'),
NI('is not in'),
EW('ends with'),
EN('does not end with'),
CN('contains'),
NC('does not contain')
what is missing is currently the isNull, isNotNull, ...
Especially the isNull would be very great because if eg. you define a filter query like email NC '@' you have no chance to get the entries were the email is null.

Check version 1.7.0
I don't know why I missed those 2 operators in the first place.

awesome!! ;-) many thanks


[Bug]: {s0} breaks the file

Contact Details
No response
What happened?
If I add to the code bellow
Case 1: "text": "system.wounds.value{s0} / system.wounds.max" == this will show system.wounds.value/ 3, but it should show 0/ 3
Case 2:  "text": "system.wounds.value {s0} / system.wounds.max" == the file stop to work

Original and working code
      {
        "name": "Wounds",
        "type": "direct",
        "align": "center",
        "header": "show",
        "minwidth": 60,
        "text": "system.wounds.value / system.wounds.max"
      },

What type of foundry hosting were you using?
No response
Relevant console log output
No response

Can you paste the error shown in your console log?
		{
        "name": "Wounds",
        "type": "direct",
        "align": "center",
        "header": "show",
        "minwidth": 60,
        "text": "system.wounds.value {s0} / {s0} system.wounds.max"
      }

results in

So there may be something else going on.

ay be something else

{s0}

There is no error in the console.
After my code like yours I just got:

It worked now. I think I need to wait a little more to click the button. If I just click the button after the world load this happens. It need a little more time to load the file.

It worked now. I think I need to wait a little more to click the button. If I just click the button after the world load this happens. It need a little more time to load the file.

I'll investigate this. I may need to hide the button until the templates have finished loading.  May I ask how you're hosting foundry? It could just be a low-system resource issue.

It worked now. I think I need to wait a little more to click the button. If I just click the button after the world load this happens. It need a little more time to load the file.

I'll investigate this. I may need to hide the button until the templates have finished loading. May I ask how you're hosting foundry? It could just be a low-system resource issue.

It's self hosted in a very slow computer.
Thank you, worked nice.


fix: downgrade web3 to 1.2.11

Make sure this

[ ] doesn't break support for working wallets
[ ] fixes support for previously not working wallets

Closes https://github.com/iearn-finance/iearn-finance/issues/100


Bug/435 open sat data

Pull Request
Description
Fixes #435
How Has This Been Tested?

[ ] No
[x] Yes, unit tests pass
[x] prepare_ml_data.py runs

Checklist:

[x] My code follows OCF's coding style guidelines
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have checked my code and corrected any misspellings

There are two commits in this PR.
I think the first commit is sufficient.
But the second commit slightly simplifies the code (but isn't strictly necessary to solve this bug!)

Thanks for the quick review, @jacobbieker!  Just to double-check:  Are you happy for the code to always use xr.open_mfdataset?  As far as I can tell, open_mfdataset does "the right thing" even if zarr_path points to a single Zarr (with no wildcards) but I haven't really put it through its paces!

Yeah, I think it's fine!


Additional Features

Describe the feature request
Upon opening Swap and upon clickiing "Connect Wallet" maybe you add the speciefic wallet like the other DEX instead of the feature "New to Etherium? Learn more about wallet.

Describe alternatives you've considered
Suggetions only, I knew that this would be a great project soon.
Additional context
Additional context here.

We'll launch a Uniswap v3 UI for the next testnet.