Please fix the search-replace in a selection

Can somebody..   It is so counterintuitive and doesnt work 90% of the time.  Please follow the guidelines of 99% of the other software which works as expected.

Select Text
Press Control-H ( The search and replace should know only to work in the selected area)
Enter the search term
enter the replace term
execute

/needsMoreInfo
Have you tried to change editor.find.autoFindInSelection setting?

I think I know what you said. This function need me to reselect the region manually after type search pattern.
I agree with you.

Have you tried to change editor.find.autoFindInSelection setting?

hello, I didn't know about this. This is acceptable for me and it does work - although i feel this should have been the default.
Thank you.  you may close this ticket


Ollama not working

I tried the latest ollama commit but still can't get Ollama models to show up in chatbot.
I tried two different setups

Debian server with ollama and chatbot-ui 2.0 running locally
Vercel deployment and setting env to point to my ollama server that accepts remote connection.

Ollama server is confirmed working when using unsaged, ollama-webui and big-AGI
I am unable to see any attempts from chatbot-ui 2.0 to ollama and nothing is showing in the local server logs or in vercel.

see #1062

@wrapss
Models show up now but when trying to use them i get

u launch ollama with arg  OLLAMA_ORIGINS=*  ?

@wrapss Models show up now but when trying to chat with them I get

u launch ollama with arg OLLAMA_ORIGINS=* ?

Yes I did. Interesting enough its working with Vercel but not my local instance. Let me double check the file changes to make sure I didn't have a typo

Well it works with Vercel so at least your fix is working for that. I will redo my local setup after lunch and report back.
Thanks for getting the models to work!

Seems to be no longer working on Vercel anymore. Not getting models to show up now

I created a whole new supabase, vercel and reinstalled ollama but models are still not showing up. I can curl and get the model list  and chat with it via curl from two different networks so I know its accepting outside connections. Not seeing anything in the logs on vercel or ollama showing that chatbot-ui has attempted to communicate with it.

try http://ip:port/api/localhost/ollama

/api/localhost/ollama

When going there I get
{"localModels":[]}
If I curl from a remote computer it is able to list the models so the ollama server is reachable just not via chatbot-ui for some reason. With the latest commit https://github.com/mckaywrigley/chatbot-ui/commit/8da68cece287b99afe1b7da560c5d277bd6738dd the menu option to select local models is gone now.
curl http://xxxxxxxx:11434/api/tags
{"models":[{"name":"codellama:13b-code","modified_at":"2024-01-11T13:52:40.378260827-05:00","size":7365960713,"digest":"bcb66db03ddd31b8ce315a0b504764340e6c2cea914d88350b566859738e1953","details":{"format":"gguf","family":"llama","families":null,"parameter_size":"13B","quantization_level":"Q4_0"}},{"name":"codeup:13b","modified_at":"2023-12-12T16:58:21.598996366-05:00","size":7365835291,"digest":"54289661f7a9c9568ec1dac8901ba56d3fb92a43dfa22fd711385ee56006e4e8","details":{"format":"gguf","family":"llama","families":null,"parameter_size":"13B","quantization_level":"Q4_0"}},{"name":"llama2:latest","modified_at":"2024-01-11T13:48:43.432395863-05:00","size":3826793677,"digest":"78e26419b4469263f75331927a00a0284ef6544c1975b826b15abdaef17bb962","details":{"format":"gguf","family":"llama","families":["llama"],"parameter_size":"7B","quantization_level":"Q4_0"}},{"name":"llava:latest","modified_at":"2023-12-13T16:32:37.432027275-05:00","size":4450242073,"digest":"e4c3eb471fd8247a4afb889408cd559aba91bfbdea87c94ffefb2af9787e6bae","details":{"format":"gguf","family":"llama","families":["llama","clip"],"parameter_size":"7B","quantization_level":"Q4_0"}},{"name":"orca-mini:latest","modified_at":"2024-01-11T13:52:29.446174636-05:00","size":1979947443,"digest":"2dbd9f439647093cf773c325b0b3081a11f1b1426d61dee8b946f8f6555a1755","details":{"format":"gguf","family":"llama","families":null,"parameter_size":"3B","quantization_level":"Q4_0"}},{"name":"phi:latest","modified_at":"2023-12-20T10:55:49.671096285-05:00","size":1602472472,"digest":"e22226989b6c4ea90b51e3368c8cbeb6edaddbf0f922c5182aa6384c7670afe7","details":{"format":"gguf","family":"phi2","families":["phi2"],"parameter_size":"3B","quantization_level":"Q4_0"}}]}

oh but you're in production mode I just understood

see https://github.com/mckaywrigley/chatbot-ui/blob/main/app/api/localhost/ollama/route.ts ligne 4

try to remove the condition if (process.env.NODE_ENV !== "production") {}

@mckaywrigley is this condition really necessary?

try to remove the condition if (process.env.NODE_ENV !== "production") {}

I changed production to test in that file vs deleting it and I now can see the models but not getting a response

do you see the request arriving on the ollama logs?

The way it is currently implemented it can't work on a hosted version, even if you remove the (process.env.NODE_ENV !== "production") condition.
The problem is that the request to the local Ollama server is proxied through a Next.js route. When this route is called on a hosted instance, it runs on the server and then of course it can't access the Ollama server, which is running locally on the client machine.
I think it is a valid use case to be able to use local Llama models even on a hosted instance.
In order to do this, the code from app/api/localhost/ollama/route.ts would simply have to be moved to the client side.

It would be great to be able to use a hosted version of ollama and be able to access it. I have a dual gpu server that I use as its much more powerful than running a local ollama on my laptop

@Bortus-AI Is the server hosting Ollama accessible from your local machine? E.g. if you are running Ollama on the standard port, http://your-server-ip-or-domain:11434/api/tags should return a JSON with your Ollama models.
If that works, you should make sure that you set the NEXT_PUBLIC_OLLAMA_URL env variable of your hosted chatbot-ui instance to something like http://your-server-ip-or-domain:11434.
If the models still don't show up in chatbot-ui, you can open the devtools network tab in the browser. When the chatbot-ui app starts, it it should make one request to the URL you set in the env variable. If the request doesn't go through it will likely be some CORS issue, but the devtools error message should provide a clue.

@Bortus-AI Is Ollama instance on your server accessible from your local machine? E.g. if you are running Ollama on the standard port, http://your-server-ip-or-domain:11434/api/tags should return a JSON with your Ollama models. If that works, you should make sure that you set the NEXT_PUBLIC_OLLAMA_URL env variable of your hosted chatbot-ui instance to something like http://your-server-ip-or-domain:11434.
If the models still don't show up in chatbot-ui, you can open the devtools network tab in the browser. When the chatbot-ui app starts, it it should make one request to the URL you set in the env variable. If the request doesn't go through it will likely be some CORS issue, but the devtools error message should provide a clue.

Yes. this is my case. I can get the model information from remote website 'NEXT_PUBLIC_OLLAMA_URL=https://xxxxx-11434.auc1.devtunnels.ms/api/tags', but when I run the app, it gives me an error "Access to fetch at 'https://xxxxx-11434.auc1.devtunnels.ms/api/tags' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled." Do you have any idea how to fix this? Thank you.

@Bortus-AI Is Ollama instance on your server accessible from your local machine? E.g. if you are running Ollama on the standard port, http://your-server-ip-or-domain:11434/api/tags should return a JSON with your Ollama models. If that works, you should make sure that you set the NEXT_PUBLIC_OLLAMA_URL env variable of your hosted chatbot-ui instance to something like http://your-server-ip-or-domain:11434.
If the models still don't show up in chatbot-ui, you can open the devtools network tab in the browser. When the chatbot-ui app starts, it it should make one request to the URL you set in the env variable. If the request doesn't go through it will likely be some CORS issue, but the devtools error message should provide a clue.

Yes. this is my case. I can get the model information from remote website 'NEXT_PUBLIC_OLLAMA_URL=https://xxxxx-11434.auc1.devtunnels.ms/api/tags', but when I run the app, it gives me an error "Access to fetch at 'https://xxxxx-11434.auc1.devtunnels.ms/api/tags' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled." Do you have any idea how to fix this? Thank you.

@BernieCr

There is an env variable for Ollama to allow CORS, try to set:OLLAMA_ORIGINS=* Also make sure not to use Firefox, it always blocked the request regardless of the CORS settings. It works fine in Chrome and Safari though, so I didn‘t investigate any further. On 8. Feb 2024, at 15:28, david3xu @.***> wrote:
@Bortus-AI Is Ollama instance on your server accessible from your local machine? E.g. if you are running Ollama on the standard port, http://your-server-ip-or-domain:11434/api/tags should return a JSON with your Ollama models. If that works, you should make sure that you set the NEXT_PUBLIC_OLLAMA_URL env variable of your hosted chatbot-ui instance to something like http://your-server-ip-or-domain:11434.
If the models still don't show up in chatbot-ui, you can open the devtools network tab in the browser. When the chatbot-ui app starts, it it should make one request to the URL you set in the env variable. If the request doesn't go through it will likely be some CORS issue, but the devtools error message should provide a clue.
Yes. this is my case. I can get the model information from remote website 'NEXT_PUBLIC_OLLAMA_URL=https://xxxxx-11434.auc1.devtunnels.ms/api/tags', but when I run the app, it gives me an error "Access to fetch at 'https://xxxxx-11434.auc1.devtunnels.ms/api/tags' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled." Do you have any idea how to fix this? Thank you.
@BernieCr
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@BernieCr Thank you. I fixed it. Actually, it is not CORS problem. But I replace all the 'localhost' to my private 'IPv4 Address'. It works. I remote it through github (vscode) to a laptop.


asciidoc: 10.2.0 -> 10.2.1

Description of changes
Diff: https://github.com/asciidoc-py/asciidoc-py/compare/10.2.0...10.2.1
Changelog: https://github.com/asciidoc-py/asciidoc-py/blob/10.2.1/CHANGELOG.adoc

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

Seems pretty minor.


Support k8s helm secrets creation for logstash helm chart

Describe the feature:
For convenient use of k8s secrets should add helm chart for create secrets.
Describe a specific use case for the feature:
Add secrets for using in k8s should be more convenient from the one logstash  helm chart.

The helm chart for secret can looks like bellow
secret.yaml
{{- if .Values.logstashSecrets }}
{{- range .Values.logstashSecrets }}
---
apiVersion: v1
kind: Secret
metadata:
name: {{ template "logstash.fullname" $ }}-{{ .name }}
labels:
  app: "{{ template "logstash.fullname" $ }}"
  chart: "{{ $.Chart.Name }}"
  heritage: {{ $.Release.Service | quote }}
  release: {{ $.Release.Name | quote }}
  {{- range $key, $value := $.Values.labels }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
data:
{{- range $key, $val := .value }}
{{ $key }}: {{ $val | toString | b64enc | quote }}
{{- end }}
type: Opaque
{{- end }}
{{- end }}

values.yaml
logstashSecrets:
  - name: "env"
    value:
      logstash.conf: |
          input {
            exec {
              command => "uptime"
              interval => 30
            }
          }
          output { stdout { } }
      api_key: ui2CsdUadTiBasRJRkl9tvNnw
  - name: "tls"
    value:
      ca.crt: "LS0tLS1CRUdJT0K"
      cert.crt: "LS0tLS1CRUdJTiBlRJRklDQVRFLS0tLS0K"
      cert.key: "LS0tLS1CRUdJTiBgUFJJVkFURSBLRVktLS0tLQo="

Hi @kksudo, thank you for submitting this request.
The current way is to manage secrets outside of the charts (which allow using something like kube-vault-controller for the secret for example), then using secretMounts or extraEnvs to mount the secret.
You can find an example in security example values.

Hello!
You can give more freedom of choice for different cases (in my case, we adding the secrets from the vault to k8s via terraform). With default k8s secrets (adding via helm chart) or  via kube-vault-controller. If the logstashSecrets variable will be empty, helm secrets will not deployed .
But if this not make sense you could  close this issue.

That make sense for me. It's definitely worth keeping in the bandwith, however we won't have any bandwith to work on this in short-term. Would you be interested to create a PR for it?

Yes, it's easy. I'll be doing PR soon.

Done in #712


Fix refs and remove bugs

Removed "page$" from xrefs
Removed docu.html file
Removed bugs

While generating the .adoc file from word file
some bug texts were created, probably from word metadata.
In this PR these bugs were fixed.

Why is it preferrable to not use page$ in xref?

Why is it preferrable to not use page$ in xref?

Because such links do not work in generated antora website.


Kimera-VIO on TUM-VI dataset

Hi, I used Kimera on Euroc with no issues and now I am trying to run Kimera on the TUM-VI dataset (https://vision.in.tum.de/data/datasets/visual-inertial-dataset). However I'm not sure how to make it work.
The only files that I change are [Left/Right]CameraParams.yaml and IMUParams.yaml following the calibration file "pinhole (512*512)" camera model that we can find in the dataset website.
When I run Kimera with those parameters, I have the following message error:
"StereoFrame.cpp:397 - undistortRectifyPoints: vector with zero depth".
Do I have to create a TUM-VI dataprovider.cpp as you did for Euroc and Kitti? Or maybe the equidistant distorsion model is not well handled? Did you already try to run Kimera with this dataset?
I am a bit confused...
Thank you!

W1020 16:39:26.933882 15720 Mesher.cpp:1380] Missing landmark information to build 3D Mesh.
W1020 16:39:26.934303 15720 Mesher.cpp:1408] Missing landmark information for the Mesher!
W1020 16:39:26.934667 15720 Mesher.cpp:1608] List of Keypoints with associated Landmarks is empty.
W1020 16:39:26.935127 15720 Mesher.cpp:1422] 2D Mesh is empty!
W1020 16:39:26.935573 15720 Mesher.cpp:432] Missing landmark information for the Mesher: cannot generate 3D Mesh.
W1020 16:39:26.935958 15720 Mesher.cpp:523] Missing landmark information for the Mesher: cannot trim 3D mesh to time horizon.
W1020 16:39:26.936389 15722 OpenCvVisualizer3D.cpp:479] No landmark information for Visualizer. Not displaying 3D points.

Or maybe the equidistant distorsion model is not well handled?

I haven't tried TUM-VI, and although we support equidistant, we don't have that part of the pipeline thoroughly tested.
We have some unit tests such as: https://github.com/MIT-SPARK/Kimera-VIO/blob/b9d9ed38fc5d9e64f8e594ac18c10dfb43ea6099/tests/testStereoFrame.cpp#L1122
but as you can see, it is currently disabled, probably because we ran into some issues there.
See an example of equidistant calibration params yaml here: https://github.com/MIT-SPARK/Kimera-VIO/blob/b9d9ed38fc5d9e64f8e594ac18c10dfb43ea6099/tests/data/ForStereoFrame/left_sensor_fisheye.yaml

Do I have to create a TUM-VI dataprovider.cpp as you did for Euroc and Kitti?
Most likely yes, unless you transform the TUM-VI dataset to the Euroc format OR if TUM-VI is given as rosbags (you'll need Kimera-VIO-ROS in that case).
Mind that we do not support Kitti anymore, so do not follow the Kitti code, rather use the Euroc one, or have a look at the dataprovider in Kimera-VIO-ROS:

RosOnlineDataProvider
RosBagDataProvider

Hope this helps!

Hi, thank you very much!
Your answer helps a lot.

Hi, I used Kimera on Euroc with no issues and now I am trying to run Kimera on the TUM-VI dataset (https://vision.in.tum.de/data/datasets/visual-inertial-dataset). However I'm not sure how to make it work.
The only files that I change are [Left/Right]CameraParams.yaml and IMUParams.yaml following the calibration file "pinhole (512*512)" camera model that we can find in the dataset website.
When I run Kimera with those parameters, I have the following message error:
"StereoFrame.cpp:397 - undistortRectifyPoints: vector with zero depth".
Do I have to create a TUM-VI dataprovider.cpp as you did for Euroc and Kitti? Or maybe the equidistant distorsion model is not well handled? Did you already try to run Kimera with this dataset?
I am a bit confused...
Thank you!

W1020 16:39:26.933882 15720 Mesher.cpp:1380] Missing landmark information to build 3D Mesh.
W1020 16:39:26.934303 15720 Mesher.cpp:1408] Missing landmark information for the Mesher!
W1020 16:39:26.934667 15720 Mesher.cpp:1608] List of Keypoints with associated Landmarks is empty.
W1020 16:39:26.935127 15720 Mesher.cpp:1422] 2D Mesh is empty!
W1020 16:39:26.935573 15720 Mesher.cpp:432] Missing landmark information for the Mesher: cannot generate 3D Mesh.
W1020 16:39:26.935958 15720 Mesher.cpp:523] Missing landmark information for the Mesher: cannot trim 3D mesh to time horizon.
W1020 16:39:26.936389 15722 OpenCvVisualizer3D.cpp:479] No landmark information for Visualizer. Not displaying 3D points.

Thank you,

Hi @Quentin-9
The parameter that you are using seems incorrect, you can find the calibration results from Kalibr here: pinhole_512

Hello @Quentin-9, I am trying to run my RGBD Realsense bag files through VIO and am running into issues.. would you please be able to share what changes you made to the launch files? Thank you!

Hi @Viky397, unfortunately I have not yet been able to run Kimera on another dataset than Euroc.
I created a new DataProvider to fit the format of TUM-VI following the EurocDataProvider.cpp but it does not work.
I think the main problem is coming from the distorsion model (equidistant) or probably wrong camera/imu settings (extrinsics/intrinsics). I am not sure and I have not checked thoroughly to understand why I have this kind of error: "undistortRectifyPoints: versor with zero depth".
About your question, I am not using ROS but I think Kimera provides params for this RealSense sensor. I know that you can also use Kalibr to get your parameters. Though, I advise you to create a new issue with all the details about your problem so you can have a proper and useful answer.

Thank you for the response! I'll open an issue.


when I require pacakge in .ts file, there are not intellisence

app.ts
let a = require("http");
vocode remind me "a" is typeof "any"
app2.js
let a = require("http");
vscode remind me "a" is typeof "http"
it is confuse me. why .ts file have no intellisence with require().

i want use "http" package in namspace with "amd". but typescript don't allow use import in namespace. so i use require(), but have no intellisence.

You need to install typings for node: npm install --save-dev @types/node


Feature Request: Preserve Client IP address for TCP ingress using Proxy Protocol

Is your feature request related to a problem? Please describe.
For TCP ingress, provide a way to access the client IP Address.
Describe the solution you'd like.
I need to know the client IP address for whitelisting, blacklisting, and logging client IP Addresses. Since Azure Container apps uses the Envoy proxy, preserving the client IP Address should be possible using the proxy protocol feature.
Describe alternatives you've considered.
The only alternative currently is not to use container apps and host the service inside of a VM with a public IP Address.

@marshallr12 for non-HTTP TCP connections, how is the client IP normally presented to your app (assuming there's some kind of proxy/middleware in the flow)?

The app is an SMTP server written in .NET using a System.Net.Socket.TcpListener which accepts connections and returns a System.Net.Socket.TcpClient. The client is then interrogated for the client IP, which is then used to trigger application-level rules to accept or reject the connection. This all works fine when hosting in a VM with a public IP.
In containers, the client IP is always an internal VNET address rather than the original external client IP. So that IP will always be the same no matter the initiating client IP address, and would not be useful to any TCP-based application. From what I read, the proxy in ACA is Envoy, which supports the proxy protocol when configured properly and preserves the original IP (or provides the means to access it).
If you have an SMTP application which exposes a port to the public, you have to dynamically identify bad actor IP addresses for clients / spammers. This is done with a combination of firewall-like behaviors (too many connections, too many failed login attempts, etc.), but also by querying services like SpamHaus and providing the client IP to those services. You also have to be able to identify whether the connecting MX server is authoritative for the domain associated with the sender of an email. This is done by providing the client IP address (which would belong to the connecting MX server) to a Sender Protection Framework API (SPF). Essentially, SPF uses DNS to see if the domain of the email sender corresponds to a known MX server for that domain, based on the client IP Address (i.e., the connecting MX server).
A deny-list in this scenario has to be built dynamically over time like an application-layer firewall. So it is not the sort of deny list where an admin would statically configure deny-lists and white-lists.

This image shows my connection log (which uses table storage) since I've containerized my mail server. All of these connections represent spam (or hacker) attempts. However, the client address reflects the proxy, and not the original connecting address. The "App" column would be any of SMTP, SMTPS, POP, POPS, IMAP, etc. as there are multiple email-related application servers involved.

Yes, Today TCP appS will see the client ip as that of the last proxy rather than the actual downstream client ip. I’m HTTP apps, the proxy protocol is just that of injecting XFF headers which we do.
For TCP, the proxy protocol requires the server to handle a custom TCP header on the very beginning of the connection. This as @JennyLawrance mentioned requires opt-in from the application as it’s no longer just raw TCP connection.
However, since we have envoy both on edge and as a sidecar, the proxy protocol can happen between the edge proxy/loadbalancer and the sidecar helper, then the sidecar can set the correct client ip and strip that packet out keeping it transparent to the application. https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/original_src_filter
We don’t have this today though.

I am also interested in preserving the client IP for TCP connections. Is there any update on whether this might be something implemented? In my case, I have an Azure Container App for which I am serving SFTP connections for clients, but it makes it impossible to do any advanced features based on client IP at the application level without it.

I have a similar use-case relating to SFTP that would benefit from this. Logging aside, it would allow for per-user IP restrictions to be implemented (i.e. user X can only login from IP Y, or, flipping it around, per-IP user restrictions).
A similar challenge I've run into is in multi-tenant scenarios in which the tenant wants to customize characteristics of the SSH channel (i.e. turn on or off ciphers, use their own public key, etc). Because of the way SSH works, there is no HTTP equivalent of a "Host" header and the SSH key exchange (which has the parameters I'd like to customize) happens prior to authentication (when I'd know who the client is). The only real option is to distinguish tenants by the public IP address they're connecting to. While this could be done by spinning up a container-app-per-tenant, it would be much more convenient if I could assign a public IP prefix to the container app and have Envoy also preserve the original destination IP.
It's unfortunate that no container offerings in Azure seem to allow for this at the TCP level rather than the HTTP level. Best I can tell, the only way to really do this would be to use Load Balancer in Floating IP mode along with a full IaaS VM, which I'd like to avoid.


Allows for adding multiple of same Shift on same day

I am not sure if what I encountered was a bug from my actions, or an intended featured that I don't understand, and the UI display makes it look like a bug.
To walk through how I arrived, I created a ShiftType called Morning with value 1 set for each day of the week.

Then from the Shifts plan view I clicked Add Shift button and filled out values as such.

When I first did this a handful of times, it did not seem to add after clicking Save so I clicked again. And again. And again... Then eventually after seeing no errors in console, I refreshed the page. VOILA!!! The result was:

Good, so it's properly adding shifts, just far too many. I had assumed the value 1 would limit it to one ShiftType on that given day of the week.

Upon viewing this in Chrome (above screenshot is in FF), the Shifts app properly expands the container for all items inside- so at least that part of this a cross-browser bug


Fix broken link in "Update" page

Broken link found here: https://docs.microsoft.com/en-us/cli/azure/update-azure-cli

Docs Build status updates of commit 625821f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/includes/az-upgrade.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Bumping
@kobulloc-MSFT @fengzhou-msft

@ethanshea-ms the link has been fixed by #2531


Dependencies are not loaded

When I use the command the first time I run x64dbg, I get an error:
Exception: System.MissingMethodException: Method not found: 'System.Collections.Immutable.ImmutableArray`1<Microsoft.Diagnostics.Runtime.ClrInfo> Microsoft.Diagnostics.Runtime.DataTarget.get_ClrVersions()'.
   at DotInfo.Plugin.Init(String[] args)
   at Dotx64Dbg.Plugins.<>c__DisplayClass44_0.<RegisterPluginCommand>b__0(String[] args)
   at Dotx64Dbg.Commands.CommandHandler(String cmd, Int32 argc, IntPtr ptr)
   at Dotx64Dbg.Commands.<>c__DisplayClass8_0.<Register>b__0(Int32 argc, IntPtr argv)

The error disappears if you add a couple of spaces in the source code to run hotreload.
After reloading x64dbg, the error reappears until you run hotreload through adding spaces...
P.S "Microsoft.Diagnostics.Runtime.DataTarget.get_ClrVersions" is a method from the nuget package.

Can you post a standalone plugin source that triggers this issue?

Sure, https://github.com/BadRyuner/DotInfo

I'm having trouble reproducing the issue, could you provide some detailed steps to how to get this error?

Add any plugin, which uses nuget package.
Try run any command, which calls anything from this nuget package.
Get the error "MissingMethodException"
Add some spaces to any source file and trigger HotReload.
Run again this command and the error disappear
PROFIT

...) After restarting x64dbg, repeat the steps again.
On first plugin load, required nuget dlls are not loaded.
On second load (after hotreload), required nuget dlls are loaded.
Why? idk

Sorry, I only saw this post today. I took a brief look at this and it appears to be a problem with a mismatched version of the System.Collections.Immutable library. Your plugin uses a Nuget library that internally requires a specific version of the 'System.Collections.Immutable'. What is likely happening is that another version of the same library is already loaded at the current assembly domain. When your plugin gets loaded is trying to use a version that doesn't contain the method implementation needed.
Looking at the loaded modules in x64Dbg, we can see two libraries loaded. The one, with the lowest base address, is the one loaded by our Nuget dependency handling. The other one is likely a kernel-loaded module and is shared across another process.

Of course, this is not your fault and is something that I may have overlooked when I did the NuGet contribution

Currently, I'm investigating why this can happen at the plugin's first startup. I believe a temporary solution is to trigger a hot reload in your plugin or reload XDot64Dbg with reloadplugin DotX64Dbg.Loader command (maybe is not recommended, idk)

Currently, I'm investigating why this can happen at the plugin's first startup. I believe a temporary workaround is to trigger a hot reload in your plugin or reload XDot64Dbg with reloadplugin DotX64Dbg.Loader command (maybe is not recommended, idk)

Thanks for looking into this, I came to the same conclusion as your comment before but I'm not really sure on what to do about it, for some reason it loads the dll twice once from nuget the other time its the system wide installed version, and as to why it works after a hot-load is a bit beyond me to be honest.


Fix version-copy button according to #3373

See issue #3373
This behaviour was introduced recently, the change seems to fix it again.

@miggland works on all delployment methods, thank you!


Add hub recovery labels to mirrorpeer

This commit adds recovery labels for ACM backup and restore.
https://issues.redhat.com/browse/ACM-1001
Signed-off-by: Vineet Badrinath<EMAIL_ADDRESS>

/cherry-pick release-4.10


[Feature Request] change data feed readStream support for "endingVersion"

Feature request
Overview
Today, when you pass "endingVersion" to DataStreamReader on a Delta Table with "Change Data Feed" enabled, it is just ignored.
The current supported options for CDF streams are documented here: https://docs.databricks.com/delta/delta-change-data-feed.html#read-changes-in-streaming-queries
I would like to write:
spark.readStream.format("delta")
  .option("readChangeFeed", "true")
  .option("endingVersion", 9)
   .table("myDeltaTable")

Motivation
Although it seems counter-intuitive to put an upper bound to a stream, it would solve a lot of our tables inconsistencies and synchronization issues. Actually, we would not require complex workflows with scheduling, race conditions, multi-tables transactions, synchronization and concurrency handling: all would be data driven. And we would still benefit from Delta powerful features like data bookkeeping/checkpointing. Ultimately, it would allow to achieve the transition from "scheduled/trigger once" to "trigger processing time" streaming.
Further details
I think the implementation of the fix is only one line of code at the good place + code for parsing and checking the option value. Ideally, I would like this option to be read dynamically at each trigger (with processing time).
I will require help on unit tests likely.
Willingness to contribute
The Delta Lake Community encourages new feature contributions. Would you or another member of your organization be willing to contribute an implementation of this feature?

[ ] Yes. I can contribute this feature independently.
[X] Yes. I would be willing to contribute this feature with guidance from the Delta Lake community.
[ ] No. I cannot contribute this feature at this time.

the change is the line 190

ending version is defined as:

Have you tried AvailableNow which is supported in Delta Lake 2.1.0? It will allow you to process all available data and stop. Or you would like to stop at a specific version? If so, could you clarify further?

Have you tried AvailableNow which is supported in Delta Lake 2.1.0? It will allow you to process all available data and stop. Or you would like to stop at a specific version? If so, could you clarify further?

Hello, yes I know trigger AvailableNow and it will be useful in an other use case. My requirement is your second assumption: I want to read and stop at a specific version. I don't want to enter too much into the details, but it is because, if we don't do that, the stream may be ahead of the other tables and lead to inconsistencies when joining them, it will not be eventually consistent. An other way to achieve my goal would be to control the commit of the offsets like in Kafka. For example, in the forEachBatch loop, decide or not if we commit the table changes as "consumed" (or read if you prefer). I already discussed this topic with experts from Databricks France and they suggested me to submit a PR.

Generally, Structured Streaming defines the input source as an unbounded input table

You will express your streaming computation as standard batch-like query as on a static table, and Spark runs it as an incremental query on the unbounded input table.

Introducing endingVersion would break it. We don't want to introduce this inconsistent model in Delta. Alternatively, you can write a batch time travel query to backfill data and start a streaming query using startingVersion.

First, the link you sent talk about unbounded table, not unbounded dataset.
Second, in streaming you have a very usual mechanism called: flow control. The trigger AvailableNow feature relies on this principle.
Third, do you actually suggest me to use static datasets by specifying starting and ending versions and reimplement the checkpoint mechanism on top of it?


Replace all fully-qualified links to https://convox.com/whatever with relative ones like /whatever

Release Playbook

[ ] Rebase against master
[ ] Code review
[ ] Merge into master
[ ] Verify changes at http://site-staging.convox.com
[ ] Promote release on site-production in the convox/production Rack

 Relative links on site


docs: #34499 Alternatives to docker, root filesystem permissions

…s in docker.rst

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Motivating issue #34499
This change has two parts:
A) A gentle, gradual step towards the notion of running Envoy using container technologies other than Docker. Specifically mentioned by name is Podman.
B) Express indication that Envoy must be run with its root filesystem in read-write mode. From a security perspective, read-only is much more desirable. So whether this newly-documented read-write requirement is ground truth, I don't know. But it is conservative, is probably established practice, and hopefully won't result in misleading anybody such that they "hold Envoy wrong" or cause damage. What I hope it will do is to enrage some kind soul to the point of motivating them to document exactly how the image can be run in read-only mode ;) My guess is that /tmp will need to be a writable tmpfs volume mount.

/wait on comments

/wait
actualy @enspritz  Please fix the format CI issue first

@tyxia Please check it

/wait-any
Thanks for fixing the CI failure, defer to @phlax for the review. Thanks!

/docs

/wait-any

All suggestions committed, pls check


Infinity Fabric for GPU-GPU data transfers?

There is no call of hipDeviceEnablePeerAccess in this benchmark. Does it mean that with the current version there is no possibility to test Infinity Fabric for GPU-GPU data transfers?

This application does not use HIP, it is directly built on top of ROCr's APIs, rather than the higher-level HIP language. If there is a path over Infinity Fabric for peer-to-peer communication, it will use it.

This application does not use HIP, it is directly built on top of ROCr's APIs, rather than the higher-level HIP language. If there is a path over Infinity Fabric for peer-to-peer communication, it will use it.


[SPARK-39056][CORE][SQL] Use Collections.singletonList instead of Arrays.asList when only one argument

What changes were proposed in this pull request?
This is pr use Collections.singletonList instead of Arrays.asList when there is only one argument.
Before
List<String> one = Arrays.asList("one");

After
List<String> one = Collections.singletonList("one");

Why are the changes needed?
A minor optimization will save a little memory due to Arrays.asList will create an E[] but Collections.SingletonList not.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass GA

OK~ close this

I'm not sure this is worth doing, it just doesn't save any memory

Do a simple size test
    println(s"Size of Arrays.asList(1) is ${SizeEstimator.estimate(java.util.Arrays.asList(1))}")
    println(s"Size of Collections.singletonList(1) is " +
      s"${SizeEstimator.estimate(java.util.Collections.singletonList(1))}")

The results as follows:
Size of Arrays.asList(1) is 64
Size of Collections.singletonList(1) is 40

And for performance
val valuesPerIteration = 1000000
val benchmark = new Benchmark(
      s"Test singletonList",
      valuesPerIteration,
      output = output)

    benchmark.addCase("Arrays.asList") { _: Int =>
      for (i <- 0L until valuesPerIteration) {
        java.util.Arrays.asList(i)
      }
    }

    benchmark.addCase("Collections.singletonList") { _: Int =>
      for (i <- 0L until valuesPerIteration) {
        java.util.Collections.singletonList(i)
      }
    }
    benchmark.run()

The results as follows:
OpenJDK 64-Bit Server VM 1.8.0_322-b06 on Mac OS X 11.4
Apple M1
Test singletonList:                       Best Time(ms)   Avg Time(ms)   Stdev(ms)    Rate(M/s)   Per Row(ns)   Relative
------------------------------------------------------------------------------------------------------------------------
Arrays.asList                                         5              5           0        213.4           4.7       1.0X
Collections.singletonList                             4              4           0        252.7           4.0       1.2X

Although the advantage is very small, it is good for performance and memory

Got it


Allow configuring DefaultAddressResolverGroup by flag

Motivation:
Domain name resolution failure was reported on Windows OS. #2243
Before solving the original problem, this workaround enables DefaultAddressResolverGroup by the flag. The flag is disabled by default.
The DefaultAddressResolverGroup uses JDK's built-in domain name lookup mechanism. See here for more information.
Modification:

Add useDefaultDnsResolver flag to enable DefaultAddressResolverGroup.
Register DefaultAddressResolverGroup.INSTANCE if it is possible.

Result:
A user can now use useDefaultDnsResolver flag to enable DefaultAddressResolverGroup.

Looking at the linked doc this seems to do blocking I/O - so I think we'd have to do more refactoring to use blocking executor. Not sure if it's worth it without getting more reports. I guess with Windows it's easy to enable the firewall on your app which could block udp packets coming back

Looking at the linked doc this seems to do blocking I/O.

When I was implementing this logic, I also read the documentation and got advice from @trustin.
He said we don't need to change the executor(EventLoop). It was late evening. So I was also wondering about the reason. I think this is the time to hear his opinion. 😎
@trustin Could you tell us why we don't need to change the given executor? 🙏

I think we'd have to do more refactoring to use blocking executor.

Had talked with @trustin. DefaultNameResolver does not run a domain name resolution on the given EventExecutor.
https://github.com/netty/netty/blob/b91dd0678d290a70817ddc44bb5ced2baed275fd/resolver/src/main/java/io/netty/resolver/DefaultNameResolver.java#L40-L47
To make DefaultNameResolver use blocking executor, I think we might need to override upstream behavior.
I'm still wondering if it is worth implementing? Because DNS is cacheable, we will fix the original issue on the next step.
I will leave some comments about this on code :-) WDYT?

The performance might be ok - we'd need to verify that it's not possible to deadlock. I'm not sure what would happen if a client and DNS request use the same event loop, but I have seen deadlock when blocking the event loop during a client request so I'm very scared of doing it.
I might rethink whether this is really needed (I'm currently assuming we've only had one report, the attached one, which might not indicate such a big hammer but if there are more you know about then it might be), but even if adding I'd recommend not making it default. Tests working on appveyor  (and my laptop and GitHub's Azure VMs :) ) I think give us reasonable confidence in our current defaults

I have seen deadlock when blocking the event loop during a client request so I'm very scared of doing it.

Just curious, Could you explain to me how blocking causes deadlock? 😀

I've seen it here - https://github.com/openzipkin/zipkin/pull/2703/files
It happens when a client request is made in a blocking way from a server request - if the client and server request are being handled by the same event loop, the client will wait for I/O forever while the server has blocked the event loop waiting for the client request to finish. I'm not sure if the same is an issue in this case, but it makes me very nervous :)

Tests working on appveyor (and my laptop and GitHub's Azure VMs :)

Could you take a DNS test for http://echo.jsontest.com and http://json.org? If you can test it, I want to get your result. 😀

but even if adding I'd recommend not making it default.

We have discussed Windows domain resolution issue and decide to divide this into 3 steps.
1st step

Offer DefaultAddressResolverGroup which resolves DNS using Jdk resolver.
Turn off default option for every OS.
Use Blocking operation.

If this is fine, we could merge this PR after turning off the flag. If you don't agree with the blocking operation even though it turns off the default option, I will fork Netty DefaultAddressResolverGroup and fetch it to run domain resolution with a given executor. 🛠
2nd step

After testing, if Netty async DNS resolver has a problem with basic Windows configuration, turning on default flag only for Window.

3th step

Investing the original problem and fetch Netty or Armeria code.

WDYT? @anuraaga /cc @minwoox @trustin

I think that looks fine since we don't change the default without more investigation. Only thing I'd add is for 2nd step, if changing the default also be sure that the blocking won't cause deadlock. I guess it won't - the pattern is probably doing one more I/O after the block which wouldn't happen since DNS is the lowest level possible - but want to be confidence since it's very confusing to debug

Only thing I'd add is for 2nd step, if changing the default also be sure that the blocking won't cause deadlock.

That sounds good to me. When we need to change the default, I will change default DNS resolver to run with blocking executor. 👍

Updated:

This flag is disabled by default.
Update PR title, description, and code.


OpenVPN 2.6.3 Client will not install

Describe the bug
Can't install OpenVPN 2.6.3 after running the "Set Service to Manual" Script
To Reproduce
Install Windows 11 Pro, Update Full, Run the script.

OpenVPN.MSI Setup Log:
OpenVPN.log

There's a bug now that disables Windows Management Instrument (WMI) instead of making it manual, given the timing quite likely culprit.
https://github.com/ChrisTitusTech/winutil/issues/735
Basically just do the same steps but set it to manual (instead of disabled) and start it.

There's a bug now that disables Windows Management Instrument (WMI) instead of making it manual, given the timing quite likely culprit.
#735 Basically just do the same steps but set it to manual (instead of disabled) and start it.

Start the WMI-Service does not solve this problem!

Resolved in #760


PD Deck Setup: Sticky Start and End in Protocol Timeline + background colour

As a protocol designer, I always want to be able to see the beginning and end of my protocol timeline in the protocol timeline sidebar.
Acceptance Criteria

'Edit Protocol Deck Setup' is sticky at the top of the sidebar
'Result' is sticky at the bottom of the sidebar
New background color for deck map in 'Edit Protocol Deck Setup'
Change name of 'Starting Deck State' to 'Edit Deck Setup'
Change name of 'Result' to 'View Result'

on hold pending open design discussion w/ @pantslakz

I'm pretty sure this is not a useful ticket anymore. Closing. @umbhau , @pantslakz , or @howisthisnamenottakenyet if there is something to be done related to this, please either re-open this ticket with details, or open a new ticket


Feature: Regexes

Regices?
There's single-header regex libraries out there. It would probably be the last single-header added because it's the last big feature.

Increasingly wondering if PCRE is the right choice here. If I have a way of collecting matches, I have M-/ basically for free. Thinking about it and evaluating my options.

I could gate out PCRE, so that those that don't need that functionality can just #define and go home. Other regexp libraries might work for basic regex search and replace. I would just dearly like those capture groups for M-/.

https://github.com/kokke/tiny-regex-c seems like the best choice, actually. However, in the great emsys tradition, M-/ will be a lot simpler than it is in gomacs.
search = last-alphanumeric-word
if strlen(search) <= 0
  return
matches = vector-of-matches
for buffer in buffers
  for line in buffer.lines
    if regex_match(line)
      append match to matches

chosen = tab_complete_on_matches()

insert chosen into row

Regexp replace should be simple enough along similar lines: find a match, replace it with the replace string, bob's yer uncle.

First part just done: a639ee90875cf8ab9c194d9dfc8ad2079798c5be
The little regex library that could! It's a great success. All we need now is a regex-replace to go with string-replace, and we'll be laughing.


Improve the look of the website

Hey! I would love to add some more CSS to modernize the look of the website. Please allow me to work on this.

Hi, currently the improvement of website look is of low priority than adding projects. However will open this in near future. Thanks!


runtime/libtock_layout.ld: ASSERT well-aligned RAM address

Rust's default linker (llvm-ld) as used with the Rust toolchain versions of at least 2022-06-10, 2023-01-26, and 2023-06-27 can produce broken ELF binaries when the RAM region's start address is not well-aligned to a 4kB boundary. Unfortunately, this behavior is rather tricky to debug: instead of refusing to produce a binary or producing a corrupt output, it generates an ELF file which includes a segment that points to the ELF file's header itself. elf2tab will include this segment in the final binary (as it is set to be loaded), producing broken TBFs. This (overrideable) check is designed to warn users that the linker may be misbehaved under these conditions.
To reproduce this on this current git revision, with a Rust toolchain version 2023-06-27, change the opentitan.ld layout file to add an offset of 0x800 bytes to the RAM segment's start address:
@@ -5,7 +5,7 @@ MEMORY {
    * the kernel binary, check for the actual address of APP_MEMORY!
    */
   FLASH (X) : ORIGIN = 0x20030000, LENGTH = 32M
-  RAM   (W) : ORIGIN = 0x10004000, LENGTH = 512K
+  RAM   (W) : ORIGIN = 0x10004000 + 0x800, LENGTH = 512K - 0x800
 }

 TBF_HEADER_SIZE = 0x60;

Further, remove the .tbf_header reservation:
@@ -67,7 +67,7 @@ SECTIONS {
     /* Add a section where elf2tab will place the TBF headers, so that the rest
      * of the FLASH sections are in the right locations. */ .tbf_header (NOLOAD) : {
-        . = . + TBF_HEADER_SIZE;
+        /* . = . + TBF_HEADER_SIZE; */
     } > FLASH

     /* Runtime header. Contains values the linker knows that the runtime needs

Now, compile the console example for the opentitan target. When looking at the generated ELF file, it contains a segment at (an ELF-file) offset 0x000000, set to be LOADed, with a non-zero size. This segment thus points to the ELF file header itself.
 For that, make the following change to .cargo/config:
@@ -9,6 +9,8 @@ rtv7em = "rthumbv7em"
 # Common settings for all embedded targets
 [target.'cfg(any(target_arch = "arm", target_arch = "riscv32"))']
 rustflags = [
+    "-C", "linker=riscv64-unknown-elf-ld",
+    "-C", "link-arg=-melf32lriscv",
     "-C", "relocation-model=static",
     "-C", "link-arg=-Tlayout.ld",
 ]

Further, change the .start section's alignment, as GNU LD does not support specifying a section alignment constraint without a preceding section:
@@ -73,7 +73,8 @@ SECTIONS {
     /* Runtime header. Contains values the linker knows that the runtime needs
      * to look up. */
-    .start ALIGN(4) : {
+    . = ALIGN(4);
+    .start : {
         /* We combine rt_header and _start into a single section. If we don't,
          * elf2tab does not parse the ELF file correctly for unknown reasons.
          */

This is the segment layout of the resulting binary, which is correct and no longer references the ELF header itself:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x10004000 0x10004000 0x00094 0x00900 RW  0x1000
  LOAD           0x001000 0x20030000 0x20030000 0x00f50 0x00f50 R E 0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00     .stack
   01     .start .text .rodata
   02

(In this case, the .stack section is included in the final binary in a segment of size 0x900, to account for the segment alignment constraints. This also points to the ELF-internal offset of 0x000000, so referencing the ELF header. Yet this is fine in this case, as the .stack symbol within that region is beyond the allocated MemSiz offset (at an offset of 0x800), so zero-initialized as intended. The .stack should not at all end in the final binary, and never at a PhysAddr / load address within the RAM section; however this is an orthogonal issue.)

bors r+
IDK if Bors still works atm, we'll see.

make raspberry_pi_pico EXAMPLE=console
LIBTOCK_PLATFORM=raspberry_pi_pico cargo run --example console  \
		--target=thumbv6m-none-eabi --release
   Compiling libtock v0.1.0 (/Users/bradjc/git/libtock-rs)
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "/var/folders/_4/n3tmwxks3318tsb36d913f600000gn/T/rustcCgQTDB/symbols.o" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/examples/console-b8d0ccdcc2019f4a.console.958763e2-cgu.0.rcgu.o" "--as-needed" "-L" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/deps" "-L" "/Users/bradjc/git/libtock-rs/target/release/deps" "-L" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/build/libtock_runtime-99ba9d61b296ff5e/out" "-L" "/Users/bradjc/.rustup/toolchains/nightly-2022-06-10-x86_64-apple-darwin/lib/rustlib/thumbv6m-none-eabi/lib" "--start-group" "--end-group" "-Bstatic" "/Users/bradjc/.rustup/toolchains/nightly-2022-06-10-x86_64-apple-darwin/lib/rustlib/thumbv6m-none-eabi/lib/libcompiler_builtins-be4ad9a9d51b230c.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/Users/bradjc/.rustup/toolchains/nightly-2022-06-10-x86_64-apple-darwin/lib/rustlib/thumbv6m-none-eabi/lib" "-o" "/Users/bradjc/git/libtock-rs/target/thumbv6m-none-eabi/release/examples/console-b8d0ccdcc2019f4a" "--gc-sections" "-O1" "-Tlayout.ld"
  = note: rust-lld: error:
          Start of RAM region must be well-aligned to a 4kB boundary for LLVM's lld to
          work. Refer to https://github.com/tock/libtock-rs/pull/477 for more
          information. Set LIBTOCKRS_OVERRIDE_RAM_ORIGIN_CHECK = 1 to override this check
          (e.g., when using a different linker).

          rust-lld: error:
          Start of RAM region must be well-aligned to a 4kB boundary for LLVM's lld to
          work. Refer to https://github.com/tock/libtock-rs/pull/477 for more
          information. Set LIBTOCKRS_OVERRIDE_RAM_ORIGIN_CHECK = 1 to override this check
          (e.g., when using a different linker).

error: could not compile `libtock` due to previous error
make: *** [raspberry_pi_pico] Error 101

What do I do?

@bradjc Merge #476. That fixes this issue.


Training dataset information of mix.pth (hugging face)

Hi,
Thanks for the great work, Could you please specify all the dataset used for training of hugging face model https://huggingface.co/spaces/ECCV2022/Screen_Image_Demoireing/tree/main "mix.pth"

Sorry for the late reply - my research has shifted away from this area, so I haven't been keeping up with this repo much.
About the demo config: it's pretty straightforward. You'll just need to write a new dataloader that can handle merging and loading multiple datasets. For handling large images, go for cropping, and for the TIP2018 dataset, resize it firstly and then do cropping. All the specific details for these implementations are mentioned in the paper, so you can check them out there.
No extra parameter tweaking needed beyond that.
Hope this helps!

Hi, Thanks for the great work, Could you please specify all the dataset used for training of hugging face model https://huggingface.co/spaces/ECCV2022/Screen_Image_Demoireing/tree/main "mix.pth"

Sorry for the late reply - my research has shifted away from this area, so I haven't been keeping up with this repo much.
About the demo config: it's pretty straightforward. You'll just need to write a new dataloader that can handle merging and loading multiple datasets. For handling large images, go for cropping, and for the TIP2018 dataset, resize it firstly and then do cropping. All the specific details for these implementations are mentioned in the paper, so you can check them out there.
No extra parameter tweaking needed beyond that.
Hope this helps!


chore: bump to 6.0.0 to prepare for release

:tada: This PR is included in version 3.0.0 :tada:
The release is available on:

GitHub release
v3.0.0

Your semantic-release bot :package::rocket:


pinocchio: 2.6.20 -> 2.6.21

Description of changes
replace #270649, with:

eigenpy 3.1.3 -> 3.1.4
hpp-fcl 2.3.7 -> 2.4.0
pinocchio 2.6.20 -> 2.6.21

ref.
https://github.com/stack-of-tasks/eigenpy/releases/tag/v3.1.4
https://github.com/humanoid-path-planner/hpp-fcl/releases/tag/v2.4.0
https://github.com/stack-of-tasks/pinocchio/releases/tag/v2.6.21
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 270680 run on x86_64-linux 1

13 packages built:

crocoddyl
hpp-fcl
pinocchio
python310Packages.crocoddyl
python310Packages.eigenpy
python310Packages.example-robot-data
python310Packages.hpp-fcl
python310Packages.pinocchio
python311Packages.crocoddyl
python311Packages.eigenpy
python311Packages.example-robot-data
python311Packages.hpp-fcl
python311Packages.pinocchio


http_request does not support the :patch action

Description
If you want to create an HTTP request using the :patch action, it is not currently possible. See http_request documentation.
Chef Version
All versions after which http_request was implemented.
Platform Version
This occurs on any platform, any version.
Replication Case
Try to create an http_request to a REST API that uses the :patch action. The option is unavailable.
Client Output
There is no output because you cannot use the :patch action.
http_request 'posting data' do
  action :patch
  url 'http://example.com/check_in'
  message ({:some => 'data'}.to_json)
  headers({'AUTHORIZATION' => "Basic #{
    Base64.encode64('username:password')}",
    'Content-Type' => 'application/data'
  })
end

dup of #6131 which we just need to get time to merge


Send the TRN back to Identity and redirect if the initial request was from Identity

Context
After being redirected to Find A TRN from Identity and a TRN has been found, send an API request back to Identity with the TRN and then redirect to the supplied redirect uri.
Changes proposed in this pull request
Creates a new API call to Identity to send the TRN for an Identity journey. Changes the controller logic to send the TRN back to Identity and redirect instead of continuing the Find A TRN process if the initial request came from Identity. If no matching TRN was found an API request will still be made with no TRN.
Checklist

[ ] Attach to Trello card
[x] Rebased main
[x] Cleaned commit history
[x] Tested by running locally

 POST /check-answers: Handover from Find to Get an identity


Sister topic (or broader scope) for Debug ASP.NET Applications in Visual Studio topic?

Is there a plan to have a sister topic (or a broader scope) for Debug ASP.NET Applications in Visual Studio for ASP.NET Core?
I was looking for such a topic to link into the Troubleshoot ASP.NET Core on IIS in the aspnet/Docs, and I needed a VS debugging topic that relied on IIS Express that included or centered on ASP.NET Core.

Nevermind ... I found something close to what I need in using the main Learn to debug using Visual Studio topic.


ci(delivery): publish to Galaxy only on new releases

galaxy job runs only when github job decided a new release was required

:tada: This PR is included in version 1.1.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Docusaurus site for docs

For Gatekeeper and Eraser we utilize docusaurus for a documentation site. Any thoughts about doing something similar for Ratify docs?
https://azure.github.io/eraser/docs/
https://open-policy-agent.github.io/gatekeeper/website/docs/

+1. If we prefer creating a generic website with a built-in documentation framework, Docsy is also a good alternative.

Closing as we now have a website. See here


References-view: "TypeError: Cannot destructure property 'range' of 'e.location' as it is undefined." occurs when a HistoryItem gets returned

Does this issue occur when all extensions are disabled?: N/A

VS Code Version: Today's insiders.
OS Version: Windows.

Steps to Reproduce:

The repro is using our C/C++ extension when doing a Find All References and then doing another Find All References while the 1st is still "confirming" references, but I don't think it's a bug with our extension. The symptom is TypeError: Cannot destructure property 'range' of 'e.location' as it is undefined.

The code with the bug is at
https://github.com/microsoft/vscode/blob/bf574780a9e2c3db6f6afa6edf0e5c597bdd7bf5/extensions/references-view/src/references/model.ts#L288
It seems like the } else { should be } else if (element instanceof ReferenceItem) {.
The element appears to be a HistoryItem: https://github.com/microsoft/vscode/blob/bf574780a9e2c3db6f6afa6edf0e5c597bdd7bf5/extensions/references-view/src/tree.ts#L226C2-L226C2
The debugger shows

I'm not sure why the element is a HistoryItem, but it seems like the code should handle that case.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Button labels should not be capitalized using CSS

Describe the bug
Currently, all button labels are capitalized by using the text-transform CSS property with a value of capitalize. This property automatically converts text to Title Case. However, while Title Case is valid in English, it isn't necessarily in other languages.
For example, Create Room is valid in English but Créer Une Salle is not in French as it should instead be Créer une salle.
Expected behavior
I think that text capitalization - and text formatting in general - should be done within the translation files themselves.

One way I can see this being solved is creating a translation class kinda how Android or Minecraft has, in which you call a function to get the translated text based on language, or a lot will need to be refactored for each individual language. Sadly, I lack the knowledge to implement something like this but someone smarter will probably read this and know how to implement it. Good bug report!

I disagree. The Text-Capitalization property exists for a reason. A11y recommends using it because screen-readers scream at you if you don't. Even worse: If they don't recognize the word, they may read it letter by letter (e.g B U T T O N)

I disagree. The Text-Capitalization property exists for a reason. A11y recommends using it because screen-readers scream at you if you don't. Even worse: If they don't recognize the word, they may read it letter by letter (e.g B U T T O N)

Firstly, why would screen readers read a word letter by letter if it's properly capitalized in the translation file? Furthermore, as of speaking, not a single string from all translation files is all uppercase, so a transition wouldn't be a potential problem for screen readers.
Secondly, as I wrote in the issue's description, Title Case simply is invalid in some languages (e.g. French). If the website wants to reach a broader international audience then issues like this one will have to get fixed, especially considering that others have pulled them off while still offering great accessibility.

Firstly, why would screen readers read a word letter by letter if it's properly capitalized in the translation file?

Because some work that way.

Furthermore, as of speaking, not a single string from all translation files is all uppercase, so a transition wouldn't be a potential problem for screen readers.

I didn't realize this was the case. It should be fine then.
I'm not sure how other projects solve this issue, I wanted to make sure people knew about it. There are more examples here. Screenreaders read the text in the DOM, regardless of how text is represented via css

This is valid for Serbian 🇷🇸  too.
It should be Направите собу, not Направите Собу.

Also german words can change meaning just by capitalisation


httpcore.ConnectError && httpx.ConnectError && git clone exception

Describe the issue
File "/usr/local/lib/python3.9/site-packages/httpcore/_exceptions.py", line 14, in map_exceptions
raise to_exc(exc) from exc
httpcore.ConnectError: [Errno 111] Connection refused
...
...
File "/usr/local/lib/python3.9/site-packages/httpx/_transports/default.py", line 89, in map_httpcore_exceptions
raise mapped_exc(message) from exc
httpx.ConnectError: [Errno 111] Connection refused
The attachment contains the command and its output.
output.md
Thanks!
Optional: Relevant documentation page
No response

Regarding the git error
RuntimeError: Failed to clone repository with fast method: hint: Using 'master' as the name for the initial branch. This default branch name

hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
Initialized empty Git repository in /pvlib__pvlib-python/.git/
error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
error: 3868 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
INFO     Beginning environment shutdown...
Traceback (most recent call last):
  File "/app/sweagent/api/server.py", line 75, in run
    main.main()
  File "/app/run.py", line 397, in main
    raise e
  File "/app/run.py", line 381, in main
    self.run(index)
  File "/app/run.py", line 345, in run
    observation, info = self.env.reset(index)
  File "/app/sweagent/environment/swe_env.py", line 331, in reset
    self._copy_repo()
  File "/app/sweagent/environment/swe_env.py", line 264, in _copy_repo
    self.communicate_with_handling(
  File "/app/sweagent/environment/swe_env.py", line 798, in communicate_with_handling
    raise RuntimeError(msg)
RuntimeError: Failed to clone repository with fast method: hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
Initialized empty Git repository in /pvlib__pvlib-python/.git/
error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
error: 3868 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

I'd say that's an internet connection problem (?).

Relevant bit seems to be
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/httpx/_transports/default.py", line 72, in map_httpcore_exceptions
    yield
  File "/usr/local/lib/python3.9/site-packages/httpx/_transports/default.py", line 236, in handle_request
    resp = self._pool.handle_request(req)
  File "/usr/local/lib/python3.9/site-packages/httpcore/_sync/connection_pool.py", line 216, in handle_request
    raise exc from None
  File "/usr/local/lib/python3.9/site-packages/httpcore/_sync/connection_pool.py", line 196, in handle_request
    response = connection.handle_request(
  File "/usr/local/lib/python3.9/site-packages/httpcore/_sync/connection.py", line 99, in handle_request
    raise exc
  File "/usr/local/lib/python3.9/site-packages/httpcore/_sync/connection.py", line 76, in handle_request
    stream = self._connect(request)
  File "/usr/local/lib/python3.9/site-packages/httpcore/_sync/connection.py", line 122, in _connect
    stream = self._network_backend.connect_tcp(**kwargs)
  File "/usr/local/lib/python3.9/site-packages/httpcore/_backends/sync.py", line 213, in connect_tcp
    sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
  File "/usr/local/lib/python3.9/contextlib.py", line 137, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.9/site-packages/httpcore/_exceptions.py", line 14, in map_exceptions
    raise to_exc(exc) from exc

##### httpcore.ConnectError: [Errno 111] Connection refused

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/run.py", line 381, in main
    self.run(index)
  File "/app/run.py", line 365, in run
    info, trajectory = self.agent.run(
  File "/app/sweagent/agent/agents.py", line 812, in run
    thought, action, output = self.forward(observation, env.get_available_actions(), state)
  File "/app/sweagent/agent/agents.py", line 488, in forward
    thought, action, output = self.forward_with_error_check(observation, state)
  File "/app/sweagent/agent/agents.py", line 646, in forward_with_error_check
    return self.check_format_and_requery(self.forward_model(observation, state))
  File "/app/sweagent/agent/agents.py", line 548, in forward_model
    return self.model.query(self.local_history)
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 336, in wrapped_f
    return copy(f, *args, **kw)
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 475, in __call__
    do = self.iter(retry_state=retry_state)
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 376, in iter
    result = action(retry_state)
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 418, in exc_check
    raise retry_exc.reraise()
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 185, in reraise
    raise self.last_attempt.result()
  File "/usr/local/lib/python3.9/concurrent/futures/_base.py", line 439, in result
    return self.__get_result()
  File "/usr/local/lib/python3.9/concurrent/futures/_base.py", line 391, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 478, in __call__
    result = fn(*args, **kwargs)
  File "/app/sweagent/agent/models.py", line 709, in query
    response = self.client.chat(
  File "/usr/local/lib/python3.9/site-packages/ollama/_client.py", line 236, in chat
    return self._request_stream(
  File "/usr/local/lib/python3.9/site-packages/ollama/_client.py", line 99, in _request_stream
    return self._stream(*args, **kwargs) if stream else self._request(*args, **kwargs).json()
  File "/usr/local/lib/python3.9/site-packages/ollama/_client.py", line 70, in _request
    response = self._client.request(method, url, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/httpx/_client.py", line 837, in request
    return self.send(request, auth=auth, follow_redirects=follow_redirects)
  File "/usr/local/lib/python3.9/site-packages/httpx/_client.py", line 926, in send
    response = self._send_handling_auth(
  File "/usr/local/lib/python3.9/site-packages/httpx/_client.py", line 954, in _send_handling_auth
    response = self._send_handling_redirects(
  File "/usr/local/lib/python3.9/site-packages/httpx/_client.py", line 991, in _send_handling_redirects
    response = self._send_single_request(request)
  File "/usr/local/lib/python3.9/site-packages/httpx/_client.py", line 1027, in _send_single_request
    response = transport.handle_request(request)
  File "/usr/local/lib/python3.9/site-packages/httpx/_transports/default.py", line 236, in handle_request
    resp = self._pool.handle_request(req)
  File "/usr/local/lib/python3.9/contextlib.py", line 137, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.9/site-packages/httpx/_transports/default.py", line 89, in map_httpcore_exceptions
    raise mapped_exc(message) from exc
httpx.ConnectError: [Errno 111] Connection refused

So this seems to be a problem with your ollama setup. There's a small bit of info here about using llama

Okay, thank you. I'll check it out.


ESP official ESP32-S3-EYE v2.2 development board flash firmware

Hello! Please tell me about the situation of ESP official ESP32-S3-EYE v2.2 development board flashing firmware (development board link: https://github.com/espressif/esp-who/blob/master/docs/en/get- started/ESP32-S3-EYE_Getting_Started_Guide.md), I tried to flash microlite-esp32-s3-firmware; microlite-esp32-s3-spiram-cs-gpio-20-firmware; microlite-esp32-s3-spiram-firmware; microlite -esp32-s3-spiram-octal-firmware, only one line is returned in PuTTY, there is no Micropython prompt to return, it seems to be stuck there, I don't know where is the problem? Thanks! As shown below

Hello, I tried the latest package from micropython.org, directly download GENERIC_S3-20220117-v1.18.bin (https://micropython.org/download/GENERIC_S3/), now this thonny can return the python character as shown below, I don’t know There is a problem there, see if you can help, generate a bin corresponding to the ESP32-S3-EYE integration, thank you

!

Thanks for this report.  For esp32 and stm32 we have our pent board configuration that were copied from micropython upstream.
I suspect something was changed in the upstream configuration.
I don't have s3 boards but I can pick up the latest upstream changes and then trigger a build on that branch for you to test on.

Hello! Thank you very much for your reply and help! Looking forward to your builds for us to test, we'll try to provide feedback! At the same time, if it is convenient for you, I can provide an ESP32-S3-EYE v2.2 board to express and mail it to you to facilitate your joint debugging and build it for everyone to share, thank you!

I found the change I made to the esp32s3's which was to disable USB.
I wonder if for your board or needed it to be there.
Are you setup to build from scratch?
You could try to revert this change and then see if the s3ima few then works for you:
https://github.com/mocleiri/tensorflow-micropython-examples/commit/2d0948b542c6c5bee92b2bb9e383fec59a1358f1

Hello! The resources we need to call include video, audio, SD card, USB, WIFI, Bluetooth, and ESP-NN acceleration in the official https://github.com/espressif/tflite-micro-esp-examples, please help, Generate and package a BIN for download testing, thank you!

Hello! The resources we need to call include video, audio, display, SD card, USB, WIFI, Bluetooth, and ESP-NN acceleration in the official https://github.com/espressif/tflite-micro-esp-examples, please For help, generate and package a BIN for downloading and testing, thank you!

Hello! The resources we need to call are video, audio, display, SD card, USB, WIFI, Bluetooth, and ESP-NN acceleration in the official https://github.com/espressif/tflite-micro-esp-examples, here The official C BIN can run, please help, generate and package a BIN called by micropython for downloading and testing, thank you!

I took a more detailed look comparing each file from the MICROLITE_S3  project against the upstream GENERIC_S3 and found there was another change in the header file which is now applied.
It enables repl over uart.
@pyharry can you check the applicable S3 build at this link have the new option set:
https://github.com/mocleiri/tensorflow-micropython-examples/actions/runs/3727467156
I changed the build to assemble a single firmware.bin like upstream which is directly flashable.


transposition improvement

I really like to use the scalar transposition feature, but one thing that bugs me is when you transpose above/below the limits of the scale vector, it loops around and shits the note to the bottom/top of the scale. This sounds bad (I think), but the nice thing is that it preserves the shape of the sequence. It sounds better to just limit the sequence to the bottom or top of the scale, but then you lose the relative positioning of the notes within the scale.

addressed in #36


Docs about Field Delineation algorithm

Submitting a documentation page about the Field Delineation BYOA that is currently being on-boarded. Any comments and suggestions are welcome.

@Dorothyrono These changes should now be published to collections.eurodatacube.com in order for field delineation to be published. Could you apply them there?

If needed soon.. @chorng  or  @Kampen1988  could help

Hi @totycro, I see that these changes have been deployed and are available at https://collections.eurodatacube.com/field-delineation/. :tada:

Thanks for applying the changes, the algorithm is now also available on the EDC marketplace:
https://eurodatacube.com/marketplace/data-products/on-demand


Memleak with hash_ring_add_node

Example code:
#include "hash_ring.h"

#define NUM_REPLICAS 512
#define NODE_NAME "asdf"

int main() {
    hash_ring_t *ring = hash_ring_create(NUM_REPLICAS, HASH_FUNCTION_SHA1);

    hash_ring_add_node(ring, NODE_NAME, sizeof(NODE_NAME));

    hash_ring_free(ring);

    return 0;
}

Valgrind output:
valgrind --leak-check=full ./chrismoos-hash-ring_test
make: Für das Ziel „all“ ist nichts zu tun.
==7480== Memcheck, a memory error detector
==7480== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7480== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==7480== Command: ./chrismoos-hash-ring_test -d -w=1 -m=2
==7480==
==7480==
==7480== HEAP SUMMARY:
==7480==     in use at exit: 3,986 bytes in 512 blocks
==7480==   total heap usage: 1,030 allocs, 518 frees, 20,447 bytes allocated
==7480==
==7480== 3,986 bytes in 512 blocks are definitely lost in loss record 1 of 1
==7480==    at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==7480==    by 0x109DC9: hash_ring_add_items (hash_ring.c:188)
==7480==    by 0x10A314: hash_ring_add_node (hash_ring.c:256)
==7480==    by 0x1098E6: main (chrismoos-hash-ring_test.c:74)
==7480==
==7480== LEAK SUMMARY:
==7480==    definitely lost: 3,986 bytes in 512 blocks
==7480==    indirectly lost: 0 bytes in 0 blocks
==7480==      possibly lost: 0 bytes in 0 blocks
==7480==    still reachable: 0 bytes in 0 blocks
==7480==         suppressed: 0 bytes in 0 blocks
==7480==
==7480== For counts of detected and suppressed errors, rerun with: -v
==7480== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Thanks @pointhi, this should be fixed in https://github.com/chrismoos/hash-ring/commit/b791f3cd5fc9c91ea7eff1871e43a5e9b4540518.


[Feature request] metro-config should add support for react-native-macos and react-native-windows

What happened?
The docs suggest the following config:
// metro.config.js
const { makeMetroConfig } = require("@rnx-kit/metro-config");

module.exports = makeMetroConfig({
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: false,
      },
    }),
  },
});

This gives monorepo support, but it would be really helpful if it also made react-native-macos and react-native-windows "just work" by setting up whatever config they need, too.
Affected Package
@rnx-kit/metro-config
Version
0.6.8
Which platforms are you seeing this issue on?

[ ] Android
[ ] iOS
[X] macOS
[X] Windows

See system information
System Information
System:
  OS: macOS 14.5
  CPU: (16) arm64 Apple M3 Max
  Memory: 8.18 GB / 48.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.16.0
    path: ~/.volta/tools/image/node/20.16.0/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.volta/tools/image/yarn/1.22.19/bin/yarn
  npm:
    version: 10.8.1
    path: ~/.volta/tools/image/node/20.16.0/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.14.3
    path: /Users/jamie/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.5
      - iOS 17.5
      - macOS 14.5
      - tvOS 17.5
      - visionOS 1.2
      - watchOS 10.5
  Android SDK:
    API Levels:
      - "31"
      - "34"
    Build Tools:
      - 32.1.0
      - 33.0.0
      - 34.0.0
    Android NDK: Not Found
IDEs:
  Android Studio: 2021.2 AI-212.5712.43.2112.8609683
  Xcode:
    version: 15.4/15F31d
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /Users/jamie/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react: Not Found
  react-native: Not Found
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Steps to Reproduce

Set up a react-native project (whether in a monorepo or regular repo).
Add react-native-macos and/or react-native-windows projects to it.
Observe that Metro can't resolve files like node_modules/react-native-windows/Libraries/Image/Image.windows.js because it's still looking inside the react-native folder rather than substituting the react-native-windows folder when the platform is Windows.

Code of Conduct

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

This is the config that is used in RNTA and it works on all platforms: https://github.com/microsoft/react-native-test-app/blob/trunk/example/metro.config.js
Can you share a repro where this doesn't work?

Think I’ll have my hands full for a few days but I’ll try to get back to you!

I think @shirakaba is trying to use it with the expo CLI, not the RN CLI.  The RN CLI automatically handles adding the platform redirections (https://github.com/facebook/react-native/blob/main/packages/community-cli-plugin/src/utils/metroPlatformResolver.js), which maybe the expo CLI doesn't.
I wonder if this is something that should be resolved in expo CLI?  Or should we detect expo CLI and do it here?

I wonder if this is something that should be resolved in expo CLI? Or should we detect expo CLI and do it here?

If the Expo CLI isn't, it probably should. I don't think we want to detect Expo CLI since we cannot determine which should be used in a mixed project (e.g. Expo for mobile and RN-CLI for desktop).
I wonder if we can merge them like below:
// metro.config.js
const { makeMetroConfig } = require("@rnx-kit/metro-config");
const { getDefaultConfig } = require('expo/metro-config');

const config = getDefaultConfig(__dirname);

module.exports = makeMetroConfig(config);

If this works, we can put it in the README.

Good point, @acoates-ms! Yes, I'm using Expo CLI here. I hadn't expected that the RN CLI would implement that logic under-the-hood.
I think @tido64's solution of merging the configs is an elegant one.
I think explicitly merging the configs feels less magical (and therefore a lot better) than silently detecting whether we're running inside Expo CLI to run implicit logic.
If that would seem like the way to go, at some point we could create a reference third-party Expo template for iOS + Android + Windows + macOS whose metro.config.js looks like the above (see expo-template-bare-minimum for reference).
I'll try to test whether that config-merging approach works and get back to you.

Hmm, I tried that merging approach on an Expo-managed react-native-macos project and it's failing to resolve:

I'll try to dig into what's going wrong. I assume maybe just the merging has been applied in the wrong order.

Oh, right. We'll still need to merge in that metroPlatformResolver.js logic from RN CLI.

I got it working, but it's a bit gross.
const { makeMetroConfig } = require("@rnx-kit/metro-config");
const { getDefaultConfig } = require("expo/metro-config");

const defaultConfig = getDefaultConfig(__dirname);
const {
  resolver: { sourceExts, assetExts },
} = defaultConfig;

/** @type {import("metro-config").MetroConfig} */
const config = {
  ...defaultConfig,
  resolver: {
    ...defaultConfig.resolver,
    // https://github.com/facebook/react-native/blob/4f47b385fa592942b34b3dba9f35bcc43677511b/packages/community-cli-plugin/src/utils/loadMetroConfig.js#L45
    resolveRequest: reactNativePlatformResolver({
      macos: "react-native-macos",
      windows: "react-native-windows",
    }),
  },
  serializer: {
    ...defaultConfig.serializer,
    // https://github.com/facebook/react-native/blob/4f47b385fa592942b34b3dba9f35bcc43677511b/packages/community-cli-plugin/src/utils/loadMetroConfig.js#L60C1-L73C9
    getModulesRunBeforeMainModule() {
      return [
        require.resolve("react-native/Libraries/Core/InitializeCore"),
        require.resolve("react-native-macos/Libraries/Core/InitializeCore"),
        require.resolve("react-native-windows/Libraries/Core/InitializeCore"),
        ...defaultConfig.serializer.getModulesRunBeforeMainModule(),
      ];
    },
  },
};

module.exports = makeMetroConfig(config);

/**
 * Copyright (c) Meta Platforms, Inc. and affiliates.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 *
 *
 * @format
 * @oncall react_native
 */

/**
 * This implementation is copy-pasted from the following file, which can't be
 * imported because it involves a subpath that's not allowed by the package's
 * exports map:
 * require("@react-native/community-cli-plugin/dist/utils/metroPlatformResolver.js").reactNativePlatformResolver
 *
 * This is an implementation of a metro resolveRequest option which will remap
 * react-native imports to different npm packages based on the platform
 * requested. This allows a single metro instance/config to produce bundles for
 * multiple out-of-tree platforms at a time.
 *
 * @param platformImplementations
 * A map of platform to npm package that implements that platform
 *
 * Ex:
 * {
 *    windows: 'react-native-windows',
 *    macos: 'react-native-macos'
 * }
 */
function reactNativePlatformResolver(platformImplementations) {
  return (context, moduleName, platform) => {
    let modifiedModuleName = moduleName;
    if (platform != null && platformImplementations[platform]) {
      if (moduleName === "react-native") {
        modifiedModuleName = platformImplementations[platform];
      } else if (moduleName.startsWith("react-native/")) {
        modifiedModuleName = `${
          platformImplementations[platform]
        }/${modifiedModuleName.slice("react-native/".length)}`;
      }
    }
    return context.resolveRequest(context, modifiedModuleName, platform);
  };
}

It could get a bit cleaner by using loadMetroConfig to fill in the resolveRequest and serializer fields under-the-hood, but as it's an async function, I'm not sure that calling it is even an option inside metro.config.js.
Not sure where to go from here. Thoughts?

I opened https://github.com/expo/expo/issues/30820 on expo to see what they think.  I don't think they are fundamentally opposed to the idea.

Not sure where to go from here. Would duplicating that resolveRequest and getModulesRunBeforeMainModule config into @rnx-kit/metro-config be worth it just to clean up the user-side code? Should @rnx-kit/metro-config derive its config from @react-native/community-cli-plugin under-the-hood?

This is exactly what @rnx-kit/metro-config already does: https://github.com/microsoft/rnx-kit/blob/8b6e6f6944be01270208a19c20185fa498d875cc/packages/metro-config/src/defaultConfig.js#L125-L133
So it looks like it either doesn't work or something is overwriting it. This is why I would like to find out why it isn't working.

@shirakaba, can you try #3266 and let me know how it works in your repo?

For the benefit of other readers: we tried this in my repo and found that resolveRequest got deleted for some reason, so the final config wasn’t as intended. Needs further investigation.

For the benefit of other readers: we tried this in my repo and found that resolveRequest got deleted for some reason, so the final config wasn’t as intended. Needs further investigation.

And the current theory for this is that the project is missing @react-native/metro-config, which is required from 0.72, and would explain why resolveRequest is not set in the rnx's default config. And it would also make sense since Expo hides away the need.

Looking now, I see that<EMAIL_ADDRESS>is present in the root-level node_modules of my monorepo, just not listed as a direct dependency of my app. I think even if I did add it explicitly, pnpm would still hoist it to the monorepo root. What do you think?

I did a quick test to find out. I performed pnpm add -D<EMAIL_ADDRESS>in my app directory. The dependency did indeed get hoisted, so it didn't show up in my app's node_modules yet, as before, it could be found in my monorepo root's node_modules.
This time, the custom platformResolver() instantiated inside outOfTreePlatformResolver() did get called, and bundling succeeded 🥳
So its mere presence in package.json seems to matter. Certainly, at the very least, yelling would be good. Would adding "@react-native/metro-config": "*" as a dependency or peerDependency be a better catch-all, though?

So its mere presence in package.json seems to matter. Certainly, at the very least, yelling would be good. Would adding "@react-native/metro-config": "*" as a dependency or peerDependency be a better catch-all, though?

It is already added as a peerDependency. I've pushed a change to check for RN version instead and throw an error if @react-native/metro-config cannot be found. Would really appreciate it if you could test the latest iteration as well before we merge.

Just copied the implementation from your commit let users know if @react-native/metro-config is missing.
Initial state
Just a quick regression test. With "@react-native/metro-config" still installed in my app's dependencies, I ran expo start and got the usual warnings:
Starting Metro Bundler
The following packages should be updated for best compatibility with the installed expo version:
<EMAIL_ADDRESS>- expected version: 1.21.0
<EMAIL_ADDRESS>- expected version: ~50.0.20
<EMAIL_ADDRESS>- expected version: 0.73.6
<EMAIL_ADDRESS>- expected version: 14.1.0
<EMAIL_ADDRESS>- expected version: ~18.2.45
Your project may not work correctly until you install the correct versions of the packages.

And, as I reported earlier when running your previous commit in the same conditions, the app ran fine; no red screen.
With removal of @react-native/metro-config
This time, I uninstalled @react-native/metro-config from my app's dependencies and ran expo start --clear to clear the Metro cache.
... however, the result was the same. Same warnings, no red screen, app just ran. It didn't warn me that I should install @react-native/metro-config. Instead, it "just worked". Was that the idea?

Just a heads-up that @byCedric has self-assigned @acoates-ms's issue https://github.com/expo/expo/issues/30820, so we should keep each other updated on whether Expo need do anything more here or should just leave it all to @rnx-kit/metro-config.

... however, the result was the same. Same warnings, no red screen, app just ran. It didn't warn me that I should install @react-native/metro-config. Instead, it "just worked". Was that the idea?

Yes, since @react-native/metro-config is still available from the root, it will use that copy. If you remove it entirely, you should see an error.

Just a heads-up that I noticed @byCedric recently self-assigned @acoates-ms's issue about this (expo/expo#30820), so we should just keep each other updated on whether Expo need do anything more here or should just leave it all to @rnx-kit/metro-config.

I think Expo will want to do address this anyway for users that don't want to or can't use @rnx-kit/metro-config.


Support index configuration like dbt-postgres

DuckDB has indexes like Postgres does, and I suspect that we will discover some use cases and pipelines where the ability to add them in helps significantly with performance.
dbt-postgres includes built-in support for creating indexes on relations, and I suspect that we will want to add the same to dbt-duckdb at some point, so I created a branch that includes the config and tests from the dbt-postgres indexing config ported over to dbt-duckdb.
I'm going to leave it out of the main branch right now though because the current limitations around DuckDB indexes mean that the Postgres-style index configuration doesn't work for a) incremental models or b) seeds. When those issues are fixed in DuckDB (and the corresponding tests pass), we can revisit including this functionality.

For the time being, assuming your use case and materialization strategy supports it, I recommend using hooks to drop/add indexes from any models in DuckDB that need them.

Worth calling out that this is also helpful for attached databases such as sqlite/postgres. Would it make sense to release this feature but gate it to tables/models whose database_type may support these without the same limitations?


"require-dependent-keys" false negative with computed decorator

The following code
import Model from 'ember-data/model';
import { attr, belongsTo } from 'ember-decorators/data';
import { computed } from 'ember-decorators/object';

export default class LayerModel extends Model {
  @belongsTo('layer-group') layerGroup
  @attr() style

  @computed('layerGroup.visible')
  get visible() {
    return true;
  }
}

Throws:

Do not use Computed Properties without dependent keys...

But a dependent key is provided.

package.json:
"ember-source": "~3.0.0",
//...
"eslint-plugin-ember-best-practices": "1.1.1",
"eslint-plugin-ember": "^5.0.0",

Maybe it's just trying to get me to use an alias there instead ;)

Added a failing test but not quite sure how to get the decorator modules imported and parsing correctly with class syntax...


Depend explicitly on the challenge to prevent some errors

like
"registry.terraform.io/cloudflare/cloudflare" produced an invalid new value
for .ownership_challenge: was null, but now cty.StringVal("[redacted]..[redacted]")

As recommended by @jacobbednarz in
https://github.com/cloudflare/terraform-provider-cloudflare/issues/2752#issuecomment-1712190497
Workaround for issues like
https://github.com/cloudflare/terraform-provider-cloudflare/issues/2794 https://github.com/cloudflare/terraform-provider-cloudflare/issues/2752 https://github.com/cloudflare/terraform-provider-cloudflare/issues/3001

👋 the data.aws_s3_bucket_object.challenge_file in the depends_on is redundant as the challenge_ownership value already references the datasource value. if you want to update that, we can get this merged

Thanks, corrected that!

thanks!


query:capture has a bug: returns wrong capture @name

In file ltreesitter/csrc/query.c on line 295 name is incorrectly calculated.
The correct line should read:
const char *name = ts_query_capture_name_for_id(q->query, m.captures[capture_index].index, &len);

Thanks for reporting! I've fixed the line and added a test for this.


Image classification customization - one label

Have I written custom code (as opposed to using a stock example script provided in MediaPipe)
No
OS Platform and Distribution
Debian 11.7
Python Version
3.9.2
MediaPipe Model Maker version
<IP_ADDRESS>
Task name (e.g. Image classification, Gesture recognition etc.)
Image classification
Describe the actual behavior
After training on only one label, the label is detected at 100% every time with no variation
Describe the expected behaviour
After customization with only one label, the scoring should vary less or more
Standalone code/steps you may have used to try to get what you need
I followed this tutorial :

https://developers.google.com/mediapipe/solutions/customization/image_classifier

Dataset :
You can you your flowers dataset, just take one folder "daisy" for example

Other info / Complete Logs
No response

Are you attempting a binary classification (ex. daisy and non daisy) ? If so you need a 0 class, basically you have to have 2 dataset, non_daisy for Class 0 and daisy for Class 1, for class 0 you can have random images that aren't daisies.

@ezawadzki,
What @WhiteHoot said is correct, you will need to at least provide one other class of 'non_daisy' so that the dataset contains examples of daisies and non-daisies.


Extending to More Classes?

Hey!
Thanks for the great work and the code
I saw you currently support only some set of labels, I want to try some experiments with more classes is it possible to modify the code to achieve that? Would just changing the binarizing part suffice or would I need to change the modelling parts too?

Hi! We would recommend you binarize the dataset in a similar fashion as in src/binarize.py and then perform the binary probing. You may also refer to our paper for how we process similar tasks like MNLI.

Thanks!


Allow class methods be async

I'm expecting something like this would allow class prototype methods to be async, but this is reported as a syntax error.
export default class {
  constructor () {
  }
  foo () {
  }
  bar async () {
    return await this.foo();
  }
}

Try "async bar" rather than "bar async".

Ah, indeed. Thanks. For some reason, having the method name first seemed more intuitive. I didn't find class methods documented, at least not explicitly.


Increase coverage for masks

Fix #14669.
The initial coverage for the branch is:

%
Lines covered
File

35.83
67/187
src/lib/merkle_mask/maskable_merkle_tree.ml

51.55
266/516
src/lib/merkle_mask/masking_merkle_tree.ml

Current state is:

%
Lines covered
File

83.81
88/105
src/lib/merkle_mask/maskable_merkle_tree.ml

79.50
380/478
src/lib/merkle_mask/masking_merkle_tree.ml

The increase in coverage is thus partly due to marking large portion of the code with [@coverage off] tags. I tried to do that rationally.
What remains to be done

[x] Cleaning up the branch history
[x] Cleaner more principled extra tests

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me