IPv6 cluster bootstrap failure

Can someone please explain how KUBERNETES_SERVICE_HOST value works. When I am trying to bootstrap IPv6 cluster, I am getting below error.

kubectl logs helm-install-cilium-jd8pw -n kube-system
if [[ ${KUBERNETES_SERVICE_HOST} =~ .:. ]]; then
echo "KUBERNETES_SERVICE_HOST is using IPv6"
CHART="${CHART//%{KUBERNETES_API}%/[${KUBERNETES_SERVICE_HOST}]:${KUBERNETES_SERVICE_PORT}}"
else
CHART="${CHART//%{KUBERNETES_API}%/${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}}"
fi
set +v -x

[[ true != \t\r\u\e ]]
[[ '' == \1 ]]
[[ '' == \v\2 ]]
shopt -s nullglob
[[ -f /config/ca-file.pem ]]
[[ -f /tmp/ca-file.pem ]]
[[ -n '' ]]
helm_content_decode
set -e
ENC_CHART_PATH=/chart/cilium.tgz.base64
CHART_PATH=/tmp/cilium.tgz
[[ ! -f /chart/cilium.tgz.base64 ]]
return
[[ install != \d\e\l\e\t\e ]]
helm_repo_init
grep -q -e 'https?://'
[[ helm_v3 == \h\e\l\m_\v\3 ]]
[[ cilium/cilium == stable/* ]]
[[ -n https://helm.cilium.io/ ]]
[[ -f /auth/username ]]
helm_v3 repo add cilium https://helm.cilium.io/
"cilium" has been added to your repositories
helm_v3 repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "cilium" chart repository
Update Complete. ⎈Happy Helming!⎈
helm_update install --namespace kube-system --version 1.14.5
[[ helm_v3 == \h\e\l\m_\v\3 ]]
++ helm_v3 ls --all -f '^cilium$' --namespace kube-system --output json
++ jq -r '"(.[0].app_version),(.[0].status)"'
++ tr '[:upper:]' '[:lower:]'
Error: Kubernetes cluster unreachable: Get "https://<IP_ADDRESS>:6444/version": dial tcp <IP_ADDRESS>:6444: connect: connection refused
LINE=
IFS=,
read -r INSTALLED_VERSION STATUS _
VALUES=
for VALUES_FILE in /config/*.yaml
VALUES=' --values /config/values-01_HelmChart.yaml'
[[ install = \d\e\l\e\t\e ]]
[[ '' =~ ^(|null)$ ]]
[[ '' =~ ^(|null)$ ]]
echo 'Installing helm_v3 chart'
helm_v3 install --namespace kube-system --version 1.14.5 cilium cilium/cilium --values /config/values-01_HelmChart.yaml
Error: INSTALLATION FAILED: Kubernetes cluster unreachable: Get "https://<IP_ADDRESS>:6444/version": dial tcp <IP_ADDRESS>:6444: connect: connection refused

I believe it should be trying to listen on ::1.

ss -nlpt | grep 6444
LISTEN 0      4096           [::1]:6444          [::]:*    users:(("k3s-server",pid=4874,fd=16))

Seems like KUBERNETES_SERVICE_HOST is hard coded here? Is there a way I can tell helm controller to use ::1 instead of <IP_ADDRESS> ?
BTW it works when I am trying Dualstack cluster with a combination of {ipv4},{ipv6} but not the other way around.

KUBERNETES_SERVICE_HOST is set by Kubernetes itself, to the address of the kubernetes service: kubectl get service -n default kubernetes -o wide

Thank you @brandond.

kubectl get svc -owide
NAME         TYPE        CLUSTER-IP                  EXTERNAL-IP   PORT(S)   AGE   SELECTOR
kubernetes   ClusterIP   2001:470:ee86:4:10:43:0:1           443/TCP   10h

I don't see helmcontroller picking the correct address then. KUBERNETES_SERVICE_HOST is somehow auto filled and it's always <IP_ADDRESS> and that's why I was wondering if this value is hard-coded.
Yes I am trying helm controller to deploy cilium. The charts is here.

The oyaml of the pod that is stuck in the CrashLoopBackOff.
kubectl get pod helm-install-cilium-jd8pw -n kube-system -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    helmcharts.helm.cattle.io/configHash: SHA256=58B430BF3EAC3F550E3E698901F5FE90E5813E65687253155DC57F03E6909F55
  creationTimestamp: "2024-01-19T13:38:57Z"
  finalizers:
  - batch.kubernetes.io/job-tracking
  generateName: helm-install-cilium-
  labels:
    batch.kubernetes.io/controller-uid: 9bb57e45-b3c6-4c21-b5dd-29b61b3f0118
    batch.kubernetes.io/job-name: helm-install-cilium
    controller-uid: 9bb57e45-b3c6-4c21-b5dd-29b61b3f0118
    helmcharts.helm.cattle.io/chart: cilium
    job-name: helm-install-cilium
  name: helm-install-cilium-jd8pw
  namespace: kube-system
  ownerReferences:
  - apiVersion: batch/v1
    blockOwnerDeletion: true
    controller: true
    kind: Job
    name: helm-install-cilium
    uid: 9bb57e45-b3c6-4c21-b5dd-29b61b3f0118
  resourceVersion: "17775"
  uid: cd31640c-7bca-48b6-8e76-cac1e4a2a2f2
spec:
  containers:
  - args:
    - install
    - --namespace
    - kube-system
    - --version
    - 1.14.5
    env:
    - name: NAME
      value: cilium
    - name: VERSION
      value: 1.14.5
    - name: REPO
      value: https://helm.cilium.io/
    - name: HELM_DRIVER
      value: secret
    - name: CHART_NAMESPACE
      value: kube-system
    - name: CHART
      value: cilium/cilium
    - name: HELM_VERSION
    - name: TARGET_NAMESPACE
      value: kube-system
    - name: AUTH_PASS_CREDENTIALS
      value: "false"
    - name: KUBERNETES_SERVICE_HOST
      value: <IP_ADDRESS>
    - name: KUBERNETES_SERVICE_PORT
      value: "6444"
    - name: BOOTSTRAP
      value: "true"
    - name: NO_PROXY
      value: .svc,.cluster.local,2001:470:ee86:1000::/56,<IP_ADDRESS>/16,2001:470:ee86:4:10:43::/112,<IP_ADDRESS>/16
    - name: FAILURE_POLICY
      value: reinstall
    image: rancher/klipper-helm:v0.8.2-build20230815
    imagePullPolicy: IfNotPresent
    name: helm
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /config
      name: values
    - mountPath: /chart
      name: content
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-6mhth
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  nodeName: k3s-m1
  nodeSelector:
    kubernetes.io/os: linux
    node-role.kubernetes.io/control-plane: "true"
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: OnFailure
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: helm-cilium
  serviceAccountName: helm-cilium
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: node.kubernetes.io/not-ready
  - effect: NoSchedule
    key: node.cloudprovider.kubernetes.io/uninitialized
    operator: Equal
    value: "true"
  - key: CriticalAddonsOnly
    operator: Exists
  - effect: NoExecute
    key: node-role.kubernetes.io/etcd
    operator: Exists
  - effect: NoSchedule
    key: node-role.kubernetes.io/control-plane
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 20
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 20
  volumes:
  - name: values
    secret:
      defaultMode: 420
      secretName: chart-values-cilium
  - configMap:
      defaultMode: 420
      name: chart-content-cilium
    name: content
  - name: kube-api-access-6mhth
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-01-19T13:38:57Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-01-20T00:16:58Z"
    message: 'containers with unready status: [helm]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-01-20T00:16:58Z"
    message: 'containers with unready status: [helm]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-01-19T13:38:57Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://73c16c515f12a8ac89af117e4766478576bca73e4540216b0956820273c6b6e6
    image: docker.io/rancher/klipper-helm:v0.8.2-build20230815
    imageID: docker.io/rancher/klipper-helm@sha256:b0b0c4f73f2391697edb52adffe4fc490de1c8590606024515bb906b2813554a
    lastState:
      terminated:
        containerID: containerd://73c16c515f12a8ac89af117e4766478576bca73e4540216b0956820273c6b6e6
        exitCode: 1
        finishedAt: "2024-01-20T00:16:58Z"
        message: |
          Installing helm_v3 chart
        reason: Error
        startedAt: "2024-01-20T00:16:56Z"
    name: helm
    ready: false
    restartCount: 129
    started: false
    state:
      waiting:
        message: back-off 5m0s restarting failed container=helm pod=helm-install-cilium-jd8pw_kube-system(cd31640c-7bca-48b6-8e76-cac1e4a2a2f2)
        reason: CrashLoopBackOff
  hostIP: 2001:470:ee86:30:192:168:30:21
  phase: Running
  podIP: 2001:470:ee86:30:192:168:30:21
  podIPs:
  - ip: 2001:470:ee86:30:192:168:30:21
  qosClass: BestEffort
  startTime: "2024-01-19T13:38:57Z"

For bootstrap charts,KUBERNETES_SERVICE_HOST is filled in by the helm controller, and always points at the IPv4 loopback address:
https://github.com/k3s-io/helm-controller/blob/f9103f66197ade3a06f4d48c9ea85f48d8c1ff1e/pkg/controllers/chart/chart.go#L556-L557
I know that k3s works on ipv6-only nodes, since k3s binds to a dual-stack address that is accessible via the IPv4 loopback even even when the node does not have a valid IPv4 interface address.
Does your node for some reason not have an IPv4 loopback configured, or have you done something else to modify the apiserver configuration? Are you using the helm controller as part of k3s, rke2, or on some other cluster type? The helm controller is almost exclusively used with k3s and rke2, if you are running it standalone on some other cluster, the assumptions that it makes about apiserver availability when installing bootstrap charts may not be valid.

I do have both IPv4 and IPv6 address on the node. As mentioned earlier, Dualstack works with a combination of {ipv4},{ipv6}.
I didn't try with IPv6 single stack but its interesting to hear it works.
I try few things and added bind-address, and advertised address it solved half the problem. The difference I see is in the listener now both on ipv4 and ipv6.
ss -nltp | grep 6444 LISTEN 0      4096               *:6444             *:*    users:(("k3s-server",pid=6615,fd=19))
And my master node status.
kubectl get nodes -o wide NAME     STATUS   ROLES                  AGE   VERSION        INTERNAL-IP                      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME k3s-m1   Ready    control-plane,master   24m   v1.28.5+k3s1   2001:470:ee86:30:192:168:30:21   <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.11-k3s2
The problem I am facing is with agent and i don't think so it is related to this issue but would love to hear some suggestions if you have.
systemctl status k3s ● k3s.service - Lightweight Kubernetes      Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)      Active: active (running) since Sat 2024-01-20 19:09:34 +08; 4s ago        Docs: https://k3s.io     Process: 3947 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, sta>    Process: 3949 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)     Process: 3950 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)    Main PID: 3951 (k3s-agent)       Tasks: 9      Memory: 21.5M         CPU: 113ms      CGroup: /system.slice/k3s.service              └─3951 "/usr/local/bin/k3s agent" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "> Jan 20 19:09:34 k3s-w1 systemd[1]: Starting Lightweight Kubernetes... Jan 20 19:09:34 k3s-w1 sh[3947]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service Jan 20 19:09:34 k3s-w1 sh[3948]: Failed to get unit file state for nm-cloud-setup.service: No such file or directory Jan 20 19:09:34 k3s-w1 systemd[1]: Started Lightweight Kubernetes.  I think I figured out what the issue was with the agent, it was missing [] in the server url. After adding that, it's working.
kubectl get nodes -o wide NAME     STATUS   ROLES                  AGE     VERSION        INTERNAL-IP                      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME k3s-m1   Ready    control-plane,master   4m3s    v1.28.5+k3s1   2001:470:ee86:30:192:168:30:21   <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.11-k3s2 k3s-w1   Ready    <none>                 3m32s   v1.28.5+k3s1   2001:470:ee86:30:192:168:30:22   <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.11-k3s2


Indexmap Dependency and Old rustc Versions

It looks like indexmap (because of hashbrown) is likely going to move up to 1.56 soon (https://github.com/bluss/indexmap/issues/214 and https://github.com/rust-lang/hashbrown/issues/310). As of a few versions ago serde-yaml now requires indexmap which moves up the minimum rustc version.
Right now I got used to being able to use serde-yaml to support old rustc versions which some users of my crates are still using. Would it be an option to make this dependency optional?

Hashbrown's approach seems fine to me. In my experience almost nobody (let's say 0.5%) cares about building Rust software with anything older than the current stable, or briefly the previous stable when a new one has just come out. Certainly a lot of people run CI builds on various much older toolchains, ostensibly to support some actual user who they think wants that toolchain to work, but if you chase the chain of "this reverse dependency wanted it" to "this second-order reverse dependency wanted it" to "this third-order reverse dependency wanted it" you'll find it always bottoms out in no actual person ever building the software for real use using the old toolchain, so the whole endeavor is almost entirely a waste of everybody's time. The people pinning old toolchains are universally better served by pinning old crate versions using a lockfile anyway.

I suppose this means that serde-yaml is likely to move up to 1.56? Mostly trying to understand my options here.

I think so.


chore(at_app_flutter): Update pubspec.yaml

Changed @ prefix to at

- What I did
Changed @ prefix to at
- How I did it
Markdown editor pubspec.yaml at_app_flutter
- How to verify it
Review edit and approve PR
- Description for the changelog

Thanks @ksanty


Add support to upload certificates in performance profile.

Current Behavior

Right now, there isn’t a support to upload cert files in performance profile, but it's a common test case to send HTTPS request with a self-signed certificate.
Desired Behavior

Add support to upload certificates in performance profile.
Implementation

Acceptance Tests

Mockups

Contributor Guides and Handbook

🛠 Meshery Build & Release Strategy
📚 Instructions for contributing to documentation

Meshery documentation site and source

🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@gyohuangxin Can you describe how you are using fortio (outside meshery) to use certs as part of performance testing?

@MUzairS15 Sure, for example, we use command like fortio load --cacert /path/to/certs https://fortio.com

@MUzairS15 Can we add a title "SSL certificates"?

@MUzairS15 I tried upload the certificates from Meshery UI, but it seems that the certificate was not used:

But it worked when I used curl with certificate:


New API for Version 1.0.0

Comments from Vitaliy: https://github.com/ingonyama-zk/icicle/pull/305#discussion_r1439067332


LinkFolder: all notes without incoming links are counted as _unlinked when Toggle outgoing is disabled

As far as I understand, Obsidian is counting note as unlinked if there is no (at least one) incoming or outgoing link inside it. If you disable Toggle outgoing all the notes without incoming links are counted as unlinked which seems wrong to me:

I was expecting LinkFolder to follow general Obsidian rule independently of the Incoming/Outgoing toggle (which I'm using to tell LinkFoler which links to use when creating virtual folders). Am I wrong?

Just another one image:

I am so sorry for being so late! However, I am really sorry I have not realised what is the matter yet.
When enabling only Incoming, notes which having no backlinks will be shown in _unlinked. This is expected behaviour. (and it is almost the same as _untagged).
However, if you have any ideas to make it better, I hope to ask it!
I think that something strange about Zoo and Bull Terrier. How does it change when 'Hide indirect notes' is enabled?


squid to 0.2.11, kc to 0.4.0 and compatible changes

Description
[x] Updated Squid-py to 0.2.11
[x] Updated keeper-contracts to 0.4.0
[x] Added more debug logs in brizo
[x] Updated test_brizo.py to be compatible with squid changes
[x] Changed keeper-contract docker image to 0.4.0 for squid-py compatibility
Is this PR related with an open issue?
No
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] Follows the code style of this project.
[x] Tests Cover Changes
[x] Documentation

Funny gif

will update versions on previous PR by @ssallam


Add license and copyright notice

Adds license and copyright notice.

Turns out this one already had the license file included.


Allow dynamic update of logging options via API

- What I did

Setup provision for dynamically updating logging options, for re-configuring the logging
driver
Implement the same for json-file logger, for max-size and max-file setting.

- How I did it

Add UpdateConfig method to logger interface.
Add provision to update config via the API route.

- How to verify it

Start a container with --log-driver json-file --log-opt max-size=1m --log-opt --max-file=2
Make a update API call to docker daemon with the following payload

{
    "LogConfig": {
      "Config": {
          "max-size": "2m",
          "max-file": "3"
      }
    }
}

Do docker inspect on the container to verify the LogConfig settings have been updated and
check the size and count of container logs /var/lib/docker/containers/CONTAINER_ID/CONTAINER_ID-json.log.*

- Description for the changelog

Allow dynamic update of logging options via API
Should the vendor change (separate commit here) to engine-api be requested at https://github.com/docker/engine-api ?

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "update-log-opt" git@github.com:r4um/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

looks like your first commit isn't signed off (the second is)

This patch worries me quite a bit. It doesn't seem like there would be a safe way to update the logger, and it needs to be handled separately for each logging driver.
Forgoing any safety issues with the drivers themselves, the log drivers that do not support update need to error out so that that changes aren't silently ignored, and that would cause issues with the rest of the update (assuming the user provided more options).

We discussed this PR in a maintainers review session, and we are currently not comfortable with adding this. There's still quite some issues around logging, and adding more options to it may complicate future decisions (e.g. if we want to move logging drivers to plugins).
I'm closing this PR for that reason, but thanks so much for contributing. Perhaps in future we can reconsider, but for now we cannot accept it.


Reset no longer needed on staking & fix underflow

Address remaining TODO in _increaseUserVoteTrackers() by eliminating reset requirement.
Fixes #108.
Fix possible underflow in withdrawLQTY().
Fixes #109.

I'd fix the invariant tests in a separate PR later, as there are already some broken ones after the voting power refactor.

On the other hand, I dug up the test case I wrote that was demonstrating the bug that was the whole reason for the reset requirement, updated it, and added it to the test suite.

Awesome, thanks!!


run bug fixed due to change off spelling word permission's' in new fl…

Response to the issue #1
Change the spelling of word permission. Add "s" to correspond of the new flutter version.

Before merging this .. can you tell me which version of flutter is causing this issue ?

Thanks


SvelteKit support

I've been working on the SvelteKit implementation for the wallet adapter. Since Vue is very similar to Svelte, I could extrapolate a lot of the code done in #107 by @lorisleiva. I think the adapter is working but I am very newbie with Solana and every time I tried to test a smart contract, this fails. Even I am having issues testing Phantom on localhost.
I am wondering two things:

If it is possible to open a PR with a code that basically is an extrapolation of #107
If it is possible to get some support for the community to test this.

Looking forward to hear from the team.

@jordansexton thanks for the clarification. I've tested with that example and it is working. The transaction is done and the wallet is connecting, persisting and disconnecting correctly.
About the UI/UX implementation, the adapter will need a component we might call <WalletProvider {idl} {localStorageKey} {network} />. That component is done for Anchor but I will need to polish some stuff there. I will ask you about what should be done there for Solana(no Anchor).There will live the initWallet() and the $useWorkspace store. I go to open the PR ;)


Translatable fields are not showing: dev-master (6d1a7d)

After installing and adding the correct additions to contenttypes.yml, config and updating the database.
Two issues:

Existing items now have a Language tab. The tab dropdown items have links like this: http://bla.localhost/bolt/editcontent/paginas/1?_locale=en
but the toggle to the translatable fields don't work. (page reloads instead of showing the right fields)

New items don't show the language tab at all.

In both cases the translate icons for translatable filetypes are missing.

Do you get any Javascript errors in the console?

 Until you have saved it it does not have anywhere to "save" the translations, (I'll try to work around this in the future to allow records to only be in an non-default locale).

The behavior is changed from setting the items via JS to setting them on the backend via the _locale query string. This is done so that we don't have to write specific js code to load fields (both bolt's own and extension fields) and also because the JS we wrote to load/unload fields was probably the most fragile thing about the 2.0 version simply because it was often fighting with bolt's own JS and the way that bolt's ajax save cycle worked.

Sounds to me like it's working as it should and the lib.js sounds like it might be unrelated since it is not from this extension.

paginas:
    name: Paginas
    singular_name: Pagina
    fields:
        locale:
            type: locale
            group: Tekst
        title:
            type: text
            class: large
            label: Titel
            group: Tekst
            isTranslatable: true
        slug:
            type: slug
            uses: title
            group: Tekst
        quote:
            type: text
            class: large
            variant: inline
            label: Quote header
            postfix: '
Wordt over de headerafbeelding getoond
'
            group: Tekst
            isTranslatable: true
        teaser:
            type: html
            height: 150px
            label: Korte introductietekst
            group: Tekst
            isTranslatable: true
        body:
            type: html
            height: 300px
            label: Uitgebreide tekst
            group: Tekst
            isTranslatable: true
        image:
            type: image
            label: Afbeelding header (1000 x 400 pixels. Fotomateriaal altijd jpg maken.)
            group: Media
        credit:
            type: text
            class: narrow
            label: Naam fotograaf
            variant: inline
            postfix: '
'
            group: Media
        selectslideshow:
            type: select
            values: slideshows/title
            label: Selecteer een slideshow voor bovenaan deze pagina
            group: Media
            postfix: '
'
        selectblokje:
            type: select
            values: actieblokjes/title
            label: Selecteer een actieblokje dat op deze pagina getoond wordt
            postfix: '
'
        selectdownload:
            type: select
            values: downloads/title
            multiple: true
            sort: title
            label: Selecteer een of meer downloads die op deze pagina getoond worden
            postfix: '
'
        seo:
            type: seo
            group: SEO
    taxonomy: [ hoofdstukken, tags ]
    record_template: item_pagina.twig
    listing_template: listing.twig
    recordsperpage: 100
    listing_records: 100

@peterboorsma The issue here is just that while fixing a few other things I changed isTranslateable to is_translateable since it better follows bolt's and YAML's rules about key names that way (I thought it was best to fix all the things that has bothered me in one breaking change when I have to bump major versions anyway).
Just change isTranslateable to is_translateable and it should work :)

Yes. I used the old "isTranslatable". Updated them now.
But...
(and I am sorry) the translations aren't stored properly. If you toggle back and forth between the languages the translated fields are not saved.
Is it intentional that the page is refreshed in the browser instead of changing the translatable fields 'ajaxy'? Because that's what's happening.

@peterboorsma yeah, it's intentional to refresh the browser instead of doing it ajaxy... That way it will be much more compatible and robust. The old way of doing it ajaxy would be much harder to make compatible with extensions and would require us to write js for loading values into every extension fieldtype.
For me (when testing with your contenttype) it seems like DB query result is getting cached... Could you try updating page with translations a few times and see if your translations appear then? Perhaps local extensions do not get their DB queries results cached which would explain why I didn't see this when writing the code...

@peterboorsma Or you should be able to disable the cache by adding database: false to the caching config in config.yml so it looks like this:
caching:
    config: true
    templates: true
    request: false
    duration: 10
    authenticated: false
    thumbnails: true
    database: false

I made a copy of my test site on my dev server. Things work fine there so it must be something on my local server. I'll try to figure that out.

Problem fixed with dev-master (7fa12c) + Bolt 3..0.10

Great :)


Add snow ball background

Fixes Issue🛠
Closes #977
Description👨💻

This repository provides a delightful snow ball background effect for web pages.
Type of change📄

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)

How this has been tested✅

Checklist✅

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have added demonstration in the form of GIF/video file
[X] I am an Open Source Contributor

Screenshots/GIF📷
https://github.com/Rakesh9100/Beautiify/assets/113046759/d2eee8d1-f72e-4335-82db-81d6633ca799

@Rakesh9100
Nice addition
Pls merge it


My Circular is unable to pull from Mongo. See screenshot of error.

I set Circular up exactly the way the readme described. Unfortunately, I'm getting this error when I get to the main dashboard.

I looked in Mongo, and it looks like collections are being created.

The issue is related to this: https://jira.mongodb.org/browse/PHP-1051
We just need to surround $app['account']['users'] with array_values():
$m->circular->posts->remove(array(
	'_id'      => new MongoId($id),
	'user._id' => array('$in' => array_values($app['account']['users']))
));

@dhilowitz Do you mind opening a Pull request?

I've created a pull request. (It's issue #59)


Proper installer for the final version?

i think we can have a file that installs python (3.8) for you, and then downloads the program?
there might be 2 problems with my idea however:

the installer wont be able to be written in python
"write once, debug everywhere"

Yes, this is certainly an option we could consider. There are some packager programs too but they don't play nice with the existing code. The one included in the source code creates an EXE successfully byt it will not launch properly.


Band Oracle Integation

Create example with Band Protocol Integration.

Nice suggestion; great to have on Celo Sage or Celo Examples, not on Celo Composer.
Closing issue.


Proposal: better type narrowing in overloaded functions through overload set pruning

TypeScript Version:  2.7.2
Search Terms: type inference, type narrowing, overloads
Code
function bar(selector: "A", val: number): number;
function bar(selector: "B", val: string): string;
function bar(selector: "A" | "B", val: number | string): number | string
{
    if (selector === "A")
    {
        const the_selector = selector;  // "A"
        const the_val = val;            // number | string but should be just number
        return "foo";                   // should give error: when selector is "A" should return a number
    }
    else
    {
        const the_selector = selector;  // "B"
        const the_val = val;            // number | string but should be just string
        return 42;                      // should give error: when selector is "B" should return a string
    }
}

Issue
The snippet above shows a limitation of the current type inference implementation in TypeScript.
As can be clearly seen from the overloaded declarations, when selector === "A" we have val: number and we must return a number, while when selector === "B" we have val: string and we must return a string. But the type-checker, although able to understand that the_selector can only be "A" in the if block and only "B" in the else block, still types the_val as number | string in both blocks and allows us to return a string when selector === "A" and a number when selector === "B".
Possible Solution
In the implementation of an overloaded function, when the type-checker decides to narrow the type of a parameter (as often happens in if-else blocks), it should also remove the overloads that don't match the narrowed parameter type from the overload set, and use the pruned overload set to narrow the types of the other parameters.
Playground Link: https://www.typescriptlang.org/play/#src=
function bar(selector%3A "A"%2C val%3A number)%3A number%3B
function bar(selector%3A "B"%2C val%3A string)%3A string%3B
function bar(selector%3A "A" | "B"%2C val%3A number | string)%3A number | string
{
    if (selector %3D%3D%3D "A")
    {
        const the_selector %3D selector%3B
        const the_val %3D val%3B
        return "foo"%3B
    }
    else
    {
        const the_selector %3D selector%3B
        const the_val %3D val%3B
        return 42%3B
    }
}

Absolutely agreed, this kind of thing would go a long way towards making overloaded functions a lot safer to use. But it might also be a breaking change: overloads can be used to assert/claim type relationships that TS cannot see. Enforcing particular rules may break attempts to use them to circumvent and/or augment those rules in the first place. But then, that usage of overloads always seemed dubious to me...
Also, related to #21879, which is requesting a similar thing for conditional types rather than overloads. The same problems raised there may also apply here.

I'm not sure the problems expressed in #21879 could be a real concern here, as we are not directly infering a generic type instantiation from another. To mirror the example that @DanielRosenwasser gave on #21879:
ts```
function compare(a: string, b: number): number;
function compare(a: T, b: T): number;
function compare(a, b)
{
switch (typeof a)
{
case "string":    // second overload removed, b is number
case "number":    // first overload removed, b is T
default:           // first overload removed, b is T
}
}

As you can see, here we are not infering `b: number` from `a: number` and `compare: function<T>(a: T, b: T)`. So, we are not narrowing a parameter more than what specified in the overload declaration. We are just narrowing it to the overload declarations that are applicable to the current block.

It would be fantastic if we could do something like this:
function f(a: number): void;
function f(a: string, b: string): void;
function f(a, b) {
  if (typeof a === 'number') {
    // `a` is a string and `b` is thus `undefined`
  }
}

The implementation would not be considered one of the overload signatures, and thus the arguments can be properly narrowed.
To preserve compatibility with implicit any, if the feature was only available when noImplicitAny is enabled it would be completely backwards compatible as it would only kick in when there were no type arguments on an overloaded constructor/method/function (right now this is an error).

The solution from @Tiedye basically makes this feature opt-in, which would serve for gradual adoption as people need / want it.

Here is a type-safe workaround by the time this feature is implemented:
type K = string | number | symbol;
const keyIs = <k extends K, C, T extends { [i in k]: unknown; }, V extends { [i in k]: C; }>(
  args: T | V, k: k, c: C): args is V => args[k] === c;
type Return<F, arg extends unknown[], R> = F extends { (...args: arg): R; } ? R : never;

function bar(selector: "A", val: number): number;
function bar(selector: "B", val: string): string;
function bar(...args: ["A", number] | ["B", string]): number | string {
  if (keyIs(args, 0, "A" as const)) {
    let _return: Return<typeof bar, typeof args, number>;
    const [selector, val] = args;
    const the_selector = selector;  // "A"
    const the_val = val;            // just number
    return _return = 42;            // when selector is "A" it returns a number, otherwise it raises an error
  }
  else {
    let _return: Return<typeof bar, typeof args, string>;
    const [selector, val] = args;
    const the_selector = selector;  // "B"
    const the_val = val;            // just string
    return _return = "foo";         // when selector is "B" it returns a string, otherwise it raises an error
  }
}

@RyanCavanaugh what was the outcome of the discussions on this? I troll myself regularly wondering why my overload isn't narrowing within my switch statement 😭

Really? Two years have passed and the issue is still being ignored?
I only see pro here and no one even mentioning any con.

Control flow analysis for dependent parameters(#47190) is an acceptable workaround if all you're wanting is TS to narrow the types of the args once they match a case. However as far as I can tell you're unable to define a return type for each case.
type Bar = (...args: ["A", number] | ["B", string]) =>  number | string

const bar:Bar = (selector, val) => {
    if (selector === "A")
        {
            const the_selector = selector;  // "A"
            const the_val = val;            // is number
            return "foo";                   // won't give error unfortunately
        }
    else
        {
            const the_selector = selector;  // "B"
            const the_val = val;            // is string
            return 42;                      // won't give error unfortunately
        }
}

I'd still rather have overloads work as @lodo1995 described, but this works for me in my case as the return type is the same in both cases and I can avoid this craziness:
  return (val as number).toFixed(2);

Until the feature is implemented, the cleanest solution is to use a discriminated union type.
Example with overloads (Cutlery is not narrowed):
type Food = 'TANGERINE' | 'PASTA';
type Cutlery = 'FORK' | 'SPOON';

function eat(food: 'TANGERINE'): void;
function eat(food: 'PASTA', cutlery: Cutlery): void;
function eat(food: Food, cutlery?: Cutlery) {
  if (food === 'TANGERINE') cutlery;
  else cutlery;
}

Example with discriminated union (Cutlery is narrowed):
type Food = 'TANGERINE' | 'PASTA';
type Cutlery = 'FORK' | 'SPOON';

type Meal = { food: 'TANGERINE'; cutlery: never } | { food: 'PASTA'; cutlery: Cutlery };

function eat({ food, cutlery }: Meal) {
  if (food === 'TANGERINE') cutlery;
  else cutlery;
}

The only "drawback" is that the function now expects a single object containing all the arguments.
For me it's a fair price to pay for having a clean and reliable narrowing.

To avoid making that wall of a comment even longer, I post this useful information in a new comment.
The problems outlined at the end of my previous comment can be fixed by making the never properties optional.
Check the playground.
type Food = 'TANGERINE' | 'PASTA';
type Cutlery = 'FORK' | 'SPOON';

type Meal = { food: 'TANGERINE'; cutlery?: never } | { food: 'PASTA'; cutlery: Cutlery };

function eat({ food, cutlery }: Meal) {
  if (food === 'TANGERINE') cutlery;
  else cutlery;
}

eat({ food: 'TANGERINE' });
eat({ food: 'PASTA' });  // error
eat({ food: 'PASTA', cutlery: 'FORK'});

I feel like I'm spamming, but I trust that one day this will be helpful for someone.

The pattern encouraged here as a work around has very poor performance characteristics for runtime code and basically should not be used for hot-paths.  The allocation of extra wrapper objects so that we can narrow off of a union of interfaces pays a double cost, both for the allocation but also for the inevitable GC interruption.

@runspired I totally agree, it's always a shame to sacrifice runtime performance to address TS shortcomings.

Is the following a problem resulting from this issue, or is it something else?
interface TestType {
    m1(): string;
    m1(arg1: number): number;
}

function mytest(obj: TestType, testNumber?: number) {
    obj.m1(testNumber);
}

As you can see in the Playground example, we have an error when calling m1 complaining that Type 'undefined' is not assignable to type 'number'.
But m1 has an overload that accepts undefined as argument.

@surdu

Is the following a problem resulting from this issue, or is it something else?

No, it’s not this problem or any TS problem—you misunderstand what your code is saying.

But m1 has an overload that accepts undefined as argument.

False. It does not have any overload that accepts undefined—it has an overload that accepts nothing, or an overload that accepts number. obj.m1() and obj.m1(undefined) are not the same thing.
Imagine this situation:
const foo: TestType = {
    m1: function() {
        if (arguments.length >= 1) {
            const arg1: number = arguments[0];
            return Math.pow(arg1, 2) * Math.PI;
        }
        return 'not a circle';
    },
};

(This is a terrible implementation of this signature, and you should almost never use arguments in Typescript, but nonetheless you can.)
Typescript isn’t actually sophisticated enough to understand what we’re doing with arguments here, as we have to use as number, but according to the definition of m1 , arguments[0] as number should be safe when arguments.length >= 1.
But if you call foo.m1(undefined), then arguments.length >= 1 would be true, but arguments[0] as number would be unsafe. You would be doing undefined as number, which isn’t what we thought we were doing, and then we’d be calling Math.pow(undefined, 2) * Math.PI—that yields NaN, for the record, but I had to test it to find out, and it certainly isn’t the string you were expecting.
In short, foo.m1() and foo.m1(undefined) are different—and your signature only allows the former.
The correct way to write TestType is
interface TestType {
    m1(arg1?: undefined): string;
    m1(arg1: number): number;
}

Now it’s clear that we can’t rely on the number of arguments to determine the type of arg1 or the correct return type—we could get foo.m1(undefined) and our implementation has to account for that.
(Also, for the record, this signature is weird, and probably a code smell. Even with my improved version of the signature, Typescript won’t recognize any function as having that signature—to assign m1, you’ll have to use as TestType['m1'] no matter what you do. That problem may well be related to this issue.)

@krryan Thank you for the clarification. That makes much more sense now.
As for the signature, it is a simplified version of what I found in the crypto module from NodeJS

Control flow analysis for dependent parameters(#47190) is an acceptable workaround if all you're wanting is TS to narrow the types of the args once they match a case. However as far as I can tell you're unable to define a return type for each case. It would look like this:
type Bar = (...args: ["A", number] | ["B", string]) =>  number | string

const bar:Bar = (selector, val) => {
    if (selector === "A")
        {
            const the_selector = selector;  // "A"
            const the_val = val;            // is number
            return "foo";                   // won't give error unfortunately
        }
    else
        {
            const the_selector = selector;  // "B"
            const the_val = val;            // is string
            return 42;                      // won't give error unfortunately
        }
}

I'd still rather have overloads work as @lodo1995 described, but this works for me in my case as the return type is the same in both cases and I can avoid this craziness:
  return (val as number).toFixed(2);

Just chiming in to mention what won't work and mention that I recently also trolled myself by thinking overloading/workaround I thought would work could narrow type.
We have a function that takes two arguments, src and dst, and the signature should be either-or:
Originally, we have code that looks like
      if (src instanceof CallerPort && dst instanceof CalleePort) {
        // do something
      } else if (src instanceof IOPort && dst instanceof IOPort) {
        // do something else
      } else { // error handling
      }

Wishing to make it a switch-case and eliminate the possibility of passing in non-matching arguments, I changed the function signature to be
    public connect<R, S extends R>(src: IOPort<S>, dst: IOPort<R>): void;
    public connect<A extends T, R, T, S extends R>(
      src: CallerPort<A, R>,
      dst: CalleePort<T, S>
    ): void;

    public connect<A extends T, R, T, S extends R>(
      src: CallerPort<A, R> | IOPort<S>,
      dst: CalleePort<T, S> | IOPort<R>
    ): void

But in the implementation it won't narrow type. Consequently I tried this modified version of a workaround:
    public connect<A extends T, R, T, S extends R>(
      ...args: [CallerPort<A, R>, CalleePort<T, S>] | [IOPort<S>, IOPort<R>]
    ): void {
      const [src, dst] = args;

But inside of if (src instanceof CallerPort), dst is not narrowed.
This really isn't a huge problem for us as it's really 3 lines of additional code, but I really do think this would be a wonderful feature to add.


[host_callback] Fix the JVP rule for id_tap(result=...)

The previous rule was leaking ad.Zero.
Fixes: #7340

Awesome!  Thanks for the quick fix!!


[Close #16482] Add border-radius to theme's navbar-inverse

[Close #16482] Add border-radius to theme's navbar-inverse

Oh, btw, little protip: you don't need the [Close #1234] in the title—just the description field or the commit :). It being in the title does nothing on GitHub.

Ah cool. Thanks :)

@kkirsche , @mdo Thanks for adding this in. I know it's a minor issue, but it's nice that it was added so quickly.  I'll read the documentation so I can find out what I need to do to submit a fix myself next time.

@secorrales No prob! You can read about contributing here. Feel free to also jump on getbootstrap.slack.com if you have any questions while working on a fix :+1:


Test: CurlWithHTTPCode using -D output

The -D (--dump-header) into stderr to be able to debug curl information
in test failires.
Signed-off-by: Eloy Coto<EMAIL_ADDRESS>

This change is

test-me-please

test-me-please

@cilium/ci please re-review.


Bot Randomly Stops Playing Music

Hey there,
I don't know if anyone else is experiencing this bug, but occasionally the bug will randomly stop playing music, and it produces zero errors, and zero console errors. I think it may have something to do with the connection, but I'm not sure honestly because my voice chat (normally) works perfectly fine, and my internet connection is generally strong to the servers (less than 50ms ping).
Does anyone know what could be the cause for this? Typing (!restart) in the chat seems to work, but we lose the entire queue of songs and everything else, so that doesn't help us very much truthfully, if anything, we'd just like the problem to resolve. It doesn't have a time limit, sometimes the bot will last all night (over 15 hours), and sometimes it'll disconnect in literally 30 minutes. It's all random.
Any help on this at all? What can I change, add or do?

Its because the websocket got closed, most likely by cloudflare.  Known issue, you should just be able to !disconnect !summon it back.  I'm trying to figure out how to fix this properly, its not a simple fix.

I'm having same issue with no error in my logs

There are a couple ways to deal with this right now.  Restarting the bot, obviously, but you lose the your queue.  Same with the !restart command.  You should be able to !disconnect and !summon it back.  Changing the server region should also make it reconnect.

Hey @imayhaveborkedit, I was just wondering if any progress has been made on a solution for this issue? I've found that using both "!restart" (as a stand-alone command), or using "!disconnect" and waiting till the bot leaves the channel, then clicking "!summon" works as well, but that does get annoying when you're in the middle of a long game of League and you have to pause it and close down your client just for something like that.
I know it's not a simple problem to fix, but was just wondering if you'd made any progress at all on something like this.

I added 9109dcd535a82a86743813071cc8be0f0ee1d620 a little while ago.  It seems to work when I used my bot earlier.

Where do I add that? @imayhaveborkedit

You use the latest version of the bot.

Did this problem definitely get fixed? I've got 2 bots running in my discord server and they both appear to disconnect randomly, basically exactly like the initial post of this thread described. Everything else appears to work perfectly.
I only set them up a couple of days ago, so they should be at the latest version (following this guide).

This should be fixed in review branch


fix DQN learning bug

the problem was input was scaled twice - once by the ScaledFloatFrame Wrapper, once by the neural net code.

How about explicitly stating as scale=False? I don't think the default argument value of wrap_deepmind() will change anytime soon, but it is more explicit and clear as rescaling is done by the DQN's nerual network code.

@christopherhesse the second scaling was happening in the input of cnn (baselines/common/models.py:conv_only)
@wookayin Good point, however, I'd rather eventually get rid of the split logic in run.py (where different set of wrappers is built for different algorithms

Ah, thanks.  I also saw some scaling here: https://github.com/openai/baselines/blob/4e2a888273f14c437fe6e036904e91c122ff9643/baselines/deepq/utils.py#L43 but this function doesn't appear to be used anywhere.

yes; in fact, let me delete it

yes, good point, thanks!


[stable/elasticsearch] allow to have a single-node cluster.

What this PR does / why we need it:
Allow to have a single-node cluster.
Can be needed in case of small tests deployments.
My own use case : lots of projects, each projects have 4 environments but two of them are basically sandboxes / development deployments. Having an easy-to-change switch to set "single node" or normal deployment depending on environment type is a huge step forward for me instead of having useless master/client nodes taking a lot of place.
Note: not sure how to handle indents here, feel free to tell me to change if you think it is needed.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

cc @simonswine @icereval @rendhalver

We can probably achieve this with #7819

We can probably achieve this with #7819

As it stands it would be possible but it would be awkward (0 replicas for coordinating nodes deployments and master nodes), but we could add enable flag to such deployments and related objects, and we could change names to make it more generic.
Would the above mentioned approach be acceptable? I'd be happy to improve #7819 to fully support this (and more, as it would make it more flexible).

Isn't that independent? In my use case, I only want to... basically disable everything. Do you want to disable anything AND set a custom data type using #7819?
Moreover, I think having a very simple, lightweight way to deploy this chart (basically, a simple switch) is good for testers and newcomers, independently to using #7819 or not.

Isn't that independent? In my use case, I only want to... basically disable everything. Do you want to disable anything AND set a custom data type using #7819?

I think the way to achieve this with #7819 would be the one you mention: disabling everything and adding a new node type. However we should rename dataTypes to nodeTypes, as it is actually possible to change the node type (we could set it as master also). So it could be achieved that way, and it's not necessarily independent.

Moreover, I think having a very simple, lightweight way to deploy this chart (basically, a simple switch) is good for testers and newcomers, independently to using #7819 or not.

I agree with you that doing it with #7819 feature's would not be as simple as this PR's (for newbies): you'd still need to configure a nodeType "from scratch", while with this PR's solution it would be just a switch.
Disclaimer: I just wanted to give more insights on what's currently possible with #7819 without having to read the whole PR, and not necessarily express my opinion on this PR.

@rendhalver any preference about having "easy" single node vs harder-but-cleaner way of doing this?

@rendhalver any preference about having "easy" single node vs harder-but-cleaner way of doing this?

@rendhalver any preference about having "easy" single node vs harder-but-cleaner way of doing this?

@rendhalver any preference about having "easy" single node vs harder-but-cleaner way of doing this?

Good point.
/ok-to-test

/assign

@rendhalver any preference about having "easy" single node vs harder-but-cleaner way of doing this?

Just added one more commit about commenting out MINIMUM_MASTER_NODES, default should already be 2 even if not defined.

Rebased.

Here is a proposition with the last commit, feel free to discuss as I don't want to impact long-term maintenance by cluttering the chart.

@christian-roggia Thoughts on this?

@rendhalver I'll be back from vacation on Wednesday but so far the PR itself looks good, I am just concerned about the growing complexity of the chart which makes it less readable and transparent.
I wonder if this should be a separated chart instead, maybe you can share your opinion on this.

@christian-roggia it is definitely getting more complex.
A separate chart might be a good plan.

@desaintmartin does a separate chart sound good for you?

For my use case, I have to switch from single-node to full-featured cluster from a single switch (separate test/production environments for a project, almost same configuration between the two but test is a single-node). Maybe it can be done with requirements.yaml black magic.
I'm more afraid about divergence between a single-node chart and this one (as it happens with other charts having several flavours).

As much as I agree with you owners here about the growing complexity of the chart, I would definitely confirm desaintmartin's approach with this PR:

a separate chart will diverge sooner or later
and anyways users' automation would have to be different between various local/test/stage/prod environments, which is not really good practice and a no-go for most teams

Elasticsearch is intrinsically complex, and there's been an amazing job from the incubator up to stable to accurately describe Elasticsearch complexity in a somewhat simple chart for anyone used to Helm.
Looking at the diff on this PR, it really is about disabling client Deployment and master StatefulSet while reusing everything else (which is really smart), and describing further a use case of Elasticsearch: a single node, here the data, covered by the existing StatefulSet.
Having 1 pod for developers locally in minikube instead of 7 is a life changer, same for integration tests or equivalent to avoid massive and costly deployments on ephemeral environments. From a developer standpoint you really are using 1 endpoint for Elasticsearch, and testing your system/application is not about testing this helm chart. Staging environments, where we usually allow more resources on the long run, would help uncover any edge case anyways.

I had the case where I wanted to test for PR review a deployment that did not need full cluster and I almost forgot it was not in upstream. This is a very handy feature for me.
Should we close this or should we reconsider the PR and/or how it is done?


after failing to synchronize file meta information with ufs, accessing related files will directly fail

Alluxio Version:
2.9.0/2.9.1
Describe the bug
We use alluxio to speed up access to the dataset on s3 for ai training;
These datasets are usually read-only, so we will perform warm-up operations before starting training to scale the waste of gpu resources caused by the slow access of the first epoch;
The fs loadMetadatacommand is used to synchronize meta information during warm-up, but we found that after failing to synchronize file meta information with ufs (some list objects request timed out due to occasional instability of s3), accessing related files will directly fail if resynchronization is not forced (for read-only datasets, there is no need to set periodic synchronization meta information;);
These synchronization errors will not be directly returned to the fs loadMetadata command, it is difficult to find without the master log;
Expected behavior
when failed to synchronize file metadata with ufs, alluxio can mark the relevant path; next accessing these paths, master can sync metadata information from ufs again;
Additional context
An optional parameter can be added, when using the fs loadMetadata command to synchronize file metadata from ufs , if an exception occurs, the synchronization can be interrupted and an exception will be thrown. In this way, we can intercept errors in the preparation stage such as warm-up, which is cheaper than the interruption cost of errors during training.

@tcrain @yuzhu for visibility

@wwq2333 we will include this in our metadata sync redesign


[SIL][PackageCMO] Fix dispatch thunk linker error and update table serialization

Do not use [serialized_for_package] for witness method before Package CMO.
Update v-table and witness-table and their entry serialization. -- Allow non-serialized but visible entries in a serialized table so they can be optimized by other SIL opt passes.
Only serialize MethodInst if it has the right visibility.

Resolves rdar://129089105&129088935

@swift-ci test

@swift-ci test

Does this PR #73902 need to be merged first? It seems this PR would have a dependency on it.

yup, merged.

@swift-ci test


Program test cases do not pass

Thank you for your codes.
I have a problem GPU version warp-transducer.
Source code compilation is ok, but the program test (build/test_gpu) did not respond.
thank you
pytorch 1.0.1
centos 7
cuda 10
Tesla V100-PCIE

@liqiang4113 CUDA10 may not support yet, please try CUDA9.0

@HawkAaron
I have a same problem.Tesla V100 , and cuda 9.0 ,the program test (build/test_gpu) also did not respond

V100 :The program does not respond to test. How to adjust in codes?
CUDA10 : loss value is sometimes nan but the learning rate is already very low

@HawkAaron Thanks for your help. Tesla V100 ,I wonder  why the test program does not pass on such a high configuration device. What is the problem and can you give us some pointers?

@liqiang4113 Could you use warp-ctc in Tesla V100 ? Since don't have this kind of device, I may not be able to help.

@HawkAaron Thanks. Warp-ctc is OK in Tesla V100. When running the following line of code, there is no response and No error messages are generated. costs = rnnt_loss(logits, labels, input_length, label_length, blank) (test_basic.py)

There were some updates recently, could you please run the test again ?


Revert the pipeline- changes

Revert "Fix some typos (#871)"
Revert "Store the pipeline ID directly in the pipelineId parameter (#845)"

What does this PR do?
We found some issues and we'll investigate once the problem will be fixed in the agent
Which scenarios this will impact?
Motivation
Additional Notes

/merge


[UX] If validation failed API walkthrough path will get broken

Description:
If the user accidentally typed name with space and hit tab to next step they can't go back and continue the walkthrough.

The same thing happened if you missed any of the steps and try to fix the previous step.
Suggested Labels:
bug
Affected Product Version:
2.1.0 update 14
OS, DB, other environment details and versions:
MacOS High sierra

Will be tracked with https://github.com/wso2/product-apim/issues/1832


Sequencer: Log contents of block production

We want a pretty level of logging likely in sequencer relayer which can provide a breakdown of the following information:

Who the tendermint proposer was for the block
Each secondary chain id included and number of txs included
DA block height the data is stored at

This ideally should be done in such a way that it looks ✨pretty✨ and can be filtered to in order to display this information in a demo environment.


Missing some context

Instead of just "Relation XXX" the list could contain some human readable context, the easiest being name tag on the problematic relation, if exists.

Fixed, thabk you for suggestion


[QA]: Integrate SDK-API-Tester in CI

QA
Description
In context of issue https://github.com/kitsudaiki/Hanami-AI/issues/98 the microservice architecture was removed from the project. Since then the deployment is much easier and requires less hardware-resources. With this it should be possible to integrate the SDK-API-Tester into the CI-pipeline for automatic API-tests. The new Ansible-playbook, which will be created in context of issue #124, should be used to deploy the project within the CI-docker-container without kubernetes.
Acceptance Criteria

at least in case of a merge-request, a complete deploy-process with SDK-API-Test is performed by the CI-pipeline

Related Issues

#98
#124

need and external ci-runner

Added basis sdk-api-test to ci-pipeline. To also test in a kubernetes or ansible setup, the issue https://github.com/kitsudaiki/Hanami/issues/269 has to be solved first.

Added integration tests to CI for kubernetes- and ansible-setup on amd64 and arm64


Changes in menu and zen mode activation

all changes are detailed here:
https://docs.google.com/document/d/1Ut8M56YDg74ySAvnYy-RwuXKVHtORZa-MXuqGyuaj0Q/edit?usp=sharing

@liatzionimorad I think isn't a bug. May be enhancement?

@nikshirobokov  I agree.


Inventory Update Item

This ain't an issue but it's a feature suggestion.
I couldn't find any type of method to update the item and still keeping his click, or even change it.

This really doesn't exist in the project yet, I should bring this feature in some time.


@stylex/open-props import (bug)

When importing the @stylexjs/open-props package im getting this error:
chunk-AEPY33DS.js?v=df81b0f4:401 Uncaught Error: stylex.defineVars should never be called. It should be compiled away.
    at stylexDefineVars (chunk-AEPY33DS.js?v=df81b0f4:401:13)
    at @stylexjs_open-props_lib_colors__stylex.js?v=e2f9464a:10:43

import * as stylex from "@stylexjs/stylex";
import { colors } from<EMAIL_ADDRESS>
const styles = stylex.create({
  base: {
    color: colors.blue11,
  },
});

function Button() {
  return <button {...stylex.props(styles.base)}>Click me!</button>;
}

export { Button };

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { stylexPlugin } from "vite-plugin-stylex-dev";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react(), stylexPlugin()],
});

I get the same error with the default vite react typescript template.
I made a sandbox to reproduce the error: https://stackblitz.com/edit/vitejs-vite-bmmdyh

Sry for late, I property know why reason cause it. Here is a relative issue https://github.com/facebook/stylex/issues/112.
In vite,vite will do a pre build in development. so stylex can't get the right entry to process. https://vitejs.dev/config/dep-optimization-options.html#optimizedeps-exclude look it, currently stylex don't provide esm so we can't use optimization :(

I think it not a bug and i create https://github.com/facebook/stylex/discussions/258

Maybe this is helping: https://github.com/HorusGoul/vite-plugin-stylex/issues/23

@Lukjuh I know, As a temporary solution I can solve it but I feel it is right for stylex to solve it

I release v0.1.3 try it plz.

Still hitting this


Tabris Calendar widget - iOS

are there plans to include an iOS version of this widget? or is this just a demonstration of how to create custom widgets on Android?
https://github.com/eclipsesource/tabris-calendar

Currently it is just a demonstration how to create a custom widget but we will also introduce iOS support in the future. Alas... PRs are welcome. :)

Since there is no direct counterpart to the Android CalendarView on iOS, i will close this issue. Please continue the discussion on https://github.com/eclipsesource/tabris-calendar


Add support for persistent user comments to portfolio.

nit: Basaam, this covers up to step 5, is that right?

Yes, up to and including step 5


make summary optional and style tweak

Hi Selva,
Can you give this a quick review pls.
Thanks
Raq

Do we also need to make blogPost summary field optional ?

Do we also need to make blogPost summary field optional ?

has always been mandatory - so will ask wider team in ticket.


JSX routes only?

Will this SDK only support JSX routes? I'm trying to use async route definitions like this (from @davezuko's react-redux-starter-kit) with no success:
definition:
import CoreLayout from '../layouts/CoreLayout/CoreLayout'
import Home from './Home'

export const createRoutes = (store) => ({
  path: '/',
  component: CoreLayout,
  indexRoute: Home,
  getChildRoutes (location, cb) {
    require.ensure([], (require) => {
      cb(null, [
        // Provide store for async reducers and middleware
        require('./ChildRoute').default(store)
      ])
    })
  }
})

export default createRoutes

usage:
import React, { PropTypes } from 'react'
import ReactDOM from 'react-dom'
import { Provider } from 'react-redux'
import createStore from './store/createStore'
import ReactStormpath, { Router } from 'react-stormpath'
import { useRouterHistory } from 'react-router'
import { syncHistoryWithStore } from 'react-router-redux'
import createBrowserHistory from 'history/lib/createBrowserHistory'

const browserHistory = useRouterHistory(createBrowserHistory)({
  basename: __BASENAME__
})
const initialState = window.___INITIAL_STATE__
const store = createStore(initialState, browserHistory)
const history = syncHistoryWithStore(browserHistory, store, {
  selectLocationState: (state) => state.router
})

const MOUNT_NODE = document.getElementById('root')

let render = (routerKey = null) => {
  const routes = require('routes').default(store)

  ReactStormpath.init({
    dispatcher: {
      type: 'redux',
      store
    }
  })

  ReactDOM.render(
    <AppContainer
      store={store}
      history={history}
      routes={routes}
      routerKey={routerKey}
    />,
    MOUNT_NODE
  )
}
render()

class AppContainer extends React.Component {
  static propTypes = {
    history: PropTypes.object.isRequired,
    routes: PropTypes.array.isRequired,
    routerKey: PropTypes.number,
    store: PropTypes.object.isRequired
  }

  render () {
    const { history, routes, routerKey, store } = this.props

    return (
      <Provider store={store}>
        <div style={{ height: '100%' }}>
          <Router history={history} children={routes} key={routerKey} />
        </div>
      </Provider>
    )
  }
}

Thanks for reporting this issue. I'm going to look into it. I think the issue here is that the type property of the route is missing, and that is what we are looking at when we are mapping up the routes (see https://github.com/stormpath/stormpath-sdk-react/blob/master/src/components/Router.js#L59). In theory it should work if you add the property type and in that, specify the React-Stormpath router types (HomeRoute, AuthenticatedRoute and LoginRoute).

Thank you for your quick response! Unfortunately, adding the HomeRoute did not solve the issue.
However, I threw a try/catch around render() and caught this, which seems like it may be helpful.

Error: Objects are not valid as a React child (found: object with keys {type, path, component, indexRoute, getChildRoutes}). If you meant to render a collection of children, use an array instead or wrap the object using createFragment(object) from the React add-ons. Check the render method of Router.

It seems that the routes prop is expected to be a JSX component exclusively, and it doesn't seem as though the childRoutes prop for PlainRoute objects. React Router's Router implementation supports passing PlainRoutes to both. https://github.com/reactjs/react-router/blob/master/docs/API.md#plainroute


[Proposal] Proto.Persistence.IEventStore should provide  PersistEventsAsync that accept multiple events as argument

Currently Proto.Persistenece.IEventStore only supports persisting single event at the tame.
Task<long> PersistEventAsync(string actorId, long index, object @event);

This may not be good option for some cases. For instance, (and this just my preference) if we are using journal db like EventStore, the client will create ACID until that single event is persisted in EventStore regardless there are other events in batch that should belong to that same ACID transaction.
As a consequence to above case, some other instance could host same persistent actor and write another event. There is very small possibility that this may occur, but again, may produce later false state in Aggregate due unintended event ordering.
I would like to extend IEventStore interface with another function with following signature
Task<long> PersistEventsAsync(string actorId, long index, object[] @event);

This would help utilize EventStore ACID transactions on steam while appending batch of events to it, plus, prevent incidental appends from other "sources" until transaction completes.
I'm open to create PR. Let me know if you are OK with this suggestion.
Thank you

It's not a very small possibility actually. I ran into this issue while migrating events from one database to another.
Happened randomly, so it took a painful while to figure out how it was possible for the order to get mixed up.

@mjaric did you find a way around this?

@mjaric did you find a way around this?

I created my persistence plugin. But I can create PR. Tho in such case I have to update all plugins in this repository 😅 before it ends in nuget.

One more thing. Since, comparing to akka.net, proto.actor actually do not require from you to create system actor that extends this framework in order to add eventsourcing. I think you can create your abstract repository and go that route, one aggregate root, one repository.... I like this because everything becomes much simpler to test where in akka you are tight coupled to test kit and your BDD test case start to look like integration test... but that's just opinion.


update readme

Update readme.
Screenshot is in french, google decided to make it french.
But does it really matters ?

Needs to be in English, I'll take some screenshots and send them to you.  Right now I'm having trouble disconnecting (maybe the tokens last for 1/2 hour after you disconnect).

updated with english screenshot.


Does not support CDK tokens properly

Expected Behavior
This should work, but it doesn't.
const datadogSite = ssm.StringParameter.fromStringParameterName(this, `${prefix}-datadog-site`, "/datadog/site");
const datadog = new Datadog(this, datadogName, {
      site: "us5.datadoghq.com", //datadogSite.stringValue, // Site is required for the sender extension layer set by extensionLayerVersion
      apiKeySecretArn: datadogAPIKey.secretArn,
      extensionLayerVersion: 25, // This is the datadog agent in lambda form. This is what sends stuff async to DD
      env: props.environmentName, // This sets the environment name for the lambda
      service: prefix, // This is the service name in DD
      version: packageVersion, // This is the version of the code we are running. This lets DD know about deployments.
      nodeLayerVersion: 81,
});

Actual Behavior

Since the CDK passes this to a token at synth time, the checks do not recognize it and mark it as invalid.
Datadog Site Value: ${Token[TOKEN.532]}
Specifications

Datadog Lambda Layer version: NA
Node version: v16.15.1
datadog-cdk-constructs-vs: 0.3.4 - just installed today

Stacktrace
/Users/.../node_modules/datadog-cdk-constructs-v2/src/common/datadogSharedLogic.ts:25
  throw new Error(
        ^
Error: Warning: Invalid site URL. Must be either datadoghq.com, datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, or ddog-gov.com.
  at Object.validateProps (/Users/dmurawsky/projects/croissant-services/node_modules/datadog-cdk-constructs-v2/src/common/datadogSharedLogic.ts:25:11)
  at new Datadog (/Users/dmurawsky/projects/croissant-services/node_modules/datadog-cdk-constructs-v2/src/datadog.ts:45:5)
  at new RetailerServicesStack (/Users/dmurawsky/projects/croissant-services/lib/retailer-services/retailer-services-stack.ts:432:21)
  at Object.<anonymous> (/Users/dmurawsky/projects/croissant-services/bin/croissant-services.ts:72:31)
  at Module._compile (node:internal/modules/cjs/loader:1105:14)
  at Module.m._compile (/Users/dmurawsky/projects/croissant-services/node_modules/ts-node/src/index.ts:1618:23)
  at Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
  at Object.require.extensions.<computed> [as .ts] (/Users/dmurawsky/projects/croissant-services/node_modules/ts-node/src/index.ts:1621:12)
  at Module.load (node:internal/modules/cjs/loader:981:32)
  at Function.Module._load (node:internal/modules/cjs/loader:822:12)

Subprocess exited with error 1

This is also the cause of a problem with the subscription filter names. It is valid (and even preferable) to pass a CDK token for the forwarder ARN. However, it is, of course, inappropriate to use the token to generate the subscription filter name since it changes each deployment. But this is exactly what the code does.

Fix has been released


Invalid type symbol given when a tuple is returned

Description:
Consider the following scenario,
function testTuple() returns string {
    return ["string", 10];
}

In the above case when we check the type of [string,10], it returns CompilationError.

Relates to #36167

Related spec doc: https://ballerina.io/spec/lang/master/#list-constructor

Here the contextual type is wrong, This happens for the mapping-constructor, table, and stream type as well. According to the compiler implementation, if the contextual type is wrong, the type, determined type and the expected type become no-type. which makes the Semantic API send a CompilerError when evaluating the type

Discussion on this: https://ballerina-platform.slack.com/archives/C9WMA6QDC/p1656578341414059

Since the contextual type is wrong, this behaviour is correct.


Add oven support

Add oven (OV) category support.
It works fine with my oven model is a Haier HWO60SM2F3XH.
The one "problem" is the huge options of programs, because show the standar programs, the special programs and the recipe list.
I think that Selects should be a parameter for filter some options that contains a string ("recipe" in my case).

Hey, awesome! Thank you for adding this! :smiley:
I have thought about this "problem" and I think a clean solution here is to solve it via the pyhOn library. I have implemented this as I thought it could be work in v0.5.0, you should be able now to create a Select with the key program_filter. Can you test this and maybe create a pr here?
I'm not sure if I understood it correctly, is it right to filter it by it's program name? Feel free to correct my code in the pyhOn library :slightly_smiling_face:


import: Fix typo in _init_dir invokation.

I think I've caught this typo. HTH.

Looks good. Thanks!


🐞 [Bug]: The (Yes) Button has no label to vote on proposals

Is there an existing issue for this?

[X] I have searched the existing issues

which package/s did you face the problem with?
Dashboard
What happened?

when trying to vote on proposals I observed that the (Yes) button has no label.

Steps To Reproduce

Navigate to https://dashboard.test.grid.tf/
Connect your wallet.
From the sidebar, select TFChain then click on TF DAO.

which network/s did you face the problem on?
Test
version
2.5.0-rc2
Twin ID/s
No response
Node ID/s
No response
Farm ID/s
No response
Contract ID/s
No response
Relevant screenshots/screen records

Relevant log output
-

Verified, Devnet 08a275d.


disparity in the left figure is all 0

hi. disparity in the left figure is all negative. When executing evaluate in eval.py on SceneFlowFlyingThingsDataset,   torch.all(invalid_mask)  is True which cause valid_samples in eval.py is 0.  eval_stats['epe'] = eval_stats['epe'] / valid_samples  in  eval.py report error.

I think you have downloaded the wrong scene flow dataset. The other dataset uses inverse disparity and their disparity is all negative. Can you check if this is the case?

Thank you very much. Sorry to bother you, I have another question.

I think you have downloaded the wrong scene flow dataset. The other dataset uses inverse disparity and their disparity is all negative. Can you check if this is the case?

Thank you very much. Sorry to bother you, I have another question.  Which dataset of FlyingThings3D subset, FlyingThings3D and Scene Flow (including FlyingThings3D, Driving, Monkaa) is used in Table 1 in the paper.

I think you have downloaded the wrong scene flow dataset. The other dataset uses inverse disparity and their disparity is all negative. Can you check if this is the case?

Thank you very much. Sorry to bother you, I have another question.  Which dataset of FlyingThings3D subset, FlyingThings3D and Scene Flow (including FlyingThings3D, Driving, Monkaa) is used in Table 1 in the paper.

I think you have downloaded the wrong scene flow dataset. The other dataset uses inverse disparity and their disparity is all negative. Can you check if this is the case?

Thank you very much. Excuse me, I have another question. Which of the FlyingThings3D subset, FlyingThings3D, Scene Flow Datasets (including FlyingThings3D, Driving, Monkaa) datasets is used for the result in table 1 in the paper .


Update std to 0.63.0

Hello, I wanted to update std.
Please do not merge until bytes_formater is updated too.

ci failed

@manyuanrong This needs updating to std 0.63.0 urgently

@manyuanrong This is failing due to the deno version being 1.0.0 and not 1.2.2 please can you update the CI to support the latest version of deno to fix std issues.

Can we get the byte formatter put back to deno.land as well please for the cdn

#67


InfiniteHits cache cannot get invalidated

🐛 Bug description
We have cache object passed to InfiniteHits, but we store the hits in cachedHits. So cachedHits becomes the second layer of cache, which cannot be invalidated. InfiniteHits always should reflect the status of cache.
🔍 Bug reproduction
Steps to reproduce the behavior:

Go to https://codesandbox.io/s/compassionate-goldberg-bmltl?file=/src/app.js
Click on "Clear Cache" button
The hits are not refreshed.

💭 Expected behavior
We should either get rid of cachedHits or make it up-to-date with cache.
Environment

OS: macOS 10.15.7
Browser: FireFox
Version: 81.0.1 (64-bit)

I think the way to go is to get rid of cachedHits (but maybe only when cache is given, otherwise the default experience might fail?)

I think the way to go is to get rid of cachedHits (but maybe only when cache is given, otherwise the default experience might fail?)

cache is always given (getInMemoryCache() by default), so it should be okay.


Logic signature validation

validate LSig (delegated signature or escrow account) when processing a transaction.
added multisignature verification.
add tests for single and multisignature
Full runtime support will be done in another task

I'm not sure if this is the right way - creating logicsig can be don through SDK. We also have few helper functions in algob. If we need to use them, then the best way will be to move that functions to other package, or to this package (in both cases algob will import a package with that functions).
The dependency flow is runtime -> algob (so algob depends on runtime, and runtime shouldn't import anything from algob).
Left few questions.

algob functions use compiled program. compiled program needs network connection.
so i think we can use algosdk directly if SDK functions can work without compiled bytes.
confirming by independent testing.

I'm not sure if this is the right way - creating logicsig can be don through SDK. We also have few helper functions in algob. If we need to use them, then the best way will be to move that functions to other package, or to this package (in both cases algob will import a package with that functions).
The dependency flow is runtime -> algob (so algob depends on runtime, and runtime shouldn't import anything from algob).
Left few questions.

algob functions use compiled program. compiled program needs network connection.
so i think we can use algosdk directly if SDK functions can work without compiled bytes.
confirming by independent testing.

confirmed, cannot use SDK function because of compiled bytes.

confirmed, cannot use SDK function because of compiled bytes.


Fix race in ScriptServer.

Fixes #76581.
TSAN flagged this issue on starting the editor:

main calls register_core_types, which calls IP::create(), which calls Thread::start on the resolver thread
Thread::callback calls ScriptServer::thread_enter(), as "Scripts may need to attach a stack."
ScriptServer::thread_enter() accesses ScriptServer::_languages, which is still being initialized on the main thread by initialize_gdscript_module

This fixes the issue by skipping thread enter/exit notifications if languages have not finished initializing yet.
I'm assuming that notifying un-initialized languages of thread starts/stops would have been pointless anyways. If we need to somehow notify languages of threads before the languages initialize, we'll need a different solution.
Godot Engine v4.0.2.stable.custom_build.7a0977ce2 - https://godotengine.org
==================
WARNING: ThreadSanitizer: data race (pid=9426)
  Write of size 4 at 0x55615b187cd0 by main thread:
    #0 ScriptServer::register_language(ScriptLanguage*) /home/rcorre/src/godot/godot/core/object/script_language.cpp:177:28 (godot.linuxbsd.editor.x86_64.llvm.san+0x9e52ab9) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #1 initialize_gdscript_module(ModuleInitializationLevel) /home/rcorre/src/godot/godot/modules/gdscript/register_types.cpp:118:3 (godot.linuxbsd.editor.x86_64.llvm.san+0x36f9c6f) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #2 initialize_modules(ModuleInitializationLevel) /home/rcorre/src/godot/godot/modules/register_module_types.gen.cpp:93:2 (godot.linuxbsd.editor.x86_64.llvm.san+0x2f50499) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #3 Main::setup2(unsigned long) /home/rcorre/src/godot/godot/main/main.cpp:1961:2 (godot.linuxbsd.editor.x86_64.llvm.san+0x2f1d40d) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #4 Main::setup(char const*, int, char**, bool) /home/rcorre/src/godot/godot/main/main.cpp:1879:10 (godot.linuxbsd.editor.x86_64.llvm.san+0x2f16370) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #5 main /home/rcorre/src/godot/godot/platform/linuxbsd/godot_linuxbsd.cpp:61:14 (godot.linuxbsd.editor.x86_64.llvm.san+0x2e67e1f) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)

  Previous read of size 4 at 0x55615b187cd0 by thread T1:
    #0 ScriptServer::thread_enter() /home/rcorre/src/godot/godot/core/object/script_language.cpp:244:22 (godot.linuxbsd.editor.x86_64.llvm.san+0x9e54aed) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #1 Thread::callback(unsigned long, Thread::Settings const&, void (*)(void*), void*) /home/rcorre/src/godot/godot/core/os/thread.cpp:61:2 (godot.linuxbsd.editor.x86_64.llvm.san+0x9464ab0) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #2 void std::__invoke_impl<void, void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*>(std::__invoke_other, void (*&&)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long&&, Thread::Settings&&, void (*&&)(void*), void*&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/bits/invoke.h:61:14 (godot.linuxbsd.editor.x86_64.llvm.san+0x9465283) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #3 std::__invoke_result<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*>::type std::__invoke<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*>(void (*&&)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long&&, Thread::Settings&&, void (*&&)(void*), void*&&) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/bits/invoke.h:96:14 (godot.linuxbsd.editor.x86_64.llvm.san+0x9465283)
    #4 void std::thread::_Invoker<std::tuple<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*>>::_M_invoke<0ul, 1ul, 2ul, 3ul, 4ul>(std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul>) /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/bits/std_thread.h:258:13 (godot.linuxbsd.editor.x86_64.llvm.san+0x9465283)
    #5 std::thread::_Invoker<std::tuple<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*>>::operator()() /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/bits/std_thread.h:265:11 (godot.linuxbsd.editor.x86_64.llvm.san+0x9465283)
    #6 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(unsigned long, Thread::Settings const&, void (*)(void*), void*), unsigned long, Thread::Settings, void (*)(void*), void*>>>::_M_run() /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/bits/std_thread.h:210:13 (godot.linuxbsd.editor.x86_64.llvm.san+0x9465283)
    #7 execute_native_thread_routine /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:82:18 (libstdc++.so.6+0xd72c2) (BuildId: 6fe66a2d539a78c993bd2d377e00fad389220963)

  Location is global 'ScriptServer::_language_count' of size 4 at 0x55615b187cd0 (godot.linuxbsd.editor.x86_64.llvm.san+0xbf46cd0)

  Thread T1 (tid=9431, running) created by main thread at:
    #0 pthread_create <null> (godot.linuxbsd.editor.x86_64.llvm.san+0x2de5776) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #1 __gthread_create /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:663:35 (libstdc++.so.6+0xd73a9) (BuildId: 6fe66a2d539a78c993bd2d377e00fad389220963)
    #2 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State>>, void (*)()) /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:147:37 (libstdc++.so.6+0xd73a9)
    #3 IP::IP() /home/rcorre/src/godot/godot/core/io/ip.cpp:347:19 (godot.linuxbsd.editor.x86_64.llvm.san+0x962cbcd) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #4 IPUnix::IPUnix() /home/rcorre/src/godot/godot/drivers/unix/ip_unix.cpp:261:9 (godot.linuxbsd.editor.x86_64.llvm.san+0x4aee599) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #5 IPUnix::_create_unix() /home/rcorre/src/godot/godot/drivers/unix/ip_unix.cpp:258:9 (godot.linuxbsd.editor.x86_64.llvm.san+0x4aee599)
    #6 IP::create() /home/rcorre/src/godot/godot/core/io/ip.cpp:339:9 (godot.linuxbsd.editor.x86_64.llvm.san+0x962ca5e) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #7 register_core_types() /home/rcorre/src/godot/godot/core/register_core_types.cpp:279:7 (godot.linuxbsd.editor.x86_64.llvm.san+0x93e2333) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #8 Main::setup(char const*, int, char**, bool) /home/rcorre/src/godot/godot/main/main.cpp:690:2 (godot.linuxbsd.editor.x86_64.llvm.san+0x2f08a49) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)
    #9 main /home/rcorre/src/godot/godot/platform/linuxbsd/godot_linuxbsd.cpp:61:14 (godot.linuxbsd.editor.x86_64.llvm.san+0x2e67e1f) (BuildId: 780a9db7c37d88e78d5ee659c4fa1cd378abd048)

SUMMARY: ThreadSanitizer: data race /home/rcorre/src/godot/godot/core/object/script_language.cpp:177:28 in ScriptServer::register_language(ScriptLanguage*)

See also #74501 , which is a different workaround (in both PRs, WorkerThreadPool remains broken for languages that need initialization)
Only one of these two should be merged.

cc @RandomShaper could you please take a look?

For 4.1, let's go with this one, just to be sure (there may be custom language extensions relying on these calls).
Post-4.1, we would really have to look into #49362.
In any case, there are changes to make here.

Thanks!