Cilium-Envoy stops receiving config updates once there is one invalid listener config with Gateway API

Is there an existing issue for this?

[X] I have searched the existing issues

Version
equal or higher than v1.16.0 and lower than v1.17.0
What happened?
Once a gateway has an invalid config inside one of its listeners (i.e. missing TLS secret), it stops receiving routing configuration updates i.e. no new routes are being served (on the non TLS listener).
How can we reproduce the issue?

Install cilium with helm and enable gateway api
Deploy a basic gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: default-gateway
  namespace: default
spec:
  gatewayClassName: cilium
  listeners:
  - allowedRoutes:
      namespaces:
        from: All
    name: default-http
    port: 80
    protocol: HTTP
```
3. Deploy a simple HTTP Route
```
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: whoami-route
  namespace: default
spec:
  hostnames:
  - whoami.cloud-native.rocks
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: default-gateway
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: whoami
      port: 80
      weight: 1
    matches:
    - path:
        type: Exact
        value: /
```
4. Patch Gateway with a (for that moment invalid config, as the referenced secret is missing)
```
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: default-gateway
  namespace: default
spec:
  gatewayClassName: cilium
  listeners:
  - allowedRoutes:
      namespaces:
        from: All
    name: default-http
    port: 80
    protocol: HTTP
  - allowedRoutes:
      namespaces:
        from: All
    hostname: whoami.cloud-native.rocks
    name: default-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: whoami-cloud-native-rocks-certs
      mode: Terminate
```
5. Change HTTP Route to simulate a config change
```
```
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: whoami-route
  namespace: default
spec:
  hostnames:
  - whoami.cloud-native.rocks
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: default-gateway
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: whoami
      port: 80
      weight: 1
    matches:
    - path:
        type: Exact
        value: /foobar
```
6. `curl` that new/changed endpoint on HTTP and get a 404

### Cilium Version

1.16.1

### Kernel Version

Linux ip-172-31-26-187.eu-central-1.compute.internal 6.1.97-104.177.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jul 16 15:18:45 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

### Kubernetes Version

v1.30.4+k3s1

### Regression

It used to work with 1.15.X

### Sysdump

_No response_

### Relevant log output

_No response_

### Anything else?

_No response_

### Cilium Users Document

- [X] Are you a user of Cilium? Please add yourself to the [Users doc](https://github.com/cilium/cilium/blob/main/USERS.md)

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

I think I am seeing the same issue.
For some reason under cilium 1.16.x, when the CiliumEnvoyConfig is being constructed for HTTPRoutes with TLS secrets, entries for the routes are added to virtualHosts under the listener-secure RouteConfiguration (th gateway CEC's .spec.resources.name = listener-secure, .'@type'=type.googleapis.com/envoy.config.route.v3.RouteConfiguration), but not the
listener-insecure one. As a result, when a non-TLS request arrives, envoy reports like the following in its debug log:
[2024-10-08 10:08:46.857][14][debug][router] [external/envoy/source/common/router/router.cc:446] [Tags: "ConnectionId":"742","StreamId":"1809078164870312584"] no route match for URL '/'

When I downgrade to 1.15.9, the routes are added to virtualHosts on both listener-secure and listener-insecure, and non-TLS requests succeed.
@SantoDE, you seem to have already have constructed the minimum test case, maybe you can check if you have whoami.cloud-native.rocks under virtualHosts for only listener-secure or both it and listener-insecure in your CiliumEnvoyConfig?

I am running on Talos v1.8.0, k8s v1.31.1 deploying cilium with argo-cd. My values.yaml:
upgradeCompatibility: '1.15'
ipam:
  mode: kubernetes

kubeProxyReplacement: true
k8sServiceHost: localhost
k8sServicePort: 7445

securityContext:
  capabilities:
    ciliumAgent:
      - CHOWN
      - KILL
      - NET_ADMIN
      - NET_RAW
      - IPC_LOCK
      - SYS_ADMIN
      - SYS_RESOURCE
      - DAC_OVERRIDE
      - FOWNER
      - SETGID
      - SETUID
    cleanCiliumState:
      - NET_ADMIN
      - SYS_ADMIN
      - SYS_RESOURCE
cgroup:
  autoMount:
    enabled: false
  hostRoot: /sys/fs/cgroup

encryption:
  enabled: true
  type: wireguard

ingressController:
  enabled: false
  loadbalancerMode: shared
  enforceHttps: false
  default: true
  defaultSecretNamespace: kube-system
  defaultSecretName: default-tls
  secretsNamespace:
    create: true
    name: mysite-cilium-secrets
  service:
    allocateLoadBalancerNodePorts: false

egressGateway:
  enabled: true

l7Proxy: true
bpf:
  masquerade: true

enableIPv4Masquerade: true

hubble:
  enabled: true
  relay:
    enabled: true
  tls:
    auto:
      enabled: true
      method: certmanager
      certValidityDuration: 1095
      certManagerIssuerRef:
        group: cert-manager.io
        kind: Issuer
        name: hubble-ca
  ui:
    enabled: true
    replicas: 1
    ingress:
      enabled: false
      annotations:
        cert-manager.io/cluster-issuer: letsencrypt-cilium
        kubernetes.io/tls-acme: "true"
        acme.cert-manager.io/http01-edit-in-place: "true"
      hosts:
      - hubble.mysite.com
      tls:
      - hosts:
        - hubble.mysite.com
        secretName: ingress-hubble-ui-tls
  metrics:
    enableOpenMetrics: true
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - port-distribution
      - icmp
      - httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction
    serviceMonitor:
      enabled: true
    dashboards:
      enabled: true

policyAuditMode: false
nodePort:
  enabled: true
  enableHealthCheck: true

envoy:
  enabled: true
  rollOutPods: true
  connectTimeoutSeconds: 5
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true
  securityContext:
    capabilities:
      keepCapNetBindService: true
      envoy:
        - NET_BIND_SERVICE
        - CAP_NET_ADMIN
        - CAP_BPF
        - NET_ADMIN
        - SYS_ADMIN
        - SYS_RESOURCE

gatewayAPI:
  enabled: true
  enableAppProtocol: true
  enableAlpn: true
  secretsNamespace:
    name: mysite-cilium-secrets

prometheus:
  enabled: true
  serviceMonitor:
    enabled: true

dashboards:
  enabled: true

operator:
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true
  dashboards:
    enabled: true
  rollOutPods: true

# for previous debug operator config
#
# imagePullSecrets:
#   - name: cilium-debug-pull-secret
# hostFirewall:
#   enabled: true

debug:
  enabled: true
  verbose: "datapath flow kvstore envoy"

hostPort:
  enabled: true

cluster:
  name: mysite
  id: 1

socketLB:
  enabled: true
  hostNamespaceOnly: true

Sure @jackmaninov. I'll validate this afternoon but if memory serves me well, I saw the same in regards to envoy config. I'm quite sure we are hitting the same, since downgrading fixes it for me as well.

I have the same Issue, using cert-manager which attaches to Port 80 for ACME Http01 Challenge while other listeners have InvalidCertificateRef. Would be nice to get an update when a fix can be provided.
[2024-12-09 16:56:51.571][15][debug][router] [external/envoy/source/common/router/router.cc:446] [Tags: "ConnectionId":"14","StreamId":"16950019938598325183"] no route match for URL '/.well-known/acme-challenge/6SFkrMb0BY_Qdp_AfrSq2QKizCEpQ9K4XNDRdBcC0q0'

 Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'

Confirmed this issue is still present on 1.16.5.


Error message for unparsable chord name

Right now it just says chord.js:23 Uncaught TypeError: daccord(...).map is not a function. An error message instead might be more helpful. I'll probably make a pull request for this sometime this month

Woops, apparently this already exists, the error was on my end :P


soc: stm32wb: fix ble low-power

Release HSI CLK48 semaphore when going to sleep to allow C2 (M0) core to start and stop clock as needed while C1 core is not running.
CLK48 is shared between RNG and USB. RNG is needed by M0 during BLE advertisement. A hardware semaphore can be locked by C1 to prevent C2 from stopping CLK48 in case C1 needs to use these peripherals.
If C1 is sleeping and C2 does BLE advertising CLK48 is started since C2 needs RNG to generate some BLE crypto stuff. If semaphore is locked, C2 core can start CLK48 when it needs to but not stop it. When C2 goes back to sleep, CLK48 is therefore left running with increased system power consumption as a result. Order is not restored until C1 later wakes up (because periodical low-power timer expires) and then goes back to sleep, but power consumption is broken as BLE advertisement cycle is repeated.
Fixes zephyrproject-rtos#69955.

^^@benothmn-st, @asm5878

Hello @gellhaar I agree with your analysis and resolution you have proposed. I have tested your changes and the power consumption is as expected

@gellhaar thanks for the PR. There was a CI glitch in main so could you please rebase on the latest main and force push to your branch? Thanks :)

Rebased, see if build steps are passing now..


Fix OS X build on CI

The latest brew requires ruby 2.3 or later, and brew-update installs its own ruby binary.
brew-install does brew-update under its process, but brew-install is continued the previous ruby envs (system default: 2.0.0), so brew reports ruby-version error.
To fix it:

do separately brew-update and brew-install
do brew-install with HOMEBREW_NO_AUTO_UPDATE=1 (means don't do brew-update in brew-install)

Codecov Report

Merging #2203 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2203      +/-   ##
==========================================
+ Coverage   74.25%   74.27%   +0.01%
==========================================
  Files          90       90
  Lines      131984   131983       -1
  Branches    28987    30858    +1871
==========================================
+ Hits        98007    98024      +17
+ Misses      33952    33930      -22
- Partials       25       29       +4

Impacted Files
Coverage Δ

src/if_xcmdsrv.c
83.81% <0%> (-0.36%)
:arrow_down:

src/channel.c
82.36% <0%> (-0.17%)
:arrow_down:

src/if_py_both.h
76.09% <0%> (-0.15%)
:arrow_down:

src/gui_gtk_x11.c
47.76% <0%> (-0.11%)
:arrow_down:

src/terminal.c
65.12% <0%> (-0.07%)
:arrow_down:

src/eval.c
80.81% <0%> (-0.05%)
:arrow_down:

src/os_unix.c
53.41% <0%> (-0.05%)
:arrow_down:

src/libvterm/src/screen.c
72.18% <0%> (+0.02%)
:arrow_up:

src/gui.c
46.39% <0%> (+0.05%)
:arrow_up:

src/term.c
51.25% <0%> (+0.05%)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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


Create a function to get notebook python version for execution

Notebooks might require a specific python version for execution. This PR creates a function that parses the notebook and gets the python version. Then passes that to the yaml file for execution.

/gcbrun

[ ] Add a log separator that makes the log more clear
[ ] Remove extra steps from the child build


fix(docs-app): remove stopWordFilter from lunr pipeline

Description:
This PR removes the stopWordFilter from the lunr pipeline. It filters words like "of" and "from" when indexing, missing some operators or functions when searching.
https://github.com/olivernn/lunr.js/blob/master/lib/stop_word_filter.js
Related issue (if exists):
Fixes #4524

I need to test that manually very quick. I'll do my best to do it asap. I'll let you know. But thanks for contributing!

awesome! thanks for reviewing it :)

hi @flakolefluk !!!!!!

hey @JWO719 @benlesh - @flakolefluk  is joining our team next week!


DOC: De-indent to remove text from code block

Changes proposed in this pull request
De-indent to remove text from code block. Noticed this when verifying that #1237 was hitting ReadTheDocs.
Documentation that should be reviewed
First note in Running a Singularity Image.
Pull-request guidelines:

[x] I have read the guidelines for contributions.
[x] I understand that my contributions will not be merged unless the work is
finished (i.e. no [WIP] tag remains in the title of my PR) and tests pass.
[x] The proposed code follows the
coding style,
to the extent I understood them (and I will address any comments raised by the PR's reviewers in this regard).
[ ] (Optional) I opt-out from being listed in the .zenodo.json file.

Fixed in circle artifacts.


Triage frontend act warnings

Background
As detailed in several previous PR's, our frontend tests sometime get cluttered with act warnings. These are coming from component side effects triggering after a testing block and may contribute to flakiness / indeterminate tests. See the writeup in this PR for more details.
We're getting act warnings in places we shouldn't be though and are currently getting around it by wrapping our tests in act, which isn't recommended. Fixing the issue has been a bit of a headache but might be related to a mismatched subdependency shared by several testing library. Bob has explored this fix initially on a separate branch and found promising results.
Action requested
Triage fixing the frontend act warnings. Push to a separate feature branch any quick straightforward fixes and make tickets for the rest.
Acceptance Criteria

Feature branch created with easy fixes
tickets created for remainder of work

Tickets created for follow up effort:
https://github.com/CDCgov/prime-simplereport/issues/6593
https://github.com/CDCgov/prime-simplereport/issues/6594


Scala Future monad

Fair async version without Future.successful:
[info] Running skynet.SkynetAsync
0. Result:<PHONE_NUMBER>00 in 647 ms.

Result:<PHONE_NUMBER>00 in 377 ms.
Result:<PHONE_NUMBER>00 in 372 ms.
Result:<PHONE_NUMBER>00 in 371 ms.
Result:<PHONE_NUMBER>00 in 342 ms.
Result:<PHONE_NUMBER>00 in 347 ms.
Result:<PHONE_NUMBER>00 in 367 ms.
Result:<PHONE_NUMBER>00 in 321 ms.
Result:<PHONE_NUMBER>00 in 308 ms.
Result:<PHONE_NUMBER>00 in 320 ms.
Result:<PHONE_NUMBER>00 in 338 ms.
Best time 308 ms.

Sync version for comparison:
[info] Running skynet.SkynetSync
0. Result:<PHONE_NUMBER>00 in 97 ms.

Result:<PHONE_NUMBER>00 in 60 ms.
Result:<PHONE_NUMBER>00 in 61 ms.
Result:<PHONE_NUMBER>00 in 67 ms.
Result:<PHONE_NUMBER>00 in 56 ms.
Result:<PHONE_NUMBER>00 in 64 ms.
Result:<PHONE_NUMBER>00 in 63 ms.
Result:<PHONE_NUMBER>00 in 62 ms.
Result:<PHONE_NUMBER>00 in 64 ms.
Result:<PHONE_NUMBER>00 in 63 ms.
Result:<PHONE_NUMBER>00 in 66 ms.
Best time 56 ms.

Only the async part makes sense, but yes, futures are quite fast everywhere :)

Thanks!
Yes, of course. Sync part just to compare.
I was just shocked with Akka numbers and mess in code and tried to show Scala from the better side :)


knights-on-chessboard python solution is wrong.

Range is too small:
is
in range(len(board) -1)
should be:
in range(len(board)) (ranges are right-half open intervals)

Shouldn't Y be a vowel?

Hi @KarolOlko,
thanks for opening the issue. 😊
Could you open a pull request to fix that?
The letter Y can be a vowel (as in the words "cry", "sky", "fly" , “my” or "why"), or it can be a consonant (as in "yellow", "yacht", "yam" or "yesterday") according to Wikipedia, so I'll leave that up to you.
Cheers!

Sure!
niedz., 13.05.2018, 10:25 użytkownik Matthias Endler <
<EMAIL_ADDRESS>napisał:

Hi @KarolOlko https://github.com/KarolOlko,
thanks for opening the issue. 😊
Could you open a pull request to fix that?
The letter Y can be a vowel (as in the words "cry", "sky", "fly" , “my” or
"why"), or it can be a consonant (as in "yellow", "yacht", "yam" or
"yesterday") according to Wikipedia
https://simple.wikipedia.org/wiki/Vowel, so I'll leave that up to you.
Cheers!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mre/the-coding-interview/issues/22#issuecomment-388610046,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AadCn7PGLD0cwH7AfnUw9nyPK9cfeiXzks5tx-32gaJpZM4T8san
.

@KarolOlko are you working on a PR? 😉

I guess you changed the code in your fork but you simply forgot to create the PR.
That's why I took the freedom to merge it in from your fork.
The fixed version should be in master now.
Thanks for your contribution. 🍸

Thanks!
czw., 9 sie 2018 o 23:25 Matthias Endler<EMAIL_ADDRESS>napisał(a):

Closed #22 https://github.com/mre/the-coding-interview/issues/22.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mre/the-coding-interview/issues/22#event-1781231286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AadCn25aHA5UtrLZX71BOuMZ8gKjPXNfks5uPKjkgaJpZM4T8san
.

--
Best regards / Pozdrawiam,
Karol Olko


Question: Hash usage

Hi,
Is there a specific reason to replace ['first_name', 'last_name', 'phone', 'address',] fields for a hash instead of an empty or fixed value like "REMOVED"?

Yes, we still wanted distinct values, but technically empty or -removed- would probably work.

Thanks!


corrected one of the tutorial's routes

What kind of changes does this PR include?

Minor content fixes (broken links, typos, etc.)

Description

Closes #
What does this PR change? Give us a brief description.
Corrects one of the tutorial's routes so that it doesn't return a 404 page when copy and pasted into a browser's address bar.
Did you change something visual? A before/after screenshot can be helpful.
No

Looks great, @ShamarYarde! Thank you so much for taking the time to correct this!  🥳


Conflict

Hi there, I am using the latest version of the calendar and have both jQuery and Bootstrap, but when trying to add the calendar to a dropdown I get the following error:
Please DO NOT specify the dropdownSelector option unless you are using jQuery AND Bootstrap.js. Please include jQuery AND Bootstrap.js, or write code to close the dropdown in the on-set-time callback.
Is it something I am doing wrong?

This directive is not detecting either jQuery or Bootstrap.js (and you have specified a dropdownSelector value)  - are you loading both of them before Angular and this directive?
Please post a fiddle or plunker that demonstrates the problem.

Thanks @dalelotts


Upgrade to isort v5.5.4

While I was fixing isort behavior in my IDE for the umpteenth time, I noticed that we're running a fairly old version of isort. After reading the guide to upgrading to 5.x I realized we were missing out on some real goodness in terms of isort's ability to automatically categorize imports and the like.
You'll note that the changes in actual behavior were pretty minimal, despite removing most of our isort config.
The biggest change to moving to a largely default config was that django is now not its own section. You'll see from the diff that that's actually not a very big deal, but I'm open to reintroducing that as a section if we want to.
@beniwohli Thoughts?

:green_heart: Build Succeeded

Expand to view the summary

Build stats

Build Cause: [Pull request #938 opened]

Start Time: 2020-10-01T22:25:39.199+0000

Duration: 25 min 30 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
10966

Skipped
8506

Total
19472


Fix: Responds to SecurityModeReject in a mobility update

If the UE state is "Deregistered", the Mobility/Periodic Update process continues.
modify "implicitly de-registered" to reject.
TS 24.501
<IP_ADDRESS>.5 Mobility and periodic registration update not accepted by the network
10 (implicitly de-registered).

Thanks for the PR!


Feat: add sibling portal support & implement interact outside the right way

closes https://github.com/melt-ui/melt-ui/issues/1077, https://github.com/melt-ui/melt-ui/issues/1153, https://github.com/melt-ui/melt-ui/issues/1167
This PR adds support for sibling portals by correctly implementing outside interactions using a stack. Previously outside interactions did not work correctly when using sibling portals.
Also, please don't be intimidated by the "size" of this PR. It's mostly tests and other than that, this PR is 70 additions and 161 deletions.
Throughout this PR, I will mention the term "floating element", what I mean by that is anything that can be mounted into a portal (i.e. dialog, tooltip, popover, link preview, menu, tooltip, listbox etc.).
The correct way to implement outside interactions is by only closing the top-most floating element given the top-most element has closeOnOutsideClick: true. If the top-most element has closeOnOutsideClick: false, no elements should close since the top-most element "asked" to not close on an outside interaction.
I also fixed an issue with the Tags Input when it's nested inside another floating element like a Popover. When editing a tag, if you click outside, we should just cancel editing. However, the popover would also close. This is solved by using the new useInteractOutside() on the edit builder to prevent other floating elements from reacting to outside interactions.
Here is a video showing nested floating elements and outside interactions only closing the top-most floating element. (ignore the craziness of the nested elements :))
https://github.com/melt-ui/melt-ui/assets/53095479/b7a48103-2d51-4f80-92b3-9fc55fd059e7
Also, to prevent issue https://github.com/melt-ui/melt-ui/issues/1167, where interact outside doesn't fire when clicking outside opens a new floating element, which is caused by checking too late whether the element is at the top of the stack. This is because the outside interaction triggers the opening of another floating element, so by the time pointerup fires for the first floating element, the second floating element had already been added to the stack. This is prevented in this PR by checking in pointerup whether the element was at the top of the stack during pointerdown. I added a regression test for this as well.
Before
https://github.com/melt-ui/melt-ui/assets/53095479/cbd69a3b-bfdf-4379-82e4-52e4f0385664
After
https://github.com/melt-ui/melt-ui/assets/53095479/c539079d-3d36-433f-a9e7-d1c810a1de56

And in case you notice the following bug:
In the escape key video example, when I press escape when the select is open, the focus goes back to the popover trigger, which is incorrect. The focus should be trapped inside the popover content. The reason this happens is because we for some reason have focusTrap: null on the listbox menu builder. Changing it to { returnFocusOnDeactivate: false, clickOutsideDeactivates: true, escapeDeactivates: true } fixes this issue (and we can add an option to disable focus trapping). I will create a separate issue and PR for this.

Oh no not the timezone tests failing due to DST again! I'll get that fixed later today on the develop branch so you can merge it in!

That failing test may just need an await waitFor() for the focus. If it still doesn't pass then it may have been introduced by this PR

@huntabyte not sure why the tests are not passing. I tried to manually test the functionality that's not passing the tests and at first glance, things seem to be working correctly. Will look into it tomorrow

@huntabyte it seems like merging the following PR will fix the tests for Date Picker https://github.com/melt-ui/melt-ui/pull/1055
it looks like the root issue was with the popover component which the Date Picker uses

The tests were passing without #1055 before so we need to identify what is breaking here with this PR

@huntabyte this PR is finally ready to be reviewed! :)
I split up some of the changes in this PR onto different PRs to make reviewing this PR easier. So the following PRs should be merged before merging this one:
https://github.com/melt-ui/melt-ui/pull/1087 - this makes sure that we correctly run cleanup functions returned from actions. We currently don't do this correctly due to race conditions and promises.
https://github.com/melt-ui/melt-ui/pull/1095 - fix focus trap deactivating when closeOnEscape: false
https://github.com/melt-ui/melt-ui/pull/1094 fix focus trap deactivating when closeOnOutsideClick: false
https://github.com/melt-ui/melt-ui/pull/1088 - this removes the need for unnecessary if checks checking the type of clean up functions returned from actions, which reduces the code significantly.

Alright, all of the dependent PRs have been merged!

@huntabyte let me resolve the conflicts

Will defer to @TGlide to give this the final review/approval 😃

@huntabyte the tests are failing because I removed the escape-keydown changes to a different PR https://github.com/melt-ui/melt-ui/pull/1142 which is what is failing the tests here. Merging https://github.com/melt-ui/melt-ui/pull/1142 will solve this.

Hi everyone, the work here is amazing 🚀 Just wanted to let you all know that in 21RISK we are also facing this issue, so it will be so good when it's fixed.
If there is anything we can help with let us know.

Hey @alexbjorlig, thanks for your patience! There are a lot of small (but mighty) internal changes going on simultaneously, so we're doing our best to ensure we don't introduce a regression into the library!


Proposal: Print logs only on test error

Rust only prints console output after a test failed. We can consider using this strategy for unit tests and e2e test (not sim). I've been adding a DEBUG env var lately to conditionally log which is not pretty.
This library accomplishes this
https://github.com/AleG94/mocha-suppress-logs

Not necessary, now we use testLogger that turns on debug logs when running with ENV DEBUG=true


workload.py

When I run main.py and get to line 301 in workload.py, an error occurs, but I haven't changed any other code. I'd like to ask for some directions on how to resolve this issue?

Hi @nldyy , thank you for your question. But it seems that your screenshot was not uploaded correctly. Could you try uploading it again so that we can get a better understanding of what happened?

I apologize for the initial failed upload. The first image contains the code that caused the error, and the second image shows the error report. Thank you for your response.

It seems to be a problem related to the in-memory-dataset class of PyG. Which PyG version do you use? Could you try to print all attributes of self so that we can better identify the problem?

I apologize for the initial failed upload. The first image contains the code that caused the error, and the second image shows the error report. Thank you for your response.

Here's the version I print：print(torch_geometric.version)-------2.5.3
Here are the attributes I understand; not sure if my comprehension is correct.
  True  True  True]
MUTAG/NeighborhoodDataset/processed/neighs_index_depth_4.npy：
[[  0   1]
[  0   2]
[  0   3]
...
[187  13]
[187  14]
[187  15]]
data/MUTAG/NeighborhoodDataset/processed/pre_filter.pt：
None
MUTAG/NeighborhoodDataset/processed/pre_transform.pt：
None

I printed out the files in the MUTAG/NeighborhoodDataset/processed directory, and indeed, I did not see the 'data' attribute when I checked before.Thank you for your response.

The data.y should be the label for prediction. If the data attribute does not exist, could you try to simply add that attribute before assigning the value?

I've noticed a peculiar situation where in the “process()” function of the “workload.py” file, executing the line “data, slices = self.collate(neighs_pyg)” and then printing “data” and “slices” does not raise any errors. However, within the “NeighborhoodDataset” class in “workload.py”, after executing “self.data, self.slices = torch.load(self.processed_paths[0])”, printing “data” results in an error, while “slices” remains consistent.

I've made an interesting discovery while modifying the code in the “NeighborhoodDataset” class of “workload.py”. The first print statement for “data” outputs normally, but the second one, when accessing “self.data”, results in an error: "In 'site-packages/torch_geometric/data/in_memory_dataset.py', line 319, in __getattr__, an AttributeError is raised stating that the 'NeighborhoodDataset' object has no attribute 'data'."

I resolved the issue by setting up the environment again. Thank you for your response and assistance.


Review Expectations chapter

@jonathancummings can you review this chapter please? Thank you!

Will do

Comments

Check chapter numbers in locations outside of the book itself. For example, the instructions say chapter #15, but the expectations chapter is #6 in the book, and has a label of 05... for its .Rmd file
For undergraduate pay: consider if a link to a description of how to access and use HR Direct should be included.
For outreach and postdoctoral researchers sections: Consider adding examples of past outreach, advisory working group, or professional service activities. While individuality in the directions of these is great and I think lab members should pursue their own paths here, it would be fun to see what other members have done and help make new members aware of some opportunities past members have (pr perhaps have not) had success with.


ParseFragment "eating" elements

I'm trying to use the ParseFragment method to parse a fragment in the context of the body. When the fragment contains a script element, the element immediately after it seems to get lost:
var parser = new HtmlParser();
var dom = parser.Parse("");
var html = @"
Test
";
var nodes = parser.ParseFragment(html, dom.Body).ToArray();
// => nodes.Length == 1
// (HtmlScriptElement with InnerHtml == ""
dom.Body.Append(nodes);
var s = dom.ToHtml();
// => s == ""

This results in the same behavior:
var dom = parser.Parse("");
dom.Body.InnerHtml = html;
var s = dom.ToHtml();
// => s == ""

This does not occur in a browser:
document.body.innerHTML = "
Test
";
// document.documentElement.outerHTML
// === "
Test
"

Sounds like a bug to me. v0.9.7 is overdue since a long time, but this one should be addressed in it.
Thanks for reporting the issue! :+1:

Fixed, see PR #359. Will be included in the next release (I plan to roll it out on Sunday or Monday).


[!] No podspec found for geolocator_web in .symlinks/plugins/geolocator_web/ios

🐛 Bug Report

-> Fetching podspec for firebase_auth_web from .symlinks/plugins/firebase_auth_web/ios
-> Fetching podspec for `firebase_core` from `.symlinks/plugins/firebase_core/ios`
-> Fetching podspec for `firebase_core_web` from `.symlinks/plugins/firebase_core_web/ios`
-> Fetching podspec for `firebase_database` from `.symlinks/plugins/firebase_database/ios`
-> Fetching podspec for `firebase_storage` from `.symlinks/plugins/firebase_storage/ios`
-> Fetching podspec for `flutter_geofire` from `.symlinks/plugins/flutter_geofire/ios`
-> Fetching podspec for `flutter_local_notifications` from `.symlinks/plugins/flutter_local_notifications/ios`
-> Fetching podspec for `flutter_native_image` from `.symlinks/plugins/flutter_native_image/ios`
-> Fetching podspec for `flutter_plugin_android_lifecycle` from `.symlinks/plugins/flutter_plugin_android_lifecycle/ios`
-> Fetching podspec for `flutter_share` from `.symlinks/plugins/flutter_share/ios`
-> Fetching podspec for `flutter_statusbarcolor` from `.symlinks/plugins/flutter_statusbarcolor/ios`
-> Fetching podspec for `flutter_vibrate` from `.symlinks/plugins/flutter_vibrate/ios`
-> Fetching podspec for `geolocator` from `.symlinks/plugins/geolocator/ios`
-> Fetching podspec for `geolocator_web` from `.symlinks/plugins/geolocator_web/ios`
[!] No podspec found for `geolocator_web` in `.symlinks/plugins/geolocator_web/ios`

pod install
[✓] Flutter (Channel stable, 1.22.4, on macOS 11.0.1 20B50 darwin-x64, locale en-NG)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 12.5)
[!] Android Studio (version 4.1)
✗ Flutter plugin not installed; this adds Flutter-specific functionality.
✗ Dart plugin not installed; this adds Dart-specific functionality.
[✓] VS Code (version 1.54.3)
[✓] Connected device (1 available)
Version: 6.2.0
Platform:

[x] :iphone: iOS

Hi @ObasiGodstime, this seems to be a duplicate of issue #659.
Please try the following steps to fix the issue:

Delete Podfile and Podfile.lock from ios folder;
Run flutter clean in the root folder of your project;
Change back into the ios folder and run pod install;
All should be good and you should be able to run you App.


Swift 2.0 support

XCGLogger does not compile with Swift 2.0, in Xcode 7 beta.

Hi @danyalaytekin!
See https://github.com/DaveWoodCom/XCGLogger/pull/62

Nice work :) @beltex @Eldrinarion


Alpine 3.19 scheduled for Nov

Depends on https://hub.docker.com/_/alpine/tags?page=1&name=3.19

[ ] Open a PR
[ ] Create a release
[ ] Update templates (if necessary)
[ ] Update https://github.com/devcontainers/images/issues/90

This issue is blocked because the upstream alpine image is not available.  Hence, we can't create an alpine 3.19 image. See https://hub.docker.com/_/alpine/tags?page=1&name=3.19
As alpine 3.19 is new, we could wait for sometime to give alpine maintainers to work through it. But, if not, we can open an issue in https://github.com/alpinelinux/docker-alpine/issues?q=

Alpine 3.19 seems available now :)

Alpine 3.19 is now released in Dev tag - ready for a prod/latest release

Closing, as completed the release 🎉
Thanks, @eljog


[REMOVAL] 0bin

Title
0bin
Removal Reason
Has not been updated for 3 years.
Association Disclosure
Creator of Paaster
Would you like to submit a PR?
Yes!
Please tick the boxes

[X] You have filled out this form accurately, and to the best of your knowledge
[X] You have indicated weather or not you are associated with this project or a competitor
[X] A similar submission has not already been opened for this software/ service
[X] You agree to the code of conduct

Hi @WardPearce! I think 0bin is already removed. Closing this now.


Caching issues over https

Hey, this is an issue I've been experiencing with more than just Enoki, so please let me know if there's a better place to put it.
I think it's stemming from your start/build scripts (which are fantastic — I copy them over to all of my dat projects now)
Often times, whenever I am ready to push a new version of a project live, it works fine on dat, because its reading the "real" bundle files or w/e, but over https, either the new files aren't getting synced — I think its because the name doesn't change, or something related to how dat picks up on changes to files...
One solution might be to give each new bundle a unique hashed name, and removing the old ones — that way there's no caching of old bundles based on the simple name bundle, and the most recent version will 100% be re-synced. This is how choo's default build script also works, last time I checked.
Let me know if this belongs elsewhere, or if my thinking is totally wrong, and this is a known issue with dat or something.

I've noticed this both using the Dat CLI on my server, and using Hashbase. Usually I have to delete the bundles from the archive entirely, publish the archive, re-bundle, and publish again so the changes are recognized.

Yeah, caching is annoying. An immediate fix is to simply append a integer to the end of the filenames. e.g. bundle.js?12345. Same for the CSS. I remember looking for a static HTML cache-busting module a while ago which could simply locate the html files within a directory and append that string to any link or script tags.


copy link to tweet

The mobile twitter site allows me to get a link to tweet I can share with people that don't have a twitter account, but anatine seems to only support sharing between twitter accounts.

From the readme:

No new features will be accepted as I don't have time to keep up on the constant Mobile Twitter changes.


Bug in SDL Wiki documentation

In the Example seection of the SDL_RenderPresent page (https://wiki.libsdl.org/SDL_RenderPresent)
The example code is
<<Include(SDL_RenderClear, , , from="== Code Examples ==", to="== Remarks ==")>>

There's a bug on the sdlwiki repo for this: https://github.com/libsdl-org/sdlwiki/issues/233


Fixed stat call for NetBSD

NetBSD uses the same stat version as Darwin and FreeBSD; this patch reflects that.

thanks


Add Authentication and Authorization to the Application

Tutorials: https://developers.sap.com/tutorials/cp-cap-java-security-local.html
At step three you have a section stating that you need to place the following code block in your application.yaml:
---
spring:
  config.activate.on-profile: default
cds:
  datasource:
    auto-config.enabled: false
  security:
    mock:
      users:
        - name: klaus
          password: pass_klaus
          additional:
            firstName: Klaus
            lastName: Sussard
            email<EMAIL_ADDRESS>        - name: mia
          password: pass_mia
          additional:
            firstName: Mia
            lastName: Bonnellac
            email<EMAIL_ADDRESS>
However, this causes several errors during deployment:
2024-01-29T13:00:36.082Z  INFO 12146 --- [  restartedMain] c.s.c.s.impl.runtime.CdsRuntimeImpl      : Exception marked the ChangeSet 3 as cancelled: Error executing the statement (service 'PersistenceService$Default', event 'CREATE', entity 'sap.capire.products.Products')
2024-01-29T13:00:36.086Z  INFO 12146 --- [  restartedMain] c.s.c.s.impl.runtime.CdsRuntimeImpl      : Exception marked the ChangeSet 4 as cancelled: Error executing the statement (service 'PersistenceService$Default', event 'CREATE', entity 'sap.capire.bookstore.Authors')
2024-01-29T13:00:36.090Z  INFO 12146 --- [  restartedMain] c.s.c.s.impl.runtime.CdsRuntimeImpl      : Exception marked the ChangeSet 5 as cancelled: Error executing the statement (service 'PersistenceService$Default', event 'CREATE', entity 'sap.capire.products.Products.texts')
2024-01-29T13:00:36.093Z  INFO 12146 --- [  restartedMain] c.s.c.s.impl.runtime.CdsRuntimeImpl      : Exception marked the ChangeSet 6 as cancelled: Error executing the statement (service 'PersistenceService$Default', event 'CREATE', entity 'sap.capire.products.Categories')

This is the original application.yaml as it's created by Maven:
---
spring:
  config.activate.on-profile: default
  sql.init.schema-locations: classpath:schema-h2.sql
cds:
  datasource.auto-config.enabled: false

You can fix the error by adding the line:
sql.init.schema-locations: classpath:schema-h2.sql

Thanks @DichoMire,
I'll check that and get back to you soon :)


Python requirements have invalid dependency combination

I think this is related to the icetea module but:
from ubuntu
MAINTAINER Michael Bartling<EMAIL_ADDRESS>
RUN apt-get update && apt-get install -y \
    python-pip \
    gcc-arm-none-eabi \
    git \
    mercurial \
    vim

RUN pip install --upgrade pip
RUN pip install mbed-cli 'colorama<0.4.0,>=0.3.9' pyserial prettytable jinja2 intelhex junit_xml pyyaml requests mbed_ls mbed_host_tests mbed_greentea beautifulsoup4 fuzzywuzzy pyelftools jsonschema future six manifest_tool mbed_cloud_sdk icetea

docker build -t dummy .
Step 1/5 : from ubuntu
 ---> f975c5035748
Step 2/5 : MAINTAINER Michael Bartling<EMAIL_ADDRESS> ---> Using cache
 ---> 2d2b948a7289
Step 3/5 : RUN apt-get update && apt-get install -y     python-pip     gcc-arm-none-eabi     git     mercurial     vim
 ---> Using cache
 ---> 4f4070c94b83
Step 4/5 : RUN pip install --upgrade pip
 ---> Using cache
 ---> a4de2e9f7265
Step 5/5 : RUN pip install mbed-cli 'colorama<0.4.0,>=0.3.9' pyserial prettytable jinja2 intelhex junit_xml pyyaml requests mbed_ls mbed_host_tests mbed_greentea beautifulsoup4 fuzzywuzzy pyelftools jsonschema future six manifest_tool mbed_cloud_sdk 'trollius==1.0.4' icetea
 ---> Running in 00088630bbd9
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting mbed-cli
  Downloading https://files.pythonhosted.org/packages/f8/2d/a40a9ef436094dd6fcdf05fd010446baa5c336d36f97ff50415208f31f18/mbed-cli-1.10.0.tar.gz (52kB)
Collecting colorama<0.4.0,>=0.3.9
  Downloading https://files.pythonhosted.org/packages/db/c8/7dcf9dbcb22429512708fe3a547f8b6101c0d02137acbd892505aee57adf/colorama-0.3.9-py2.py3-none-any.whl
Collecting pyserial
  Downloading https://files.pythonhosted.org/packages/0d/e4/2a744dd9e3be04a0c0907414e2a01a7c88bb3915cbe3c8cc06e209f59c30/pyserial-3.4-py2.py3-none-any.whl (193kB)
Collecting prettytable
  Downloading https://files.pythonhosted.org/packages/ef/30/4b0746848746ed5941f052479e7c23d2b56d174b82f4fd34a25e389831f5/prettytable-0.7.2.tar.bz2
Collecting jinja2
  Downloading https://files.pythonhosted.org/packages/1d/e7/fd8b501e7a6dfe492a433deb7b9d833d39ca74916fa8bc63dd1a4947a671/Jinja2-2.10.1-py2.py3-none-any.whl (124kB)
Collecting intelhex
  Downloading https://files.pythonhosted.org/packages/bf/77/bf670318b3db325c71e2ac6a90b7bcfdf9fc739b7cf6aebb31715721623e/intelhex-2.2.1-py2.py3-none-any.whl (50kB)
Collecting junit_xml
  Downloading https://files.pythonhosted.org/packages/a6/2a/f8d5aab80bb31fcc789d0f2b34b49f08bd6121cd8798d2e37f416df2b9f8/junit-xml-1.8.tar.gz
Collecting pyyaml
  Downloading https://files.pythonhosted.org/packages/a3/65/837fefac7475963d1eccf4aa684c23b95aa6c1d033a2c5965ccb11e22623/PyYAML-5.1.1.tar.gz (274kB)
Collecting requests
  Downloading https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl (57kB)
Collecting mbed_ls
  Downloading https://files.pythonhosted.org/packages/e0/20/7d016c3fd8e9c402340a85be15e6e18981377997e223f25a0d1d9689c23a/mbed-ls-1.7.7.tar.gz
Collecting mbed_host_tests
  Downloading https://files.pythonhosted.org/packages/44/4a/44ad7f0a8081cd718f0a3c56febe75f40828836fee9a3f42ae6cb9b4f0d3/mbed-host-tests-1.5.7.tar.gz (56kB)
Collecting mbed_greentea
  Downloading https://files.pythonhosted.org/packages/a3/0f/06e564f8633ec5175ed92952156e86ec5319cdd0e9b80ae083e9ad701d0f/mbed-greentea-1.7.1.tar.gz
Collecting beautifulsoup4
  Downloading https://files.pythonhosted.org/packages/39/0e/cfae701dc1143409adf1dc78ebc138f7c507e342e5814b1ead2a727bc900/beautifulsoup4-4.8.0-py2-none-any.whl (97kB)
Collecting fuzzywuzzy
  Downloading https://files.pythonhosted.org/packages/d8/f1/5a267addb30ab7eaa1beab2b9323073815da4551076554ecc890a3595ec9/fuzzywuzzy-0.17.0-py2.py3-none-any.whl
Collecting pyelftools
  Downloading https://files.pythonhosted.org/packages/fa/9a/0674cb1725196568bdbca98304f2efb17368b57af1a4bb3fc772c026f474/pyelftools-0.25.tar.gz (499kB)
Collecting jsonschema
  Downloading https://files.pythonhosted.org/packages/aa/69/df679dfbdd051568b53c38ec8152a3ab6bc533434fc7ed11ab034bf5e82f/jsonschema-3.0.1-py2.py3-none-any.whl (54kB)
Collecting future
  Downloading https://files.pythonhosted.org/packages/90/52/e20466b85000a181e1e144fd8305caf2cf475e2f9674e797b222f8105f5f/future-0.17.1.tar.gz (829kB)
Collecting six
  Downloading https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Collecting manifest_tool
  Downloading https://files.pythonhosted.org/packages/ea/df/59413d8b568514730c718a251bdf140ce3d32aeb5c1ac512d6f9507d2a44/manifest-tool-1.5.2.tar.gz (54kB)
Collecting mbed_cloud_sdk
  Downloading https://files.pythonhosted.org/packages/42/cb/616171db4aa65f54d0839bff70293b8570e5d796c09040a52762ec7918a8/mbed_cloud_sdk-2.2.0-py2.py3-none-any.whl (973kB)
Collecting trollius==1.0.4
  ERROR: Could not find a version that satisfies the requirement trollius==1.0.4 (from versions: 2.1.post2, 2.2, 2.2.post1)
ERROR: No matching distribution found for trollius==1.0.4
The command '/bin/sh -c pip install mbed-cli 'colorama<0.4.0,>=0.3.9' pyserial prettytable jinja2 intelhex junit_xml pyyaml requests mbed_ls mbed_host_tests mbed_greentea beautifulsoup4 fuzzywuzzy pyelftools jsonschema future six manifest_tool mbed_cloud_sdk 'trollius==1.0.4' icetea' returned a non-zero code: 1```

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1537

@mbartling Yes you're right this is a problem with the icetea dependency, the root cause is that trollius before version 2.1 was deleted from PyPI. I don't know why this happened but it has since been restored. Hopefully this should work ok now.
bash-3.2$ pip install trollius==1.0.4
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting trollius==1.0.4
  Using cached https://files.pythonhosted.org/packages/ca/21/74eedbeba3649fe9f1c807958c36a4cf54e775d263ff4cb3944e605d2328/trollius-1.0.4-py2-none-any.whl
Collecting futures (from trollius==1.0.4)
  Using cached https://files.pythonhosted.org/packages/d8/a6/f46ae3f1da0cd4361c344888f59ec2f5785e69c872e175a748ef6071cdb5/futures-3.3.0-py2-none-any.whl
Installing collected packages: futures, trollius
Successfully installed futures-3.3.0 trollius-1.0.4
 bash-3.2$ pip list
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Package    Version
---------- -------
futures    3.3.0
mbed-cli   1.10.0
pip        19.2.1
setuptools 41.0.1
trollius   1.0.4
wheel      0.33.4
bash-3.2$


Flyout is clipped off by Expander

Before you start...

[X] Have you updated your dependencies? You might be using an old version of the library.
[X] Have you checked for an existing issue on this topic? If there is one, post a comment on it instead.

What browsers are you seeing the problem on?
Firefox, Chrome
Description
If you open a Flyout that's placed inside an Expander, it gets clipped off, because the Expander has set 'overflow: hidden'.
AFAIK this problem can not be solved CSS-only, because the height of the Expander is transitioned and doesn't work with height set to auto.

Relevant Assets
No response

Yeah this is an unfortunate limitation of using CSS to position flyouts and not some JS-based DOM library. I've considered switching the flyouts to use something like popper or floating-ui (or just writing my own positioning library), but that's not without limitations as well.


Slight clipping of input text in Chrome 73

The corresponding CSS is:
https://github.com/necolas/normalize.css/blob/fc091cce1534909334c1911709a39c22d406977b/normalize.css#L160-L169
Changing line-height to 1.2 or greater fixes the clip.
I'm not experiencing this issue in Firefox 65 though.
Related #769

The descenders (the "g" characters) are clipping because the particular font-family in use here has a computed content-area height that is significantly more than the computed virtual-area height (that is, the line-height). This might help illuminate the issue: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
The corresponding CSS rules you cited presuppose that the font-family that's getting inherited has a computed content-area that's within a typical (normal) range.
line-height: normal is based on font metrics. Using it in this situation will likely prevent clipping,
It would be good to have a reduced test case that loads the font-family depicted in your screenshot

add height : 100% to inputs

This occurs in Chrome 87 with the common font Segoe UI. For example, see the search box at the top left of https://pradyunsg.me/furo/
Setting line-height: normal fixes the problem.

This occurs in Chrome 87 with the common font Segoe UI. For example, see the search box at the top left of https://pradyunsg.me/furo/
Setting line-height: normal fixes the problem.

@mhsmith , line-height: normal is -- not coincidentally -- the default value in Chromium, Gecko, and WebKit user agent stylesheets.
There is no longer a need to normalize line-height here. See my previous comment in this issue.

@mhsmith , line-height: normal is -- not coincidentally -- the default value in Chromium, Gecko, and WebKit user agent stylesheets.
There is no longer a need to normalize line-height here. See my previous comment in this issue.


how to add extension?

i am trying to add user agent crx file but not showing anything. could u plz help me out , how to add extensions?
thanks in advance

Ive removed this feature in the latest update since playwright doesn't support extensions.


feat(frontend): implement WITH ORDINALITY clause

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
fix #12043  fix #11167 (duplicate issues)

Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[x] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
May refer to test cases, and https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-TABLEFUNCTIONS

@lmatz @chenzl25 We may add the user's full query in tests if necessary/possible

@lmatz @chenzl25 We may add the user's full query in tests if necessary/possible

AFAIK, the users didn't tell us the specific query.

Seems related #12204

here: https://github.com/risingwavelabs/risingwave-customer-testcases/blob/main/e2etest/rippling/with_ordinality_as.sql
Thanks!
Maybe modify the original query to a simplified one that does not reveal any info about this user


Graph DB QA chain

Issue you'd like to raise.
How to resolve [This model's maximum context length is 4097 tokens] ?
If Graph DB have many nodes, can not send those tokens to OpenAI by one time.
Suggestion:
No response

it seems like you're dealing with an issue related to the maximum context length of the model and how to handle it when working with a Graph DB (Database) containing a large number of nodes. The error you're encountering is due to the fact that the total number of tokens being sent to OpenAI is exceeding the model's maximum context length of 4097 tokens. My suggestion are.....

Adjust the max_tokens Parameter:
You can adjust the max_tokens parameter in the OpenAI instance of the LLMChain. This parameter determines the maximum number of tokens to generate in the completion. However, the total token count of your prompt and max_tokens cannot exceed the model's context length (4097 tokens in this case).
Example code:
from langchain import OpenAI, ConversationChain, LLMChain, PromptTemplate
from langchain.memory import ConversationBufferWindowMemory

template = """..."""  # Your template here
prompt = PromptTemplate(input_variables=["history", "human_input"], template=template)

chatgpt_chain = LLMChain(
    llm=OpenAI(temperature=0, max_tokens=1000),  # Adjust this value as needed
    prompt=prompt,
    verbose=True,
    memory=ConversationBufferWindowMemory(k=2)
)

Adjust the max_tokens value according to your needs, keeping in mind the limitations of the model you're using.

Split Your Data into Smaller Chunks:
If adjusting the max_tokens parameter doesn't resolve the issue, you can try splitting your data from the Graph DB into smaller chunks that fit within the token limit. This way, you can send multiple smaller requests instead of one large request.

You can use a method similar to the get_sub_prompts method mentioned in the context to split your data into smaller chunks. This method takes into account the batch_size to ensure that each sub-prompt fits within the token limit.
Adjust the batch_size value to control the number of tokens in each sub-prompt. The method returns alist of sub-prompts, each of which contains a subset of your data that fits within the token limit.
By either adjusting the max_tokens parameter or splitting your data into smaller chunks, you should be able to work around the issue of exceeding the model's maximum context length. Make sure to carefully test your approach to ensure that it works effectively with your specific dataset and use case.

I have encountered the same problem, my knowledge graph is too large. Has anyone solved this problem？

Same here! My knowledge graph schema itself exceeds the token limit of my deployed model which is 4096 tokens. Can the question be sent in chunks and the answer can be aggregated?
If we are passing the graph object to the chain, where do yu recommend calling the get_sub_prompts method? Is there any internal functionality in langchain that can do this?

I am still facing the same issue . Did the chunking work ? I am having issue when i am passing in the graph.schema i the llm model definitely exceeding the token limit


RequestResponse requests shouldn't get data in the onComplete callback

The full context of this issue can be found on this SO question: https://stackoverflow.com/questions/62119541/rsocket-js-client-not-getting-elements-generated-from-a-spring-boot-rsocket-serv/62120181

Reviewing the implementation for requestResponse we see that it returns a Single from rsocket-flowable, which only implements onComplete via IFutureSubscriber. Given that, I'm not sure that this is actually something we should address, in that it appears that the internals of rsocket-js are properly handling the frame flags as indicated in the Protocol, it is just that the interfaces implements in rsocket-flowable do not match 1:1 to other reactive streams implementations. In my opinion, I think that this is acceptable as a characteristic of rsocket-flowable, but maybe something that should be kept in mind/re-visited should rsocket-flowable be overhauled down the road.
  /**
   * Request-Response interaction model of `ReactiveSocket`. The returned
   * Publisher resolves with the response.
   */
  requestResponse(payload: Payload<D, M>): Single<Payload<D, M>>;


[BUG]: Drizzle-kit does not obey composite primary key order when generating SQL (relevant for SQLite)

What version of drizzle-orm are you using?
0.31.2
What version of drizzle-kit are you using?
0.22.7
Describe the Bug
When creating a composite primary key, drizzle-kit does not obey the ordering of the columns for the composite key. This is important in SQLite because index-based querying only works of the left-most keys are included in the query.
For example, if a composite key with three columns is declared (col1, col2, col3) then having a WHERE col1=2 or WHERE col1=2 AND col2=5 will not result in a table scan, whereas the query WHERE col2=5 will result in a table scan.
Using the example in the docs: https://orm.drizzle.team/docs/indexes-constraints#composite-primary-key
export const bookToAuthor = sqliteTable("book_to_author", {
  authorId: integer("author_id"),
  bookId: integer("book_id"),
}, (table) => {
  return {
    pk: primaryKey({ columns: [table.bookId, table.authorId] }),
    pkWithCustomName: primaryKey({ name: 'custom_name', columns: [table.bookId, table.authorId] }),
  };
});

CREATE TABLE `book_to_author` (
  `author_id` integer,
  `book_id` integer,
  PRIMARY KEY(`book_id`, `author_id`)
);

In realty, it's more likely that you would want a list of books by an author (so querying the book_to_author just on author_id) - with the above create statement in SQLite a query on just author_id will result in a table scan.
Reversing the columns: [table.bookId, table.authorId] to columns: [table.authorId, table.bookId] does not generate the PRIMARY KEY statement as PRIMARY KEY(`author_id`, `book_id`), instead it is still generated as PRIMARY KEY(book_id, `author_id`).
Note, the above code doesn't actually generate the SQL as stated in the docs when I run it, it instead generates PRIMARY KEY(`author_id`, `book_id`). Having tested it with a few tables I think the composite keys are sorted alphabetically at the moment, which again.
This stack overflow question provides info on the ordering requirement in SQLite for composite keys: https://stackoverflow.com/a/19401415/141708
The ordering does not appear to be documented on sqlite.org but I have tested with EXPLAIN QUERY PLAN on Cloudflare D1 and the ordering of composite keys is still important to the query not using a scan.
Expected behavior
composite primary keys should be generated in the order in which they are provided in the primaryKey() function.
Environment & setup
M1 MacBook Pro for code, tested with Cloudflare D1 (SQLite).

After some digging through the drizzle-kit source, it seems this issue stems from the sqlite schema serialization that occurs when generating migrations (drizzle-kit generate), pushing schema changes (drizzle-kit push) and introspecting (drizzle-kit introspect).
When defining a composite primary key in your schema, the columns to include are specified as an array in your schema. It turns out that these are being sorted using the default Array.sort method (alphabetic ascending) during the conversion into the structure required for serialization. This is to ensure consistency between the output of generate/push commands and introspect.
I can't link to specific parts of the code, as drizzle-kit is closed source (😢 ), but this happens within the generateSqliteSnapshot method of sqliteSerializer:
primaryKeys.forEach((it) => {
          if (it.columns.length > 1) {
            primaryKeysObject[it.getName()] = {
              columns: it.columns.map((it2) => it2.name).sort(),
              name: it.getName()
            };

A fix for this is to remove the .sort(), and the resulting migration and push output will have composite primary key definitions in the specified array order within your schema 🎉  You can apply the following patch to<EMAIL_ADDRESS>diff --git a/bin.cjs b/bin.cjs
index 5f1228dc9a361fcd0443146445b27c119a01bd01..ca6fb4090856bc8417979c859cc7c81285e5dcf0 100755
--- a/bin.cjs
+++ b/bin.cjs
@@ -22617,7 +22617,7 @@ The unique constraint ${source_default.underline.blue(
         primaryKeys.forEach((it) => {
           if (it.columns.length > 1) {
             primaryKeysObject[it.getName()] = {
-              columns: it.columns.map((it2) => it2.name).sort(),
+              columns: it.columns.map((it2) => it2.name),
               name: it.getName()
             };
           } else {

This only seems to affect sqlite(?) and I can't see the same sort logic being applied to PostgreSQL or MySQL.
I assume the explanation for including the sort, is due to the sqlite introspection serialization implementation. This currently queries all columns for all tables. The columns are iterated over and any column names that are marked as a primary key are added into an array for each table. The order that these columns are returned in and iterated over will not necessarily match the order of your composite primary key definition in your schema, so they are similarly being sorted:
      for (const [key, value] of Object.entries(tableToPk)) {
        if (value.length > 1) {
          value.sort();
          result[key].compositePrimaryKeys = {
            [`${key}_${value.join("_")}_pk`]: {
              columns: value,
              name: `${key}_${value.join("_")}_pk`
            }
          };

It's hard to properly diagnose without having access to the source, but I feel fix for the introspection serialization issue would be to query the indexes from the database (if this is possible?) and reconstruct the composite primary key columns that way . This would ensure the schema that is output has the correct composite primary key order. This falls outside my expertise however, so this may not be possible...


Namespace in external DLL causes issues in component code generation.

I have an enum in a namespace in a DLL that is separate from the code that has my components in it. I'm using that enum in a component.

If I use a 'using' directive at the top of the component then the generated code doesn't bring that over or fully qualify the namespace for the type.
If the enum is in the same DLL as the components then the generated code does fully quality the namespace and will compile.
If the enum is left in a separate DLL but I fully qualify the namespace in the component, then the generated code will fully qualify the namespace and compile.

Here's some code
// This is in Foo.dll
namespace Foo
{
    public enum Color
    {
        Blue,
        Red,
        Yellow,
        Green,
        Purple,
    }
}

// This is in Bar.dll
using Foo;
using Entitas;

namespace Bar.Components
{
    [Game]
    public class ColorComponent : IComponent
    {
        public Color color;
    }
}

// Generated code, in Bar.dll
public partial class GameEntity {

public Bar.Components.ColorComponent color { get { return (Bar.Components.ColorComponent)GetComponent(GameComponentsLookup.Color); } }
public bool hasColor { get { return HasComponent(GameComponentsLookup.Color); } }

// *** The new line is what fails to compile. The function parameter, Color, is not found ***
public void AddColor(Color newColor) {
    var index = GameComponentsLookup.Color;
    var component = CreateComponent<Bar.Components.ColorComponent>(index);
    component.color = newColor;
    AddComponent(index, component);
}

...

If I fully quality the type in my component instead of using a using, then the code generator seems to pick that up.
// This is in Bar.dll
using Entitas;

namespace Bar.Components
{
    [Game]
    public class ColorComponent : IComponent
    {
        public Foo.Color color;
    }
}

// Generated code, in Bar.dll
public partial class GameEntity {

public Bar.Components.ColorComponent color { get { return (Bar.Components.ColorComponent)GetComponent(GameComponentsLookup.Color); } }
public bool hasColor { get { return HasComponent(GameComponentsLookup.Color); } }

// *** Fully qualified type is now listed here ***
public void AddColor(Foo.Color newColor) {
    var index = GameComponentsLookup.Color;
    var component = CreateComponent<Bar.Components.ColorComponent>(index);
    component.color = newColor;
    AddComponent(index, component);
}

...

I added both the path to the folder with the source itself and the path to the folder with the .dll, to the Jenny.SearchPaths, and that didn't seem to have any effect.

Cannot reproduce, works for me.
With which .NET version is the dll compiled?

.NET 4.7.1 for both dlls.
I'm able to work around the issue for now by using the full namespace in the component variables. So this isn't a blocking issue. Just seemed like it might be a bug. It's a shame you can't reproduce it though.

I hope your fine with the workaround. Sorry that I couldn't reproduce. When in doubt, you can send me stripped down demo project with you specific setup so I can try. Will close the issue for now


Update package.json

Fix path to the main script

Hello @francoislaberge
The package main script was incorrect, it was impossible to use the package :)

Thanks! Messed that up when migrating.

I published the fixed module to npm. Again, thank you for catching that.

@onesime Please do try it if you can, to see if it works for you.


RFC: Allow type inference for const or static

Allow type inference for const or static when the RHS is known.
const PI = 3.1415; // inferred as f64
static MESSAGE = "Hello, World!"; // inferred as &'static str
const FN_PTR = std::string::String::default; // inferred as fn() -> String

Pre-RFC discussion: #1349
cc #1623
Rendered

Both of these drawback could be addressed using an allow-by-default clippy lint for const and static types.

Make that a rustc lint, and make it warn by default, unless

The type is unnamable
The item was generated by a macro
The item is private or not accessible outside the crate (i.e. not part of the public API)

Then I'd be very happy with this proposal.

I'd like to point out that all of the mentioned downsides also apply to function return types. The main difference is that functions support impl Trait as return type, but const/static items do not. Allowing this would make Rust more expressive:
const FOO: impl Fn() -> i32 = || {
    todo!();
};

Many of the cases where this would be helpful would also be addressed by type_alias_impl_trait; in particular, it helps with dealing with unnameable types and macro / code generator output, without the drawbacks of loss of clarity and semver trouble (because the trait is guaranteed, and is also the only property usable in other crates).
This may not be an argument against this RFC, but at least warrants discussion in the alternatives.

Many of the cases where this would be helpful would also be addressed by type_alias_impl_trait

That's a good thing to note as an alternative, but it won't help with array lengths, which are one of the ways the current rules frequently create pain (especially for include_bytes!()ed arrays where the length isn't even a property of the same source code file):
static ARRAY_OF_UNINTERESTING_LENGTH = [
    "foo",
    "bar",
    // ...
];

In the cases where a TAIT such as impl AsRef<[T]> could reasonably be used, you can also use an static &[T] slice, but not all cases are that.

I feel like providing explicit types for values should be assumed to be the default, and use of the _ placeholder in types looks better to me:
// I prefer this
const FOO: _ = "hello";
// over this
const FOO: "hello";

The use of placeholders also I think works better in the event of a "partially-nameable" type, e.g.:
struct MyWrapper<T>(T);

// We can name `MyWrapper`, but not its generic argument.
static FOO: MyWrapper<_> = MyWrapper(|| todo!());

Also, for type inference around literals specifically, I'd prefer it not guess between options. I think this could lead to some confusion around things like this:
fn takes_u8(_: u8) {}
fn takes_u16(_: u16) {}

// Demonstrating type inference on local variables.
fn local() {
    let foo = 7;
    // Uncommenting either of these lines works, but uncommenting both results in a compile error.
    // takes_u8(foo);
    // takes_u16(foo);
    // If both lines are commented, `foo` is an i32; otherwise, the uncommented line changes its type.
}

// Demonstrating type inference on static variables.
fn local() {
    static foo: _ = 7; // Inferred as i32 since there's no uses.
    // Can uncommenting one of the below lines work?
    // I don't like uses of a static changing its value, but it also feels wrong to let inference change a literal's inferred type based on uses in locals, but not statics.
    // takes_u8(foo);
    // takes_u16(foo);
}

I'd prefer if literals still have to be explicitly annotated (either on the static definition or in the literal itself).

Both of these drawback could be addressed using an allow-by-default clippy lint for const and static types.

Given that the main use-case IMO is for types that can't be named, I think making a deny-by-default lint in rustc for a placeholder in the place of anything nameable (except for macro-generated code) would also be a good idea. And once TAIT is stabilized, I think it should expand to also lint any type in a public API (but not array lengths), regardless of whether it's macro-generated or nameable, since that can be used instead.

I do think that requiring at least a _ placeholder is a good idea. It nudges people to specify explicit types when they can by making const inference "opt-in".
Given the semver compatibility concerns, I also think that it's a good idea to require numerical types used for inference to have explicit typing.
However, I don't think a deny-by-default lint is a good idea. Some types can just be too cumbersome to type, and I think we should leave this decision up to the users.

However, I don't think a deny-by-default lint is a good idea. Some types can just be too cumbersome to type, and I think we should leave this decision up to the users.

in that case I think it would be totally reasonable to add an #[allow(...)] attribute to the item.  And I think such a lint should (at least by default) only apply to public items.

Adding a prior art for const array length inference with a macro, regardless whether this rfc ends up accepted or not: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=121942080c9bb1d9a7a83bfbf315e6c2
Other points were already discussed, but just to summarize: globals should have sandboxed inference context, where their type would be fully known after all constraints in const expr block has been applied; i.e. no default types for literals, nor implicit casts should be allowed. Otherwise it'd be confusing and inconsistent at best.
const PI = 3.1415926; should not compile, add a literal suffix.
const NEWS = String::new; should have function item type.
There was no mention of associated consts in trait impls, perhaps it's best to leave them as is for now. However their type is known from trait definition, it's a future possibility.

the NEWS example being a fn actually would be an implicit conversation still

the NEWS example being a fn actually would be an implicit conversation still

Function item type is different from fn pointer type. It'd have an unnameable type of ZST closure associated with this item. Its type is reported by type_name_of_val as ::alloc::string::String::new, but it can't be written like this.

There should be some discussion of https://github.com/rust-lang/rfcs/pull/2010, why that was closed, and why this RFC is apparently better. At a glance it's not clear to me what, if anything, has changed since then.
After re-skimming that old thread, I believe the only clear factual/technical issue with the idea is when some concrete data was gathered, it implied this change would be far less helpful than anyone expected, where in most "trivial" cases we'd only be adding the option to e.g. rewrite const FOO: f64 = 1.0; as const FOO = 1.0f64; but not really preventing the need to write out the type. And this was the only non-vague reason cited for "postponing" it.

From what I understand, the main motivation for this is that  it allows you to have consts and statics with unnameable types. Data on current usage of const and static isn't very useful for that, since you can't currently have consts or statics with those values.
Some additional points:

the things that can be done in a const expression is greatly expanded since 2017, which means it is more likely to use a complicated type or an unnameable type
it is now possible to use impl types in function returns (although having impl type aliases could provide a similar solution for const and statics)
const and static aren't necessarily at the top level. It feels weird that the type can be elided on a let statement inside a function, but not on a const or static inside a function
that RFC was closed as postponed, not completely rejected

Strong no on this one.
The motivation is very weak.

Sometimes the constant's value is complex, making the explicit type overly verbose.

Use a type alias. If your const type is too complex, it will make it painful to use in downstream code. You can infer a complex type, but you can't ignore it, and you must still bend your code to fit the specific type.
You also don't need to put that complex type into a const item. You can use a function, or maybe a const fn, which is in many ways easier to use (e.g. it can be generic).

In some cases, the type may be unnamable.

That should be fixed by making impl Trait properly work with consts. Nothing fundamental is blocking it, it just isn't done yet.

When creating macros, the precise type might not be known to the macro author.

But it should be known to the macro user, and the author can just ask to supply that type. It will also likely make the macro more readable.

Code generators may not have enough information to easily determine the type.

Same as above. Also nothing forces you to declare items as a const. Code generator can just directly inline the item. If the const item is part of the public API, then I definitely want the generated code to contain the type. If the code generator's author can't reasonably define the type, knowing full well how their generator works, how the hell am I supposed to deduce it from a barf of generated code?

This change aims to make Rust more expressive, concise and maintainable

There is literally no gain in expressivity, the same code is possible. It is more concise, yes, but conciseness on its own isn't a virtue. Not at the cost of readability. And it's definitely less maintainable, because you have less information to go with, and errors are easier to make.

That's a good thing to note as an alternative, but it won't help with array lengths, which are one of the ways the current rules frequently create pain (especially for include_bytes!()ed arrays where the length isn't even a property of the same source code file)

If you don't care about the length of the array, don't type it as an array. Use a slice. Particularly relevant with include_bytes!, which can easily includes many kilobytes of code, which would make it a terrible array (slow to copy, prone to stack overflow). Putting an include_bytes! array into a const is just asking for unexpected SO in your code.

The types of all literals must be fully constrained, which generally means numeric literals must either have a type suffix, or the type must specify their type

Numeric consts are the most common kinds of consts out there. If I can't omit the type on such consts (and to be clear, omitting it would just cause ambiguity and type/semantic errors), then that slashes a major reason to introduce this feature. It also means that I can't omit any type which contains a number, e.g. the element type of arrays.

When declaring a top-level item, the typing may not be entirely omitted.

Why? It doesn't serve any purpose. You still lose the explicit typing, you still must remember to type redundant information. With lifetime elision, the point of explicit '_ is to signify that the function is lifetime-generic.

There are some proposals to make the string syntax polymorphic. E.g. it could define a &str or String depending on the inferred type. This proposal would block any string literal polymorphism, so that must be called out explicitly.

const FN: _ = std::string::String::default;

String::default isn't a closure, it's a specific function. There is no way currently to specify the unique function type, but there is no reason why it shouldn't exist, given a reasonable syntax and compelling use cases.
Which also shows that the const type elision is harmfully ambiguous in this case. Did the author intend to use a unique function type? A closure type? An erased fn() -> String type? Not everyone even knows that functions and closures have unique types, which are different from function pointers!
You may say "what if I use the closure syntax". Well, a closure in a const item can't capture any context, so it's by definition coercible to a function pointer. So what should const F = || (); be? Is it a zero-sized closure? A function pointer? They will behave differently in code.

static ARR: [u8; _] = [12, 23, 34, 45];

Ok, now I want to use that array in my downstream code. I need to know its exact length, because my API requires an array of specific size. Am I supposed to manually count the array size each time?
For the original author, writing the array size is trivial. Just write 0, and the compiler will complain that it doesn't match the actual size 4. Write it down, done. It's a trivial annoyance, and it doesn't matter much unless you change the lengths of your arrays frequently (in which case its a semver break anyway, so it should be made explicit and done deliberately, rather than the compiler silently swallowing the breaking change).
You're trading a trivial ease-of-writing change into an issue for each one of your downstream consumers.

That said, I would be more open to type inference in const & static items which are strictly local to a function. Those are definitely not part of a public API, and any inference issues aren't harder to resolve than for a simple let binding. It's basically like a local variable, but which is known to be const at compile time, or which has a stable address.
However, given that the examples above present more cases for confusion than assumed by the RFC, I'm not so certain that the minor possible simplifications would pull the weight of a new feature.
I also don't think it's a good idea to introduce const type inference for private items (i.e. not part of the crate's public API). Yes, the semver issues don't exist, so there is less motivation to oppose it, but all the other issues are still present. It's a matter of protecting inexperienced users from themselves, for the same reason that we don't infer signatures of private functions, even though we could. Without a clearly defined small inference scope, type inference becomes a footgun, as demonstrated by languages such as Haskell and OCaml, where the best practice is to annotate all toplevel items, even though the compiler can infer their types.

The array length case would simply for me. I have had a few cases where I have static private (to the module) arrays. These can grow or shrink pretty often as they represent "passes" or "checks" of the code that it iterates over.
A recent example is the code implementing an environment sanity check in my command line program. It has an array of (check name string, function pointer that implements check). There is no good reason to have to update the number as well.
Is it a fairly minor annoyance? Yes. Perhaps not worth the semver hazard that exists for public items. But I rarely make globally visible constants, most constants are module local in my programs.
So I can see both sides of the argument.

Use a type alias. If your const type is too complex, it will make it painful to use in downstream code. You can infer a complex type, but you can't ignore it, and you must still bend your code to fit the specific type.

For a public const, sure. But for a local const or static, that seems like overkill.

You also don't need to put that complex type into a const item. You can use a function, or maybe a const fn, which is in many ways easier to use (e.g. it can be generic).

That isn't the case for a static.

But it should be known to the macro user, and the author can just ask to supply that type. It will also likely make the macro more readable.

Not necessarily. For example, what if the type is the return type of calling a user-supplied generic function with a type that is generated by the macro? And even if it is known, in some cases it could significantly hurt the ergonomics of the macro to require the user to supply it.

Also nothing forces you to declare items as a const. Code generator can just directly inline the item.

Again, that is not the case for statics.

If the code generator's author can't reasonably define the type, knowing full well how their generator works, how the hell am I supposed to deduce it from a barf of generated code?

Often you don't really care that much about the actual type, just a trait that it implements.

There is literally no gain in expressivity, the same code is possible.

Not unless/until we get impl Trait type aliases that are usable on consts and statics, in the case of unnameable types.

It is more concise, yes, but conciseness on its own isn't a virtue. Not at the cost of readability. And it's definitely less maintainable

If your type is a combination of a bunch of combinitors for an internal or local const or static, I don't think having a large complex type is very readable, or maintainable.

If you don't care about the length of the array, don't type it as an array

What if you need to pass the array as an array, not a slice, to a function that is generic in the size of the array?

Numeric consts are the most common kinds of consts out there.

Just because a use case isn't the most common use case doesn't mean it isn't important.

Ok, now I want to use that array in my downstream code. I need to know its exact length, because my API requires an array of specific size. Am I supposed to manually count the array size each time?

I would hope that the generated documentation would document the actual inferred type, not just the type as written in code.
All that said, If we get impl Trait type aliases in the near future, I'm not entirely convinced either way for top level const/static. I do really want inference for local const/static though.

Use a type alias

There is exactly one place in the code where I want to declare say static with the type OnceLock<Arc<RwLock<HashMap<String, SystemTime>>>, impl FnOnce() -> Arc<RwLock<HashMap<String, SystemTime>>>>. I only speak with it through a specific public API that manages this singleton. How exactly type alias is supposed to help?

But it should be known to the macro user, and the author can just ask to supply that type.

Macro doesn't know any types whatsoever. It only works with the source text. Supplying the type could be an option in some cases, unless it creates too much burden on macro author and/or user.

Numeric consts are the most common kinds of consts out there.

Given complex expressions on numeric consts, you'd have to add a literal suffix. Most numeric APIs reside in methods that are useful too often. Consts that use other consts are also a very common scenario. They do not require a literal, so only one const would have to be explicitly typed, the rest can benefit from it. I don't see why the workflow must be limited to plain const literals.

static ARR: [u8; _] = [12, 23, 34, 45];

Ok, now I want to use that array in my downstream code. I need to know its exact length

You can do the exact same thing you've proposed: add anonymous const, then just write 0 in the explicit type, the compiler would emit the correct value. Also why would you care about the exact value if the maintainer doesn't.
Besides, it is already trivially possible to hide the array length behind a macro I've left in this thread.

There are some proposals to make the string syntax polymorphic.

 It's a non-goal to hide a performance footgun behind a syntax sugar, which a flaky type inference combined with general misunderstanding on how it works would be constantly leading to, creating a nightmare for code reviewers. We already do not insert any implicit clones for the same reason. And, as you notice, no matter how useful Copy is and how rare it is to be the source of problems, it still can easily introduce stack overflows. Fstrings/custom prefixes would be a far better solution.

If you don't care about the length of the array, don't type it as an array. Use a slice.

Thank you for advice but please let me decide myself.

That said, I would be more open to type inference in const & static items which are strictly local to a function.

Unfortunately statics can be used in several user-facing functions. You can't declare an item local to multiple functions.

You also don't need to put that complex type into a const item. You can use a function, or maybe a const fn, which is in many ways easier to use (e.g. it can be generic).

In some cases, the type may be unnamable.

That should be fixed by making impl Trait properly work with consts. Nothing fundamental is blocking it, it just isn't done yet.

When creating macros, the precise type might not be known to the macro author.

But it should be known to the macro user, and the author can just ask to supply that type. It will also likely make the macro more readable.

Code generators may not have enough information to easily determine the type.

Same as above. Also nothing forces you to declare items as a const. Code generator can just directly inline the item. If the const item is part of the public API, then I definitely want the generated code to contain the type. If the code generator's author can't reasonably define the type, knowing full well how their generator works, how the hell am I supposed to deduce it from a barf of generated code?

All above are almost nonsense in practice. The const declarations may be expected by macros as interface contracts, e.g. for generation of some language binding code. If the const item is part of the public API, I definitely do not want to repeat the type again to mention its type when is clear enough (say, for some enums). I never deduce it because this is visually explicit.
More importantly, there can be actually some interface which in forms const NAME: unspecified-type = VAL; where only the name and the value, but not the concrete types are exposed. Then, how the hell do you can't imagine interface without nominal typing at all? (You shouldn't if you have used any seriously standardized APIs enough. ISO C, ISO C++, POSIX... all have such "unspecified" things deliberately, where "do not relying on the concrete type expressed in the source language" forms part of the interface contract.) Again, how the hell you'd insist on that overly typed entities are not risks on API design? Is the story of [u]intmax_t not already a(n) (in)famous but necessary lesson (if not the common sense) for any native language user who needs to take any API design work seriously?

Use a type alias. If your const type is too complex, it will make it painful to use in downstream code. You can infer a complex type, but you can't ignore it, and you must still bend your code to fit the specific type.

For a public const, sure. But for a local const or static, that seems like overkill.

No. This is nothing to do with publicity or locality, but the intent of the API author. Until the language supports the feature to express "unspecified" items explicitly in the syntax, it is legitimate to encode the concrete type in the public code but annotated with documentation to caveat users about the fact that parts of them are implementation details and subject to change.

Here's my perspective as someone new to Rust:
I was confused by the compiler asking me to add a type for a const string literal, as it seemed like the type would be already known to the compiler.
I would support making type declarations optional for any const/static where there is exactly 1 possible type. I think this is an unimpeachable ergonomics improvement -- however, as mentioned abovethread, there is an argument against it if, through unrelated RFCs, there exists a possibility of making currently unambiguous types ambiguous in the future. (Though doing something like that sounds like a bad idea in the first place.)
I wouldn't support automatic type inference for numeric literals or other values where the literal value could fit multiple types. I think the user should always know what type is coming out of the const/static declaration, and the compiler should not be making any choices regarding that type.

how the hell am I supposed to deduce it from a barf of generated code?

Then, how the hell do you can't imagine interface without nominal typing at all?

Again, how the hell you'd insist on that overly typed entities are not risks on API design?

@FrankHB All of these are violations of the Code of Conduct.  Please treat people with respect and work constructively.

how the hell am I supposed to deduce it from a barf of generated code?

Then, how the hell do you can't imagine interface without nominal typing at all?

Again, how the hell you'd insist on that overly typed entities are not risks on API design?

@FrankHB All of these are violations of the Code of Conduct. Please treat people with respect and work constructively.

You are likely offensive by just pointing out something with clueless quotes and no proof, or even without any links to the rules in your so-called Code of Conduct, which is at least not obvious in this repository. I guess you were referring to this upstream one. But what are violated? Am I calling names? Or, just you, are uncomfortable to some words based on your cultural background?
I have no interests to comment much towards a concrete user in the community, but your words are not that helpful to clarify anything notable besides the ignorance someone already strongly misbehaved here (and even so they are not violating such code of conduct). For instance, you've assert the "all of these" without further reasonable accuses, which is certainly against "be kind and courteous" and "keep unstructured critique to a minimum" AFAIK. Not to mention that ignorance of the technical points is often considered more impolite to anyone dedicate to improve the status quo, which is even more unkind and discourteous.

You also don't need to put that complex type into a const item. You can use a function, or maybe a const fn, which is in many ways easier to use (e.g. it can be generic).

In some cases, the type may be unnamable.

That should be fixed by making impl Trait properly work with consts. Nothing fundamental is blocking it, it just isn't done yet.

When creating macros, the precise type might not be known to the macro author.

But it should be known to the macro user, and the author can just ask to supply that type. It will also likely make the macro more readable.

Code generators may not have enough information to easily determine the type.

Same as above. Also nothing forces you to declare items as a const. Code generator can just directly inline the item. If the const item is part of the public API, then I definitely want the generated code to contain the type. If the code generator's author can't reasonably define the type, knowing full well how their generator works, how the hell am I supposed to deduce it from a barf of generated code?

All above are almost nonsense in practice. The const declarations may be expected by macros as interface contracts, e.g. for generation of some language binding code. If the const item is part of the public API, I definitely do not want to repeat the type again to mention its type when is clear enough (say, for some use of scoped enums). I never deduce it because this is visually explicit.  (Good, in Rust it just can play well the plain old C-style unscoped enumerators so this can be worked around normally, but this in turn adds additional requirements of the code layout or extra use declarations in local mods. Notice in this case mod can be a necessity, say, where some attribute macros are relied on. Then, what if the project setting deny use ...::*?
More importantly, there can be actually some interface which in forms const NAME: unspecified-type = VAL; where only the name and the value, but not the concrete types are exposed. Then, how the hell do you can't imagine interface without nominal typing at all? (You shouldn't if you have used any seriously standardized APIs enough. ISO C, ISO C++, POSIX... all have such "unspecified" things deliberately, where "avoiding to rely on the concrete type expressed in the source language" forms part of the interface contract.) Again, how the hell you'd insist on that overly typed entities are not risks on API design? Is the story of [u]intmax_t not already a(n) (in)famous but necessary lesson (if not the common sense) for any native language user who needs to take any API design work seriously?
It turns out that only the belief of putting the explicit type annotations everywhere is the obsession leading to all the insanity. Drop it. Accept the fact that more explicit (nominal) typing imply no clearer API. Appreciate that types considered harmful, ultimately.

This verbatim quotes is the reaction to the irresponsible and unconstructive "marked as abuse" action. The technical points should not be ignored before sufficient discussions.
Hope there is no need to waste time like this.

Please keep a welcoming and cooperative discussion environment. Disagreement is fine, but do it consructively and without insults or attacks


Demo link give 404

The link to the demo / GitHub pages link gives a 404 / page not found.

Apparently the repo owner has renamed from stackframe-projects to stack-auth.
The (new) correct link is: https://stack-auth.github.io/pgmock/

Thanks, fixed!


Feature request: Sync settings by Mozilla account.

Just as title.

not a fan of the remote sync stuff ... but i'll see what i can do.

technically i should also make the options locally ex-and importable ... so much work

while i see how this feature would be useful to have i currently assume that the number a sites a user wants to (or doenst want to) opend in a temporary container doenst change much after the inital set is defined. So for now i wont adding this feature. Not saying i wont at some point, but not right now.


HighchartsMore problem with Meteor 1.3 + React 15.0

When trying to include the HighchartsMore module in  Meteor 1.3 + React 15.0 project, I'm getting the dreaded error 17 when trying to create a solidgauge chart. I've tried importing it in various ways to no avail. Any thoughts?
var HighchartsMore = require('highcharts-more');
HighchartsMore(ReactHighcharts.Highcharts)```

```Error: Highcharts error #17: www.highcharts.com/errors/17
    at Error (native)```

Managed to find a solution. Not sure if this is something specific to my setup but the only way I got the solidgauge chart type to work is by requiring it as follows:
const ReactHighcharts = require('react-highcharts');
const HighchartsMore = require('highcharts-more');
const SolidGauge = require('highcharts/modules/solid-gauge')

HighchartsMore(ReactHighcharts.Highcharts)
SolidGauge(ReactHighcharts.Highcharts)

Thanks! This worked for me too...


kapp logs: add support for wildcard filtering in container names

Add support for wildcard filtering in container names in kapp logs command output.
Related to #103.

Decided to merge this functionality into another PR related to #103 .


Switch libsodium crate

This is causing flaky builds on Windows - https://github.com/holochain/lair/actions/runs/7627099560/job/20774998548?pr=121

Separately, this is deprecated https://github.com/sodiumoxide/sodiumoxide

Separately, this is deprecated https://github.com/sodiumoxide/sodiumoxide

This is indeed why we switched to libsodium-sys-stable jedisct1 is maintaining this for projects other than sodiumoxide.


installation of label-studio via python 3.7

I am currently working on NER models in UiPath. For this purpose I am installing label-studio on my machine which is having windows 10 operating system. I have successfully installed the label-studio via python on my machine. But I am unable to launch it as it gives the following error in cmd.
'label-studio' is not recognized as an internal or external command,
operable program or batch file.

I have set the PATH variable also and crossed checked it.
Any help in this regard will be highly appreciated.
Thank You

How did you install LS? Via pip install?
Please, try to use Anaconda Python.

I have installed python and then  run pip command on it

Now I am trying to install it via docker. But after creating volume on docker I am using docker run -it -p 8080:8080 -v labeldata:c:/label-studio/data heartexlabs/label-studio:latest command to install Label studio. But facing issues,

@enthusiastic12 Try this one:
docker run -it -p 8080:8080 -v c:/label-studio/data:/label-studio/data heartexlabs/label-studio:latest

-v <absolute-path-on-your-machine>:<path-inside-of-docker>

Actually, I have the same error. When I run label-studio start I get the same error.
How can I solve this without using Docker?

Please use python virtualenv and run inside of it
pip install -U label-studio

Please use python virtualenv and run inside of it
pip install -U label-studio

thanks! it works now. -U did the magic!


Feature Request: Starting of moto_server within Python

Hello :)
Thanks for developing and improving this great and helpful library!
Versions we used:

moto==1.3.16
moto[server]==1.3.16

Here's our feature request (I used the search function but didn't find a similar request):

Current state:

We are using a s3 moto standalone server for mocking our production s3 bucket
We don't want to start the moto s3 server outside of our Python code to keep our tests as self-contained as possible
This is why we currently run the moto with subprocess inside our Python tests:nohup_out = os.path.join(SCRIPT_DIR, 'integration_test_nohup.out')
command = [f"nohup moto_server s3 > {nohup_out} 2> {nohup_out}"]

Our concerns with this:

We have to mess around with os stuff to make sure the server is running as expected and is killed after we're done with testing

What we would like to have:

Starting and stopping of the moto server inside our Python code.
Simplified, we run code that might look like this:

from moto import moto_server
server = moto_server.run("s3", "<host>:<port>")
(do testing)
server.stop()

We don't care too much how the interface to the server looks like we would just be glad to have one to get aroud
os stuff.
This feature would really help us in our testing design!
It would be cool if you could give us feedback on this and tell us why it might (not) be a good idea :)
We're also willing to write the code on our own and do a pull request if you think the feature would be good to have

Hi @dagrimmy, good to hear moto is useful to you!
It sounds like this is what you're after: https://github.com/spulec/moto/issues/1015
We don't support it yet, but the gist that's linked in that issue should be a good starting point to write your own service/wrapper/decorator/however you want to use it

Thanks for the fast answer, we'll look into the linked issue :)

Hi @dagrimmy, Moto 3.0.6 now includes a way to start the MotoServer programmatically.
See the documentation here: http://docs.getmoto.org/en/latest/docs/server_mode.html#start-within-python
It is still in beta while we collect feedback, so if you find any bugs or improvements, feel free to open a new issue!