[BUG][2.10] script user-cluster.sh fails to cleanup Rancher Components from Registered Clusters

Ticket to port all fixes for #43343 to 2.10 branch

PR that adds the fix in 2.10 https://github.com/rancher/rancher/pull/48319

Test Environment

Component
Version / Type

Rancher version
v2.10-33fc602feb5f335943023ce0645e523ed0d2d7e9-head

Installation option
Docker

Docker version
v27.1.2

Helm version
v2.16.8-rancher2

Logged in user role
Admin

Dashboard
release-2.10 3221965

#
Description
PASS/FAIL

1
Run cleanup Rancher Components script
✅ PASS

Run cleanup Rancher Components script

Create and Import the RKE Cluster to Rancher.
Download the script for this version (v2.10)

$ curl -o user-cluster.sh https://raw.githubusercontent.com/rancher/rancher/refs/heads/release/v2.10/cleanup/user-cluster.sh

Run user-cluster.sh

$ chmod +x user-cluster.sh
$ ./user-cluster.sh rancher/rancher:v2.10-head

For previewing the script's outcome without making changes, add the flag: -dry-run

Outcome

Command Output

serviceaccount/cattle-cleanup-sa created
clusterrolebinding.rbac.authorization.k8s.io/cattle-cleanup-binding created
job.batch/cattle-cleanup-job created
clusterrole.rbac.authorization.k8s.io/cattle-cleanup-role created
time="2024-12-09T21:54:27Z" level=warning msg="failed to reconcile kubelet, error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"

Release test

Component
Version / Type

Rancher version
v2.10.1-alpha1

Installation option
Docker

Docker version
v27.1.2

Helm version
v2.16.8-rancher2

Logged in user role
Admin

Dashboard
v2.10.1-alpha1

#
Description
PASS/FAIL

1
Run cleanup Rancher Components script
✅ PASS

Run cleanup Rancher Components script

Create and Import the RKE Cluster to Rancher.
Download the script for this version

$ curl -o user-cluster.sh https://raw.githubusercontent.com/rancher/rancher/refs/heads/release/v2.10/cleanup/user-cluster.sh

Run user-cluster.sh

$ chmod +x user-cluster.sh
$ ./user-cluster.sh rancher/rancher:v2.10-head -dry-run

Outcome

Command Output

serviceaccount/cattle-cleanup-sa created
clusterrolebinding.rbac.authorization.k8s.io/cattle-cleanup-binding created
job.batch/cattle-cleanup-job created
clusterrole.rbac.authorization.k8s.io/cattle-cleanup-role created
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
Error from server (BadRequest): container "cleanup-agent" in pod "cattle-cleanup-job-zrn8p" is waiting to start: ContainerCreating
time="2024-12-13T18:14:12Z" level=warning msg="failed to reconcile kubelet, error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"


dotnet tool install fails to install "latest" dotnet-monitor

Description
dotnet tool install --tool-path /tools dotnet-monitor fails to install in latest dotnet/sdk:8.0 container with:
Tool 'dotnet-monitor' failed to update due to the following:
The settings file in the tool's NuGet package is invalid: Settings file 'DotnetToolSettings.xml' was not found in the package.
Tool 'dotnet-monitor' failed to install. Contact the tool author for assistance.

it looks like only v9.0.0 can't be installed.

Configuration
Running inside latest .net SDK official container: mcr.microsoft.com/dotnet/sdk:8.0@sha256:f91f9181d68b5ed2c8dea199dbbd2f6d172e60bdc43f8a67878b1ad140cf8d6b
Also tried with sdk:8.0-noble - same result as this is not env-specific IMO.

Regression?

Other information
it works fine if I specify version explicitly:
dotnet tool install --tool-path /tools --version 8.0.5 dotnet-monitor

or with the latest version:
dotnet tool install --tool-path /tools --version 8.0.6 dotnet-monitor

.NET Monitor 9 tool package is only installable in an environment that contains a .NET 9 SDK. If you are unable to change the .NET SDK container to .NET 9, then you'll only be able to install .NET Monitor 8. You can get the latest installation of .NET Monitor 8 by running
dotnet tool install -g dotnet-monitor --version 8.*

Yeah, that's what I did already, but it's kinda odd to not being able to install it without explicitly specifying the version.

In general, .NET tools can only be installed via matching SDKs where the runtime version of the tool has to match the SDK version. Since .NET Monitor 9 only has a target framework of net9.0, it will require the .NET 9 SDK to install it. Similarly, .NET Monitor 8 only has a target framework of net8.0, it will require the .NET 8 SDK to install it.
I can go update the docs to reflect this requirement.

We have no plans for allowing .NET Monitor 9 to run on versions lower than .NET 9.
Since there is a solution to the reported problem, and there is no work to be done on the tool itself, I will be closing this issue as not planned.


MultiphaseConvergence test case not working in gfortran debug

This issue has been around for quite along time. Could you guys take a look?

it works now, but the result is not the same as with ifort (probably due to linking with mkl-lapack)


Investigate stack overflow error

I've looked into it but didn't find the exact reason for the error. User has no data and app crashed before it creates the log file.
User has added event viewer data and error dumps
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540620(v=vs.85).aspx
http://stackoverflow.com/a/7223814
case 211267

Deleting toggldesktop.db, .db-shm and .db-wal files resolved this issue for me on Windows 8.
The program failed to start before, debugging showed a stack overflow error.

Closing as issue is out of date and has not been reported recently.


🔐 Security Section

Not sure the way of working previously, but I like my teams to raise PRs at the beginning to allow for early feedback.
This WIP PR will be used for my draft of the security section, as taken on at the meeting on 2023/06/21.

There is work going on in the Security Collaboration Space at the OpenJS Foundation to help give guidance to JavaScript developers around security as well. Part of our plan is go take guidance and direction from the OpenSSF and tailor it to JS projects. That being said, we may want to highlight some of the resources at OpenSSF for the time being might be good.
A couple examples:

https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software

https://training.linuxfoundation.org/training/developing-secure-software-lfd121/

@joesepi are you suggesting that we include some OpenSSF links as a separate section for external resources or, do you think it should be included in one of the existing titles?


Documentation is obsolete

Which parts of the documentation are you referring to specifically?

As far as I remember, not all of this framework's features are outlined in the documentation.


Integrate plant_id_ferc1 assignment into FERC Form 1 transform process

Now that we have a working plant_id_ferc1 generator, we need to to integrate those IDs into the DB ingest process so that they can be used to connect FERC to EIA and do time series cost regressions (#204), etc.
This is a sub-issue of #144

Whoops, meant to close #218 not #219.


Add endpoint for all polling places for election (alternatively, include stall name in map API endpoint)

I was able to link our dataset to Democracy Sausage's quite easily, without spamming the Democracy Sausage API, by pulling the /map endpoint and matching on coordinates.
However, this hasn't been perfect - there's a couple of hundred polling places that weren't linked, and upon inspection have differing coordinates between our systems.
If there was a /polling_places/all endpoint, this would work nicely and allow the most thorough matching.
Alternatively, if the /map endpoint included polling place name, this could be used as another way to match polling places.

Hey Effy, thanks for the interest - let's have a think about the best way to do this.
Does your integration need to display sausage status in a list form (e.g. all polling places, or all polling places for a particular division) or is it only on a per-polling place basis?
We've already got a /polling_places/all sort of endpoint for internal use, so exposing that is easy. It's a little db intensive - particularly for a Federal election - so we've kept it private for now. If I was to expose it I'd probably add in API keys so we can throttle/blacklist anyone who abuses it.
I'm trying to keep the /map endpoint's size to an absolute minimum to keep map load times for users super speedy.
By the way - we have API documentation over here.
The mismatches between your polling places and ours may just be a case of when we both pulled the data from the NSW Electoral Commission. We loaded ours on March 1st.

It's per polling place. We already show all the polling places on a map, it's just a case of adding the additional data.
What I currently did was hit the map endpoint, download the entire json, perform matching, and add a democracy_sausage_id to all matched polling places.
When a client hits our API to get the polling places for an electorate, our API gets all the democracy_sausage_ids and hits your search endpoint, adding the resulting data back to the polling places before sending them to our client.
Mismatches might be that, but I think it's more likely just geocoding inconsistencies.
I found the Swagger, very helpful.
My integration wouldn't need to hit /all regularly - even just a once off dump now would be perfect.

Neat approach - one caveat to be aware of with doing that is that our polling place ids aren't immutable. They'll all change each time we do an ingest and update with new data from the electoral commission. That doesn't happen often, only a couple of times for each election, but when it does it'll mean all of your /polling_places/search/ queries will start returning 0 results for any query you send it using the old ids.
That's a little suboptimal for you :)
What if we allowed searching by polling place names on /polling_place/search/? Does that remove the need for you to match and store democracy_sausage_id?

I believe you already can search by individual names. But I'd need to be able to give a list of names (same way you can give a list of IDs), or hit the API once per place instead of just once. But yes, that would work well I think.

Sort of - the search_term param returns any polling places with a name, premises, or address that contains the search term (case insensitive).
That returns a single polling place in most cases, but common words - or parts of words - get a bit messy. e.g. ACON https://democracysausage.org/api/0.1/polling_places/search/?election_id=26&format=json&search_term=ACON
OK, so we'll add a polling_place_names parameter to /polling_places/search/ that accepts a comma separated list of polling place names. I should have time to tackle that Tuesday/Wednesday this week - will keep you in the loop.

Alternatively, if you'd like to get your hands dirty a PR would be most welcome :)

FYI I've also included the polling place name in the GeoJSON /map/ API endpoint now. In doing that the structure of the properties for each polling place has changed a little.
From this:
{
      "id": 37575,
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          151.155831,
          -33.901247
        ]
      },
      "properties": {
        "bbq": true,
        "cake": true,
        "nothing": false,
        "run_out": false,
        "other": true
      }
    }

to this:
{
      "id": 37575,
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          151.155831,
          -33.901247
        ]
      },
      "properties": {
        "noms": {
          "bbq": true,
          "cake": true,
          "nothing": false,
          "run_out": false,
          "other": true
        },
        "name": "Wilkins Public School"
      }
    }

@keithamoss Beautiful, thank you. I just tested matching by coords or name, and I'm down to literally 4 places across the entire state.

@keithamoss The following request (via either Swagger or a HTTP request in my Lambda) is giving a 502:
curl -X GET "https://democracysausage.org/api/0.1/polling_places/search/?polling_place_names=Balmain%20Election%20Manager's%20Office%2CAnnandale%20North%20Public%20School%2CJimmy%20Little%20Community%20Centre%2CLeichhardt%20Town%20Hall%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2CLeichhardt%20Town%20Hall%2CSydney%20Secondary%20College%20-%20Balmain%20Campus%2CSydney%20Secondary%20College%20-%20Leichhardt%20Campus%2CJimmy%20Little%20Community%20Centre%2CSt%20Fiacres%20Church%20Hall%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2CInner%20Sydney%20Montessori%20School%2CBalmain%20Election%20Manager's%20Office%2CSydney%20Town%20Hall%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2CSydney%20Secondary%20College%20-%20Leichhardt%20Campus%2CAnnandale%20North%20Public%20School%2CSt%20Scholasticas%20College%2CLeichhardt%20Town%20Hall%2CSt%20Barnabas%20Church%20Broadway%2CSydney%20Town%20Hall%2CBirchgrove%20Public%20School%2CBalmain%20Election%20Manager's%20Office%2CSt%20Fiacres%20Church%20Hall%2CBalmain%20Hospital%2CGlebe%20Town%20Hall%2CLeichhardt%20Town%20Hall%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Hospital%2CLeichhardt%20Town%20Hall%2CInner%20Sydney%20Montessori%20School%2CBalmain%20Election%20Manager's%20Office%2CSydney%20Town%20Hall%2CLeichhardt%20Town%20Hall%2CForest%20Lodge%20Public%20School%2CSt%20Barnabas%20Church%20Broadway%2CAnnandale%20Public%20School%2CGlebe%20Town%20Hall%2CSt%20Barnabas%20Church%20Broadway%2CBalmain%20Election%20Manager's%20Office%2CLeichhardt%20Town%20Hall%2CSt%20Barnabas%20Church%20Broadway%2CLeichhardt%20Town%20Hall%2CSydney%20Town%20Hall%2CRozelle%20Public%20School%2CKegworth%20Public%20School%2CSt%20Barnabas%20Church%20Broadway%2CKegworth%20Public%20School%2CPeter%20Forsyth%20Auditorium%2CSt%20Barnabas%20Church%20Broadway%2CSydney%20Town%20Hall%2CSydney%20Town%20Hall%2CSydney%20Town%20Hall%2CSydney%20Town%20Hall%2CNicholson%20Street%20Public%20School%2CSt%20Scholasticas%20College%2CSt%20Barnabas%20Church%20Broadway%2CSt%20Barnabas%20Church%20Broadway%2CLeichhardt%20Town%20Hall%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2COrange%20Grove%20Public%20School%2CBalmain%20Public%20School%2CSydney%20Secondary%20College%20Blackwattle%20Bay%20Campus%2CBalmain%20Election%20Manager's%20Office%2CRozelle%20Public%20School%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2CBalmain%20Election%20Manager's%20Office%2CSt%20Barnabas%20Church%20Broadway%2CBalmain%20Election%20Manager's%20Office%2CLeichhardt%20Town%20Hall%2CForest%20Lodge%20Public%20School%2CSt%20Barnabas%20Church%20Broadway%2CBalmain%20Election%20Manager's%20Office%2CUltimo%20Public%20School%2CSydney%20Secondary%20College%20Blackwattle%20Bay%20Campus%2CLeichhardt%20Town%20Hall%2CSydney%20Secondary%20College%20-%20Balmain%20Campus%2COrange%20Grove%20Public%20School%2CSydney%20Town%20Hall%2CBalmain%20Public%20School%2CLeichhardt%20Town%20Hall%2CSt%20Barnabas%20Church%20Broadway%2CBalmain%20Election%20Manager's%20Office%2CSt%20Barnabas%20Church%20Broadway%2CPeter%20Forsyth%20Auditorium%2CLeichhardt%20Town%20Hall%2CSydney%20Town%20Hall%2CBirchgrove%20Public%20School%2CNicholson%20Street%20Public%20School&election_id=26" -H "accept: application/json" -H "X-CSRFToken: nq8El2hvb4UxJeC1W8Bcxfa1s0E54eZHDAD9TZ2aN29jn2B7k4cCuA3Mk9ocxrkq"

OK, that's fixed now.
By default UWSGI only accepts requests with headers up to 4096 bytes in length. I've doubled that now, so you should be good.

@keithamoss I can confirm that's working! Thank you for your help.


[FEATURE] Create eve/std.h to emulate std::experimental::simd

See https://en.cppreference.com/w/cpp/experimental/simd

As per discussion, this amounts to providing properly named using clauses to provide a eve::experimental::simd version of std::simd and std::simd_mask .

@hkaiser Looks like the type generated by std::experimental::simd/native_simd<T> are rather inconsistent or even silly.

On ARM and PPC, simd<T>is just T and simd_mask<T> is bool.
On AVX, native_simd<T> is what is expected but for simd<T>, it's m256 for float/double but reverts back to m128i for integral types.

Should we consider that compiler bugs and just don't test those or should we emulate this inconsistent behavior?

@hkaiser Looks like the type generated by std::experimental::simd/native_simd<T> are rather inconsistent or even silly.

On ARM and PPC, simd<T>is just T and simd_mask<T> is bool.
On AVX, native_simd<T> is what is expected but for simd<T>, it's m256 for float/double but reverts back to m128i for integral types.

Should we consider that compiler bugs and just don't test those or should we emulate this inconsistent behavior?

I think they simply have not implemented things on ARM and PPC platforms yet. Therefor the fallback to intrinsic types...

OK so I'll de-activate the test for ARM/PPC and fix AVX with a std::conditional or something

OK so I'll de-activate the test for ARM/PPC and fix AVX with a std::conditional or something

I don't think you should try to reproduce problems their implementation exposes. Let's go with what the specification says.

OK so I'll de-activate the test for ARM/PPC and fix AVX with a std::conditional or something

I don't think you should try to reproduce problems their implementation exposes. Let's go with what the specification says.

Changed the test to be that:
https://github.com/jfalcou/eve/blob/6add70d52f66a8a0189afe24ae8753d582b803bd/test/unit/meta/std_compatibility.cpp
Basically, I ignore whatever the current bad QoI of the compiler does and check meaningful sizes.

Changed the test to be that:
https://github.com/jfalcou/eve/blob/6add70d52f66a8a0189afe24ae8753d582b803bd/test/unit/meta/std_compatibility.cpp
Basically, I ignore whatever the current bad QoI of the compiler does and check meaningful sizes.

Fixed in b94f8a00fa1f2751930708894c743ba8ea0d62b8


azd package requires an environment name

[x] Make sure you've installed the latest version using instructions in the wiki

Output from azd version
Run azd version and copy and paste the output here:
azd version 1.5.1 (commit 3856d1e98281683b8d112e222c0a7c7b3e148e96)
Describe the bug
I want to use azd package as a "smoke test" in CI to ensure that the packages can be successfully built on each commit/push to a branch.
I've created a workflow like so:
name: azd package

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main", "feature/*"]

jobs:
  package:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Install azd
        uses<EMAIL_ADDRESS>
      - name: Package with azd
        run: azd package

But it errors when running because there's not environment name set, as showing by the repeated log message:
Enter a new environment name: environment name '' is invalid (it should contain only alphanumeric characters and hyphens)
Also, it keeps attempting to get the environment name, so I either have to kill the job or wait for it to time out. Here's an example run.
To Reproduce

Create a GitHub Actions workflow as above
Push and run
See the logs for GitHub Actions.

Expected behavior
Since I'm not deploying, I shouldn't need an environment name to run azd package.
Environment
GitHub Actions

Seems a duplicate of issue #2857
Can you try the following workaround? https://github.com/Azure/azure-dev/issues/2857#issuecomment-1780064962
cc @wbreza

Ah damn, I tried to search but seems like I was unsuccessful in my efforts 🤣
That workaround is what I've done in our situation too.

Marking as duplicate of #2857


Add some training material and use postreise as the client

Purpose
Incremental progress, mainly for the training.
What it does

use postreise as the client container since it also contains powersimdata
update readme organization and commands
add training.ipynb notebook containing some of the content from the slides
add training.yml compose file, which rather than using a named docker volume, does a bind mount to a local directory, (set by the DATA_PKG environment variable) which will be the equivalent of rootdir but containing a selected set of scenario data and corresponding ScenarioList.csv. This allows having multiple independent folders containing arbitrary scenarios, as long as the structure matches

Next step will be adding a script or something to download data into the mounted folder. Currently I have just copied the data locally to test the notebook.

I believe the images are built every time develop is updated. Are going to use the last version of develop in the training or v0.4.1? What do you think @danielolsen. Then should we use scenario.state.get_grid or scenario.get_grid()?

If it's critical, we could add docker images tagged with our releases (e.g. v0.4.1), but was planning on using latest since it's just for demo purposes.

develop and v0.4.0 are currently bugged. The v0.4.1 branch is fully-working. We could see if we can patch in PowerSimData#420 into v0.4.1 if we want, then we'll have the better user interface, or we can make sure that we get develop fully working and use that.

develop and v0.4.0 are currently bugged. The v0.4.1 branch is fully-working. We could see if we can patch in PowerSimData#420 into v0.4.1 if we want, then we'll have the better user interface, or we can make sure that we get develop fully working and use that.

I believe the bug(s) in develop won't be an issue for the training, right? Assuming it's just the concurrency related issues.

develop and v0.4.0 are currently bugged. The v0.4.1 branch is fully-working. We could see if we can patch in PowerSimData#420 into v0.4.1 if we want, then we'll have the better user interface, or we can make sure that we get develop fully working and use that.

I believe the bug(s) in develop won't be an issue for the training, right? Assuming it's just the concurrency related issues.

At least on Windows, scenario creation seems to be bugged due to the permissions issue. Maybe it doesn't matter for plug for the training.


Refactor/ rename Huobi to HTX

Before submitting this PR, please make sure:

[ ] Your code builds clean without any errors or warnings
[ ] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
Tests performed by the developer:
Tips for QA testing:

@nikspz try to run a strategy in HTX too

Test performed:

Cloned and installed PR6796
Connected HTX successfully
checked balance successfully
Created/started pureMM using htx with no issues
Checked status and order_book succesfully update in --live
Review filled orders events handled succesfully,  in Client/exchange matched


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


istioctl proxy-config listeners: show filter chains

Currently a lot of logic missed in the listener summary. This will get much worse once https://github.com/istio/istio/issues/22217 is done. Once that is final, the current command would return:
ADDRESS           PORT      TYPE
<IP_ADDRESS>           15001     HTTP+TCP
<IP_ADDRESS>           15006     HTTP+TCP

which is not useful at all and it is entirely static.
I propose we make listeners more filter-chain centric. I tried this out a bit in howardjohn:istioctl/listener-filterchains.
I found your code at https://github.com/howardjohn/istio/blob/istioctl/listener-filterchains/istioctl/pkg/writer/envoy/configdump/listener.go
I recall writing some code to print Istio Match rules scraped from Envoy nicely.  This was an experiment in Javascript and didn't make it into Istio.  Do you want me to try to make a PR with your stuff and add that stuff?  Or is there a different way we can collaborate?

If you are interested that would be great. I think there is some improvement we can make to the "match" part for sure. If I have some time ill probably play with it some more but always happier to review a PR than create it :slightly_smiling_face:


Change to a valid mediaType

Context
Fixes #1503
Changes & Results
Testing

Checklist
PR

[] My Pull Request title is descriptive, accurate and follows the
semantic-release format and guidelines.

Code

[] My code has been well-documented (function documentation, inline comments,
etc.)

[] I have run the yarn build:update-api to update the API documentation, and have
committed the changes to this PR. (Read more here https://www.cornerstonejs.org/docs/contribute/update-api)

Public Documentation Updates

[] The documentation page has been updated as necessary for any public API
additions or removals.

Tested Environment

[] "OS:
[] "Node version:
[] "Browser:

can you make this configurable from init wado?


Expose Live-Mode functionality

Use Case
Please provide a use case to help us understand your request in context
Acceptance Criteria
Please describe how you know this is done
Details
Update to expose the functions needed for Live mode playback. This will also involve adding some missing functions (or parameters to differentiate live/playback mode).
Questions

Should this be a separate mode of operation?
Should switching be allowed between both modes?

live mode needs more specification in another issue


Add attribution to mfT docs links

Closes #2703

utm_source = {one per msg}

multipodwarn - warning that multipod mode is on but no operator
copytarget - generated config from doc comments, no platform
teamscmd - cli only, mirrord Teams command
errreqop - cli only, error message for if config has copy target enabled but no operator
erropfailed - cli only, error message for when something failed while using the operator (general OperatorApiError::KubeError or OperatorApiError::StatusFailure)

utm_medium = {cli, (plugin), vscode, intellij}

parsed from plugin → specific in the plugin code
vscode: can use replace() on link string


abap-dev-create-package formatting, screenshots...

Edited validation

Hi Daniel, I have now made the changes you suggested and would like to merge the Pull Request. Once this is done, I can update the Group in tutorial-grouping.md as discussed. Thanks a lot.

Hi Daniel, I have tried to make the changes as discussed. I have shortened the intro text of abap-dev-create-table. I will try to do the same with abap-dev-create-package at a later date.
Thanks


README: update the example to work out-of-box on macOS

Minor changes to the example in the readme to work out-of-the box in macOS.
Two parts:

without the loop (taken from #262), the window will be stuck in background and reported as "program not responding" by macOS.

without the surface.FillRect(nil, 0), the window is not properly cleared.

Thanks @martinlindhe!


fix(api): warn instead of crash in unconfigured environments

Hi! There is some incorrect if statement logic in the new api_key_cmd setup that results in this nasty-looking error on startup in environments without an API key (this can happen in a variety of situations like editing your kitty settings in this example screenshot)

This pr fixes the if statement logic, and switches to a more pleasant warning if this kind of thing ever happens:

Great job, thanks!


[Bug Report] Using v-text inside the Button component causes the effect of loading to fail

Element UI version
2.4.3
OS/Browsers version
win10
Vue version
2.5.9
Reproduction Link
https://jsfiddle.net/dun5pt26/
Steps to reproduce

What is Expected?
I want to be able to insert the text of the button in v-text to make sure that the loading is valid
What is actually happening?
The effect of loading fails when v-text is used inside the Button

v-text should only be used on native HTML elements.
https://vuejs.org/v2/api/#v-text


Dashboard 2.0: Implement collection management

New dashboard currently supports product and category management but there is no collection management.

Blocked by #3144

Closed via #3135


Bug: Drives not loading in side menu

Description
At present, none of the drive letters appear on the left-side menu. They also do not appear in the Home page.
Drives do however, appear perfectly fine on the "This PC" tab.

Steps To Reproduce

Install latest version
Launch Files app
Compare results between clicking the Drives tab on left menu & the drive list on the This PC panel.

Requirements

e.g. Fix crash that occurs when...
Drives should populate as they do on the "This PC" tab.

Files Version
<IP_ADDRESS>
Windows Version
10.0.22631.2861
Log File
debug.log

at Vanara.Windows.Shell.ShellLink.get_Target()
at Files.App.Utils.RecentItem.RecentItems.<>c__DisplayClass14_1.b__2()
2024-01-11 21:15:13.6780|Warning|System.ComponentModel.Win32Exception (15): The system cannot find the drive specified.
at Vanara.PInvoke.Shell32.ShellUtil.GetShellItemForPath(String path)
at Vanara.Windows.Shell.ShellLink.get_Target()

Do you know if this was also an issue in previous versions?

@yaira2 It seems to be the same issue as #14345, which I have encountered several times as well.

The log file looks a little different but it's possible. Do you know when this issue started? I'm wondering if there is a bug in Windows.

Do you know if this was also an issue in previous versions?

Sadly, I was using an older version last night (probably six months behind), and after going through a few directories, I opted to update and noticed the lack of drives.
I'm going to do a wipe of the software today and go install an older version.
I also have a 2nd machine I'm going to try installing on.
Should be about an hour or two, and I'll report back.

Just an interesting note.
I opted to try loading the latest stable build into a VMWare Virtual Machine with Windows 11. The drives loaded right up, without hesitation.

App
Version

Files
<IP_ADDRESS>

Windows
10.0.22621.3007

A new interesting note.
A few minutes ago, I was working on my virtual machine. I was transferring a file from an old backup to load into my VM.
I noticed when it was transferring that I got an error that the virtual machine was currently in-use of a process called "COM Surrogate".
I went looking to see what COM Surrogate was, and that it "shouldn't" be force-closed, but it could be if it gives issues.
I had 4 instances of COM Surrogate running so I opted to shut them down. I figured if Windows needs them, they'll be re-launched.
The very second that I killed that task, I noticed on my other machine that my drives magically started loading.
I'm not too familiar with how the processes interact with Windows, but Files is now successfully showing every single drive.  I even closed the Files app and re-loaded it, and all the drives immediately load.

I had 4 instances of COM Surrogate running so I opted to shut them down. I figured if Windows needs them, they'll be re-launched.

Interesting, I suppose a safer method is to restart Windows.
I think we can chalk this up as a Windows issue but let us know if it happens again.


Rewrite the internal unsigned_abs

This was motivated by the new nightly unsigned_abs() inherent method on primitives, which is currently raising a future-compatibility warning that it will take precedence in the future. That would actually be fine, since they do the same thing, but the warning is annoying in the meantime.
So ours is now uabs(), and I also added a new checked_uabs() that cleans up the branching a bit.

bors r+


add healthz to eventer

Fix #1293 .
This PR adds /healthz and /metrics http service to eventer.

healthz endpoint currently only checks latest scrape time, if LatestScrapeTime is 3 minutes later than now, healthz endpoint will return with http response code being 500.
metrics endpoint is used for Prometheus.

Note: This PR needs to be merged after #1539 because newly added file's boilerplate is 2017. :). Currently this PR will not pass successfully, i will rebase this PR once #1539 is merged.
/cc @AlmogBaku @DirectXMan12 @piosz @kubernetes/heapster-reviewers

This change is

/lgtm

Code rebased. Friendly ping @AlmogBaku @DirectXMan12 @piosz

@k8s-bot test this

I think this LGTM :+1:, but if we're going to land the Godeps update, I'd like to get that landed first.

@DirectXMan12

but if we're going to land the Godeps update, I'd like to get that landed first.

There is no Godeps update. Any clue?

There is no Godeps update. Any clue?

#1537 contains a major Godeps update that pulls in the latest dependencies, and therefore changes a lot of import paths.

@DirectXMan12 #1537 has been merged. And, seems nothing needs to rebase. :)

err... considering eventer no longer builds when rebased onto master, I'd say a rebase is in order (not sure why the unit tests aren't showing it, but just tested locally).  Nothing from k8s.io/kubernetes (with the exception of one package of types from kubelet)) is imported, so you'll need to change that.

@DirectXMan12 This PR will only import k8s.io/kubernetes/pkg/healthz. If we need to change this to k8s.io/metrics package, we may need first add the healthz package to k8s.io/metrics first.
BTW, what is the purpose of creating k8s.io/metrics.

Finally, i find that healthz package has been change to k8s.io/apiserver/pkg/server/healthz. So, in order to keep consistency, i have renamed the healthz package to k8s.io/apiserver/pkg/server/healthz too. @DirectXMan12 PTAL.

Please rebase on top of the latest master.

@DirectXMan12 Done. PTAL.

@k8s-bot test this

Friendly ping. :) @DirectXMan12 @piosz

@DirectXMan12 PTAL~.


when is Finetuning on SQuAD part available?Roberta

your model  Roberta is  very helpful to me，but the Finetuning on SQuAD part is still on coming!

Waiting for it.. :)

Closing in favor of #933


My story into blogs

Trello card
https://trello.com/c/MYSl7HO4/3267-remove-my-story-and-integrate-into-the-blogs
Context
Move some of the 'my story' pages into the blog. The remaining ones will be dropped in #2591

@gemmadallmandfe have left some suggestions. Should we also be adding in some keyword tags to the front matter? (See ticket in backlog)


proposal: use PCG Source in math/rand for Go 2

The original math/rand package had a number of flaws. Some of the flaws in the API have been addressed, such as the addition of the Source64 interface, but the most important issue remains: the default Source is poor.
The Source has several problems.

It has no clear provenance (it came from Plan 9, but its history before that is unknown).
It is a linear feedback shift register, which is known to have flaws uncovered by various empirical tests.
It is difficult and expensive to seed.
It is enormous! The shift register itself comprises 607 64-bit words, a total of 4856 bytes.

This last point is not fatal if there is only one instance, but it couples poorly with another fundamental and perhaps unfixable problem: bad behavior when accessed concurrently. It must be protected with a mutex, but if it were much smaller (and cheaper to seed) it would be practical instead to have each client in the address space access a separate instance, seeded uniquely.
To put it another way, with a separate Source for each goroutine, no locking would be required, but the current implementation is impractically large for such an approach.
The proposal here is in several parts.
First, we create an alternate Source implementation. Our choice is the Permuted Congruential Generator (PCG) designed and thoroughly tested by O'Neill in:
PCG: A Family of Simple Fast Space-Efficient Statistically Good
Algorithms for Random Number Generation
Melissa E. O’Neill, Harvey Mudd College
http://www.pcg-random.org/pdf/toms-oneill-pcg-family-v1.02.pdf
A 128-bit PCG generator producing a 64-bit output is only two words of memory but provably has a period of 2**128, is cheap to seed, and efficient. (A 64-bit generator would be noticeably cheaper, but a period of only 2**64 is deemed too small for modern hardware). It is practical and reasonable for every goroutine to have a local Source (a simple seeding algorithm is to use the address of the Source as the seed).
An implementation of this generator, specifically PCG XSL RR 128/64 (LCG), is checked in to golang.org/x/exp/rand as its default Source.
Second, we work on the compiler, possibly through math/bits, to make it a little more efficient. The current implementation, in pure Go, is somewhat slower than math/rand, but could be comparably fast or even faster given compiler support for the 128-bit multiply inside.
The third part is the critical piece.
We propose to make this generator the default one in math/rand for Go 2. The Go 1 compatibility decree could allow it to happen today, but we have chosen in the past to take the guarantee more literally than is expressed by also requiring that the generated stream of bits will never change. This decision was made when a fix was done, but enough tests in production were discovered that depended on the exact stream that it was deemed simpler to lock down the implementation rather than to fix all the tests.
However, with Go 2 on the horizon, there is enough time and understanding and process to offer an opportunity to use rolling out an improved, API-compatible version of math/rand as an early test case for Go 2. Changing math/rand to use PCG is strictly incompatible, but not in a way that the Go 1 decree actually prohibits. A soft breakage at this level would be an excellent step on the way to understanding what it takes to roll out a breaking change for Go 2.
In essence, the proposal is to use the fixing of math/rand as a test case for introducing breaking changes in Go 2. And a much better random number generator would result, too: the breaking change is worth making.
The precise sequence of steps to roll it out needs discussion, but one possible outline is like this:

Add PCG as a secondary source to math/rand, but not as the default.
Make it available under an alternate name; PCGSource is the obvious.
Provide an alias for the current source, say LFSRSource.
Optional: Provide a gofix that updates existing code to use LFSRSource rather than Source. Since Source is usually hidden, accessed through Rand, this may be ineffectual unless we also provide PCG functions explicitly for Int32, etc. Or perhaps provide LFSR versions and rotate towards those in legacy code.
Make announcements of what's to come.
At some point, flip the alias so Source points to PCGSource and LFSRSource is no longer the default.
In parallel with this work, make math/bits support its operations more efficiently through the compiler.
Just prior to Go 2, delete LFSRSource.

At some point along the way, Source64 should become the default, under a similar sequence of events. Minor cleanups could occur too, tidying up the API and fixing some old-style names like Intn not IntN.
There is much detail that remains to be worked out; this proposal is only an outline.

@robpike github ate your exponential notation. 2^n is safe from markdown's helpfulness.

I've taken the liberty of fixing it with backquotes.

@MichaelTJones perhaps you might be interested in this issue, as already implemented a PCG generator at https://github.com/MichaelTJones/pcg.

@MichaelTJones perhaps you might be interested in this issue, as you already have an implementation of Melissa O'Neill's PCG generator at https://github.com/MichaelTJones/pcg.

I would very much support this change. In fact my careful PCG implementation is because of the weaknesses mentioned here. I long ago switched to this code and will not use the present library PRNG. In addition to being technically excellent, a new generator can be created in 2.72ns, makes new 64-bit values in 5.56ns, and has small state. Examine the tests in my implementation for details.

why not bring it to Go 1

@dongweigogo please read the proposal text carefully, it is explained.

To put it another way, with a separate Source for each goroutine, no locking would be required, but the current implementation is impractically large for such an approach.

For some random generators, generating a bunch of new streams is worse statistically for once stream. Section 4.3.2 of the paper suggests that this is not a problem with PCG if the seeding is done properly. Just wanted to comment for anyone curious.

yes that's how i do it.
BenchmarkNew32-8<PHONE_NUMBER>          0.67 ns/op
BenchmarkRandom32-8<PHONE_NUMBER>          3.23 ns/op
BenchmarkBounded32-8    100000000         15.0 ns/op
BenchmarkNew64-8        300000000          6.64 ns/op
BenchmarkRandom64-8    100000000         15.8 ns/op
BenchmarkBounded64-8    50000000         45.3 ns/op
A new one is 0.67ns for 32 bits or 0.67ns for 64. Easy to have one or more
per concurrent function.
On Tue, Oct 24, 2017 at 2:28 PM, Brendan Tracey<EMAIL_ADDRESS>wrote:

To put it another way, with a separate Source for each goroutine, no
locking would be required, but the current implementation is impractically
large for such an approach.
For some random generators, generating a bunch of new streams is worse
statistically for once stream. Section 4.3.2 of the paper suggests that
this is not a problem with PCG if the seeding is done properly. Just wanted
to comment for anyone curious.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21835#issuecomment-339137103, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHgypZGI0OER3trgpt7Eq23dW_V8-q-Yks5svlZwgaJpZM4PS_P2
.

--
Michael T. Jones
<EMAIL_ADDRESS>

If get per-P storage in Go 2, or if we are willing to let math/rand have privileged runtime access, I think we should consider adding a global Source that:

stores state in a P
is lock-free
is explicitly documented not to have Any reproducibility
is seeded at startup or on first use
panics if Seed is called

This would allow people not to have to manually thread PRNG state around through goroutines, which seems to be a significant complaint.
Maybe it should even be the default Source, and have people opt in to reproducibility by making their own Source.

cc @cespare for that last comment

(@imneme)  O'Neill (PCG's inventor) has a relevant blog post...
Efficiently Generating a Number in a Range
http://www.pcg-random.org/posts/bounded-rands.html

Second, we work on the compiler, possibly through math/bits, to make it a little more efficient. The current implementation, in pure Go, is somewhat slower than math/rand, but could be comparably fast or even faster given compiler support for the 128-bit multiply inside.

Go 1.12 includes 64 bit arithmetic in math/bits. I happened to want the speed-up today, so I implemented it. Go 1.12 isn't out yet, so it doesn't make sense to mail a CL, but in case anyone wants it in the interim, here are drop-in replacements/additions:

const (
	mulHigh    = multiplier >> 64
	mulLow     = multiplier & maxUint64
)

func (pcg *PCGSource) add() {
	var carry uint64
	pcg.low, carry = bits.Add64(pcg.low, incLow, 0)
	pcg.high, _ = bits.Add64(pcg.high, incHigh, carry)
}

func (pcg *PCGSource) multiply() {
	hi, lo := bits.Mul64(pcg.low, mulLow)
	hi += pcg.high * mulLow
	hi += pcg.low * mulHigh
	pcg.low = lo
	pcg.high = hi
}

If no one beats me to it, I'll eventually mail a CL to upstream these.

https://go-review.googlesource.com/c/exp/+/163258

Nice speedup
benchmark                        old ns/op     new ns/op     delta
BenchmarkPCGMultiply-4           3.48          2.31          -33.62%
BenchmarkSource-4                7.46          3.54          -52.55%
BenchmarkInt63Threadsafe-4       21.6          19.4          -10.19%
BenchmarkInt63Unthreadsafe-4     7.69          3.60          -53.19%
BenchmarkIntn1000-4              17.3          13.2          -23.70%
BenchmarkInt63n1000-4            17.7          13.2          -25.42%
BenchmarkInt31n1000-4            17.4          13.2          -24.14%
BenchmarkFloat32-4               13.5          8.57          -36.52%
BenchmarkFloat64-4               11.1          6.43          -42.07%
BenchmarkPerm3-4                 64.6          49.2          -23.84%
BenchmarkPerm30-4                614           430           -29.97%
BenchmarkPerm30ViaShuffle-4      556           450           -19.06%
BenchmarkShuffleOverhead-4       969           788           -18.68%
BenchmarkRead3-4                 11.7          10.1          -13.68%
BenchmarkRead64-4                127           83.0          -34.65%
BenchmarkRead1000-4              1820          1191          -34.56%

I understand this is PCG XSL RR 128/64 LCG. While it has decent performance on amd64, it drops dramatically compared to the current math/rand on 32bits platforms:
goos: linux
goarch: amd64
pkg: golang.org/x/exp/rand
BenchmarkSource-6       200000000                6.21 ns/op
BenchmarkSource_stdlib-6    200000000                7.07 ns/op

goos: linux
goarch: 386
pkg: golang.org/x/exp/rand
BenchmarkSource-6       30000000                45.8 ns/op
BenchmarkSource_stdlib-6    200000000                8.01 ns/op

BenchmarkSource_stdlib is the same as BenchmarkSource but using current math/rand. It might be worth including it in the benchmark suite.
Another thing to consider is licensing: PCG is under Apache 2.0 or MIT.
While I do not want to get into a debate about PRNGs or whether 32bits platforms are obsolete, there may be alternatives to consider like xoshiro256** and xoroshiro128** which are in the public domain and do not exhibit such dramatic performance drops on 32bits.

@db47h @imneme

there may be alternatives to consider (...) which are in the public domain

There may be good arguments for choosing something else than PCG... but this licensing issue is incorrect in my opinion. One PCG C++ library has been made available under "Apache 2.0 or MIT". If you want to use this particular library, then you should check the license, of course. However, if you implement a PCG algorithm in Go, you get to choose which license you want to apply. The reverse apply, I can pick any generator and apply a super evil license.
Furthermore, I'd like to point out that Go itself is not in the public domain.
A more relevant question is whether there is a patent for the PCG schemes. I just checked (it is easy to do) and there is not.

Furthermore, I'd like to point out that Go itself is not in the public domain.

Yes, but so far the Go standard library is under a single license. My "licensing concern" was to keep it that way.

A more relevant question is whether there is a patent for the PCG schemes. I just checked (it is easy to do) and there is not.

My bad, I assumed the license applied to the algorithms as well.

I have stumbled in the code for PCGSource (we decided to teach Go as first language to undergrads at my university), and in case you are considering it for inclusion in the standard library, I think it would IMHO a good idea to add to the code some documentation about the perils of seeding the generator with states that share a large number of lower bits. For example:
package main
import . "fmt"
import . "github.com/golang/exp/rand"

func main() {
   var pcg0, pcg1 PCGSource

   pcg0.UnmarshalBinary([]byte { 128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 });
   pcg1.UnmarshalBinary([]byte { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 });

   for i := 0; i <<PHONE_NUMBER>; i++ {
      pcg0.Uint64()
      pcg1.Uint64()
   }

   for i := 0; i < 10; i++ { Printf("0x%x\t0x%x\n", pcg0.Uint64(), pcg1.Uint64()) }
}

This program creates two PCGSource instances whose initial states differ only in the upper bit by unmarshaling; then, it advances the generators a billion times, and then prints ten outputs:
0xd8e3ee0662fca74c	0x62fca74cd8e2ee06
0x2e769d76dc6e4f1c	0xdc4e4f1c2e769d76
0x73a027a3ae1b700f	0xae1b700f53a027a3
0x746dd81a74fe2b99	0x74de2b99746dd81a
0xc0fb5795c97c77e7	0xc97c77e7e0fb5795
0xd2a86c8b49b7c14d	0x49b7c14d52a86c8b
0xce996d79a596d046	0xa596d446ce996d79
0xa5df4766d500990b	0xd500994ba5df4766
0x12681951f83f039c	0xf83f039c52681951
0x4616238466319291	0x663192914616238c

It is visible even to the naked eye that the outputs are the same, modulo a 16-bit rotation and single-bit change, whereas we would expect to obtain, maybe after a few iterations, different and uncorrelated streams.
The problem lies in the basic flaw of LCGs with power-of-2 modulus: if you create two LCGs with the same multiplier and additive constant, and start them from states with the same k lower bits, this will be true forever—the next-state operations all propagate bit changes to the left, never to the right. So the two generators above, even starting from different states, will have forever the same 127 lower bits.
This is an extreme example—127 lower bits in common. But you can still experience a strong correlation between streams generate by different seeds with less low bits in common, even if you cannot see the correlation as easily. For example, the following program uses the standard seeding interface to create two different generators, and then write their output to standard output in binary:
package main
import . "os"
import eb "encoding/binary"
import . "github.com/golang/exp/rand"

func main() {
   var pcg0, pcg1 PCGSource

   pcg0.Seed(0);
   pcg1.Seed(uint64(1) << 63);

   for i := 0; i <<PHONE_NUMBER>; i++ {
      pcg0.Uint64()
      pcg1.Uint64()
   }

   b := make([]byte, 8)
   for {
      eb.LittleEndian.PutUint64(b, pcg0.Uint64())
      Stdout.Write(b)
      eb.LittleEndian.PutUint64(b, pcg1.Uint64())
      Stdout.Write(b)
   }
}

Since we are using two different seeds, we expect the two associated streams, which are non-overlapping, to be uncorrelated. In particular, if we interleave the streams the resulting stream should still look random. But if we pipe the output of the program in PractRand, we obtain after few seconds of testing
rng=RNG_stdin, seed=unknown
length= 32 megabytes (2^25 bytes), time= 9.2 seconds

  Test Name                         Raw       Processed     Evaluation
  BCFN(0+1,13-3,T)                  R= +17.9  p =  3.0e-8   very suspicious
  BCFN(0+2,13-4,T)                  R= +30.8  p =  2.0e-13    FAIL
  ...and 935 test result(s) without anomalies

All classical PRNGs (MCGs with prime modulus, F₂-linear, (C)MWC, etc.) mix wholly their state even after the smallest state change (e.g., one bit). Some are very slow (e.g., the Mersenne Twister with 19937 bits takes a few million iterations), but sooner or later the state change will propagate to all bits. At that point, they will pass the interleaving test above. All PRNGs based on cryptographic primitives will, too, as the smallest change in state generates a random perturbation of the output.
This is not true for PCG because of the very weak base LCG.
For the same reason, I suggest that in case the "jump" functionality of PCG is made available in the future, the documentation should state clearly that jumping by a large power of 2 is very dangerous, as it will yield a new state with a large number of lower bits in common with the starting state, leading to the consequences above.

Shouldn't there be a discussion regarding the other potential alternative Sources? And regarding the requirements that such a replacement will have to fulfill?
Currently math/rand is explicitly meant for applications that are not "security sensitive", but wouldn't it be in the spirit of Go to provide safe defaults? Standard library users will not always know or figure out in time that their application requires resistance to attacks on the PRNG. I think that this applies in the case of an algorithm that uses randomization being exposed on the public Internet, for example.
Randen is an alternative to PCG that seems to pass the relevant statistical tests (as PCG does), but should also provide resistance against prediction of future inputs and empirical indistinguishability from randomness while the generator state is not compromised, and also it ensures that past outputs can't be reconstructed even after the state is compromised.
The Randen paper also shows that, given hardware acceleration of AES, Randen can be faster than PCG in real world applications like shuffling and sampling.
The Randen paper on Arxiv: https://arxiv.org/abs/1810.02227
The Randen Git repository: https://github.com/google/randen
However, considering Randen raises the question of whether the alternate Go PRNG should, given the same seed, generate the same pseudorandom bits across all supported computer architectures; because presumably one wouldn't want to use Randen on, e.g., the old ARMs or Pentiums.

TLDR for Vigna's post above: don't seed PCGs with non-random seeds or jump by a large power of 2.

There seems to be much discussion on the PCG family on the Numpy Github, a lot of which is probably relevant to this issue:
https://github.com/numpy/numpy/issues/13635
https://github.com/numpy/numpy/issues/16313
It's a bit much to consume, but I noticed at least these important facts:

The author of PCG published a new member of the family on her Github in 2019. There was no blog post and I think the only announcement was on one of the linked Numpy Github issues, but the DXSM variants are supposed to be faster and have even better statistical qualities according to the relevant empirical tests, as well as being immune to some of the peculiarities of the earlier PCG schemes. Here's the commit: https://github.com/imneme/pcg-cpp/commit/871d0494ee9c9a7b7c43f753e3d8ca47c26f8005

Prof Vigna (appears a couple posts above here), a rival non-crypto PRNG designer (a small but "lively" field, it seems), proposes some supposed improvements applicable to PCG, even though he doesn't recommend using generators like PCG.

Another thing that may be of import is how nontrivial or "challenging" predictability is explicitly a design goal for the PCG family. AFAIK, "challenging" just means (in the context of PCG) that there are/were no publicly known efficient attacks, but without a stronger kind of guarantee, such as applicable to a CSPRNG or to Randen, making the claim imprecise in such a way that it is somewhat deceptive, coming from an expert. This "challenging" stuff seems to come at the cost of necessary trade-offs at the expense of speed or statistical quality, and is, on the other hand, of dubious utility (considering that no real guarantee is given, and that a relatively efficient attack has recently been demonstrated).

Sebastiano Vigna wrote a pretty scathing review of some of the claims made in O'Neill's paper:
http://pcg.di.unimi.it/pcg.php

Dr. Vigna's criticisms are mostly about (extraordinarily) highly correlated sequences given nearby initial states. This is a very important concern for people performing intensive mathematical, scientific, or statistical work. However, based on discussion here and in #26263, that does not seem to be the Go team's target audience for math/rand. In particular, such people are more likely to understand the reasons for choosing or avoiding a particular class of PRNG.
Instead, the goals for a new math/rand generator seem to be speed, reasonable distribution quality, and a state size small enough that many goroutines can use independent generators. PCG fits these traits[n1][n2], as do many other generators, including several mentioned here.
Now, since this proposal is for PCG, suggesting other generators here does not make progress. Instead, we should be looking at how people currently use math/rand – keeping in mind that it is already a weak generator – to verify that the problems proven with PCG are, in a sense, beside the point. Another idea is to look at how many projects implement or import specific PRNG algorithms such as PCG, xoshiro, Mersenne Twister, &c., or collections like gonum/mathext/prng that provide several PRNGs, to see the reasons people choose those algorithms over math/rand.
[n1] The issue with speed on 32-bit platforms mentioned in https://github.com/golang/go/issues/21835#issuecomment-500225120 does seem like an important concern, especially as Wasm becomes more prominent.
[n2] Notably, the idea mentioned in the proposal to seed different PCGs with the generators' respective addresses, or having many goroutines each seed with the current nanosecond time, may exacerbate its problems with highly correlated states. On the other hand, a high-quality seeding algorithm might avoid that.

@zephyrtronium  I was under the impression that wasm did have 64-bit integer support universally today? Is this not the case? Or do you mean to refer to something else with the remark "especially as Wasm becomes more prominent". Or is there a particular issue with how Go generate wasm outputs?
cc @jfbastien

Sebastiano Vigna wrote a pretty scathing review of some of the claims made in O'Neill's paper:
http://pcg.di.unimi.it/pcg.php

It's worth noting that I responded to his critiques here.

@zephyrtronium I was under the impression that wasm did have 64-bit integer support universally today? Is this not the case? Or do you mean to refer to something else with the remark "especially as Wasm becomes more prominent". Or is there a particular issue with how Go generate wasm outputs?

So it does, my mistake. I must have misread something about Wasm at some point.

Also, as observed by some of the commentators here, more recently Vigna has raised concerns about self-similarity in PCG. If we interleave outputs from carefully chosen seedings of PCG, although the outputs are superficially different, the closer scrutiny applied by sensitive PRNG tests will reveal correlations of some kind indicating that the generator exhibits self-similarity between distant parts of its output.
I think this kind of self-similarity is interesting (and well known for the LCGs that underlie PCG), but Vigna's apparent grave concern about this issue was rather undercut when, on the NumPy mailing list, Tyge Løvset pointed out that similar issues affected Vigna's own most-recent PRNG, xoshift** (comment, code).
If users follow good practice for seeding PRNGs (which they should for a wide variety of other reasons), these kinds of issues won't arise (or rather, they are vanishingly unlikely).  An alternative is to scramble the output more aggressively, but the trade-off is execution time.  PCG's newest output permutation, DXSM, does represent an attempt to scramble better at no added cost on many platforms, but it is still making a trade off in this space.

I wasn't sure of the impact of the claims made, but the general tone was harsh enough it made it more difficult to take his critiques seriously, although I felt there was some interesting points mentioned, and I'm happy you took the time to address them, and thank you for providing that information here.

@zephyrtronium I was under the impression that wasm did have 64-bit integer support universally today? Is this not the case? Or do you mean to refer to something else with the remark "especially as Wasm becomes more prominent". Or is there a particular issue with how Go generate wasm outputs?

@lemire sorry for missing this, I don't look at github notifications often.
Yes, wasm supports 64-bit integers universally as a first-class type. The initial discussion in 2016 hedged a bit in case there were JS-based implementations in some browsers, but now all relevant browsers support wasm natively (that's 92% of all users on the web). Non-browser implementations of wasm also support 64-bit integers natively.

@zephyrtronium I was under the impression that wasm did have 64-bit integer support universally today? Is this not the case? Or do you mean to refer to something else with the remark "especially as Wasm becomes more prominent". Or is there a particular issue with how Go generate wasm outputs?

@lemire sorry for missing this, I don't look at github notifications often.
Yes, wasm supports 64-bit integers universally as a first-class type. The initial discussion in 2016 hedged a bit in case there were JS-based implementations in some browsers, but now all relevant browsers support wasm natively (that's 92% of all users on the web). Non-browser implementations of wasm also support 64-bit integers natively.

There is no mention of a multiply-with-carry generator in these discussions. Unlike many of these other algorithms, it is listed on wikipedia and is simply a LCG with less constants.
If the multiply-with-carry generator had a lag of at least 2 (according to the parlance used), it would be parallelizable by typical cpu dispatch units as there would be less dependencies.
Hopefully whatever the generator used will allow for 64-bit seeds or at least frequent reseeding.

Randen is an alternative to PCG that seems to pass the relevant statistical tests (as PCG likewise does), but should also provide resistance against prediction of future inputs and empirical indistinguishability from randomness while the generator state is not compromised, and also it ensures that past outputs can't be reconstructed even after the state is compromised.

This AES-NI accelerated RNG is faster and has performance nearly that of a CPU's memory transfer limit: dragontamer/aesrand
Adding an extra AES round might make it cryptographic.

Hi everyone! I'm a numpy developer with a particular focus on our PRNG capabilities. For some background, the older PCG64 with the XSL-RR output function is our current default PRNG for the past couple of years. The next release will have an optional implementation with the stronger DXSM output function. We expect we will make it the default some undetermined time down the road.
I have written up a what I hope to be an accessible explanation of the consequences so you don't have to reconstruct everything from those long digressing threads. My prose style is prone to long, complicated sentences, so please ask if anything needs to be clarified; that will help me edit this down for my own audience. I hope to provide a point of view as a PRNG library maintainer that is helpfully complementary to those of our PRNG algorithm authors. To be clear about where I'm writing from, numpy is an anchor library for scientific computing and machine learning, so we have a particular risk profile that is driving our decisions. The extreme conditions that would make this weakness non-negligibly likely are not really a practical use case right now, but you can see it on the horizon, at least for my audience. This is likely a different risk profile for you, but I try to give the information needed to evaluate things for yourself rather than boil everything down to a universal safe/unsafe declaration.
If I were still asked my opinion for what you should do, if you do decide to use a PCG algorithm, I would recommend using the DXSM variant over the XSL-RR. While the risks of XSL-RR are rare outside of extreme use cases and usually inconsequential, I think they are still worth documenting. And it's a pain to document and a pain for the user to work through the math to determine that yes, they are safe using it. DXSM provides an extra safety margin that renders those computations (and my article) unnecessary. I can think about the DXSM variant with a mental model that is a lot less complicated than one I would now use for XSL-RR. As a library maintainer and documenter, that's golden.

@rkern

My prose style is prone to long, complicated sentences,...

You sir have no idea what long and complicated sentences are... :-)

Thanks for the write up!  Nicely done.
(It might be too tangential to include, but the only thing I'd add is that detectable self-similarity is not unique to LCGs (and PCG); it's findable in a number of non-cryptographic PRNGs.)

See #60751 for a GitHub Discussion that I hope will lead to a math/rand/v2. Closing as duplicate of that.


[ERR] EvalError: [KODADOT::SUBAPI] Error: cannot get instance at wss://rpc.basilisk.cloud

What happened?
When you create a new collection, it crashes at the point of "Uploading data to IPFS". Error message:

Please reproduce in steps
Creating a new collection. Upload an intro image for a collection - error
Expected Behavior
ERR] EvalError: [KODADOT::SUBAPI] Error: cannot get instance at wss://rpc.basilisk.cloud
What browsers are you seeing the problem on?
Firefox
At which address did you encounter bug?
No response
Are you logged in?
Yes
Which wallet you are using?
PolkadotJS, SubWallet
Screenshots
scr is up
Relevant log output
No response
Payment link for reward
https://kodadot.xyz/transfer?target=FqCJeGcPidYSsvvmT17fHVaYdE2nXMYgPsBn3CP9gugvZR5
Code of Conduct

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

I heard that @jak-pan has fingers in it 👁:snake::eye:

Have problem with hostings would be better to switch to wss://basilisk-rpc.dwellir.com in the meantime


[Feature] Wayland support.

Before Requesting

[X] I found no existing issue matching my feature request

Describe the feature you'd like!
I use a 4K monitor, so I am forced to use Wayland because X does not scale correctly at high DPIs. I see no reason for this software to not support Wayland compositors, even if Discord itself is a different problem.
Anything else?
https://github.com/BetterDiscord/BetterDiscord/issues/1528#issue-1575218969 depicts the current blurriness.

Are you running the app as a native wayland app using the proper parameters or settings? Have a look at the Arch Wiki's page on Electron to see how to do this.

@QbDesu, indeed http://forums.opensuse.org/t/164044 was the problem, but I still would like Wayland support. To that end, is this feasible for BetterDiscord, or should I merely follow https://support.discord.com/hc/en-us/community/posts/360047644231?

Simplest way is to modify the discord entry to start with the appropriate command line flags. The way to do this depends on the desktop environment you are using.
One way that may work in an environment like sway or Weston but probably wouldn't work in Plasma or Gnome is overriding the .desktop file by first copying the existing file from /usr/share/applications/discord.desktop (exact path varies depending on distribution) to the ~/.local/share/applications/ folder and adding  --enable-features=WaylandWindowDecorations,UseOzonePlatform --ozone-platform=wayland at the end of the Exec= line.
This shouldn't really be considered for BD to add as a feature. Wayland implementations are still unstable and the Wayland specification is still far from done. On top of that the Wayland support for Chromium - and therefore by extension Electron and Discord - is still experimental. Wayland is just not quite there yet.

This sounds like an issue with the installer and not BD... moving issue


PrintSolutionRejectionReason in KernelWriter.py

update global parameter "PrintSolutionRejectionReason" for KernelWriter.py

@aazz44ss since all CI pipelines passed at least once, please feel free to squash-merge.  Thanks so much.


fix(components): scalar icon info

this pr updates the scalar icon info in order to comply with icon styleguide and pass linting.

Before this PR


Server SAC releases are badly out of date. Where's v2009?

Server SAC releases are badly out of date. Where's v2009?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fbf74885-9525-9828-95c9-0ab9167b1f35
Version Independent ID: f0a39382-120b-0cfa-692f-621124a23f37
Content: Windows Server release information
Content Source: WindowsServerDocs/get-started/windows-server-release-info.md
Product: windows-server
Technology: getting-started
GitHub Login: @JasonGerend
Microsoft Alias: jgerend

#assign:IngridAtMicrosoft

#assign:xelu86

Hey @evan-morris,
Thanks again for contacting Microsoft. We value your feedback.
Had to go down the rabbit hole to gain more insight into this documentation. We discovered that this document belongs to another team that maintains "release info" documents. As this is a cross-repository reference, we forwarded your inquiry to the appropriate team to handle any changes necessary. We do not have a timeframe for when this will be updated as we aren't the owners.
Due to this, any future inquiries about Windows Server Release information will still fall under the Windows Server Docs team as it is a cross-repo. We are more than happy to engage with the owning team if more issues or documentation changes need to be made.
We will now be closing this thread. Thank you and have a most pleasant day. #please-close


artifact attribute - {{path}}

The coding of function getDestrinationPath (Plugin/Twig/Writer/Twig.php) does not work in a consistent manner with the file names generated where the artifact attribute is missing.  i.e.
Processing file called 'classes\my class.php' will generate fundamentally different file names depending on whether the artifact attribute is present
   'classes.my+class.html'     -  artifact is not defined in a transformation

   'classes%2Fmy%20class.php.txt'     - artifact is set to '{{path}}.txt'

With apache, it is necessary to get AllowEncodedSlashes enabled on the web server to access the file.
Problem is associated with clear Template.

Solved.  See #1461


Mirror object is in incorrect position when dragging inside a modal or similar

When dragging a draggable item inside a modal (or, I'd imagine, anything else which is similarly offset from the rest of the content), the mirrored item has the wrong coordinates and doesn't compensate for this.
This codepen demonstrates this inside a Materialize modal.

Library version: 1.0.0-beta.4
Browsers: all
Tech stack: jQuery (3.3.1) is the most complex thing in the example, other than that nothing but draggable and Materialize are included

Hey!
I made 2 tiny tweaks to your Codepen: https://codepen.io/beefchimi/pen/PQxPNv?editors=0100

I added a really high z-index for the draggable-mirror in the CSS - this allows it to be above your modal.
I used appendTo on the 2nd instance of Draggable to put the mirror on the body instead of within the modal. You could append this anywhere outside of the modal if you wanted.

The offending code that caused the problem was the transform: scaleX(1) scaleY(1) on the modal. Not sure why this style is needed... nor do I fully understand why its affecting the positioning of the mirror. I've never actually used Materialize myself - but thats where the issue is.
Thanks for bringing this up! Personally I don't believe this is an issue with Draggable. Its just a matter of adjusting the styling based on the consumers specific use case. Closing this issue, but feel free to re-open and reply.

Thanks a ton for the help, I wouldn't have thought to do that.  It seems I misunderstood appendTo as what where the dragged element would go upon placement.
Thanks!

Maybe we can make the appendTo  option clearer by moving it inside the mirror options namespace, e.g.
new Sortable(containers, {
  mirror: {
    appendTo: 'body',
  },
  ...remainingOptions
});

@tsov yea thats a pretty good point actually... we can chat a bit about this in person but perhaps we put this on the roadmap for beta5

I have a problem with this approach. I too added the code below to compensate for a mirror at a wrong position. My draggable item isn't in a modal, but it is part of a pretty complex DOM structure with different positions applied in the CSS. However, as soon as I append the mirror to the body, the drag:over and drag:out events don't fire anymore. Anyone has an idea why this might be?
        this.draggableContext = new Draggable(document.querySelectorAll('.layerContainer, .drop-zone'), {
            draggable: '.draggable-item',
            distance: 12,
            mirror: {
                appendTo: 'body'
            }
        });

I have a problem with this approach. I too added the code below to compensate for a mirror at a wrong position. My draggable item isn't in a modal, but it is part of a pretty complex DOM structure with different positions applied in the CSS. However, as soon as I append the mirror to the body, the drag:over and drag:out events don't fire anymore. Anyone has an idea why this might be?
        this.draggableContext = new Draggable(document.querySelectorAll('.layerContainer, .drop-zone'), {
            draggable: '.draggable-item',
            distance: 12,
            mirror: {
                appendTo: 'body'
            }
        });


tests: Make use of tests/libsecret

What this PR does
Change tests that involve defining simple Secret objects to use tests/libsecret package
Affected test suites:

compute/credentials.go
storage/export.go
virtctl/credentials.go
vmi_configuration_test.gp
vmi_lifecycle_test.go

Before this PR:
E2E tests created the secret in-line, some added the kubevirt.io/secret label and some dont.
After this PR:
E2E tests create the secret object using libsecret, all tests use the same expected configuration.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer
The global test suite deletes cleanup that runs after each test delete secrets who has kubevirt.io/secret label.
It is not clear why this filtering is necessary, therefore we should revisit it and maybe remove the filtering so that all secrets in Kubevirt tests namespaces will get deleted by the global tests suite clean up.

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

/hold
Based on https://github.com/kubevirt/kubevirt/pull/11545. Wait until it is merged

/sig code-quality

rebased

https://github.com/kubevirt/kubevirt/pull/11545 is merged
/unhold

sig-storage passed but it seems to failed on teardonw nhttps://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/11547/pull-kubevirt-e2e-k8s-1.29-sig-storage/1783101831979732992#1:build-log.txt%3A4576-4580

/test pull-kubevirt-e2e-k8s-1.29-sig-storage
/test pull-kubevirt-e2e-k8s-1.29-sig-compute

It looks good. I think including the generalization I sent will be a good addition to this change. And it will be better to include it here over going again over all the callers and change them later.

I think we can do it as a follow up, lets not block this PR on it.

Rebased

Changes: Rebased on #11854

Changes: Change tests to use  libsecret.StringData{} and libsecret.Data{}

Rebased


[Proposal] Create standalone installer

Describe the proposal
We can create a standalone install package with dapr CLI and daprd binary and perhaps the docker containers we need. The idea being, a package that you can self-host/cache somewhere and deploy dapr without depending on the github API.
We could create Windows, Mac, and Linux installers.
Release Note

RELEASE NOTE:

It sounds like alternative as offline deploy, we can download it and deploy without network.

I would reuse dapr init to do this job and enable to pass in an URL (or local path) to a tar file with "everything" in it.

related to #640

@shivamkm07 You may consider to help enhancing #898, thanks :)

Thank you @beiwei30 for your contributions. We can handle the scenario in different ways. Below are the possible designs for the installer(Changes in https://github.com/dapr/cli/pull/898 are presented as 3rd design):
DAPR standalone installer for airgap environments
Purpose: To support DAPR installed and running in the isolated environments where there is no internet connectivity.
In the current scenarios user must install Dapr CLI first and then run dapr init to load all the needed artifacts to run DAPR in the given environments:

Downloads binaries(daprd, dashboard) and places them in right directory
Downloads daprio/placement and runs the container
Downloads openzipkin/zipkin and redis images and runs the containers
Slim installation(dapr init -s) installs binaries without loading any containers

Airgap/Standalone installer is also expected to support all the above 4 steps
Design
There are 3 approaches that we can generate the standalone installer.
Design 1

All required binaries(cli, daprd, dashboard) and daprio/placement image are downloaded and combined into one executable standalone(e.g., dapr-standalone.exe)
On execution, standalone installs binaries and loads placement container by default
Third party images(redis, zipkin) are not bundled with standalone since that would require a new version of executable to be released with every new version of redis or zipkin.
User can either manually pull and run the redis and zipkin containers or provide path to saved images to executable to load them up
Slim installation would also be supported, in which only binaries would be installed
A separate standalone repo to handle the dependencies across repositories as this standalone installer depends on dapr runtime, dashboard as well as CLI releases.

Pros:

Relatively easy dev experience for the user, since all images/binaries are combined into one single executable
No dependency on zipkin/redis releases

Cons:

There is a bit of code duplication, which might require further maintenance as and when there are some changes to dapr init
This would lead to having two executables for installing dapr: dapr cli and standalone
User must manually download redis/zipkin images and run the containers

Commands
./standalone  [--slim] [--path-to-images images/]      # Installs binaries and loads placement container, images/ contain downloaded zipkin and redis images
Design 2

All required binaries(cli, daprd, dashboard) and daprio/placement image are downloaded and released as one bundled artifact, structured as a zipped folder dapr-bundle
User downloads the released artifact and runs enchanced dapr init(see commands) itself to install the binaries including cli and load placement container. While currently dapr init downloads binaries from github, the enhanced version will override the behavior and load them up from the dapr-bundle when provided.
Third party images(redis, zipkin) are not bundled in the artifact since that would require a new version of executable to be released with every new version of redis or zipkin.
User can either manually pull and run redis/zipkin containers or add saved images in images/ folder mentioned below(see commands)
Slim installation is by default supported in dapr init
A separate standalone repo to handle the dependencies across repositories as this standalone installer depends on dapr runtime, dashboard as well as CLI releases.

Artifact Structure
Artifact would be structured as follows:

dapr-bundle/

bin/
| dapr
| daprd
| dashboard
images/
| placement-1.6.0.tar.gz

Pros:

Decoupling of dapr CLI with the dapr-bundle would lead to better long term code maintenance
No dependency on zipkin/redis releases
A consistent user experience, since dapr init itself would be used to install dapr in airgap mode as well

Cons:

Setup in airgap mode would be relatively more involved
User must manually download redis/zipkin images and run the containers

Commands
./dapr-bundle/bin/dapr init [--slim] [--path-to-binaries bin/] [--path-to-images images/]  #Installs binaries located in /bin and loads and run containers in images/
// To load redis and zipkin, either they can be run manually or the saved tar.gz files can be added in images/ folder
Design 3
https://github.com/dapr/cli/pull/898 describes another possible way of having airgap installation

A fat/airgap CLI binary would be released bundling all binaries as well as images(e.g. airgap-dapr.exe)
User has to run dapr init using airgap CLI to have all the binaries installed as well as the containers loaded up
Slim installation would be by default supported
No separate repo, since airgap CLI would be released from CLI release workflow itself

Pros:

Consistent and easiest dev experience, just using dapr init without any extra flags etc. would do the airgap installation
User won't need to manually pull redis/zipkin images since they would be bundled as well in airgap CLI

Cons:

Without having a separate repo, for every release/hotfix in dapr runtime/dashboard, a new version of CLI would need to be released
airgap CLI is just required for installing dapr, after that user can do away with using normal CLI binary, instead of the big fat airgap binary
For every redis/zipkin release, a new version of airgap CLI would need to be released due to the dependency

Commands
./airgap-dapr init [--slim]
Let us collaborate further to finalize the solution.

FYI, following PRs resolve the issue:
Release workflow: https://github.com/dapr/installer-bundle/pull/1
Enhancing Dapr CLI: https://github.com/dapr/cli/pull/898
@artursouza this can be closed now.

FYI, following PRs resolve the issue: Release workflow: dapr/installer-bundle#1 Enhancing Dapr CLI: #898
@artursouza this can be closed now.

closing.

@shivamkm07 - Please complete the documentation for the feature. This issue https://github.com/dapr/docs/issues/2299


[TS Error]  Argument of type 'StoreEnhancer | ....' is not assignable to parameter of type 'StoreEnhancer<{}, {}> | undefined'.

Following the usage guide for legacy redux with middleware + ts:
import { createStore, applyMiddleware } from "redux";
import { composeWithDevTools } from "redux-devtools-expo-dev-plugin";

const store = createStore(
  reducer,
  /* preloadedState, */ composeWithDevTools(
    applyMiddleware(...middleware),
    // other store enhancers if any
  ),
);

Is giving the following TS error signifying the signature is mismatched.
Argument of type 'StoreEnhancer | ((...funcs: StoreEnhancer[]) => (...args: unknown[]) => StoreEnhancerStoreCreator<{}, {}>) | ((...args: unknown[]) => StoreEnhancerStoreCreator<{}, {}>)' is not assignable to parameter of type 'StoreEnhancer<{}, {}> | undefined'.
      Type '(...funcs: StoreEnhancer[]) => (...args: unknown[]) => StoreEnhancerStoreCreator<{}, {}>' is not assignable to type 'StoreEnhancer<{}, {}>'

The signature of @redux-devtools/extension's composeWithDevToolsDevelopmentOnly  works as expected and using a similar definition as theirs fixes the TS issue.
 Options<S, A>) => StoreEnhancer;
 export default _default;
-export declare function composeWithDevTools(...funcs: [Options<unknown, Action<string>>] | StoreEnhancer[]): StoreEnhancer | ((...funcs: StoreEnhancer[]) => (...args: unknown[]) => StoreEnhancerStoreCreator<{}, {}>) | ((...args: unknown[]) => StoreEnhancerStoreCreator<{}, {}>);
+export declare function composeWithDevTools(...funcs: StoreEnhancer[] | [Options<unknown, Action<string>>]): StoreEnhancer;
 //# sourceMappingURL=devtools.d.ts.map
\ No newline at end of file

Is it just the typing that is the issue? If you add a /// @tsignore comment does everything work as expected?

@matt-oakes Yes this is just a TS issue! All works as expected with/without @tsignore, and the ts issue goes away if you apply the patch.
Does that make sense?

It does. I'm unsure if changing the library to match your patch would cause issues for other people with different setups.
For now, keep using the patch and I will investigate this next time I work on this project. Note that this might be a while as I'm currently working on client apps full time.
If anyone else can investigate if this patch causes and issues, then leave a comment or open a PR with your findings and we can get it merged.
In the meantime, thanks for reporting this issue and providing a workaround for people!

@matt-oakes Of course, no problem!


Firefox unable to call remote function

I'm getting Javascript errors in Firefox 10.0.1 when my app attempts to call a function using the remote macro, the request doesn't even reach the server (I've checked with logging etc), all I get returned in the "Firebug" javascript error console is the message uncaught exception: EOF every time this code is hit
What's odd is the fact that everything works fine in Webkit based browsers (Chrome, Safari, iOS Safari, Android etc) so I'm not really sure what's going on here

after a lot of banging my head against a wall, I think I finally figured out what was going on. Should be fixed in the latest snapshot.

Yep that's done it, thanks for fixing this Chris.


Unable to Set New Env Variables

Description
I am trying to create new Env Variables but it shows me undefined
Steps to reproduce
"scripts": {
"start": "cross-env PAGE_ID=xxxxxx NODE_ENV=development node server",
}
Expected behavior
process.env.PAGE_ID should give the id
Versions

React-Boilerplate: latest
Node/NPM: 10.16
Browser: Chrome

You want to access .env in package.json?


⚠ ClamAV has degraded performance

In 0429a79, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 49 ms

Resolved: ClamAV performance has improved in 5b85b1f.


React to nested artifacts

Right now, our publish process produces artifacts of the form:
- agent
--- linux-x64
------ vsts-agent-linux-arm-2.160.1.tar.gz
--- win-x64
------ vsts-agent-win-2.160.1.tar.gz
...etc

see https://dev.azure.com/mseng/AzureDevOps/_build/results?buildId=10942550&view=artifacts&type=publishedArtifacts as an example
Previously, they were just of the form:
- agent
--- vsts-agent-linux-arm-2.160.1.tar.gz
--- vsts-agent-win-2.160.1.tar.gz
...etc

see https://dev.azure.com/mseng/AzureDevOps/_build/results?buildId=10894910&view=artifacts&type=publishedArtifacts as an example
I think this was probably introduced by https://github.com/microsoft/azure-pipelines-agent/pull/2581/files, though I'm not 100% sure.
This was causing an issue where when we were looking to extract the version name from the artifact, we looked at the folder name (e.g. linux-x64) instead of the filename (vsts-agent-linux-arm-2.160.1.tar.gz) - which led to us writing x64 or x86 as the version.
This fixes that problem

Yikes, sorry guys.


Set content-type to application/json

Set content-type to application json for /cluster_setup requests

+1
thank you @garrensmith

merged


Feature/sagemaker runner

resolves: https://github.com/ml6team/fondant/issues/663

Thanks @GeorgesLorre! Is there a reason not to implement the interface from #651 yet?

Thanks @GeorgesLorre! Is there a reason not to implement the interface from #651 yet?

want to keep changes manageable. It will come in a follow up PR


Hyphenated lastname support

In Cyrillic we have many double lastnames.
This includes some simple cases such as:

Петров-Водкин
Бестужев-Марлинский

Female lastname also can be double, but I can not remember any famous one at the time.
These can be handled by naive code: split the lexem by hyphen, translate each part, join back with hyphen.
However, this becomes nasty with exceptions, including Бонч-Бруевич, Мамин-Сибиряк, Муравьёв-Апостол.
Can this be supported by pytrovich rules model?
Here is the list of the most famous names.

Hi Yuriy, fair point, thanks!
Will try to find the time to look into it; meanwhile, pull requests are welcome.


Connect ThreeJS to a server via socket.io

My attempt was to send a message from a server to ThreeJSApp.
We wrote a server script and there's a node.js server running, whose IP address was <IP_ADDRESS> and was able to send messages through 'message'. We tested that any web page connected to the same network with the code below was able to get the message.
var serverIP = 'http://<IP_ADDRESS>'; // This should be the IP address that's assigned by your router
var messagePort = '8000';
var socket = io.connect(serverIP + ':' + messagePort);
socket.on('message', function (data) {
    console.log(data);
});

and sure the code should have imported the javascript file from https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.0.3/socket.io.js
In the "ThreeJSApp" sample, I simply put the code into app.js from https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.0.3/socket.io.js
and wrote the previous code into app.js:
but there were errors when running the
var socket = io.connect(serverIP + ':' + messagePort);

The error messages were

Any tips?

Is socket.io using WebSockets? Is yes, then there's some work to be done to implement support for them in the native layer. If not, then this could be an easy fix in the XHR implementation.

Partially.
"Note: Socket.IO is not a WebSocket implementation. Although Socket.IO indeed uses WebSocket as a transport when possible, it adds some metadata to each packet: the packet type, the namespace and the ack id when a message acknowledgement is needed. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a WebSocket server (like ws://echo.websocket.org) either. Please see the protocol specification here."
from https://github.com/socketio/socket.io/
Socket IO protocol:
https://github.com/socketio/socket.io-protocol

In app.js, when I run
var serverIP = 'http://<IP_ADDRESS>'; // This should be the IP address that's assigned by your router
var messagePort = '8000';
console.log(serverIP);
var socket = io(serverIP + ':' + messagePort);

I got the message from Output window in Visual Studio 2015:
log: http://<IP_ADDRESS>
Exception thrown at 0x77062502 in threejsapp.exe: Microsoft C++ exception: Js::JavascriptExceptionObject at memory location 0x01EC9CA4.
'threejsapp.exe' (Win32): Loaded 'C:\Windows\System32\urlmon.dll'. Symbols loaded.
'threejsapp.exe' (Win32): Loaded 'C:\Windows\System32\mlang.dll'. Symbols loaded.
Exception thrown at 0x77062502 in threejsapp.exe: Microsoft C++ exception: Js::JavascriptExceptionObject at memory location 0x01ECCCC4.
Exception thrown at 0x77062502 in threejsapp.exe: Microsoft C++ exception: Js::JavascriptExceptionObject at memory location 0x01EC99BC.
Failure in file c:\users\bryanbo.cao\documents\repos\ar-collaboration\src\holojs\holojs\holojshost\objectevents.h, line 52
Failure in file c:\users\bryanbo.cao\documents\repos\ar-collaboration\src\holojs\holojs\holojshost\windowelement.cpp, line 149
Failure in file c:\users\bryanbo.cao\documents\repos\ar-collaboration\src\holojs\holojs\holojshost\windowelement.cpp, line 149
Failure in file c:\users\bryanbo.cao\documents\repos\ar-collaboration\src\holojs\holojs\holojshost\windowelement.cpp, line 149
Failure in file c:\users\bryanbo.cao\documents\repos\ar-collaboration\src\holojs\holojs\holojshost\windowelement.cpp, line 149
Failure in file c:\users\bryanbo.cao\documents\repos\ar-collaboration\src\holojs\holojs\holojshost\windowelement.cpp, line 149

On the server which is running on another laptop, I could see that a new client was connected.

There were a couple missing functions that socket.io needs (get/set headers, clearTimeout).
I implemented those in the develop/fix-socket-io and I got the chat sample working with this code:
    var serverIP = 'http://<IP_ADDRESS>';
    var messagePort = '3000';
    var socket = io.connect(serverIP + ':' + messagePort);

    socket.on('chat message', function (msg) {
        console.log(data);
    });

Can you please give it a try and let me know if it works for you?


Header disappears on third page of table

On the website, under Buildings, the header disappears on the third page.

Finished.

Turns out that we were just doing the column headings mildly incorrectly.

IT'S BACK. But that's okay. Leave it to the person who has to touch it next.

Fixed with commit . Conflicting slot-scopes in the search bar.


Support File/Folder hierarchy

I see no reason for the build aborting -- I suspect some kind of system/resource issue, and also note java 11 was ok. Let's kick it off again and see if the issue reoccurs.

recheck

@planetf1 thanks Nigel


storage: compose objects API

https://cloud.google.com/storage/docs/json_api/v1/objects/compose
This method lets you compose an object in GCS from other existing objects in GCS. The generated client can be called like so:
obj, err := svc.Objects.Compose("bucket", "destObj", &storage.ComposeRequest{
  SourceObjects: []*storage.ComposeRequestSourceObjects{
    {Name: "srcObj1"},
    {Name: "srcObj2"},
    {Name: "srcObj3"},
    //... and so on...
  },
}).Do()
// destObj's contents are now the source objects' contents, concatenated.

Source objects must be in the same bucket as each other, and the destination object. The API allows the caller to specify a particular generation of source objects, and to require that the destination's object is of a given generation. It also allows the caller to specify a pre-defined ACL for the destination object.
The destination object can be composed of itself and other objects, which allows for appending to an existing object.
An simple idiomatic Go API for this might look like:
func ComposeObject(ctx context.Context, bucket, destObject string, srcObjects... string) (*Object, error)

I'd really love to be able to use this with the storage package.

At first glance this looks straightforward. I want to be able to make sure that it can support the generation-matching precondition, or at least that the API will extend to that use case. So it might be worth working out a good solution to #188 first.


Uncaught KeyError in models.py line 1107

Aider version: 0.62.1
Python version: 3.10.15
Platform: macOS-14.5-arm64-arm-64bit
Python implementation: CPython
Virtual environment: No
OS: Darwin 23.5.0 (64bit)
Git version: git version 2.40.0
An uncaught exception occurred:
Traceback (most recent call last):
  File "aider", line 8, in <module>
    sys.exit(main())
  File "main.py", line 638, in main
    problem = models.sanity_check_models(io, main_model)
  File "models.py", line 1046, in sanity_check_models
    problem_main = sanity_check_model(io, main_model)
  File "models.py", line 1090, in sanity_check_model
    possible_matches = fuzzy_match_models(model.name)
  File "models.py", line 1107, in fuzzy_match_models
    provider = (attrs["litellm_provider"] + "/").lower()
KeyError: 'litellm_provider'

config of .env
OPENAI_API_BASE=http://<IP_ADDRESS>:1234/v1
OPENAI_API_KEY=lm-studio
AIDER_MODEL=14b@q4_k_m

This should be fixed in the latest version. You can get it like this:
aider --upgrade

# or...

python -m pip install --upgrade --upgrade-strategy only-if-needed aider-chat

If you have a chance to try it, let me know if it works better for you.