Helm upgrade fails applying hpa

When performing an upgrade to our nginx-ingress chart from the stable repository, it's not applying the new HPA configuration. I suspect this is because the api version has changed from autoscaling/v1 to autoscaling/v2beta1.
Output of helm version:
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:17:39Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.10", GitCommit:"be1a908c6aa47e0ae1b1dc861a1de6ccfe963aa2", GitTreeState:"clean", BuildDate:"2018-11-13T11:33:04Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Output from the upgrade with debug enabled.
helm upgrade nginx-ingress stable/nginx-ingress --debug --install --namespace="kube-ingress" -f values.yaml

[debug] Created tunnel using local port: '58545'

[debug] SERVER: "<IP_ADDRESS>:58545"

[debug] Fetched stable/nginx-ingress to /Users/redacted/.helm/cache/archive/nginx-ingress-0.31.0.tgz

REVISION: 68
RELEASED: Wed Nov 28 12:38:38 2018
CHART: nginx-ingress-0.31.0
USER-SUPPLIED VALUES:
controller:
  autoscaling:
    enabled: true
    maxReplicas: 5
    minReplicas: 1
    targetCPUUtilizationPercentage: 85
    targetMemoryUtilizationPercentage: 85
  config:
    use-proxy-protocol: "true"
  image:
    pullPolicy: IfNotPresent
    repository: quay.io/kubernetes-ingress-controller/nginx-ingress-controller
    runAsUser: 33
    tag: 0.20.0
  name: controller
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: 3600
      service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'
  serviceAccount:
    name: nginx-ingress-controller
defaultBackend:
  enabled: true
  image:
    pullPolicy: IfNotPresent
    repository: k8s.gcr.io/defaultbackend
    tag: "1.4"
  name: default-backend

COMPUTED VALUES:
controller:
  affinity: {}
  autoscaling:
    enabled: true
    maxReplicas: 5
    minReplicas: 1
    targetCPUUtilizationPercentage: 85
    targetMemoryUtilizationPercentage: 85
  config:
    use-proxy-protocol: "true"
  customTemplate:
    configMapKey: ""
    configMapName: ""
  daemonset:
    hostPorts:
      http: 80
      https: 443
    useHostPort: false
  defaultBackendService: ""
  dnsPolicy: ClusterFirst
  electionID: ingress-controller-leader
  extraArgs: {}
  extraContainers: []
  extraEnvs: []
  extraInitContainers: []
  extraVolumeMounts: []
  extraVolumes: []
  headers: {}
  hostNetwork: false
  image:
    pullPolicy: IfNotPresent
    repository: quay.io/kubernetes-ingress-controller/nginx-ingress-controller
    runAsUser: 33
    tag: 0.20.0
  ingressClass: nginx
  kind: Deployment
  lifecycle: {}
  livenessProbe:
    failureThreshold: 3
    initialDelaySeconds: 10
    periodSeconds: 10
    port: 10254
    successThreshold: 1
    timeoutSeconds: 1
  metrics:
    enabled: false
    service:
      annotations: {}
      clusterIP: ""
      externalIPs: []
      loadBalancerIP: ""
      loadBalancerSourceRanges: []
      servicePort: 9913
      type: ClusterIP
  minAvailable: 1
  minReadySeconds: 0
  name: controller
  nodeSelector: {}
  podAnnotations: {}
  podLabels: {}
  priorityClassName: ""
  publishService:
    enabled: false
    pathOverride: ""
  readinessProbe:
    failureThreshold: 3
    initialDelaySeconds: 10
    periodSeconds: 10
    port: 10254
    successThreshold: 1
    timeoutSeconds: 1
  replicaCount: 1
  resources: {}
  scope:
    enabled: false
    namespace: ""
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: 3600
      service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'
    clusterIP: ""
    enableHttp: true
    enableHttps: true
    externalIPs: []
    externalTrafficPolicy: ""
    healthCheckNodePort: 0
    labels: {}
    loadBalancerIP: ""
    loadBalancerSourceRanges: []
    nodePorts:
      http: ""
      https: ""
    targetPorts:
      http: http
      https: https
    type: LoadBalancer
  serviceAccount:
    name: nginx-ingress-controller
  stats:
    enabled: false
    service:
      annotations: {}
      clusterIP: ""
      externalIPs: []
      loadBalancerIP: ""
      loadBalancerSourceRanges: []
      servicePort: 18080
      type: ClusterIP
  tolerations: []
  updateStrategy: {}
defaultBackend:
  affinity: {}
  enabled: true
  extraArgs: {}
  image:
    pullPolicy: IfNotPresent
    repository: k8s.gcr.io/defaultbackend
    tag: "1.4"
  minAvailable: 1
  name: default-backend
  nodeSelector: {}
  podAnnotations: {}
  podLabels: {}
  port: 8080
  priorityClassName: ""
  replicaCount: 1
  resources: {}
  service:
    annotations: {}
    clusterIP: ""
    externalIPs: []
    loadBalancerIP: ""
    loadBalancerSourceRanges: []
    servicePort: 80
    type: ClusterIP
  tolerations: []
imagePullSecrets: []
podSecurityPolicy:
  enabled: false
rbac:
  create: true
revisionHistoryLimit: 10
serviceAccount:
  create: true
  name: null
tcp: {}
udp: {}

HOOKS:
MANIFEST:

---
# Source: nginx-ingress/templates/controller-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: "controller"
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-controller
data:
  enable-vts-status: "false"
  use-proxy-protocol: "true"
---
# Source: nginx-ingress/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress
---
# Source: nginx-ingress/templates/clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - extensions
    resources:
      - ingresses/status
    verbs:
      - update
---
# Source: nginx-ingress/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress
subjects:
  - kind: ServiceAccount
    name: nginx-ingress
    namespace: kube-ingress
---
# Source: nginx-ingress/templates/role.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress
rules:
  - apiGroups:
      - ""
    resources:
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - endpoints
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses/status
    verbs:
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      - ingress-controller-leader-nginx
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - create
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
---
# Source: nginx-ingress/templates/rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress
subjects:
  - kind: ServiceAccount
    name: nginx-ingress
    namespace: kube-ingress
---
# Source: nginx-ingress/templates/controller-service.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: "controller"
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-controller
spec:
  loadBalancerSourceRanges: []
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    app: nginx-ingress
    component: "controller"
    release: nginx-ingress
  type: "LoadBalancer"
---
# Source: nginx-ingress/templates/default-backend-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: "default-backend"
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-default-backend
spec:
  clusterIP: ""
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
  selector:
    app: nginx-ingress
    component: "default-backend"
    release: nginx-ingress
  type: "ClusterIP"
---
# Source: nginx-ingress/templates/controller-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: "controller"
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-controller
spec:
  replicas: 1
  revisionHistoryLimit: 10
  strategy:
    {}

  minReadySeconds: 0
  template:
    metadata:
      labels:
        app: nginx-ingress
        component: "controller"
        release: nginx-ingress
    spec:
      dnsPolicy: ClusterFirst
      containers:
        - name: nginx-ingress-controller
          image: "quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.20.0"
          imagePullPolicy: "IfNotPresent"
          args:
            - /nginx-ingress-controller
            - --default-backend-service=kube-ingress/nginx-ingress-default-backend
            - --election-id=ingress-controller-leader
            - --ingress-class=nginx
            - --configmap=kube-ingress/nginx-ingress-controller
          securityContext:
            capabilities:
                drop:
                - ALL
                add:
                - NET_BIND_SERVICE
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          livenessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
          readinessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          resources:
            {}

      hostNetwork: false
      serviceAccountName: nginx-ingress
      terminationGracePeriodSeconds: 60
---
# Source: nginx-ingress/templates/default-backend-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: "default-backend"
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-default-backend
spec:
  replicas: 1
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: nginx-ingress
        component: "default-backend"
        release: nginx-ingress
    spec:
      containers:
        - name: nginx-ingress-default-backend
          image: "k8s.gcr.io/defaultbackend:1.4"
          imagePullPolicy: "IfNotPresent"
          args:
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            timeoutSeconds: 5
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
            {}

      terminationGracePeriodSeconds: 60
---
# Source: nginx-ingress/templates/controller-hpa.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: "controller"
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-controller
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: nginx-ingress-controller
  minReplicas: 1
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 85
    - type: Resource
      resource:
        name: memory
        targetAverageUtilization: 85
Release "nginx-ingress" has been upgraded. Happy Helming!
LAST DEPLOYED: Wed Nov 28 12:38:38 2018
NAMESPACE: kube-ingress
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Role
NAME           AGE
nginx-ingress  2d

==> v1beta1/RoleBinding
nginx-ingress  2d

==> v1/Service
nginx-ingress-controller       2d
nginx-ingress-default-backend  2d

==> v2beta1/HorizontalPodAutoscaler
nginx-ingress-controller  49m

==> v1/Pod(related)

NAME                                            READY  STATUS   RESTARTS  AGE
nginx-ingress-controller-5c8bd9b689-5ndjl       1/1    Running  0         50s
nginx-ingress-default-backend-5455568d9d-dm6qt  1/1    Running  0         2d

==> v1beta1/ClusterRole

NAME           AGE
nginx-ingress  2d

==> v1beta1/ClusterRoleBinding
nginx-ingress  2d

==> v1beta1/Deployment
nginx-ingress-controller       2d
nginx-ingress-default-backend  2d

==> v1/ConfigMap
nginx-ingress-controller  2d

==> v1/ServiceAccount
nginx-ingress  2d

HPA configuration after helm upgrade performed above
$ kubectl get hpa -n kube-ingress -o yaml nginx-ingress-controller
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2018-11-28T11:49:51Z","reason":"SucceededGetScale","message":"the
      HPA controller was able to get the target''s current scale"},{"type":"ScalingActive","status":"False","lastTransitionTime":"2018-11-28T11:49:51Z","reason":"FailedGetResourceMetric","message":"the
      HPA was unable to compute the replica count: unable to get metrics for resource
      memory: unable to fetch metrics from resource metrics API: the server could
      not find the requested resource (get pods.metrics.k8s.io)"}]'
    autoscaling.alpha.kubernetes.io/metrics: '[{"type":"Resource","resource":{"name":"memory","targetAverageUtilization":85}}]'
  creationTimestamp: 2018-11-28T11:49:21Z
  labels:
    app: nginx-ingress
    chart: nginx-ingress-0.31.0
    component: controller
    heritage: Tiller
    release: nginx-ingress
  name: nginx-ingress-controller
  namespace: kube-ingress
  resourceVersion: "526810"
  selfLink: /apis/autoscaling/v1/namespaces/kube-ingress/horizontalpodautoscalers/nginx-ingress-controller
  uid: a53e2d5b-f303-11e8-b45c-02a2b4397c10
spec:
  maxReplicas: 5
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: nginx-ingress-controller
  targetCPUUtilizationPercentage: 85
status:
  currentReplicas: 1
  desiredReplicas: 0

As we can see from the debug output, it's trying to apply the new configuration but silently fails.

any logs from tiller?

Further investigation its looking like a possible bug with Kubernetes 1.10.10.

Opened Kubernetes issue: https://github.com/kubernetes/kubernetes/issues/71556

Further investigation its looking like a possible bug with Kubernetes 1.10.10.

I see the same issue with Kubernetes 1.11.5

Given that a describe doesn't work at all even if the API version is used as suggested in https://github.com/kubernetes/kubernetes/issues/71556, that seems like a separate issue and perhaps the one effecting Helm?

Yes, thats my understanding as well. It will definitely remove any confusion about the true configuration that was deployed.

Feels like this should be re-opened?

Has anyone got an update on this? Facing the same issue on k8s v10, v11, v12

We see the same for most HPA updates via helm 2 on k8s 1.14. The tiller service logs [kube] 2020/01/08 11:03:02 Looks like there are no changes for HorizontalPodAutoscaler "xyz" but there is a change and the debug flag from helm will also print the expected yaml.

Please try a more recent version of Helm.


[RFC][Tracking Issue] Meta Schedule (AutoTIR)

This is a global tracking issue for landing the meta schedule. The RFC can be found here.
Steps
The steps are numbered following TensorIR (#7527).
[M3a] Core infrastructure

[x] Instruction & Trace #8615
[x] TracedSchedule #8623
[x] Sampler #8642 #8817
[x] Design space generator #9079
[x] Search strategy #9132
[x] Task Scheduler #9154
[x] Tune Context #9053

[M3b] Enable measurement

[x] Argument Info #9059
[x] Builder; Builder input/result #9044
[x] Runner; Runner input/result #9111
[x] Tuning Record; Database #9061

[M3c] Enhance search

[x] ScheduleRule, Mutator, PostProcessor #9761 #9789
[x] Cost model #9859 #9789
[x] Feature extraction #9760 #9860
[x] Measure callback #9780

[M4a] Performance & Coverage
Schedule Rules

[x] Add-RFactor #9975
[x] Auto-Inline #9943
[x] Cross-Thread-Reduction #9994
[x] Multi-Level-Tiling #10043
[x] Parallel-Vectorize-Unroll #10033
[x] Random-Compute-Location #9940

PostProcessors

[x] Disallow-Dynamic-Loop #9997
[ ] Rewrite-Cooperative-Fetch
[x] Rewrite-Parallel-Vectorize-Unroll #10071
[x] Rewrite-Reduction-Block #10013
[x] Rewrite-Unbound-Block #10027
[x] Verify-GPU-Code #9945

Mutators

[x] Mutate-Compute-Location #10028
[ ] Mutate-Parallel
[ ] Mutate-Tile-Size
[x] Mutate-Unroll #10045

User interface

[ ] Tune-TE
[ ] Tune-TIR
[ ] Tune-Relay

Misc

[x] Local Runner #9153
[x] Design-Space-Generator: Post-Order-Apply #9761
[x] SearchStrategy: Replay-Func (random search) #9799
[x] SearchStrategy: Evolutionary-Search #9836

[M4b] Relay integration

[x] Task extraction #9382
[x] Apply-History-Best #10049
[x] Builder/Runner working with Relay and Relay BYOC #9757 #10055

@junrushao1994 ,
In looking tracking for auto-tensorization ability of TVM (to explore search for accelerators designs & custom ISA) permit me to ask:

Was Auto Tensorization removed form this list (was at section [M4b] if I recall), what was/is the plan with ?
Wanted to also ask if its design will/have something in common with principles of https://arxiv.org/abs/2101.08458 ?

Thank You !

Hey @cbalint13 thanks for asking! Absolutely!

Was Auto Tensorization removed form this list (was at section [M4b] if I recall), what was/is the plan with ?

The only reason is that I'm trying to organize the roadmap. Auto tensorization is a huge item and we want to have a separate tracking issue for it. As you already see, we have been upstreaming auto tensorization-related PRs, including #9871 #10066. My branch also contains auto tensorization-related working examples if you want to try them out now :-)

Also regarding of design plan, will/have something in common with principles of https://arxiv.org/abs/2101.08458?

This work is done by my fellow colleagues, and of course we are aware, and we have a lot in common :-)  Their codebase is public here. The difference here is that we are now using TensorIR, a more powerful and systematic IR/scheduling system to support tensorization

Hey @cbalint13 thanks for asking! Absolutely!

@junrushao1994
First, thanks a lot for your time !

I am very happy even just to witness what is going on recently in TVM (on mind blowing pace).

Was Auto Tensorization removed form this list (was at section [M4b] if I recall), what was/is the plan with ?

The only reason is that I'm trying to organize the roadmap. Auto tensorization is a huge item and we want to have a separate tracking issue for it. As you already see, we have been upstreaming auto tensorization-related PRs, including #9871 #10066. My branch also contains auto tensorization-related working examples if you want to try them out now :-)

I see now, thanks for clarification, noticed the recent "blockize - tensorize" PR (quite a large piece, still diving on it).

Also regarding of design plan, will/have something in common with principles of https://arxiv.org/abs/2101.08458?

This work is done by my fellow colleagues, and of course we are aware, and we have a lot in common :-) Their codebase is public here. The difference here is that we are now using TensorIR, a more powerful and systematic IR/scheduling system to support tensorization

Was familiar that code-base for UNIT, it is good to know that such feature will make it into the new TIR.
I am thinking on framework (early public sketch) that emits HDL (verilog) blocks reusable and/or as cpu-isa extensions in many possible forms sampled within some combinatorial search-space and auto-tensorisation would be key process in evaluation and metrics here.
It may end sampling some very wierd-looking hardware (including systolic blocks) so auto-tensorizer might need enhancement on some more challenging ends (as i already looked at UNIT).

Can't wait to try it, will look into mentioned WiP early branch.
Many thanks again !

Thank you @cbalint13 for your kind response! We are super excited to hear about your work and more than happy to assist/collaborate on TensorIR/MetaSchedule!

Would be good to get a status update @junrushao1994 . I would suggest we move followup non-infra part to separate trackings to keep things tracable.


hubble: Rate limit "hubble events queue is full" logs

If Hubble events queue can't keep up with the incoming events, there are two warnings logged:
hubble events queue is full; dropping messages
hubble events queue is processing messages again: N messages were lost

They are reported to be very noisy in some environments, e.g. with frequent traffic bursts. This PR mitigates it by:

rate limiting the first message (and making it more helpful)
reducing the level of the second message from warning to info

This is a rough patch for the problem. The underlying reasons for excessive logging are somewhat different issues:

The events queue is considered "back to normal" after only one event is received. That causes the pair of warnings logged again and again in a loop.
When Hubble already can't keep up with the incoming messages, it gets additional LostEvent messages. That seems... suboptimal.
Logs and Hubble events are not good signals for reporting the number of lost events. It should be a metric.

A "proper fix" was proposed in https://github.com/cilium/cilium/issues/15112. But rate limiting "hubble events queue is full" warnings should be useful nonetheless.
Fixes #19202
Rate limit "hubble events queue is full" logs

/test

The test failure is this: https://github.com/cilium/cilium/issues/22931
/ci-aks

/ci-aks

Thanks, looks like this is passing CI and reviews are in. Should we mark this for backport to v1.13 for the upcoming release? Seems like it could be a nice QoL improvement.

Is it possible to backport this to v1.11.x?

sounds fine to me. @rolinh added needs-backport for v1.13 and v1.12, but not for v1.11. let's check with him if it was intentional 👀

sounds fine to me. @rolinh added needs-backport for v1.13 and v1.12, but not for v1.11. let's check with him if it was intentional eyes

That was intentional as when I did add the labels, Cilium v1.12 was the latest stable release and v1.13 had already branched. I was just applying the usual backporting criteria. I think the patch is low-risk enough that we could backport to v1.11 although that's not something we do usually.

This doesn't appear to have actually been backported into 1.13.  Is that intentional?  Looking at the releases I only see it landing in 1.12.6, and this just happened to me in production a few minutes ago on 1.13.3.


[stable/wordpress] Explicitly unset nodePort when service is ClusterIP

What this PR does / why we need it:
This allows the Helm release to be switched between LoadBalancer and ClusterIP without getting the following error:
Service "wordpress" is invalid: [spec.ports[0].nodePort: Forbidden: may not be used when `type` is 'ClusterIP', spec.ports[1].nodePort: Forbidden: may not be used when `type` is 'ClusterIP']

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped

@juan131 You should be able to reproduce with the following:
helm install stable/wordpress --name wordpress
helm upgrade --set service.type=ClusterIP wordpress stable/wordpress

Thanks for providing the detailed command! I'm able to reproduce the issue now!


make the visuals more basic

no video background
should not be a reveal tutorial, but a template for nlesc slides, at the very least:

title slide
slide with an image
slide with basic text
final slide (with contact info etc)

Perhaps we can use these mixins for automatically changing text color depending on background
https://github.com/hakimel/reveal.js/blob/4fe3946cb43de57f79aaa7b646aee7e78f4bcc75/css/theme/template/mixins.scss#L31-L45


Have any possible way to set initial zooming level for chart

C3 version : c3-0.7.1:
D3 version : 5.9.7:
Browser: Chrome, Safari, IE:

Is there any possible way to set initial zooming level for charts? because for large data chart become cluttered.

In theory, you can set the initial zoom. But, it's broken.
you can test it here:
https://c3js.org/samples/interaction_zoom.html
var chart = c3.generate({
data: {
columns: [
['sample', 30, 200, 100, 400, 150, 250, 150, 200, 170, 240, 350, 150, 100, 400, 150, 250, 150, 200, 170, 240, 100, 150, 250, 150, 200, 170, 240, 30, 200, 100, 400, 150, 250, 150, 200, 170, 240, 350, 150, 100, 400, 350, 220, 250, 300, 270, 140, 150, 90, 150, 50, 120, 70, 40]
]
},
zoom: {
enabled: true
}
});
// add this line
chart.zoom([10, 15]);
If there're other options to do this, please tell me.


Received messages are buffered

Messages produced by a server at say 4 hz, will be batched such that 4 messages are received every second.  If I change the server to produce at 10hz, I get 10 messages received in a batch every second.  I verified this happens regardless if I use a dealer/dealer or pub/sub connection type.  I also, verified this happens with a server written in Julia (instead of Python).  This seems to be something unique to the dart ZMQ client as it doesn't happen when I used Julia or Python clients.
Here is the output from the Dart code (below).  It shows the batching of messages:

Here is the important part of the Dart code:

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;
  final ZContext _context = ZContext();
  late final ZSocket _socket;
  late StreamSubscription _subscription;
  String _receivedData = '';
  DateTime ? lastTime = null;

 @override
  void initState() {
    _socket = _context.createSocket(SocketType.dealer);
    _socket.connect("tcp://localhost:4482");

    // listen for messages
    _subscription = _socket.messages.listen((msg) {
      _receivedData = msg.toString();
      var now = DateTime.now();
      if (lastTime != null) {
        var diff = now.difference(lastTime!);
        print("msg received  timing = $diff");
      }
      lastTime = now;
      setState(() {
      });
    });
    super.initState();
  }

Here is the entire server Python code:
import zmq
import time

context = zmq.Context()
socket = context.socket(zmq.DEALER)
socket.set(zmq.LINGER, 0)
address = "tcp://*:4482"
socket.bind(address)

print("Running...")
try:
    last_time = None
    while True:
        time.sleep(.25)
        try:
          socket.send_string("test", zmq.NOBLOCK)
          now = time.time()
          if last_time is not None:
            print(f"Sent message.  timing = {now - last_time}")
          last_time = now
        except Exception as e:
            pass
finally:
    socket.unbind(address)  # ALWAYS RELEASE PORT
    socket.close()  # ALWAYS RELEASE RESOURCES
    context.term()  # ALWAYS RELEASE RESOURCES

Am I doing something wrong?  Would love to get this fixed!  Willing to help!

Duplicate of #4


Allow access to the host/port in response template

Templating is an awesome feature but I have a use case that is currently not supported and probably wouldn't require too much work to support.
I am writing test against webservice. I first retrieve the WSDL and then make the SOAP request.
I want wiremock to serve these 2 requests and to avoid port conflict I want to be able to use dynamic port.
Now the issue is that the wsdl reference the full url with port where the 2 request should be made. So I need to be able to figure out the right port on which wiremock is listening when serving the first request.
to make it more clear, here is an small part of my WSDL where I'd like to template the port:
...
<wsdl:port name="WebServiceSoap" binding="tns:WebServiceSoap">
    <soap:address location="http://localhost:{{wiremock_port}}/web/service"/>
</wsdl:port>
...

My understanding is that this could be implemented in RequestTemplateModel, using request.getAbsoluteUrl(). But there might be better ways or more things that other would want to include.
If you can give me some general idea on how you'd envision this, I'd be willing to send a PR.

on a side note, I feel that url for the path is slightly misleading, AFAIK url should be the full "absolute" url include scheme, host, port, path and query (https://www.ietf.org/rfc/rfc1738.txt). Currently it seems that in the Request interface, getUrl() return the path, and getAbsoluteUrl() return the url. It's not a big deal but I'm curious about the reasons behind this choice (the logic is in WireMockHttpServletRequestAdapter).

This is a pretty old enhancement request and WireMock has supported scheme, host and port in the request model for a little while now.  As a result I am closing this issue


Error: Duplicate LwM2M Server Configuration

Dear dbaba,
I am enjoying using your plugin for node-red, thank you for develpment!
I am trying to simulate several devices and send data over LWM2M to the same server, but with different endpoints.
So i am using several "lwm2m client" nodes with different configurations:
The server URL is the same,
but endpoints are different (each endpoint should be a separate device (with its own smart objects, etc..))
When i deploy such configuration, i get an error:
Error: Duplicate LwM2M Server Configuration (Host:, Port:5683)
is there any way to uuse the same server but with different endpoints?
Thanks in advance for your reply,
Andrey.

Sorry for late response.
I understood what you'd like to do. Currently, the node doesn't allow you to create a config node having duplicate destination host and port.
Let me look into if I can modify the behavior or not.

Thank you!
Yes, that's what i need - duplicate destination host and port :)
It would be great if it is possible to fix!

I've published v1.2.0, which is available from npm as well. Please try this version.
Now you can add a server configuration having the same host and port. But duplicate client endpoint name isn't allowed for the same server host and port.
And you have to pay attention to Listen Port property, which is a LwM2M client listening port. The port cannot be duplicate as LwM2M server failed to communicate with the valid client.
I close this ticket but you can re-open it or issue a new one if necessary.
Thank you for your feedback.


[Android] How to open gallery/camera immediately after accept permissions?

Question
How to open gallery/camera directly after accept camera and storage permissions? In Android, upon accepting permissions, the dialog dismissed and not showing gallery/camera. I need to tap again to launch the gallery/camera. I'm using ImagePicker.launchCamera and ImagePicker.launchImageLibrary.

I'm not sure how you can do it directly from those calls if you don't have permission already, but one work around would be to add a Permissions check in your button click handler. That can check if you have the permissions already, prompting the user if you dont, and awaiting their response to then open the camera/image library. Or if you already have the permissions, skipping straight to opening the camera/image library.

@bmbmjmdm yeah i'm using that workaround for now, just thinking if there's another better way using this library. thanks tho


Profile/metadata feedback on testing

          In Dart, we were already handling debug session ends and calling `.end()` on the test run (whether it was created by VS Code, or by us). We don't seem to have any bugs with stopping debug sessions that are test runs.

However, restart doesn't work great - because it seems to end the test run, then start a new debug session that is not tied to a test run (so you don't get the results recorded). It's not clear to me if your fix here will solve that, but I wonder if there are going to have issues with test runs where VS Code doesn't have all of the related data. We discussed this before in https://github.com/microsoft/vscode/issues/144169#issuecomment-1071143185 about "Test: Rerun Last Run" not working because of this. If we let VS Code handle restarting test runs by just calling runTests, I think any context that we weren't able to capture in the TestRun won't come back to us, and we'll start a test run with some parameters missing.
Originally posted by @DanTup in https://github.com/microsoft/vscode/issues/214486#issuecomment-2157937737

I realized I never followed up on https://github.com/microsoft/vscode/issues/144169#issuecomment-1071143185, apologies.

but it didn't seem like they could be scoped to specific files, and the UX wasn't as good

The filtering is possible through use of the TestRunProfile.tag which, if set, says the profile is only applicable to tests with the given tag.

(eg. having a menu option for "execute using profile" and then having another step to pick one was just way more clicks):

Yea, currently users can pick the default profile used when they hit the button, but a non-default option will involve extra steps. However I did make a change in more recent versions such that the "run" button always works regardless of whether the default profile is applicable or not (we'll fall back to whatever profile does match it.) Not sure if that solves your use case, but I'd like to try and make profiles work for you.
Maybe we finally do need to add code lenses 😛  https://github.com/microsoft/vscode/issues/133338

Update-goldens (run the tests, but instead of comparing the app screens to golden image files on disk, re-generate those images - for example because you've just made changes you know affect the UI)

Related, you may be interested in the testing/message/content contribution point which allows you to place a button on the failure message editor


Switch of signature line on motion PDF in some cases.

The line should be visible only if the motion is in some early state.

Signature lines were removed in new motion pdfs (generated with pdfmake) - wlil be released with 2.1.


gpmdp will not launch

If you have done those 3 things go ahead and fill out the information below.
Once again, thanks for taking the time to submit an issue
-->
OS:
windows 10 home 64 bit
version 1511
OS Build 10586.494
Issue Descriptions:
when I try to open the app I start to get a swarm of error from what I think is java it started after I was playing music and it when silent and the app just when black I closed it and tried starting it and I just got a bunch of error I restarted my computer and even tried reinstalling when I reinstalled the  app It when well but ass soon as it tried launching the app it gave me the same errors

I screenshotted all the errors in the order they came as the files are numbered I think they are 2 error that keep repeating but just to be sure I am uploading all of the errors in the order they came by file name
Steps to Reproduce:
try launching app

Please delete the %APPDATA%/Google Play Music Desktop Player/json_store folder


Scans by ClamScan en RkHunter slowing down Pi

Scans by ClamScan en RkHunter slowing down Pi

Introduced the nice command in the script. This gives the process less priority than the others. Also added sudo.


Web4542 update coding styles

What are the links to relevant tickets?
WEB-4542
What does this PR do?
Add make-up
Make pass hinting linting etc
What unit tests does this PR have?
N/A
How should a developer review this?
Pull down & run tests / see travis run
Any background context you want to provide?
Part of something bigger
Screenshots (if appropriate)

Quality checklist (for PR author to complete BEFORE code review):

[x] I've checked there is appropriate unit test coverage.
[x] I've updated documentation with any changes to procedures.
[x] I've tested this cross browser for any visual changes.
[x] I've checked this work against the requirements of the Jira.
[x] I am ready for this to be code reviewed, merged and tested.

Reviewer 1

[ ] I agree with the assumptions made in the quality checklist.
[ ] I’ve witnessed the work behaving as expected.
[ ] I’ve witnessed the tests running succesfully.
[ ] I’ve checked for appropriate test coverage.
[ ] I’ve checked for coding anti-patterns.
[ ] I've checked this work against the requirements of the Jira.
[ ] I don’t believe this work introduces unnecessary technical debt.
[ ] +1 from me!

Reviewer 2

[ ] I agree with the assumptions made in the quality checklist.
[ ] I’ve witnessed the work behaving as expected.
[ ] I’ve witnessed the tests running succesfully.
[ ] I’ve checked for appropriate test coverage.
[ ] I’ve checked for coding anti-patterns.
[ ] I've checked this work against the requirements of the Jira.
[ ] I don’t believe this work introduces unnecessary technical debt.
[ ] +1 from me!

The tests fail on this repo because it tries to set up a local Elephant database.
I've made a jira to fix the problem, but I won't be fixing it as part of this.

Can we strip Phil's details from the main lib file pls

Removed Phils & Your details, when this branch is merged I'll burn the history.

Thanks @philmeehan  - I didn't know that you could do that, updated now.


6.4.6 hasPolicy

Should the Range in section 6.4.6 be "odrl:Policy" ?

Since dprod:DataProduct is a specialisation of dcat:Resource, I would suggest to reference instead:
https://www.w3.org/TR/vocab-dcat-3/#Property:resource_has_policy
@jgeluk

6.1.10 has the correct range
https://www.w3.org/TR/odrl-vocab/#term-hasPolicy

Sorry, what I meant is that dcat:Resource already defines odrl:hasPolicy as a property, and dprod:dataProduct is a specialisation.

We will update the shape which drives the generation of 6.4.6

The SHACL is correct, the doc generation needs to be updated:
dprod-shapes:DataProduct-hasPolicy
a sh:PropertyShape;
rdfs:isDefinedBy dprod-shapes:;
sh:path odrl:hasPolicy;
sh:class odrl:Policy;


Better handling of streaming JSON data in JsonObjectDecoder

Motivation:
When the JsonObjectDecoder determines that the incoming buffer had some data discarded, it resets the internal index to readerIndex and attempts to adjust the state which does not correctly work for streams of JSON objects.
Modifications:
Reset the internal index to the value considering the previous reads.
Result:
JsonObjectDecoder correctly handles streams of both JSON objects and arrays with no state adjustments or repeatable reads.
Fixes #7820

@ikurovsky can you please sign our icla and let me know once done:
https://netty.io/s/icla
thanks

@normanmaurer done


register changes made by git

Somehow changes made by git are not registering on inotify.

Brief investigation puts the blame on a bug in watchDir function. Replacing it with watchTree should fix the issue.
This script misses events as well:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where

import Control.Monad(forever)
import Control.Concurrent
import Control.Concurrent.Chan as Chan
import System.FSNotify

main = do
  evtChan <- Chan.newChan
  forkIO $ forever $ readChan evtChan >>= print
  withManagerConf (defaultConfig { confDebounce = NoDebounce
                                 , confUsePolling = False }) $ \mgr -> do
    System.FSNotify.watchDirChan mgr "." (const True) evtChan
    threadDelay<PHONE_NUMBER>0

Replacing watchDirChan with watchTreeChan fixes the issue.

Hi folks, and happy new year !
Is there a workaround to use before this problem is solved ?
Cheers

Hi folks, and happy new year !
Is there a workaround to use before this problem is solved ?
Cheers

Hi @ngirard, there are several user scenarios where this bug is a little annoying. I'll assume here you're switching branches. You can always force detection by touching the changed files, or adding them explicitly using the entangled command line. I tend to keep both the markdown and generated sources in version control, so when you're switching a branch (for instance) It can be best to 'touch' the markdown files, so that the database is updated accordingly.
If switching branches is a frequent element in your daily workflow, you could write a bash script that updates the database after the switch; if you have your markdown files in lit/*.md and you'd switch to develop branch:
git switch develop
entangled insert -s lit/*.md
entangled tangle -a

This should work even if you have an entangled daemon running at the same time.
The issue is a rather fundamental one: when you switch a branch, what changes is a hard-link on your filesystem, meaning that the files themselves don't change. I'm expecting progress here in the next few weeks. The workaround will effectively run a loop checking if we're in the same branch every second or so.
Let me know if this helps.

Hi @ngirard, there are several user scenarios where this bug is a little annoying. I'll assume here you're switching branches. You can always force detection by touching the changed files, or adding them explicitly using the entangled command line. I tend to keep both the markdown and generated sources in version control, so when you're switching a branch (for instance) It can be best to 'touch' the markdown files, so that the database is updated accordingly.
If switching branches is a frequent element in your daily workflow, you could write a bash script that updates the database after the switch; if you have your markdown files in lit/*.md and you'd switch to develop branch:
git switch develop
entangled insert -s lit/*.md
entangled tangle -a

This should work even if you have an entangled daemon running at the same time.
The issue is a rather fundamental one: when you switch a branch, what changes is a hard-link on your filesystem, meaning that the files themselves don't change. I'm expecting progress here in the next few weeks. The workaround will effectively run a loop checking if we're in the same branch every second or so.
Let me know if this helps.

Hey @jhidding, thanks for your thorough reply: yes, it helps !
Should I assume that the problem doesn't arise using other git operations, e.g. pull ?
Although, just a thought: from the days when I was following Git-annex's developements I think Joey Hess stumbled upon the same problem. Perhaps it would be worth taking a look at it ?

Hey @jhidding, thanks for your thorough reply: yes, it helps !
Should I assume that the problem doesn't arise using other git operations, e.g. pull ?
Although, just a thought: from the days when I was following Git-annex's developements I think Joey Hess stumbled upon the same problem. Perhaps it would be worth taking a look at it ?

The issue is most pernicious when switching branches. I never ran into problems with 'git pull' but I guess the problem is there also. Thanks for the pointer to git-annex, I will definitely take a look!

The issue is most pernicious when switching branches. I never ran into problems with 'git pull' but I guess the problem is there also. Thanks for the pointer to git-annex, I will definitely take a look!


Minor documentation improvments

Pull Request Checklist:

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

This PR fixes #880

[ ] Tests for the changes have been added (for bug fixes / features)
[x] Documentation has been added / updated (for bug fixes / features)
[ ] HISTORY.rst has been updated (with summary of main changes)

[ ] Link to issue (:issue:number) and pull request (:pull:number) has been added.

[ ] bumpversion patch has been called on this branch
[ ] The relevant author information has been added to .zenodo.json

What kind of change does this PR introduce?

Added a section on translation in the "customize" notebook linked it from the "internationalization" page (and vice-versa).
Moved the API pages of cfchecks, datachecks and dataflags to the "Health checks" page. The API page of missing was already there, so it felt logical to bring everyone together.
Various fixes for formatting, references, etc.

Does this PR introduce a breaking change?
No.
Other information:
I might not have seen some obvious formatting bugs that merit fixing. This PR is a good place for them.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
8 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.0007%) to 90.241%

Files with Coverage Reduction
New Missed Lines
%

xclim/core/locales.py
8
88.12%

Totals

Change from base Build<PHONE_NUMBER>:
-0.0007%

Covered Lines:
12474

Relevant Lines:
13823

💛  - Coveralls


Menu bar list expands upwards to second display if using stacked monitors

Before Submitting Your Bug Report

[x] I have verified that there isn't already an issue reporting the same bug to prevent duplication.
[x] I have seen the FAQ.

Maccy Version (see 'About' window)
2.0.0
macOS Version
No response
Maccy Settings
{
    "KeyboardShortcuts_delete" = "{\\"carbonKeyCode\\":51,\\"carbonModifiers\\":2048}";
    "KeyboardShortcuts_pin" = "{\\"carbonKeyCode\\":35,\\"carbonModifiers\\":2048}";
    "KeyboardShortcuts_popup" = "{\\"carbonKeyCode\\":9,\\"carbonModifiers\\":768}";
    "LaunchAtLogin__hasMigrated" = 1;
    "NSStatusItem Preferred Position Item-0" = 5695;
    "NSStatusItem Visible Item-1" = 0;
    "NSWindow Frame SUUpdateAlert" = "1596 1311 620 398 0 0 3840 2135 ";
    "NSWindow Frame com.sindresorhus.Settings.FrameAutosaveName" = "1783 1360 710 386 0 0 3840 2135 ";
    SUEnableAutomaticChecks = 1;
    SUHasLaunchedBefore = 1;
    SULastCheckTime = "2024-09-19 15:10:10 +0000";
    SUUpdateGroupIdentifier =<PHONE_NUMBER>;
    enabledPasteboardTypes =     (
        "public.png",
        "public.tiff",
        "public.utf8-plain-text",
        "public.rtf",
        "public.html"
    );
    ignoredPasteboardTypes =     (
        "com.agilebits.onepassword",
        "de.petermaurer.TransientPasteboardType",
        "net.antelle.keeweb",
        "com.typeit4me.clipping",
        "Pasteboard generator type"
    );
    migrations =     {
        "2024-07-01-version-2" = 1;
    };
    pasteByDefault = 1;
    pinTo = top;
    popupPosition = cursor;
    showFooter = 1;
    showSearch = 1;
    showTitle = 1;
    windowSize = "[450,800]";
}

Description
When using stacked displays (one monitor on top of the other), when I select Maccy from the menu bar at the top of the bottom display, the list expands upwards instead of down to the monitor that is above the display I am using.
On the top monitor when I select it from the menu bar it goes down as you'd expect.
Steps to Reproduce

Set monitors as stacked (one above the other)
Click Maccy in the bottom display's menu bar

Worth noting this was not the behavior prior to 2.0.


Update Runway Team's X (Twitter) handle

We semi-recently secured a handle closer to our company name (sans the underscore) so we'd like to account for this change

Thanks!

Thanks!

Thank you Dave!


Handle tombstones that were written before kubexit started.

This avoids a race condition where already dead death dependencies weren't causing kubexit to exit.
Fixes #8
Replaces #10

@RemcodM can you please verify that this fixes your problem?

@karlkfi Sadly no, as this change introduces a new issue on side A (in the context of #8). When there is a timeout waiting for birth dependencies, no tombstone is written, because ShutdownNow() returns an error which causes fatalf to shutdown directly and not write a tombstone. Since no tombstone is written, the is no way to reproduce the environment in which #8 can occur.
Logs:
2020-08-13T05:29:32.169289349Z Name: a
2020-08-13T05:29:32.169306084Z Graveyard: /tools
2020-08-13T05:29:32.169309021Z Tombstone: /tools/a
2020-08-13T05:29:32.169311267Z Birth Deps: b
2020-08-13T05:29:32.169313371Z Death Deps: N/A
2020-08-13T05:29:32.169315510Z Birth Timeout: 30s
2020-08-13T05:29:32.169317603Z Grace Period: 30s
2020-08-13T05:29:32.169319668Z Pod Name: <POD_NAME_REDACTED>
2020-08-13T05:29:32.169321898Z Namespace: default
2020-08-13T05:29:32.169568257Z Watching pod updates...
2020-08-13T05:29:32.185562385Z Event Type: ADDED
2020-08-13T05:29:32.960856704Z Event Type: MODIFIED
2020-08-13T05:30:02.169724892Z Error: timed out waiting for birth deps to be ready: 30s
2020-08-13T05:30:02.169741025Z Error: failed to shutdown child process: child process not running

I am not entirely sure what would be a good fix. You could just always write a tombstone, even if ShutdownNow() returns an error. However, after ShutdownNow() has returned an error it is not always safe to call waitForChildExit(child). If ShutdownNow() has somehow failed due to it failing to send a SIGKILL to the process, waitForChildExit(child) might hang forever.
However, writing a tombstone without calling waitForChildExit(child) might miss out on an exit code. If waitForChildExit(child) is failing because the process is not running, it might be the case that the process has ran before. In that case waitForChildExit(child) would give back the exit code of the child. Without calling waitForChildExit(child), the exit code might not be written correctly.
Even though I am not completely sure about a good fix, I would propose to always write a tombstone anyway. If fatalf is called, kubexit needs to exit anyway. Writing a tombstone should always happen, regardless of the status of the child process.

I checked the code paths once more, and it seems there is only one case (at the moment at least) in which fatalf can be called while the child process has already exited (but has actually ran before). That is the case when the child process has been succesfully started but recording the birth fails (https://github.com/karlkfi/kubexit/blob/master/cmd/kubexit/main.go#L158).
If recording the birth fails, there might be a race condition with the child that also has immediatly finished after startup. In that case fatalf would call ShutdownNow() and this would fail with child process not running. In this case it would still be nice to record the exit code of the child (if possible at all, since recording the birth already failed).

When there is a timeout waiting for birth dependencies, no tombstone is written, because ShutdownNow() returns an error which causes fatalf to shutdown directly and not write a tombstone. Since no tombstone is written, the is no way to reproduce the environment in which #8 can occur.

Doesn't that mean the original race condition is solved, because it can't happen any more? If the process never started, there shouldn't need to be a tombstone. The process never started nor died. Is there actually a case that might need one other than a transitive dependency?

If recording the birth fails, there might be a race condition with the child that also has immediatly finished after startup. In that case fatalf would call ShutdownNow() and this would fail with child process not running. In this case it would still be nice to record the exit code of the child (if possible at all, since recording the birth already failed).

The writes probably need retry loops, if Go doesn't do that already within the std lib.

Doesn't that mean the original race condition is solved, because it can't happen any more? If the process never started, there shouldn't need to be a tombstone. The process never started nor died. Is there actually a case that might need one other than a transitive dependency?

Wouldn't that defeat the purpose of kubexit in the first place? If service A has a birth dependency B. B fails to start within the timeout. A would in that case stop and never write a tombstone (because the proces never started). B then starts outside of the timeout, cannot detect that A has stopped and will continue to run.
Kubexit was created with Kubernetes Jobs with sidecar containers in mind. If B is the 'sidecar' container here, B will never stop if it has not started in time. The Kubernetes Job will run forever, which in my humble opinion defeats the purpose of this project in the first place.

you're right. thanks for spelling it out.
we need to write a tombstone even if the process didn't start so that others can still have a death dependency on it.
i think we can also simulate this in a test with a sleep before running kubexit.

Any progress on this PR?

Sorry, man. I got a test added and failing for the reasons you specified. I need to either adopt your change or figure out an alternative. But I’m going on vacation till next week, when I’m starting a new job. So you probably are gonna need to run your own or h for a while. Hoped I can get back to it in a week or so.
Thanks so much for your feedback and PRs!

Just wanted to say that we've faced same issue.
How it looks to me:

For some reason, primary process starts seconds after dependent sidecar process
Sidecar process never exits :disappointed:

Should we make some kind of wait-for loop for dependent processes to ensure primary tombstone is there?

@RemcodM @karlkfi How did you go? I'd be happy to test this out if it helps?


Added show puzzle command.

Fist implementation of show puzzle. Please check if I got all the edge cases and no bugs. I'd also like to implement color coding, but I don't know how, but I think one of you do, so maybe open another branch and add it to the function later.

Comments are added!!


Price button hover cuts-off issues

Issue :
when I'm hovering over the price card button the animation works well but when I remove the mouse the animation cuts of fast.
Screencast from 09-05-24 07:49:48 PM IST.webm

assign this issue to me , i can fix this

Sure! Now you can proceed!!

@abhay-raj19 pls add the level tag in this issue , gssoc members are saying it is mandatory to have both gssoc and level tag
thank u


GwtFileHandle lists all asset types and directories instead of only texts

This is a followup of #3721 - original PR author disappeared, but the change is good. So I merged against current master and fixed a small bug.

We don't need a CLA signed for this, do we? It's a non-original bugfix, that's OK right?

I'm sure his signed CLA is in Mario's drawer, right next to mine.


feat(schematics): address form schematic

A address form schematic
Demo: https://stackblitz.com/edit/shipping-form

@jelbourn - Addressed feedback.

@jelbourn - rebased.


Fix some bugs in image conversion

This patch fixes some bugs in image conversion using LayerConvertFunc and ConvertHookFunc.

append nydus.remoteimage.v1 to os.features of the manifest descriptor in the index
add "containerd.io/snapshot/nydus-blob": "true" to the annotations of the blob layer descriptor in the manifest
avoid appending duplicate bootstrap layer digest to the diffID list of the config

This patch also adds a smoke test TestContainerdImageConvert to make sure LayerConvertFunc and ConvertHookFunc work well with the containerd image conversion library.
Signed-off-by: Nan Li<EMAIL_ADDRESS>

@imeoer Can you please rerun the action? There may be a network error. Thanks :)

/retest

The current main branch has Golang race problem, which fails this PR. I will fix it

Please rebase to the latest main branch.


history shows chromecast off all the time

I have just installed and tested out chromecast integration. It works just fine but there is issue with history. Even if it is on and shows the video I am playing on youtube for, say, 5 minutes, it doesn't reflect it in history. Loogbook shows proper state changes for chromecast but history never reflects it. I can share the logs and screenshot of UI if needed for getting more details around this issue.
Plus, on chromecast component page (https://home-assistant.io/components/media_player.cast.html), example shows platform as chromecast. but it should be just cast. It doesn't work with chromecast as a platform name.

Plus, on chromecast component page (https://home-assistant.io/components/media_player.cast.html), example shows platform as chromecast. but it should be just cast. It doesn't work with chromecast as a platform name.

Thanks. Fixed 5d60db0

Awesome! That was prompt!
Have you had a chance to look at history related issue?
Thanks!
-Deepak.

Sorry, I don't use/have a chromecast. I guess that the issue with the history is an easy fix but I don't know how busy the other guys are or the priority to fix it.

No issues. I will look into code and see if I can fix it.
As I am not a python dev, it will take little bit efforts from my side. A pointer in a right direction would help though.


important CI environments missing

From what I can tell, right now we're CI'ing on 5.0 on 18.04 (ie. OpenSSL 1.1) only. Given that APNSwift essentially has code that works different for OpenSSL 1.0/OpenSSL 1.1; as well as for Swift 5.0/5.1, we need at least four environments :(

[x] Swift 5.0 on 18.04 (ie. OpenSSL 1.1)
[x] Swift 5.0 on 16.04 (ie. OpenSSL 1.0)
[x] Swift 5.1 on 18.04 (ie. OpenSSL 1.1)
[x] Swift 5.1 on 16.04 (ie. OpenSSL 1.0)

On top of that, we should make use of TSan (thread sanitizer) on 5.1 (swift test --sanitize=thread) as well as ASan (address sanitizer) (swift test --sanitize=address).

Done.


Can you copy a material instance with all its parameters to a new one with a new parent material?

Can you copy a material instance with all its parameters to a new one with a new parent material?
Background:
I want to convert material instances from third party apps to native Unreal material instances. So I need to find all those material instances read out its parameters and create new native Unreal instances with these parameters and lastly replace all "old" material instances with the newly created ones.
So could this be easily done with python or is it more complicated? Any suggestions how to do it?
In the meanwhile I could progress further but have one problem with setting the material_static_switch_parameter:
UDT = material.get_material_static_switch_parameter('UseDiffuseTex')
material_instance.set_material_static_switch_parameter('UseDiffuseTex', UDT)

'unreal_engine.UObject' object has no attribute 'set_material_static_switch_parameter'
Traceback (most recent call last):
  File "<string>", line 38, in <module>
AttributeError: 'unreal_engine.UObject' object has no attribute 'set_material_static_switch_parameter'

I'm using the latest binary build but it seems that the attribute 'set_material_static_switch_parameter' does not exist, see also https://github.com/20tab/UnrealEnginePython/pull/365.

Finally solved now.


feat: handling of named prepared statements

This PR introduces support for prepared named statements in transaction mode.
Supavisor attempts to decode all incoming queries from connected users and retrieves the SQL statement by parsing the decoded queries through an existing Rustler wrapper around libpg_query. When the parsed query contains PrepareStmt or DeallocateStmt (which requires removing an existing named statement), the ClientHandler broadcasts it to all other DbHandlers in the pool.
In DbHandler, these queries accumulate in the anon_buffer list and will be applied when data.caller is nil. They will wait until the current PID is unlinked in cases where the process is reserved by another client

Excellent description and diagram. I have only one question though: @abc3 does it mean the statement will be prepared once per db handler? Would it make sense to keep the statements in memory and, given you parse queries, when there is an attempt to execute the statement, you immediately prepare it before (which then stays prepared)?

@josevalim Thanks for the review and the excellent suggestion for improvement 🔥
We will try to implement it in the next iteration


How to set Lora_dropout=0 when loading trained peft model for inference?

System Info
peft==0.10.0
transformers==4.39.3
Who can help?
No response
Information

[ ] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder
[ ] My own task or dataset (give details below)

Reproduction
class Linear(nn.Module, LoraLayer):

   def forward(self, x: torch.Tensor, *args: Any, **kwargs: Any) -> torch.Tensor:
        self._check_forward_args(x, *args, **kwargs)
        adapter_names = kwargs.pop("adapter_names", None)

        if self.disable_adapters:
            if self.merged:
                self.unmerge()
            result = self.base_layer(x, *args, **kwargs)
        elif adapter_names is not None:
            result = self._mixed_batch_forward(x, *args, adapter_names=adapter_names, **kwargs)
        elif self.merged:
            result = self.base_layer(x, *args, **kwargs)
        else:
            result = self.base_layer(x, *args, **kwargs)
            torch_result_dtype = result.dtype
            for active_adapter in self.active_adapters:
                if active_adapter not in self.lora_A.keys():
                    continue
                lora_A = self.lora_A[active_adapter]
                lora_B = self.lora_B[active_adapter]
                dropout = self.lora_dropout[active_adapter]
                scaling = self.scaling[active_adapter]
                x = x.to(lora_A.weight.dtype)

                if not self.use_dora[active_adapter]:
                    result = result + lora_B(lora_A(dropout(x))) * scaling
                else:
                    x = dropout(x)
                    result = result + self._apply_dora(x, lora_A, lora_B, scaling, active_adapter)

            result = result.to(torch_result_dtype)

        return result

Expected behavior
We can see that lora_dropout in forward function is working the same way whether under train or inference mode.

We can see that lora_dropout in forward function is working the same way whether under train or inference mode.

Did you try it out? The nn.Dropout layer is not applying dropout unless it is in training mode. Moreover, when we set dropout to 0 at initialization, self.dropout is set to nn.Identity. Please check if dropout is really applied in your case or if it's a misunderstanding of the code.

We can see that lora_dropout in forward function is working the same way whether under train or inference mode.

Did you try it out? The nn.Dropout layer is not applying dropout unless it is in training mode. Moreover, when we set dropout to 0 at initialization, self.dropout is set to nn.Identity. Please check if dropout is really applied in your case or if it's a misunderstanding of the code.

Thank you! The key point is training mode of the model! I train the model without evaluation, so the model after training is still in 'training' mode, which led to inconsistent performance between the model and the one loaded from a checkpoint.


Project specific rectors should be in their own repos

This looks amazing! Really looking forward to testing it. One thing I noticed straight from the README, though. Shouldn't the nette, symfony, etc rectors be in their own repositories? I think it will be a pain, further down the road, to strip them from the main repo and notify everyone to update the dependencies, etc.

It is great idea, but for now I mean it is over engineering. Main primary reason is Rector API is not stable. I like this way - simple for use, simple for development, simple for tests :-)

I don't understand your issue. What should that solve?

Closing for now for reasons that @grogy mentioned. Let's focus on API maturation now instead of premature split

Closing for now for reasons that @grogy mentioned. Let's focus on API maturation now instead of premature split


Stretchy head on pistol + middle click

The pistol (available in shadows.scn) can cause a stretchy head glitch when right click (aim) is combined with middle click (lock on).

@intelliverse777 is working on this as a test task right now

Fixed


build: fix detect-secrets issue

PR summary
PR Checklist
General checklist
Please make sure that your PR fulfills the following requirements:

[ ] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] Dependencies have been updated as needed
[x] .secrets.baseline updated as needed?

Checklist for adding a new validation rule:

[ ] Added new validation rule definition (packages/ruleset/src/rules/*.js, index.js)
[ ] If necessary, added new validation rule implementation (packages/ruleset/src/functions/*.js, updated index.js)
[ ] Added new rule to default configuration (packages/ruleset/src/ibm-oas.js)
[ ] Added tests for new rule (packages/ruleset/test/*.test.js)
[ ] Added docs for new rule (docs/ibm-cloud-rules.md)

:tada: This PR is included in version 1.10.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.10.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.3.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Riften missions not advancing

it seems like with every patched bug 5 more pop up. rikke won't issue new quests after completing first quests in riften

here is mcm

for clarification it didn't say setting up new missions

also when you force start a campaign it says setting up campaign in___ campaign is miss spelt in that message

i think yu should readd the force start siege debug option as a fallback if this kind of bug occurs

update: using win this hold breaks the civil war quest and the mcm

update update: unsure what caused this on second attempt it worked fine

So I will try to replicate this but you might have hit an interesting edge case. Thanks to the CWO Debugger screen shot you provided, I can tell that you had a surprise defense of the city. Since the Rikke dialogue didn't work at one point and works now, I am wondering if the defense siege was still running (or in the stopping state). So when a siege is stopping (which happens once you actually leave the hold where the siege took place), it runs this routine to update ownership of the whole hold and is doing a bunch of cleanup stuff. This can sometimes take 2-3 actual human minutes to complete (due to Skyrim's extremely inefficient scripting engine). Missions do not get kicked off again until you don't have any other missions or sieges running. So this could have been an issue with just having to wait a little while. I'll see if there is a way to better synergize with the Surprise defense quest.

while i did get a defence mission for riften in this case it was offence this can be seen by the flags in the bottom corner and by the mcm. idk why it was on defence

Sorry for responding to this so late but do you happen to remember if the defense was for Riften or some other hold? It should not have been for Riften since you don't control it yet. When the CWCampaign quest is 200, that means a Spanish Inquisition occurred.

i do remember one for whiterun occuring at some point but i don't remember if it was in that specific save but if a spanish inquisition did occur or is occuring i'd be whiterun since i haven't experienced them in the minor holds

Should be fixed going forward in https://github.com/schofida/CWORR/releases/tag/v1.0.14a
This was definitely a weird interaction between Spanish Inquisiton and continuing the campaign.


Babashka test runner

The test runner is currently using a dev version of babashka which implements some previous special-forms as macros.

I skipped some test namespaces due to the incompatibility with missionary:
Message:  Unable to resolve classname: org.reactivestreams.Publisher
Location: missionary/impl.clj:2:3

I'm sorry that I made some unnecessary whitespace changes as a result of activating the formatter in my editor. I can revert those if you want.

@dustingetz I released a new version of babashka and used that in the tests. PR should be good to go from my side.

Locally, I've used a version of RCF and babashka with this pull applied.  Any blockers to getting it merged?

I attempted to merge today, there is a conflict with this commit: https://github.com/hyperfiddle/rcf/commit/2d1ef6fac0c980d79a3ebf39c31a7c0226391211
@borkdude can you quickly spot the issue? I will take a closer look later, gtg
I f'ed up the PR, sorry, i guess i force pushed the wrong thing. Master currently has babashka support merged and pushed, but fails CI in babashka due to the conflict, which is a correct error (I bisected)

rcf git:(babashka-dustin4) ./ci/run_tests_bb.sh
Running Babashka tests
----- Error --------------------------------------------------------------------
Type:     clojure.lang.ExceptionInfo
Message:  Method getName on class sci.lang.Namespace not allowed!
Data:     {:type :sci/error, :line 20, :column 1, :file "/Users/dustin/src/hf/rcf/test/hyperfiddle/rcf_test.cljc"}
Location: /Users/dustin/src/hf/rcf/test/hyperfiddle/rcf_test.cljc:20:1
Phase:    macroexpand

----- Context ------------------------------------------------------------------
16:                     :form4 (quote (inc 1)) ; interpreted as if evaluated after code emission
17:                     :form5 (quote (quote (inc 1))) ; escaping interpretation
18:                     )))
19:
20: #?(:clj
    ^--- Method getName on class sci.lang.Namespace not allowed!
21:    (tests
22:      "Custom var meta on def symbol are interpreted as if they were evaluated after emission."
23:      ;; CLJ only, no vars in cljs.
24:      (my-def ^{:form1 (quote (inc 1))
25:                :form2 (inc 1)}        ; read and evaluated as usual

----- Stack trace --------------------------------------------------------------
hyperfiddle.rcf/tests                          - /Users/dustin/src/hf/rcf/src/hyperfiddle/rcf.cljc:106:1
hyperfiddle.rcf-test/apply                     - /Users/dustin/src/hf/rcf/test/hyperfiddle/rcf_test.cljc:20:1
hyperfiddle.rcf-test                           - /Users/dustin/src/hf/rcf/test/hyperfiddle/rcf_test.cljc:20:1
clojure.core/apply                             - <built-in>
runner                                         - /Users/dustin/src/hf/rcf/bb/runner.clj:15:5
exec-d0f5b07e-cbd6-42af-82a4-361e5b511f13/exec - <expr>:22:1
exec-d0f5b07e-cbd6-42af-82a4-361e5b511f13      - <expr>:4:1
user-a5406db3-03a4-4cbd-80cd-08ebb1b8978d      - <expr>:26:1

Don't worry, I'll take a look :)

Confirmed electric test suite passes with the babashka support applied, so this is all clear as soon as we fix the conflict. I took a closer look at the conflict and it is nontrivial.

@dustingetz Fixed in https://github.com/hyperfiddle/rcf/pull/79

thank you!

:chefskiss:
On July 20, 2023, GitHub @.***> wrote:

thank you!

—
Reply to this email directly, view it on GitHub
https://github.com/hyperfiddle/rcf/pull/71#issuecomment-1644385358, or
unsubscribe <https://github.com/notifications/unsubscribe-
auth/AADOXTA2R4AZIXHGJ5V6P7TXRFZEHANCNFSM6AAAAAASSJLNJA>.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


[Basic] Change PathImpl to internal for a compiler bug workaround

https://bugs.swift.org/browse/SR-3009

LGTM


effectiveGasPrice missing in transaction receipts for optimism chain

Environment

Browser version: node v16.14.2
Alchemy SDK version: 2.6.2

Describe the problem
alchemy.core.getTransactionReceipt() response doesn't return effectiveGasPrice for transactions on optimism chain. L1 fee data is also not returned via sdk request.
How to reproduce:

Find any address for optimism chain
Fetch transaction receipt for any transaction belonging to the address

Relevant code or sample repro:
Composer Request
https://github.com/shaileshshivam/optimism-test

@thebrianchen I wanted to know whether this is a valid bug or if there is a mistake on my end. I would greatly appreciate it if you or someone from your team could investigate this matter and provide any necessary guidance or clarification.

@shaileshshivam The alchemy sdk uses ethers.js to execute and format transaction receipts, and it only populates the TransactionReceipt with fields that all evm chains have and strips unrelated fields. As a workaround, you can call alchemy.core.send() and send the request as raw json-rpc call. That way, all the fields you want will be returned in the response.

@thebrianchen Thank you for your help! I was able to get the L1 details through the RPC call, but unfortunately, I'm still stuck on trying to get the L2 gas price. Do you happen to have any ideas or suggestions that might help me out ?

@shaileshshivam Can you share a sample call you are trying to make?

const alchemy = new Alchemy({
    apiKey: process.env.ALCHEMY_API_KEY,
    network: Network.OPT_MAINNET,
})

const transactionHash = "0x852b87d82317aa35cbe737ebc128587929f65d41a15517218d3e96fcb5ab23c8"

async function getTransactionReceipt(hash) {
    const receipt = await alchemy.core.send("eth_getTransactionReceipt", [hash])
    const gasUsed = receipt.gasUsed
    const effectiveGasPrice = receipt.effectiveGasPrice

    console.log(receipt)

    console.log({
        gasUsed,
        effectiveGasPrice
    })

}

await getTransactionReceipt(transactionHash);

@thebrianchen have attached the sample call

@shaileshshivam effectiveGasPrice is supported only on eip-1559 transactions, which is only available on bedrock. We'll have to wait until the mainnet upgrade is completed.

@thebrianchen thank you for your help.


error about iter and multiprocessing

Epoch:3 || epochiter: 470/485|| arm_L: 8.8112 arm_C: 0.0169|| odm_L: 6.2153 odm_C: 2.6775|| loss: 17.7210||iteration time: 0.9821 sec. ||LR: 0.00010 || eta time: 1 day, 8:41:09
Epoch:3 || epochiter: 480/485|| arm_L: 8.6689 arm_C: 0.2845|| odm_L: 7.7286 odm_C: 2.3880|| loss: 19.0699||iteration time: 1.0188 sec. ||LR: 0.00010 || eta time: 1 day, 9:54:11
Epoch:4 || epochiter: 0/485|| arm_L: 8.8543 arm_C: 0.0937|| odm_L: 7.0829 odm_C: 2.2283|| loss: 18.2593||iteration time: 0.6582 sec. ||LR: 0.00010 || eta time: 21:54:03
Traceback (most recent call last):
File "train.py", line 329, in
main()
File "train.py", line 311, in main
gamma, end_epoch, cfg)
File "train.py", line 90, in train
for iteration, (imgs, targets, _) in enumerate(train_loader):
File "/home/ubuntu/XXX/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 280, in next
idx, batch = self._get_batch()
File "/home/ubuntu/XXX/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 259, in _get_batch
return self.data_queue.get()
File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 345, in get
return _ForkingPickler.loads(res)
File "/home/ubuntu/XXX/lib/python3.6/site-packages/torch/multiprocessing/reductions.py", line 70, in rebuild_storage_fd
fd = df.detach()
File "/usr/local/lib/python3.6/multiprocessing/resource_sharer.py", line 58, in detach
return reduction.recv_handle(conn)
File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 182, in recv_handle
return recvfds(s, 1)[0]
File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 161, in recvfds
len(ancdata))
RuntimeError: received 0 items of ancdata

batchsize=32
num_images=15493
python train.py --cfg ./configs/refine_vgg_voc_512.yaml
(arm_conf): ModuleList(
(0): Conv2d(512, 6, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
(1): Conv2d(1024, 6, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
(2): Conv2d(256, 6, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
(3): Conv2d(256, 6, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
)
)
Traceback (most recent call last):
File "train.py", line 329, in
main()
File "train.py", line 311, in main
gamma, end_epoch, cfg)
File "train.py", line 90, in train
for iteration, (imgs, targets, _) in enumerate(train_loader):
File "/home/ubuntu/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 280, in next
idx, batch = self._get_batch()
File "/home/ubuntu/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 259, in _get_batch
return self.data_queue.get()
File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 345, in get
return _ForkingPickler.loads(res)
File "/home/ubuntu/lib/python3.6/site-packages/torch/multiprocessing/reductions.py", line 70, in rebuild_storage_fd
fd = df.detach()
File "/usr/local/lib/python3.6/multiprocessing/resource_sharer.py", line 58, in detach
return reduction.recv_handle(conn)
File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 182, in recv_handle
return recvfds(s, 1)[0]
File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 161, in recvfds
len(ancdata))
RuntimeError: received 0 items of ancdata

只允许1024的输入造成的影响

what's your means "只允许1024的输入造成的影响"?

I think this problem is a problem with pytroch itself. You can try to run the code again once. This error should not occur. 1024 refers to the upper limit of the number of pytroch bytes.

I think this problem is a problem with pytroch itself. You can try to run the code again once. This error should not occur. 1024 refers to the upper limit of the number of pytroch bytes.

Thank you so much！


store:del-* with multiple arguments

These commands currently only accepts one argument.
It is slow (with a lot of  I/O) if a lot of commands are deleted. Does the server save the changes after every deletion? In this case, if the ṡtore:del-cmd function could accept more arguments, a lot of I/O could be avoided.

Hmm, that is a fair point. The overhead likely comes from the IPC round trip instead of IO though; how many calls are we talking about here?
Also, note that del-cmd's sequence number is kind of funny; see commit message in 89bc1e5fa6f56995898f0ffe322558cc72e79efc.

I don't know how many I/O calls does it cause, but it requires all the hard disk I/O capacity, and the script is very slow. Isn't the IPC socket on tmpfs?


Create a new microservice in Java for Inventory Management APIs

For more details, open the Copilot Workspace session.

Not required


docs(guides): add observable and subscription instructions

This pr migrate the static content from the old docs for the observable.md and subscription.md.

Thanks, @JWO719


Join ZeroTier network by entering hostname

The user should be able to type in a hostname (e.g. prakashlab.dedyn.io) to try to join a network, rather than having to type in the full network ID. In the future we'll default to having user-friendly domain names from registries instead of requiring typing a domain name, but this is enough for now as a proof-of-concept.

One way we could enable lookup is by adding a TXT record to a domain name, e.g. "sargassum-network-id=897a891jkl1jdf1". However, I'm not sure if our application would be able to perform a DNS lookup like that.
Another option is to put it at a GET endpoint, such as /.well-known/sargassum; this limits a domain name to only one "primary" network.
Another option is to allow WebFinger lookup.

We can standardize that ZeroTier networks should have their domain name as their network name; then, if the domain name has a TXT record matching the network name, we can display the network's domain name as "confirmed"/"corroborated". For security we'd need the TXT record to be secured by DNSSEC (I believe deSEC does this).


Use-after-move in STObject_test.cpp

Problem:
src/test/protocol/STObject_test.cpp:535:30: warning: 'b' used after it was moved [bugprone-use-after-move]
                BEAST_EXPECT(b.empty());
                             ^
src/test/protocol/STObject_test.cpp:534:25: note: move occurred here
                st[sf4] = std::move(b);
                        ^
src/test/protocol/STObject_test.cpp:554:30: warning: 'b' used after it was moved [bugprone-use-after-move]
                BEAST_EXPECT(b.empty());
                             ^
src/test/protocol/STObject_test.cpp:553:25: note: move occurred here
                st[sf5] = std::move(b);

This code is explicitly testing the state of a moved from object. The code is OK as-is.


Update poi version to 5.2.3

It looks like 5.2.3 brings about some log4j changes which are conflicting with older versions of Spark

@dazfuller not sure why it failed, it's specific to the build 3.3.1 only?

It seems to be stopping all of them when one of them fails, which isn't how it's meant to work. I'm going to run them 1 at a time in a while to see if it's just that one, or if it's pre 3.4

Okay, seems like it needs to pull in a later version of log4j to get it to work. I'm running some tests now but seems to be working by adding in these to the dependencies
  "org.apache.logging.log4j" % "log4j-core" % log4JVersion.value % Compile,
  "org.apache.logging.log4j" % "log4j-api" % log4JVersion.value % Compile

Need to test in on a Databricks instance or something though to make sure the shading rules don't mess up

Not sure why the action didn't trigger on this. Guess that's another item in the to-do list

Probably because of the target branch switched from main to elastacloud:0_1_12-release?

possibly, the action should kick in for opened and re-opened PRs though. Could be because I tweaked that mid-PR though


App is out of date. Please get new version at https://sourcerer.io

I just installed sourcerer with curl -s https://sourcerer.io/app/install | bash
and everything seems to work fine. I've entered my Github username and password, but I get an "App is out of date." Error everytime I run sourcerer

Hi @dantuluri !
Problem fixed, try again, please. Thank you for creation of the issue!


what's the meaning of hyper-parameter "tm_sent_len"?

Hello, I am a little confused about the hyper-parameters "tm_sent_len"(default value is 3 ) and "lm_sent_len" (default value is 30) .
Although I have read your ACL paper, knowing that "tm_sent_len" is "Output sequence length for topic model",  lm_sent_len is Sequence length for language model , I'm still not so clear what is the specific meaning of "Output sequence length for topic model" and "Sequence length for language model"..... (:」∠) thank you very much!

tm_sent_len = Output sequence length for topic model = we predict 3 words at a time for TM
lm_sent_len = Sequence length for language model = we predict a sequence of 30 words for LM (it's the sentence length)

@jhlau  oh I got it ! thanks !
Best regards.


Add hashCode & equals for FileSystemResource

Add  hashCode & equals implementation to the FileSystemResouce class.
The location is never null, which is forced by the constructor of the class, so added methods don't perform any extra null checks.
public FileSystemResource(String location) {
    this.location = new File(location);
}

Please note that ClassPathResource analogue implements equals & hashCode.

Thanks. What specific problem does this solve?

I have a class holding the resource which can be either ClassPathResource, or FileSystemResource or null.
class MigrationScript {
   private final Resource resource;
   // .. the other fields
}

This class implements hashCode and equals in a classic manner:
    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (!(obj instanceof MigrationScript)) return false;
        final MigrationScript that = (MigrationScript)obj;
        return Objects.equals(resouce, that.resource()) // && the other fields.
    }

    @Override
    public int hashCode() {
        int hash = 7;
        hash = 31 * hash + Objects.hashCode(resource);
        // the other fields
        return hash;
    }

Everything worked fine with ClassPathResource but i started getting NPEs when MigrationScript instance was created  with FileSystemResource, so i added all the necessary checks to my code
and now it uses resource.getLocation() directly, but:
1 - i wouldn't say it is convenient to use it in such a way
2 - i think that if an implementation of the Resource provides it's own equals & hashCode then
it's mostly preferable to reuse those methods instead of picking values exposed by instance(like with resource.getLocation()).
3 - when i see that ClassPathResource implements equals & hashCode i expecte the same from the other  FileSystemResource core implementation.


Optimistic lock for associations when FullSaveAssociations is enabled

Your Question
When FullSaveAssociations is enabled and an association is updated, the generated query is not modified by this plugin and therefore locking is not working even though version field is available for that association.
Is there any possible solution for this? (except disabling FullSaveAssociations)

The document you expected this should be explained

Expected answer

Could you please share some sample code for testing purposes?

Hi @icpd
Consider these two models:
type User struct {
	ID        uint64                 `gorm:"primary_key;column:id"`
	FirstName string                 `gorm:"type:varchar(100);column:name_given_name"`
	LastName  string                 `gorm:"type:varchar(100);column:name_family_name"`
	Orders    []*Order               `gorm:"many2many:user_orders"`
	Version   optimisticlock.Version `gorm:"type:bigint;column:version"`
}

type Order struct {
	ID      uint64                 `gorm:"primary_key;column:id"`
	Amount  int64                  `gorm:"type:bigint,column:amount"`
	Version optimisticlock.Version `gorm:"type:bigint;column:version"`
}

a user is fetched from db which is preloaded with order association:
	u := User{
		ID:        1000,
		FirstName: "aaa",
		LastName:  "bbb",
		Orders:    []*Order{
			{
				ID:      2000,
				Amount:  5000,
				Version: optimisticlock.Version{
					Int64: 1,
					Valid: true,
				},
			},
		},
		Version:   optimisticlock.Version{
			Int64: 1,
			Valid: true,
		},
	}

updating the order
u.Orders[0].Amount = 6000
db.Session(&gorm.Session{FullSaveAssociations: true}).Table(TableNameUser).Updates(&u)

will generate these queries
INSERT INTO "orders" ("id","amount","version") VALUES (2000,'6000',1) ON CONFLICT ("id") DO UPDATE SET "amount"="excluded"."amount","version"="excluded"."version"

INSERT INTO "user_orders" ("user_id","order_id") VALUES (1000,2000) ON CONFLICT DO NOTHING

UPDATE "persons" SET UPDATE "users" SET "id"=1000,"first_name"='4321',"last_name"='1234',"version"="version"+1 WHERE "persons"."version" = 1 AND "id" = 1000

The first query to update the order association does not have version condition clause (and increase in case of update) and will be overwritten with the model value.

Unfortunately,  INSERT INTO ... UPDATE ...  is a INSERT statement, so there is no way to achieve the expected results you want.

Thanks @icpd


Is there a way to update_schema automatically when in dev mode?

restart server is such a pain

Yes, I feel your pain.
I think it's possible. Base server could watch for src/graphql/schema/**/*.js, run update_schema and restart front-end server automatically, but I have no time to implement this.


[6.x] Verify column names are actual columns when using guarded

This PR will verify column names are actual columns on the database when using guarded with explicit column names.

@driesvints @GrahamCampbell could you explain the reasoning behind this change? It broke some functionality in @octobercms, see https://github.com/octobercms/library/commit/b779df0174454fea203c10d7582465f9ddaf22fb

Please see https://blog.laravel.com/security-release-laravel-61834-7232, https://blog.laravel.com/security-release-laravel-61835-7240.

I've used Eloquent mutators/accessors to create virtual model columns in the past, but this change suggests that was never part of intended usage (otherwise we'd need to check for a method name within isGuardableColumn)?

That's correct @shengslogar, see https://github.com/octobercms/library/commit/b779df0174454fea203c10d7582465f9ddaf22fb#commitcomment-41334767


Handler executing multiple times

I am using MediatR with a .net core 3.0 application and registering my handlers via the MediatR extension. My notification handler is being executed multiple times (8 times or so). My code is very simple (gist: https://gist.github.com/julipur/032ce2b512100586b1750280ea9ca627). Am I using something incorrectly here?
I have used similar approach before with success and am wondering if there any known issues with .net core 3.0 (DI maybe)?

This is almost always because the handlers are registered multiple times. Check the IServiceCollection object to make sure you don't see multiple entries.
I haven't tested with Core 3.0 yet, but there weren't many (if any) changes made to the core DI stuff.

All my command handlers and query handlers working registered the same way and working. This the first notification handler I added and registered it, and it has the issue. I do see it multiple times in the collection even if I remove my line that explicitly adds it to DI (from my startup.cs file in the gist)

I replaced all my explicit handler registrations with this line
services.AddMediatR(typeof(Startup).GetTypeInfo().Assembly);

and it worked.
Thanks @jbogard  for responding.

Ohhhhhhh yes those other ones use the type as a marker type to grab the
assembly. You don’t register individual handlers.
On Tue, Oct 8, 2019 at 11:21 AM qudoos<EMAIL_ADDRESS>wrote:

I replaced all my explicit handler registrations with this line
services.AddMediatR(typeof(Startup).GetTypeInfo().Assembly);
and it worked.
Thanks @jbogard https://github.com/jbogard for responding.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/448?email_source=notifications&email_token=AAAZQMRUCCXKV4CWG5PCSLLQNSXSHA5CNFSM4I6R4FA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAUYLYY#issuecomment-539592163,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMUHX567YV7FEZXL4F3QNSXSHANCNFSM4I6R4FAQ
.

All of my pipeline behaviors are running twice. Registering the services, I tried Assembly.GetExecutingAssembly(), typeof(Startup).Assembly, and typeof(Startup).GetTypeInfo().Assembly.
I am on version 8.1.0. Any ideas what could be going on?

Pipeline behaviors are not registered using the extension method discussed above.  You have to register them manually.  Can you show what service registration code you are using?

@lilasquared Turns out one of the behavior handler is calling _mediator.Send, which sends that through the handler itself and through the other pipelines.

ah yes that can be problematic.  It is highly recommended to not use the IMediator from within any hander or pipeline.  as of 9.0 that interface was split into IPublisher and ISender to help mitigate those mistakes.


Disable packager tests

The packager is soon going to be on its own npm repo. The reason tests fail most of the time on open source is because of configurations that are different, but it actually runs properly. Disabling the tests on open source is going to make for less flaky tests.

@facebook-github-bot import

The packager is soon going to be on its own npm repo.

happycry


chore(master): release 0.6.0

:robot: I have created a release beep boop
0.6.0 (2024-07-16)
Features

add token introspect support (50f0214)
change go sdk version (c97625e)
region support for app space (797434e)

Bug Fixes

no isuuer (7fd07b1)

Documentation

fix documentation templates (612bb53)

Miscellaneous Chores

apply pre-commit rules (eb985f0)
deps: update everything (8f09f6c)
master: release 0.6.0 (d81dcf4)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.6.0
:sunflower:


Maintainers wanted

Hi, I would be interested in taking over the maintenance of this repository.

Hi @loelkes
Be my guest. I'd be happy to transfer ownership, though I'd be grateful if you could acknowledge its provenance.

Do you mean that you will remain in the credits (README, LICENSE, ...) as one of the authors? Are you the only author? The commit history is quite short, was it reinitialised from a previous repository?

Do you mean that you will remain in the credits (README, LICENSE, ...) as one of the authors? Are you the only author? The commit history is quite short, was it reinitialised from a previous repository?

Essentially, yes, if that's OK. I was the original author (it wasn't based on any previous work) but there have been 4 or 5 relatively minor contributions from others along the way, all of which should be retained in the Git history.

Of course we can keep it that way.
Can you identify the other authors? The git history of this repository only contains four commits, all of which are yours.

Of course we can keep it that way.
Can you identify the other authors? The git history of this repository only contains four commits, all of which are yours.

Ok I must have effectively rebased it a few of months ago - my original repo was created around 5 years ago as far as I can I recall. I used to maintain about 10 Ansible repos at various points over the past 7/8 years or so but have since deleted them all as I no longer had the time.
I'll see if I can dig out the full commit history from an old backup, but I don't think anyone's going to be too precious about it.

Done.
If you don't want to continue development in this repository, I would recommend either updating the readme to point to the fork and put it in read-only/archive mode, or just deleting it completely.

All yours.


⚠ Bofrost.fr has degraded performance

In 11d0231, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 978 ms

Resolved: Bofrost.fr performance has improved in 31e4c0a.


Details on accessibility testing

Motivation
Since Ariakit is an accessibility-focused library, it would be great to have documentation around how this accessibility is validated. I've found some vague claims here and there (for example, it's great that every component links to the corresponding ARIA spec), but I feel like it's missing a more nuanced, systematic way of documenting accessibility details.
From "Your Accessibility Claims Are Wrong, Unless…":

Don’t assert the thing works in screen readers (for example) and leave it at that. Tell me which screen readers (plural). Tell me which versions of those screen readers on which operating systems with which browsers and which versions of those browsers.
Tell me how you tested it, which commands, which interaction mode (sticking with screen readers here), what was announced, where they differed.

This kind of information will be extremely useful for users/developers to evaluate which Ariakit components/examples are well-tested and work well with assistive technology, which ones still have issues (found during testing), which ones are pending testing, etc. When a certain feature hasn't been recently tested in Ariakit, it would be a clear indicator for users that they need to spend extra time testing it on their end.
Usage example
As an example, take a look at the "Accessibility" sections of Carbon design system. Every component page has this information available, and there is also a central page for a bird's eye view of all components.
Related, see the "Research" sections on component pages of Gov.UK design system.
See also Radix UI which documents things like keyboard interactions for complex components.
Requirements

Documentation pages for components and examples should indicate how, if, and what parts of the code was tested with which assistive technologies (including version numbers and browser pairings). Any problems found during testing should be clearly listed.

For automated accessibility tests, it would be helpful to also link to the test source code from the documentation.
For manual tests, it would be helpful to have captioned videos showing how it works with different assistive technology.

Optionally, each of these pages could have badges (similar to Carbon design system) indicating the testing status of that component/example. This would make it easier to glance; it would also be useful for contributors who want to add tests.

Workaround
No response
Possible implementations
No response

Some examples do include detailed notes on accessibility tests (e.g., Combobox Tabs: Testing with screen readers and Submenu with Combobox: Testing with screen readers). However, I agree they could benefit from more details, like browser and screen reader combinations. Producing videos is currently out of our budget, but we may eventually get there.
I don't think this information should determine whether or how much developers test their apps. When a component or example is used in context, the context can impact accessibility, even if it works in isolation. These notes should encourage developers to test more and report any issues they find.