This is the issue. It couldn't find /outside Did you name one of your folders with a space? It seems the build sequence cannot handle folder with spaces in them.

Oh
Awesome
Thanks it workes
@joniaiuser

Oh
Awesome
Thanks it workes
@joniaiuser

Class AMSupportURLConnectionDelegate is implemented in both

is a warning from Xcode command line tools that have been emitted for years.  It's confusing, but it's never the reason your build is failing.  We're tracking showing better error messages from Xcode with https://github.com/flutter/flutter/issues/22536.
I'm going to close this.  You're all hitting totally different errors, and you need to file separate issues with flutter run -v output.
As @joniaiuser has pointed out, @yvngaayush and @amoslai5128 hit https://github.com/flutter/flutter/issues/70895.

Class AMSupportURLConnectionDelegate is implemented in both

is a warning from Xcode command line tools that have been emitted for years.  It's confusing, but it's never the reason your build is failing.  We're tracking showing better error messages from Xcode with https://github.com/flutter/flutter/issues/22536.
I'm going to close this.  You're all hitting totally different errors, and you need to file separate issues with flutter run -v output.
As @joniaiuser has pointed out, @yvngaayush and @amoslai5128 hit https://github.com/flutter/flutter/issues/70895.

I encountered the same error on a M1 Mac Mini and with the stable channel.
But if I change to the master channel, the error is gone.
My issue is that I can't use the master branch on my project, so I'm stuck with this.

I switch to master but same issue

I encountered the same error on a M1 Mac Mini and with the stable channel.
But if I change to the master channel, the error is gone.
My issue is that I can't use the master branch on my project, so I'm stuck with this.

I switch to master but same issue

Class AMSupportURLConnectionDelegate is implemented in both

is a warning from Xcode command line tools that have been emitted for years.  It's confusing, but it's never the reason your build is failing.  We're tracking showing better error messages from Xcode with #22536.
I'm going to close this.  You're all hitting totally different errors, and you need to file separate issues with flutter run -v output.
As @joniaiuser has pointed out, @yvngaayush and @amoslai5128 hit #70895.

If it's just a warning then why build is failing, can you have look and tell me the exact error. I'm struggling from 3 days due to this issue.
Launching lib/main.dart on iPhone 12 Pro Max in debug mode...
Running pod install...                                             14.6s
Running Xcode build...
Xcode build done.                                           62.1s
Failed to build iOS app
Error output from Xcode build:
↳
    objc[24686]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x1eb6a78f0) and ?? (0x115bac2b8). One of the two will be used. Which one is
    undefined.
    objc[24686]: Class AMSupportURLSession is implemented in both ?? (0x1eb6a7940) and ?? (0x115bac308). One of the two will be used. Which one is undefined.
    ** BUILD FAILED **

Xcode's output:
↳
    /Users/abdullahkhan/Development/atlast/ios/Pods/libwebp/src/enc/backward_references_enc.c:663:12: warning: variable 'best_offset' may be uninitialized
    when used here [-Wconditional-uninitialized]
              (best_offset << MAX_LENGTH_BITS) | (uint32_t)best_length;
               ^~~~~~~~~~~
    /Users/abdullahkhan/Development/atlast/ios/Pods/libwebp/src/enc/backward_references_enc.c:595:20: note: initialize the variable 'best_offset' to silence
    this warning
        int best_offset;
                       ^
                        = 0
    1 warning generated.
    While building module 'firebase_core' imported from
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_storage-5.2.0/ios/Classes/FLTFirebaseStoragePlugin.m:6:
    In file included from <module-includes>:1:
    In file included from /Users/abdullahkhan/Development/atlast/ios/Pods/Target Support Files/firebase_core/firebase_core-umbrella.h:13:
    In file included from
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebaseCorePlugin.h:11:
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebasePlugin.h:9:9: error: include of
    non-modular header inside framework module 'firebase_core.FLTFirebasePlugin':
    '/Users/abdullahkhan/Development/atlast/ios/Pods/Headers/Public/FirebaseCore/FirebaseCore.h' [-Werror,-Wnon-modular-include-in-framework-module]
    #import <FirebaseCore/FirebaseCore.h>
            ^
    1 error generated.
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_storage-5.2.0/ios/Classes/FLTFirebaseStoragePlugin.m:6:9: fatal error:
    could not build module 'firebase_core'
    #import <firebase_core/FLTFirebasePluginRegistry.h>
     ~~~~~~~^
    2 errors generated.
    note: Using new build system
    note: Building targets in parallel
    note: Planning build
    note: Constructing build description

Could not build the application for the simulator.
Error launching application on iPhone 12 Pro Max.

Class AMSupportURLConnectionDelegate is implemented in both

is a warning from Xcode command line tools that have been emitted for years.  It's confusing, but it's never the reason your build is failing.  We're tracking showing better error messages from Xcode with #22536.
I'm going to close this.  You're all hitting totally different errors, and you need to file separate issues with flutter run -v output.
As @joniaiuser has pointed out, @yvngaayush and @amoslai5128 hit #70895.

If it's just a warning then why build is failing, can you have look and tell me the exact error. I'm struggling from 3 days due to this issue.
Launching lib/main.dart on iPhone 12 Pro Max in debug mode...
Running pod install...                                             14.6s
Running Xcode build...
Xcode build done.                                           62.1s
Failed to build iOS app
Error output from Xcode build:
↳
    objc[24686]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x1eb6a78f0) and ?? (0x115bac2b8). One of the two will be used. Which one is
    undefined.
    objc[24686]: Class AMSupportURLSession is implemented in both ?? (0x1eb6a7940) and ?? (0x115bac308). One of the two will be used. Which one is undefined.
    ** BUILD FAILED **

Xcode's output:
↳
    /Users/abdullahkhan/Development/atlast/ios/Pods/libwebp/src/enc/backward_references_enc.c:663:12: warning: variable 'best_offset' may be uninitialized
    when used here [-Wconditional-uninitialized]
              (best_offset << MAX_LENGTH_BITS) | (uint32_t)best_length;
               ^~~~~~~~~~~
    /Users/abdullahkhan/Development/atlast/ios/Pods/libwebp/src/enc/backward_references_enc.c:595:20: note: initialize the variable 'best_offset' to silence
    this warning
        int best_offset;
                       ^
                        = 0
    1 warning generated.
    While building module 'firebase_core' imported from
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_storage-5.2.0/ios/Classes/FLTFirebaseStoragePlugin.m:6:
    In file included from <module-includes>:1:
    In file included from /Users/abdullahkhan/Development/atlast/ios/Pods/Target Support Files/firebase_core/firebase_core-umbrella.h:13:
    In file included from
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebaseCorePlugin.h:11:
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebasePlugin.h:9:9: error: include of
    non-modular header inside framework module 'firebase_core.FLTFirebasePlugin':
    '/Users/abdullahkhan/Development/atlast/ios/Pods/Headers/Public/FirebaseCore/FirebaseCore.h' [-Werror,-Wnon-modular-include-in-framework-module]
    #import <FirebaseCore/FirebaseCore.h>
            ^
    1 error generated.
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_storage-5.2.0/ios/Classes/FLTFirebaseStoragePlugin.m:6:9: fatal error:
    could not build module 'firebase_core'
    #import <firebase_core/FLTFirebasePluginRegistry.h>
     ~~~~~~~^
    2 errors generated.
    note: Using new build system
    note: Building targets in parallel
    note: Planning build
    note: Constructing build description

Could not build the application for the simulator.
Error launching application on iPhone 12 Pro Max.

@abdullah432
Please just read through your own error logs
/Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebasePlugin.h:9:9: error: include of
    non-modular header inside framework module 'firebase_core.FLTFirebasePlugin':
    '/Users/abdullahkhan/Development/atlast/ios/Pods/Headers/Public/FirebaseCore/FirebaseCore.h' [-Werror,-Wnon-modular-include-in-framework-module]
    #import <FirebaseCore/FirebaseCore.h>

Xcode clearly states when something is a warning or an error and errors are usually at the end of the build logs because the build stops when an error is encountered.

@abdullah432
Please just read through your own error logs
/Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebasePlugin.h:9:9: error: include of
    non-modular header inside framework module 'firebase_core.FLTFirebasePlugin':
    '/Users/abdullahkhan/Development/atlast/ios/Pods/Headers/Public/FirebaseCore/FirebaseCore.h' [-Werror,-Wnon-modular-include-in-framework-module]
    #import <FirebaseCore/FirebaseCore.h>

Xcode clearly states when something is a warning or an error and errors are usually at the end of the build logs because the build stops when an error is encountered.

Running pod install...                                           2,620ms
Running Xcode build...
Xcode build done.                                            3.5s
Failed to build iOS app
Error output from Xcode build:
↳
    objc[55804]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x204ba8188) and ??
    (0x115f0c2b8). One of the two will be used. Which one is undefined.
    objc[55804]: Class AMSupportURLSession is implemented in both ?? (0x204ba81d8) and ?? (0x115f0c308).
    One of the two will be used. Which one is undefined.
    ** BUILD FAILED **

Xcode's output:
↳
    /Users/prasathsivanathan/Desktop/Projects/Flutter/Test3/qwe/ios/Pods/GoogleUtilities/GoogleUtilities/
    Logger/GULLogger.m:130:20: warning: this old-style function definition is not preceded by a prototype
    [-Wstrict-prototypes]
    void GULResetLogger() {
                       ^
    /Users/prasathsivanathan/Desktop/Projects/Flutter/Test3/qwe/ios/Pods/GoogleUtilities/GoogleUtilities/
    Logger/GULLogger.m:135:29: warning: this old-style function definition is not preceded by a prototype
    [-Wstrict-prototypes]
    aslclient getGULLoggerClient() {
                                ^
    /Users/prasathsivanathan/Desktop/Projects/Flutter/Test3/qwe/ios/Pods/GoogleUtilities/GoogleUtilities/
    Logger/GULLogger.m:139:35: warning: this old-style function definition is not preceded by a prototype
    [-Wstrict-prototypes]
    dispatch_queue_t getGULClientQueue() {
                                      ^
    /Users/prasathsivanathan/Desktop/Projects/Flutter/Test3/qwe/ios/Pods/GoogleUtilities/GoogleUtilities/
    Logger/GULLogger.m:143:27: warning: this old-style function definition is not preceded by a prototype
    [-Wstrict-prototypes]
    BOOL getGULLoggerDebugMode() {
                              ^
    4 warnings generated.
    /Users/prasathsivanathan/Desktop/Projects/Flutter/Test3/qwe/ios/Pods/FirebaseCore/FirebaseCore/Source
    s/FIRLogger.m:61:28: warning: this old-style function definition is not preceded by a prototype
    [-Wstrict-prototypes]
    void FIRLoggerInitializeASL() {
                               ^
    /Users/prasathsivanathan/Desktop/Projects/Flutter/Test3/qwe/ios/Pods/FirebaseCore/FirebaseCore/Source
    s/FIRLogger.m:104:20: warning: this old-style function definition is not preceded by a prototype
    [-Wstrict-prototypes]
    void FIRResetLogger() {
                       ^
    2 warnings generated.
    1 error generated.
    note: Using new build system
    note: Building targets in parallel
    note: Planning build
    note: Analyzing workspace
    note: Constructing build description
    note: Build preparation complete
    warning: Capabilities for Signing & Capabilities may not function correctly because its entitlements
    use a placeholder team ID. To resolve this, select a development team in the Runner editor. (in
    target 'Runner' from project 'Runner')

Could not build the application for the simulator.
Error launching application on iPhone 8.
Prasaths-MacBook-Pro:qwe prasathsivanathan$

@abdullah432
Please just read through your own build logs
    /Users/abdullahkhan/Documents/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.5.3/ios/Classes/FLTFirebasePlugin.h:9:9: error: include of
    non-modular header inside framework module 'firebase_core.FLTFirebasePlugin':
    '/Users/abdullahkhan/Development/atlast/ios/Pods/Headers/Public/FirebaseCore/FirebaseCore.h' [-Werror,-Wnon-modular-include-in-framework-module]
    #import <FirebaseCore/FirebaseCore.h>
            ^
    1 error generated.

Xcode clearly states when something is a warning or an error and errors are usually at the end of the build logs because the build stops when an error is encountered.

I resolved the issue, It was my first time trying to run an application on Macbook. It was firestore configuration issue. I follow firestore configuration guide but later turnout, the developers are no longer need to follow that guide. I removed it and now everything is working. Thanks for your time.

Same output as @amoslai5128. And @markusaksli-nc, yes no issue with a new project, but after I try to transfer some files even from an existing project that compiled fine in my old computer onto the new project, it still gives this error after a certain point. Not sure...

Can you found the solution?

@prasath95 To find your issue. Open your project on xcode and run through there. Your build error log will show you the real problem.

I don't even have flutter installed flutter doctor -v zsh: command not found: flutter.  One of the two will be used. Which one is undefined.
objc[2291]: Class AMSupportURLSession is implemented in both ?? (0x1f23101d8) and ?? (0x118274308). One of the two will be used. Which one is undefined.

Class AMSupportURLConnectionDelegate is implemented in both

is a warning from Xcode command line tools that have been emitted for years. It's confusing, but it's never the reason your build is failing. We're tracking showing better error messages from Xcode with #22536.
I'm going to close this. You're all hitting totally different errors, and you need to file separate issues with flutter run -v output.
As @joniaiuser has pointed out, @yvngaayush and @amoslai5128 hit #70895.


Support min_tokens in sgl.gen

Motivation

Fix https://github.com/sgl-project/sglang/issues/1564. Currently, the frontend (SglSamplingParams) and backend (SamplingParams) SamplingParams are not consistent. The frontend one does not expose min_new_tokens. This PR adds necessary fields to the frontend to enable min_new_tokens be passed to the backend
Modifications

Context
The lifecycle of sampling params is as followed. The frontend side currently does not expose min_new_tokens

Add min_tokens to the frontend (sgl.gen, sgl.gen_int, sgl.gen_string)
Fill min_tokens in api, ir, and Interpreter. Enabling min_tokens to be serialized into http json object.
Example
Code:
"""
This example demonstrates how to use `min_tokens` to enforce sgl.gen to generate a longer sequence

Usage:
python3 sgl_gen_min_tokens.py
"""

import sglang as sgl

@sgl.function
def long_answer(s):
    s += sgl.user("What is the capital of the United States?")
    s += sgl.assistant(sgl.gen("answer", min_tokens=64, max_tokens=128))

@sgl.function
def short_answer(s):
    s += sgl.user("What is the capital of the United States?")
    s += sgl.assistant(sgl.gen("answer"))

if __name__ == "__main__":
    runtime = sgl.Runtime(
        model_path="/shared/public/elr-models/meta-llama/Meta-Llama-3.1-8B-Instruct/07eb05b21d191a58c577b4a45982fe0c049d0693/"
    )
    sgl.set_default_backend(runtime)

    state = long_answer.run()
    print("=" * 20)
    print("Longer Answer", state["answer"])

    state = short_answer.run()
    print("=" * 20)
    print("Short Answer", state["answer"])

    runtime.shutdown()

Result:
====================
Longer Answer The capital of the United States is Washington, D.C. (short for District of Columbia). It's located on the East Coast, along the Potomac River, and serves as the seat of the federal government. The White House, the Capitol Building, and many other important government institutions are all located in Washington, D.C.
====================
Short Answer The capital of the United States is Washington, D.C. (short for District of Columbia).

Test
Add test_gen_min_new_tokens in test_programs to ensure min_tokens is effective by checking the generated length > min_tokens
Checklist

[x] Format your code according to the Contributor Guide.
[x] Add unit tests as outlined in the Contributor Guide.
[x] Update documentation as needed, including docstrings or example tutorials.

@zhyncs @hnyls2002 can you take a look at this PR? thanks!


Difference in commands for running OMP and IMP Pruning

There seems to be no difference in the commands for using OMP and IMP pruning as mentioned in the README (except for the fact that the OMP command takes rate as an argument and the IMP command takes pruning_times as an argument:
OMP
python -u main_imp.py --data ./data --dataset $data --arch $arch --prune_type rewind_lt --rewind_epoch 8 --save_dir ${save_dir} --rate ${rate} --pruning_times 2 --num_workers 8
IMP
python -u main_imp.py --data ./data --dataset $data --arch $arch --prune_type rewind_lt --rewind_epoch 8 --save_dir ${save_dir} --rate 0.2 --pruning_times ${pruning_times} --num_workers 8
Is this a mistake? Which method would the command mentioned run by default? I am not able to determine that by looking at the code. I would like to run OMP pruning, what would be the correct command to do so?

Hi, OMP is one-shot pruning with the rewinding, i.e. it only takes the pruning process once, while IMP is the iterative one with multiple pruning times. So basically, they share the same code base. You can get the OMP process by setting the --pruning_times to 2, as the former command indicated (Sorry for the confusion, I thought the pruning_times here meant the times of the training process, we would fix it later).


ccmlib/scylla_node: stop hardcoding api_port

servel place in the code were assuming that api_port would be 10000.
some tests in the java-driver we setting api_port to a random port hence breaking some of the ccm functionality, like nodetool and wait_for_other_notice logic
Testing

[x] 🟢  https://jenkins.scylladb.com/job/scylla-staging/job/dtest-pytest-gating/480/ (Gossip - OSS)
[x] 🟢 https://jenkins.scylladb.com/job/scylla-staging/job/dtest-pytest-gating/481/ (Gossip - Enterprise)
[x] 🟢 https://jenkins.scylladb.com/job/scylla-staging/job/dtest-pytest-gating/482/ (Raft - OSS)
[x] 🟢 https://jenkins.scylladb.com/job/scylla-staging/job/dtest-pytest-gating/483/ (Raft - Enterprise)
[x] 🟢 https://jenkins.scylladb.com/job/scylla-staging/job/dtest-pytest-gating/484/ (Tablets - OSS)
[x] 🔴 https://jenkins.scylladb.com/job/scylla-staging/job/dtest-pytest-gating/485/ (Tablets - Enterprise)

now, trying the same without breaking lots of gating tests


Adding random number generation API

In conjunction with the Array API, often need some form of random number generation as well. Since this would generate Arrays and be used with Arrays the user has, there is some benefit from downstream users perspective if there is a standard API for handling random number generation.
For example in scikit-learn, the following discussion ( https://github.com/scikit-learn/scikit-learn/issues/22352#issuecomment-1125663465 ) may shed some light. A couple points that came up were whether to have a state or stateless API and NumPy's old and new APIs.

A couple points that came up were whether to have a state or stateless API and NumPy's old and new APIs.

I'd like to quote @rgommers from there (https://github.com/scikit-learn/scikit-learn/issues/22352#issuecomment-1126243581) because I feel it clarified a lot:

It's not a stateless PRNG (there's no such thing)

Yeah was just summarizing the discussion up to that point.
Stateless isn't really the right term for this I think. A more correct description might be functional as many functional languages use a similar strategy. IOW something like this
state0 = seed(42)
state1, n = randint(state0)
state2, m = randint(state1)

IOW the user is responsible for tracking the state in this model and threading it through subsequent random number generation function calls.
The other model is object oriented like NumPy's where state lives in some object that gets mutated each time a random number is generated.

We had a previous discussion on PRNG APIs, and IIRC no one was attached to the legacy numpy.random API (which most libraries currently have as their default - although TensorFlow is quite different: tf.random.Generator, also class-based).
The new NumPy API seems a little more user-friendly than the JAX APIs, and offers more functionality too. And it's no less safe - I think it's just as well possible to shoot yourself in the foot with JAX: just forget to manually create a new sub-key once. This is more of a philosophical difference: there's only one way of doing things in JAX, which is more verbose but the same for serial and parallel execution - while NumPy has a more concise way for serial (its default mode), but the user must remember to use a second method (equivalent to jax.random.split) to get the right parallel behavior.
One advantage of the JAX API is that there's only one way to do things, while NumPy has multiple ways to deal with parallelism - so more functionality, but also harder to understand or standardize. That may be partly due to providing multiple PRNG algorithms though, while JAX provides only the Threefry algorithm (not entirely true, there's a second experimental one - XLA Random Bit Generator). PyTorch for example provides Philox (which JAX also could have used) and MT19937. Now a standard doesn't have to deal with exact reproducibility across libraries, but it should allow a design that allows libraries to choose their own algorithms. I think this works with either JAX's key (which contains an algorithm selector), or NumPy's class-based API. NumPy's SeedSequence is like the seeding part of JAX's key, and should work with any algorithm too. NumPy's .jumped cannot be supported by all algorithms AFAIK.
The main issues for standardization I see are:

(a) JAX cannot adopt any class-based API,
(b) NumPy probably isn't going to be very receptive to yet another API, and
(c) it'd be a lot of work for other libraries like PyTorch to switch from their old API to any other API.

tl;dr this will not be easy to standardize

Thanks for the detailed write up Ralf! 🙏
FWIW Dask is already working on adopting the new NumPy API ( https://github.com/dask/dask/pull/9038 )
It looks like CuPy already did this in 9.0.0 with PR ( https://github.com/cupy/cupy/pull/4177 ) (though Leo should feel free to correct me)
That all being said, maybe it is worth asking if a subset of NumPy's API might be easier to adopt and if so what that looks like.
Also the other important question here is what API is going to be most useful for downstream users. Started with scikit-learn as they make a lot of use of random number generation and creating some usable API with scikit-learn would be a win. Though maybe there are other downstream libraries that would make sense as well (perhaps statsmodels? others?).

Specifically, this code:
# NumPy parallel
sseq = np.random.SeedSequence(entropy=seed)
child_seeds = sseq.spawn(4)
rngs = [np.random.default_rng(seed=s) for s in child_seeds]

would become:
rngs = rng.spawn(4)

Sorry for a bit of a tangent here, but is calling .spawn() incrementally valid? Like
rng1 = rng.spawn(1)
rng2 = rng.spawn(1)
...
rngn = rng.spawn(1)

This can come up when new children processes are created/destroyed on-demand (IOW autoscaling).

I went searching through some older notes and found this from @alextp: "I think the direction in TensorFlow is to follow JAX. Have functions for stateless random generation. They compose well. But they are not ergonomic. Layer on top of this will be something stateful. Once you do this, you introduce checkpoints etc, for determinism. So I would OK to add stateless API, but wouldn't be okay to add stateful one." That's from more than a year ago, so I don't know if it has been implemented like that, or anything changed in the meantime in TensorFlow. Maybe @edloper you can tell us?

I'm perfectly content with having 0 PRNG APIs in the standard (and far prefer 0 in the standard to having 2 in the standard). It seems like there is significant variety in what different communities need and want.

I think it's equally straightforward to write an explicitly stateful RNG system like numpy.random.Generator using JAX. Here's a prototype:
``python
import jax
class JaxGenerator:
def init(self, state):
self.state = state
def uniform(self):
self.state, key = jax.random.split(self.state)
return jax.random.uniform(key)
def spawn(self, count):
self.state, *keys = jax.random.split(self.state, count + 1)
return [JaxGenerator(key) for key in keys]
def repr(self):
return f'{type(self).name}(state={self.state})'
def jax_default_rng(seed):
return JaxGenerator(jax.random.PRNGKey(seed))
rng = jax_default_rng(0)
print(rng.uniform())  # 0.10536897
print(rng.uniform())  # 0.2787192
print(rng)  # JaxGenerator(state=[2384771982<PHONE_NUMBER>])
rng2 = JaxGenerator(rng.state)
print(rng2)  # JaxGenerator(state=[2384771982<PHONE_NUMBER>])
rngs = rng.spawn(2)
print(rngs)  # [JaxGenerator(state=[1777981902<PHONE_NUMBER>]), JaxGenerator(state=[ 669635267<PHONE_NUMBER>])]

From a JAX design perspective, stateful RNGs like this are not encouraged, because JAX's function transforms will break if you pass stateful objects into them. But you can still safely use this sort of API with JAX, as long as you're careful to create Generator objects _inside_ pure functions, e.g.,

```python
@jax.jit
@jax.vmap
def batched_random_uniform(seed):
  return jax_default_rng(seed).uniform()

print(batched_random_uniform(jnp.arange(5)))
# DeviceArray([0.10536897, 0.12568676, 0.4336251 , 0.47652578, 0.7844808 ],            dtype=float32)

Or explicitly keeping track of updated RNG state:
@jax.jit
def explicit_state_random_uniform(state):
  rng = JaxGenerator(state)
  sample = rng.uniform()  # must happen *before* calculating new_state
  new_state = rng.state
  return new_state, sample

state = jax.random.PRNGKey(0)
state2, sample = explicit_state_random_uniform(state)
print(state2, sample)

In fact, Haiku, which is one of the most popular neural net libraries in JAX, does something very similar with haiku.next_rng_key.
These stateful interfaces are perhaps easier to misuse with JAX's functional transforms than pure functions, but are still a major improvement over global state.

To bridge the gap between NumPy's and JAX's random number APIs, I would suggest slightly extending NumPy's API so it's easier to be explicit about state. Namely, we should add the spawn() method, and also support directly accessing/setting .state on Generator objects, rather than only on BitGenerator.
Here's my minimal wrapper of NumPy's RNG API with these extensions, to match the JAX API above:
import numpy as np

class NumpyGenerator:

  def __init__(self, state):
    # TODO: avoid initializing this dummy Generator/BitGenerator?
    self._rng = np.random.default_rng()
    self.state = state

  def uniform(self):
    return self._rng.uniform()

  def spawn(self, count):
    entropy = self._rng.integers(2**63)  # TODO: better entropy?
    sseq = np.random.SeedSequence(entropy)
    child_seeds = sseq.spawn(count)
    return [numpy_default_rng(seed) for seed in child_seeds]

  @property
  def state(self):
    return self._rng.bit_generator.state

  @state.setter
  def state(self, value):
    self._rng.bit_generator.state = value

  def __repr__(self):
    return f'{type(self).__name__}(state={self.state})'

def numpy_default_rng(seed):
  return NumpyGenerator(np.random.default_rng(seed).bit_generator.state)

rng = numpy_default_rng(0)
print(rng.uniform())  # 0.6369616873214543
print(rng.uniform())  # 0.2697867137638703
print(rng)  # NumpyGenerator(state={'bit_generator': 'PCG64', 'state': {'state':<PHONE_NUMBER>56486183636066271097634410721, 'inc':<PHONE_NUMBER>7582989555478159403783844777}, 'has_uint32': 0, 'uinteger': 0})

rng2 = NumpyGenerator(rng.state)
print(rng2)  # NumpyGenerator(state={'bit_generator': 'PCG64', 'state': {'state':<PHONE_NUMBER>56486183636066271097634410721, 'inc':<PHONE_NUMBER>7582989555478159403783844777}, 'has_uint32': 0, 'uinteger': 0})

rngs = rng.spawn(2)
print(rngs)  # [NumpyGenerator(state={'bit_generator': 'PCG64', 'state': {'state':<PHONE_NUMBER>60684748498847325894109072011, 'inc':<PHONE_NUMBER>43570234404080558697197945801}, 'has_uint32': 0, 'uinteger': 0}), NumpyGenerator(state={'bit_generator': 'PCG64', 'state': {'state':<PHONE_NUMBER>55839246335449654370252341036, 'inc':<PHONE_NUMBER>95095609630857841553467033115}, 'has_uint32': 0, 'uinteger': 0})]

It's nice to see the alternative wrapping for perspective

Namely, we should add the spawn() method, and also support directly accessing/setting .state on Generator objects, rather than only on BitGenerator.

Am curious how much work it would be to add these to NumPy?

Not much.

One note regarding JAX:

JAX does seem to have a few gotchas with seed creation, it can't deal with high-entropy seeds apparently (at least in 0.2.27, released 18 Jan 2022):

JAX disables 64-bit data types by default, but you can enable this if you wish to use them:
https://jax.readthedocs.io/en/latest/notebooks/Common_Gotchas_in_JAX.html#double-64bit-precision
If you enable 64-bit values, then 64-bit seeds will be fine.

One other thing to point out: the JAX docs comparing to NumPy are wildly outdated/unfair, they use the non-recommended (global state) way of using the legacy API.

I'm happy to update these if you think it would be helpful. Whether the seed is global or a mutated rng object, I think the bulk of the discussion still holds.

I think the recommendation from the TF side would still be to use the stateless API.  (As mentioned above, a stateful API can be layered on top of the stateless one, if desired.)

We can build shim APIs across either implementation to get stateless or stateful APIs, but the way that each shim API needs to be implemented has its own costs, constraints, and tradeoffs. I would suggest exploring those implementation strategies and how well they actually support a set of use cases before relying on the mere existence proof of shim APIs as a reason to go ahead and standardize on one API instead of another. What would the shim APIs actually allow us to do?
Let's say a stateless API becomes the standard. data = xp.uniform(key, low, high), etc. We can certainly build a stateful shim API on top that just uses the standard and manages the key splitting internally. What does this shim let us do? Can I write some Monte Carlo routines using that stateful shim API (completely ignorant of JAX) and still use that routine in JAX code? @shoyer suggests that has limitations. It seems like I'd be taking all the compromises necessary to make a stateless API without getting the corresponding benefits. Splittable PRNG schemes don't grow on trees, and are difficult to design robustly; the API standard would have to define an implementation as well, and I don't think I can recommend JAX's after investigating it. I can go into that in more detail here or somewhere else, if anyone would like.
Vice versa, we can definitely make a stateless API on top of the current implementation of np.random with just a bit of manual manipulation of SeedSequence inside the xp.split() function (SeedSequence can also be minorly rewritten to support more efficient pure-function splitting). Now that might allow me, a pure numpy user, to use a sampling routine that was written with JAX in mind (but otherwise restricted to the xp API). But making the stateful API standard just to allow an implementation to wrap a stateless API around it doesn't solve JAX's problem of not wanting to have a stateful API implementation in the first place (and you should not have to, IMO).
Again, I'm pretty happy for there to be no API standard on this subject. I would be interested in talking more on how to hand off from one style of API to the other, though. There's room in the SeedSequence design space to make easier.

I can go into that in more detail here or somewhere else, if anyone would like.

I vote for presenting them here, please.

It's, uh, getting long. Not because my list of issues is long, just that I am long-winded and am including a lot of background.

Apologies
This is long, and everyone has my apologies for that, but I want to make sure the background is laid out.
Introduction
So first off, I want to say that the issues I am going to lay out don't make JAX's PRNG a bad one for all purposes. JAX has a fairly specific usage profile, and these are limitations that can be usefully lived within, if one is willing to. But these are limitations that I would hesitate to propagate up to general use amongst all Array API users, particularly in contexts where one doesn't get the benefits paid for by those limitations. I will mention a number of issues that I have with specific implementation choices that are in principle addressable. I don't really count those as determinative (they can indeed be fixed while still maintaining the style of API). But I do think they can be taken, as a whole, that imposing this style of API places some serious constraints on implementations that is probably out of scope of this standardization effort.
Reviewing JAX's Design
To review, JAX's PRNG API is based around explicit splitting of the PRNG state and then pure functions to generate possibly-large arrays of data from the leaf keys. The split(prng_key, num=2) function takes prng_key and derives num new PRNG keys from it. Generally, you'll take the leftmost PRNG key and keep it around for later and then pass the other split PRNG keys down to functions (either those in jax.random or others that will do further split()s). The core PRNG algorithm for actually drawing random bits in those jax.random functions comes from Parallel Random Numbers: As Easy as 1, 2, 3 ([Random123]). In particular, it uses the threefry2x32 weak cryptographic block cipher as a primitive. This is a block cipher that takes a 64-bit plaintext block and encrypts it using the given 64-bit cipher key to get a 64-bit ciphertext. For this variant, all of the 64-bit blocks are broken up into 2 32-bit words (hence the name) so we can use cheap 32-bit arithmetic.
cipher_text = threefry2x32(cipher_key, plain_text)

This primitive is a keyed bijection: given a fixed cipher_key, there is an invertible one-to-one mapping between plain_text and cipher_text. Changing the cipher_key, you select a different bijection.
For the core PRNG algorithm to draw random bits, we use a simple incrementing counter as each plaintext block. This is nice for GPUs because we can create that counter array and then have the GPU run threefry2x32 in parallel across the whole thing. The JAX implementation of threefry_random_bits() which does this operation has some quirks that don't make too much of a difference for the quality of the pseudorandom numbers from a single call, but will show up a bit later when we talk about splitting.
In particular, instead of incrementing the counter in 64-bit blocks, it creates a 32-bit counter array, splits it in half to use the first half as the upper 32-bit word and the second half as the lower 32-bit word. That's a bit wasteful (you could instead just use zeros(rem//2) and lax.iota(rem//2) for rem requested words instead), but they are valid inputs. The two arrays which are output (being separately the upper and lower words of the cipher_text blocks) are then concatenated together end-to-end instead of reassembling those words. I assume this is done because it's cheaper to concatenate than to interleave again. This is fine as far as it goes; it doesn't hugely affect the quality of numbers coming out of one jax.random.uniform() call, for example. But it does wreck the bijection properties, which will become important when we talk about implementation choices for split().
So far, so good. Despite that quirk, I have only one qualm with the core PRNG scheme for drawing bits in the jax.random functions: 64 bits is quite small. I consider 128-bit PRNGs to be de rigeur today, particularly in contexts where we are talking about large amounts of parallelism (and the JAX API enforces a large amount of parallelism). By itself, that doesn't have to be too much of an issue, and you get the benefit of a cheaper PRNG by using this smaller variant. But it does place a limit on the number of jax.random calls that you can make with different PRNG keys. Unless if you have a tightly controlled mechanism for allocating those PRNG keys to ensure that they are distinct, you are subject to Birthday Collisions, which happen at around the square-root of the state space size, in this case, about 2**32. That's a lot! But you probably want to stay well under that, maybe even the square root of the Birthday Bound (2**16, which is not a lot). Big distributed reinforcement learning runs should definitely be wary.
The mechanism that JAX uses to split() reuses this implementation of threefry_random_bits(). For the moment, let's just talk about split(prng_key, num=2): it's convenient to label the two outputs as "left" and "right". In fact, let's define two operations left() and right() as follows:
def left(prng_key):
    return jax.random.split(prng_key)[0]

def right(prng_key):
    return jax.random.split(prng_key)[1]

None of the following really depend on restricting ourselves to that, but it's handy to talk about things.
So we use the current prng_key to encrypt the 2 64-bit counter blocks and get out 2 64-bit ciphertexts to use as the left and right keys (modulo the quirks discussed above). This follows the general treatment in Splittable pseudorandom number generators using cryptographic hashing ([Splittable2013]) which uses the full-strength cryptographic Threefish block cipher ([Random123]'s Threefry is a weakened variant of this cipher). That is, we use the old key as the cipher_key, encrypt a counter block that's different whether it's the left() or right() branch, and take the resulting cipher_text as the next prng_key for that branch. So we're feeding back the output of this algorithm as an input to the next iteration. This is a standard construction for cryptographic hashes. In fact, people do use this construction as a way to make sequential PRNGs, essentially keep appending 0 blocks to a cryptographic hash and yielding the internal state of that hash as the random bits (equivalently, keep calling left() on its own output).
It has nice properties for cryptographic purposes, but it has some significant drawbacks for PRNGs used for scientific and statistical purposes. left() defines a non-invertible mapping (right() defines a different one). As discussed above, a block cipher defines a keyed bijection: fixing cipher_key, there is a one-to-one mapping between the plain_text and cipher_text. But if instead you fix plain_text (i.e. we use the same counter block in left() every time), then the mapping from cipher_key to cipher_text is many-to-one, and thus non-invertible. This is important in cryptography; if we could invert the cipher_text to get the cipher_key, then the cipher would allow an attacker to recover the cipher_key in a variety of scenarios. But iterations of non-invertible mappings have some unfortunate effects for scientific PRNGs where those security properties don't matter and other properties become more desirable.
Damn Statistics
While there are few guarantees without knowing something about the structure of the mapping, you can calculate some useful statistics about the population of random non-invertible mappings. Particularly since the left() iteration is constructed from a (weak) block cipher, it is about as good of a random sample from that population as any. @imneme has a good pair of articles about the statistics of non-invertible mappings and also of invertible mappings. The state space of a random non-invertible mapping is not good for a scientific PRNG. You have a forest of trees that filter down to roots that are on cycles of various sizes. When a cycle completes, obviously, you have a Birthday Collision and start repeating values. The "rho length" statistic (the average number of iterations until a repeat is found) reflects that. Increasing the state space reduces the chance of these collisions predictably.
However, such state spaces are inherently biased and non-uniform, and this doesn't go away as the state space increases. The states that follow states which have in-degrees greater than 1 will be overrepresented if you repeat with different initial seeds. States on small cycles will also be overrepresented. Small cycles will have big trees attached to them. A large fraction of states (on the order of half) are not reachable from any other state; you have to start with them as the initial seed to ever observe them. This is particularly an issue when you reduce the initial seeding space to just 32 bits, as is the default configuration of JAX. I will never recommend a PRNG based on non-invertible mappings for scientific use.
So far, I've talked about iterating left(left(left(...))). Why do I care about this, even though we are going to be using the right() branch, too? Well [Splittable2013] also throws up its hands to say that talking about things like periods don't make sense for splittable PRNGs. After all, you are guaranteed to get a collision (by a pigeonhole argument) within only 64 steps down a full binary tree exploring all of the left() and right() branches (which sounds bad, but I'm not particularly concerned). But in practice, our trees are very left-heavy due to certain conventions (we tend to reserve the left-most key to pass on in the data-flow for further splitting and use the right key(s) to pass to be consumed in other functions). After all, to translate a serial PRNG code that calls multiple methods in sequence:
x = rng.uniform(0, 1)
y = rng.uniform(10, 20)
z = rng.uniform(-1, 1)

# -->

key, subkey = split(key)
x = uniform(subkey, 0, 1)
key, subkey = split(key)
y = uniform(subkey, 10, 20)
key, subkey = split(key)
z = uniform(subkey, -1, 1)

So the iteration of left() is kind of important to characterize, IMO. There are things we can say about it, and maybe improve it.
So I did construct a PRNG out of repeated iteration of left() and fed its output to PractRand. And we can observe that we do in fact find one of those cycles and fail right around the Birthday Bound (2**35 bytes corresponds to 2**32 iterations yielding 8-byte keys).

PractRand output for jax.random.split(key)[0]
❯ ./jax_keys.py
WARNING:absl:No GPU/TPU found, falling back to CPU. (Set TF_CPP_MIN_LOG_LEVEL=0 and rerun for more info.)
RNG_test using PractRand version 0.93
RNG = RNG_stdin64, seed = 0x6ae890b2
test set = expanded, folding = extra

rng=RNG_stdin64, seed=0x6ae890b2
length= 8 megabytes (2^23 bytes), time= 2.6 seconds
  no anomalies in 694 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 16 megabytes (2^24 bytes), time= 7.8 seconds
  no anomalies in 747 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 32 megabytes (2^25 bytes), time= 15.6 seconds
  no anomalies in 796 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 64 megabytes (2^26 bytes), time= 28.1 seconds
  no anomalies in 843 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 128 megabytes (2^27 bytes), time= 50.3 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/32]Gap-16:B                 R=  -4.7  p =1-5.0e-4   unusual
  ...and 890 test result(s) without anomalies

rng=RNG_stdin64, seed=0x6ae890b2
length= 256 megabytes (2^28 bytes), time= 92.0 seconds
  no anomalies in 938 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 512 megabytes (2^29 bytes), time= 171 seconds
  no anomalies in 985 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 1 gigabyte (2^30 bytes), time= 326 seconds
  no anomalies in 1039 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 2 gigabytes (2^31 bytes), time= 628 seconds
  no anomalies in 1092 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 4 gigabytes (2^32 bytes), time= 1237 seconds
  no anomalies in 1151 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 8 gigabytes (2^33 bytes), time= 2439 seconds
  no anomalies in 1224 test result(s)

rng=RNG_stdin64, seed=0x6ae890b2
length= 16 gigabytes (2^34 bytes), time= 4831 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/64]BCFN_FF(2+2,13-1,T)      R=  +9.4  p =  1.6e-4   unusual
  ...and 1300 test result(s) without anomalies

rng=RNG_stdin64, seed=0x6ae890b2
length= 32 gigabytes (2^35 bytes), time= 9622 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN_FF(2+0,13-0,T)               R= +41.3  p =  1.3e-21    FAIL !!
  BCFN_FF(2+1,13-0,T)               R= +33.9  p =  1.1e-17    FAIL !
  BCFN_FF(2+2,13-0,T)               R= +44.0  p =  4.4e-23    FAIL !!
  BCFN_FF(2+3,13-0,T)               R= +48.1  p =  3.1e-25    FAIL !!
  BCFN_FF(2+4,13-0,T)               R= +44.8  p =  1.6e-23    FAIL !!
  BCFN_FF(2+5,13-0,T)               R= +48.1  p =  3.0e-25    FAIL !!
  BCFN_FF(2+6,13-0,T)               R= +40.9  p =  2.2e-21    FAIL !!
  BCFN_FF(2+7,13-1,T)               R= +29.0  p =  4.5e-15    FAIL
  BCFN_FF(2+8,13-1,T)               R= +30.6  p =  6.1e-16    FAIL
  DC6-9x1Bytes-1                    R=+230.8  p =  4.5e-155   FAIL !!!!!

[RTK: snipping 630 more failures; this is definitely a cycle]

  ...and 717 test result(s) without anomalies

As mentioned in the article, increasing the state size does help with this. You can hold off those collisions more and more with larger state sizes. You can hide this flaw with larger state spaces, as done in the original [Splittable2013] paper, which uses a full-strength 256-bit block cipher.
Just to be sure that this wasn't trivially fixable by fixing the aforementioned quirk, I retried this a version that did the threefry2x32 manually with a fixed plaintext of 0. This also failed at 2**36 bytes (about the same, essentially), so confirming that the general scheme of using the old prng_key as the cipher_key is still a non-invertible mapping.
Alternatives
There are alternatives, which are to use invertible mappings to define left() and right() (and further for num > 2). Random invertible mappings have much nicer expected properties. Every state is on a cycle and has an in-degree of 1. Given a uniform distribution of root seeds, you have an equal chance of seeing any state (if you don't draw enough to hit a cycle). We have a good idea of the distribution of sizes of those cycles. Very, very roughly, in expectation, half of the states are on the biggest cycle, 1/4 are on the next one, 1/8 on the next one and so on. There still are small cycles, but the chance that your initial seed actually places you on one goes down as the size does. For 64-bit states, the chance of your root seed being on a cycle less than 2**32 (that Birthday Bound) is 1/2**(64-32) == 1/2**32, a pretty tiny probability. Whereas for the non-invertible mapping used in JAX, your chance of hitting a repeat in 2**32 draws is about half.
How do we construct useful invertible mappings? One way is to use SeedSequence, whose construction is conceptually very similar to the splitting mechanism here. Instead of a cryptographic hash, it folds data into the internal pool using invertible operations such that bijections are maintained where possible. So repeated iterations of left() or right() will at least have the invertible mapping statistics. There is also an MCG in the middle there driving it, much like SFC64 incorporates a 64-bit counter. That has the effect of creating a minimum cycle size of at least 2**28 (I think) when we repeatedly take the leftmost spawn child.
So for example, I have here a PractRand run where I use a tiny 32-bit pool size (though this is a little misleading as the MCG has to be tracked as well, so it's really a 64-bit state size). I run it like I did the JAX splitting test, where I just repeatedly fold in the 0 counter.

PractRand output for seed_sequence.spawn(1)[0]
❯ ./ss_split.py -p 1
RNG_test using PractRand version 0.93
RNG = RNG_stdin64, seed = 0x64fd6e66
test set = expanded, folding = extra

rng=RNG_stdin64, seed=0x64fd6e66
length= 1 megabyte (2^20 bytes), time= 2.1 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/32]FPF-14+6/32:cross        R=  +6.5  p =  2.8e-5   mildly suspicious
  ...and 530 test result(s) without anomalies

rng=RNG_stdin64, seed=0x64fd6e66
length= 2 megabytes (2^21 bytes), time= 6.2 seconds
  no anomalies in 585 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 4 megabytes (2^22 bytes), time= 12.4 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/64]FPF-14+6/32:cross        R=  +6.0  p =  7.7e-5   unusual
  ...and 640 test result(s) without anomalies

rng=RNG_stdin64, seed=0x64fd6e66
length= 8 megabytes (2^23 bytes), time= 22.8 seconds
  no anomalies in 694 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 16 megabytes (2^24 bytes), time= 41.6 seconds
  no anomalies in 747 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 32 megabytes (2^25 bytes), time= 77.3 seconds
  no anomalies in 796 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 64 megabytes (2^26 bytes), time= 147 seconds
  no anomalies in 843 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 128 megabytes (2^27 bytes), time= 280 seconds
  no anomalies in 891 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 256 megabytes (2^28 bytes), time= 544 seconds
  no anomalies in 938 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 512 megabytes (2^29 bytes), time= 1066 seconds
  no anomalies in 985 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 1 gigabyte (2^30 bytes), time= 2106 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/64]Gap-16:B                 R=  -5.6  p =1-7.8e-5   unusual
  ...and 1036 test result(s) without anomalies
rng=RNG_stdin64, seed=0x64fd6e66
length= 2 gigabytes (2^31 bytes), time= 4204 seconds
  no anomalies in 1092 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 4 gigabytes (2^32 bytes), time= 8436 seconds
  no anomalies in 1155 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 8 gigabytes (2^33 bytes), time= 16916 seconds
  no anomalies in 1224 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 16 gigabytes (2^34 bytes), time= 33704 seconds
  no anomalies in 1302 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 32 gigabytes (2^35 bytes), time= 67929 seconds
  no anomalies in 1358 test result(s)

rng=RNG_stdin64, seed=0x64fd6e66
length= 64 gigabytes (2^36 bytes), time= 136044 seconds
  no anomalies in 1434 test result(s)

And it's still going strong past the point that the JAX one failed. Now, to be fair, this definitely created a duplicate entropy pool state somewhere along the way, which would have seeded an identical copy of the BitGenerator if it were used. Only the 32-bit pool plays a role in the seeding of the BitGenerator, not the MCG. If we actually drew a lot of numbers from each BitGenerator, PractRand would have found that out. It's still separately important that generated seeds that go into the number-generating API calls still have an acceptable size to avoid collisions.
Currently, SeedSequence is written statefully. It keeps track of the number of spawned children requested of it so that repeated calls return freshly independent SeedSequences. It is also somewhat wasteful in keeping an explicit representation of the path down the split tree from the root entropy. Neither of these implementation choices are necessary to the algorithm. Here is an implementation with an idempotent .split() method.
Now maybe you don't want to do all that. Maybe you don't like the expense of all of those multiplications; maybe you don't like that extra MCG hanging around taking up space. You have a keyed bijection already: threefry2x32(). But to get a bijection, you have to reverse the roles of the old prng_key and the counter block. Instead of using the old prng_key as the cipher_key and the counter block as the plain_text, flip it.
new_prng_key = threefry2x32(counter, old_prng_key)

Now there is a bijection between the two prng_keys because that's what a block cipher does. Running the repeated left(left(left(...))) iteration as a PRNG is still going strong long past where the original failed.

PractRand output for a ThreeFry2x32 bijection scheme
❯ ./jax_keys.py --variant bijective
WARNING:absl:No GPU/TPU found, falling back to CPU. (Set TF_CPP_MIN_LOG_LEVEL=0 and rerun for more info.)
RNG_test using PractRand version 0.93
RNG = RNG_stdin64, seed = 0x7a16bac8
test set = expanded, folding = extra

rng=RNG_stdin64, seed=0x7a16bac8
length= 8 megabytes (2^23 bytes), time= 2.5 seconds
  no anomalies in 694 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 16 megabytes (2^24 bytes), time= 7.6 seconds
  Test Name                         Raw       Processed     Evaluation
  BCFN_FF(2+1,13-5,T)               R= +12.1  p =  6.5e-5   unusual
  ...and 746 test result(s) without anomalies

rng=RNG_stdin64, seed=0x7a16bac8
length= 32 megabytes (2^25 bytes), time= 15.2 seconds
  no anomalies in 796 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 64 megabytes (2^26 bytes), time= 27.5 seconds
  no anomalies in 843 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 128 megabytes (2^27 bytes), time= 49.1 seconds
  no anomalies in 891 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 256 megabytes (2^28 bytes), time= 89.2 seconds
  no anomalies in 938 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 512 megabytes (2^29 bytes), time= 166 seconds
  no anomalies in 985 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 1 gigabyte (2^30 bytes), time= 318 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/16]Gap-16:B                 R=  -4.8  p =1-3.8e-4   unusual
  ...and 1035 test result(s) without anomalies

rng=RNG_stdin64, seed=0x7a16bac8
length= 2 gigabytes (2^31 bytes), time= 616 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/64]FPF-14+6/4:all           R=  -4.8  p =1-2.8e-4   unusual
  ...and 1091 test result(s) without anomalies

rng=RNG_stdin64, seed=0x7a16bac8
length= 4 gigabytes (2^32 bytes), time= 1211 seconds
  no anomalies in 1155 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 8 gigabytes (2^33 bytes), time= 2405 seconds
  no anomalies in 1229 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 16 gigabytes (2^34 bytes), time= 4777 seconds
  no anomalies in 1303 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 32 gigabytes (2^35 bytes), time= 9522 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low4/64]BCFN_FF(2+1,13-0,T)      R=  +9.5  p =  1.3e-4   unusual
  ...and 1359 test result(s) without anomalies

rng=RNG_stdin64, seed=0x7a16bac8
length= 64 gigabytes (2^36 bytes), time= 18960 seconds
  Test Name                         Raw       Processed     Evaluation
  [Low1/32]BCFN_FF(2+0,13-0,T)      R=  +8.5  p =  4.4e-4   unusual
  [Low4/32]FPF-14+6/32:all          R=  +5.5  p =  1.3e-4   unusual
  ...and 1429 test result(s) without anomalies

rng=RNG_stdin64, seed=0x7a16bac8
length= 128 gigabytes (2^37 bytes), time= 37487 seconds
  no anomalies in 1506 test result(s)

rng=RNG_stdin64, seed=0x7a16bac8
length= 256 gigabytes (2^38 bytes), time= 74451 seconds
  no anomalies in 1567 test result(s)

Now, that's neat (I think). But we don't just do iterations of left(). We mix up left() and right() (and more). Each of those are different bijections. There is still a chance that a right() call will give you an earlier-seen state. While the structure provided by bijections lets you have a better safety factor on parts of the split tree (important parts, IMO), it doesn't help much for arbitrarily mixed operations. With the statistics of random bijections, I think you could probably derive more accurate bounds, but even with SeedSequence, we tell you to rely on the Birthday Bound in any case. But you still get the statistical benefits of using bijections.
Conclusion
I want to close with a quote from the conclusion of Evaluation of Splittable Pseudo-Random Generators:

Conventional wisdom in computational statistics and Monte Carlo simulation indicate that one PRNG cannot suit every purpose. Different applications have different priorities, and calling for different trade-offs between sequence length, distribution, running time, and theoretical guarantees.

The JAX style of PRNG is a very specific flavor of splittability and pure functionalism. There are splittable PRNGs that are not functional, and there are pure functional APIs that don't force explicit splitting (and of course, useful PRNG schemes that are neither). JAX has a specific profile of needs that make this specific flavor of PRNG very appealing for its use cases. However, JAX's profile is not universal and should not define the API standard, which has a broad scope. For that matter, the profile behind the current design of np.random is not universal either.
I am perfectly content with this functionality not being standardized by the Array API.

It's probably also worthwhile to tie this back to how downstream users would leverage this API.
Going back to scikit-learn, many APIs take a RandomState object (for example). This of course is referencing the old NumPy API, but that's not really the point (as NumPy's new API is also object-based). Instead the point is scikit-learn depends on having an object to pass state around and generate random numbers from different distributions (reusing the example above). Though this isn't unique to scikit-learn, statsmodels also does this (for example).
Given the current usage of the object API by these libraries, it is relatively straightforward to see how they would adopt an object API if added to the spec.
What is less clear is how they would leverage a functional API. If we are interested in evaluating that option, it would be worth seeing how that API would be used in a downstream library. Should add we probably want to look at something a bit more general than JAX's current API given it is tied to a specific class of PRNGs as pointed out in a few places in this issue already.

Another way to think about it is that all PRNG schemes have a certain finite amount of safety margin, and it is a consumable resource. Just serially drawing arrays of numbers from it consumes a small amount of that safety margin. Splits, no matter how implemented, consume a lot of that safety margin.
My general recommendation is to only split when you have to, at the place where you need parallelism. In JAX programs, that's everywhere, because JAX is awesome at enabling incredible amounts of parallelism without having to explicitly code it. A splitting-central PRNG scheme fits very well in that environment. The parallelism pays back what you spent in terms of the lowered safety margin. But for most of the other Array API implementations, forcing that amount of splitting is forcing everyone to live with that impaired safety margin for no corresponding benefit.
The issue is not merely the ergonomics of the API. Simply wrapping a stateful API around a splitting-central stateless API does not restore the safety margin built into the more typical stateful PRNG implementations.

One other thing to point out: the JAX docs comparing to NumPy are wildly outdated/unfair, they use the non-recommended (global state) way of using the legacy API.

I'm happy to update these if you think it would be helpful. In my experience, the global default rng is how most users use numpy's random APIs, despite more recent changes to recommendations in numpy's docs, so it's a useful way to introduce how JAX differs. As for the JAX discussion, whether the seed is global or a mutated rng object, I think the bulk of the discussion (regarding side effects, implicit vs. explicit statefulness / pure functions) still holds true.

Thanks @jakevdp. I think it would be nice to either update it, or at least add a note saying that the section talks about legacy APIs and that numpy has had a default_rng/Generator API that has parallel capabilities and statistical properties & performance similar to (or even better than, xref Robert's analysis above) JAX since 2019. A sentence like "The Mersenne Twister PRNG is also known to have a number of problems, it has a large 2.5Kb state size, which leads to problematic initialization issues. It fails modern BigCrush tests, and is generally slow." looks like it is solely designed to say "see how much better JAX is than NumPy here".

I do think it is worth talking about SeedSequence spawning there too (even if you do have to address the legacy np.random.* stuff as well). It is a place where modern numpy is quite similar to JAX. The recommended ways to achieve parallelism are the basically same in both; the major difference is when and how much parallelism is enforced by the API (and enabled by the rest of JAX).
The other thing I would remove is the discussion about the sequential-equivalent guarantee. We have none. If there is a place in our docs that says otherwise, please let me know so I can expunge it. Something like that might have crept into some of the examples, which were mostly written by third-party contributors who might have assumed that the behavior they observed was guaranteed for some reason. Most methods do happen to behave that way because it's generally the easiest thing to implement with a serial PRNG, but we do not guarantee anything about it. For example, if we had a distribution where there was an algorithm that worked well in bulk but had a costly one-time setup and another that worked better for small numbers at a time, we reserve the right to implement a switchover point.

Hi @rkern - thanks for those comments. Just to be clear, the doc you linked to is not really "documentation" per se, but rather a years-old design doc meant to lay-out the motivation for JAX's initial PRNG design (which has evolved since then, and will continue to evolve). For that reason, I don't think I will be updating it, but rather will add a disclaimer at the top mentioning its intent. How does that sound?

There might be a couple of other opportunities to standardize something, but it's not particularly clear to me what it would actually enable across implementations as different as numpy and JAX, say.
So for example, we could say, informationally, that there are 3 basic flavors of PRNG state flow that an implementation could have, but the standard doesn't specify any one or any of the details about each.

Stateful Generator with distribution methods (x = rng.uniform(0, 1)) (implemented by numpy, dask, maybe others)
JAX-like splitting-central pure functional (key, subkey = split(key); x = uniform(subkey, 0, 1), etc.) (implemented by JAX)
Copy-and-return-iterated pure functional (rng, x = uniform(rng, 0, 1)) (not implemented by anyone that I'm aware of)

But it could standardize on a basic list of methods/functions that an implementation ought to have, along with the semantics of the other arguments not related to the PRNG state flow, and allowing for extra implementation-specific arguments (dask adds chunks=, for example). In particular, in the transition from RandomState.randint() to Generator.integers(), we fixed a number of corner cases that had made it hard to specify the full range of np.uint64, for example. It would be a really good idea for all of the implementations to also implement that logic and not suffer from the naive implementation mistakes I made in randint().
This is not likely actually enable one to write significant backend-agnostic code. So the Array API standard might not be the best place for that. Maybe a SPEC is a better instrument? The Array API does have the advantage of having convened the right people.

@jakevdp Sure, but it's also in the tutorial.

Thanks for pointing that out. To be honest, it's news to me that numpy does not provide a sequential-equivalent guarantee in it's pseudo-random values. I've spent the better part of the last couple decades assuming it did.

Is there a place in the numpy docs that mentions the lack of a sequential equivalent guarantee in pseudo-random numbers? I'd like to link to it in the discussion. If not, I can link to this thread.

On Wed, Jun 8, 2022 at 2:46 PM Jake Vanderplas @.***>
wrote:

Is there a place in the numpy docs that mentions the lack of a sequential
equivalent guarantee in pseudo-random numbers? I'd like to link to it in
the discussion. If not, I can link to this thread.

This is the closest I found: https://numpy.org/neps/nep-0019-rng-policy.html
-Edward

—
Reply to this email directly, view it on GitHub
https://github.com/data-apis/array-api/issues/431#issuecomment-1150270761,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMFVDFX6UK2GJFQV7I4YELVODTBLANCNFSM5V3YMQ5Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks for the pointers - in that case I think I will link to this thread, because it seems more direct than linking to a long doc and pointing out the omission of the topic in question.

@froystig That's all good to hear! Like I said in my introduction, I didn't consider any of those details as immutable black marks against JAX or the overall design, but they did serve as a way to talk about the similarities with SeedSequence, the kinds of improvements that are left in the design space (bijections as far as the eye can see!), and what limits are still fundamental to a splitting-centric design (the Birthday Bound).

I don't know all of JAX's rewriting capabilities, but I don't think it can handle whatever it needs to do to make the Generator-like API work with the same reordering benefits.
data1 = rng.uniform()
data2 = rng.uniform()

What it would have to do here is recognize that rng is a Generator, so the special case applies, and magically under the covers transform the code to do a couple of splits up at the top before any of the uniform() calls.
And even if JAX did have technical capability of doing so, I'm not sure that they want their users to mix mental models like that. It's hard enough to teach people to use one consistently.

they did serve as a way to talk about the similarities with SeedSequence, the kinds of improvements that are left in the design space (bijections as far as the eye can see!), and what limits are still fundamental to a splitting-centric design (the Birthday Bound).

@rkern Absolutely – I understood that and it makes sense. I only meant to share some related thoughts and work that's in progress, mostly as an aside. Your comments are super valuable, and this thread is a rare opportunity for us on JAX. Thank you!

I'm the author of tf.random.Generator and several docs (e.g. this and this). TF RNG's current status is using stateless RNGs (similar to JAX's) as the underlying engine, and a mutable counter (implemented as a tf.Variable) to advance the RNG state (code). tf.random.Generator is basically stateless RNGs + a mutable counter. It works well in TF because TF is more friendly to mutability than JAX.
Unlike JAX, tf.random.Generator supports but doesn't do splitting unless asked to (code). It just does counter increment in common (sequential) cases (code). I feel splitting is more wasteful of the (key, counter) space than counter increment, but I'm not sure.
TF only supports counter-based RNG algorithms and has no plan to support non-counter-based ones.

Yes, I can confirm that splitting is more profligate of the state space than the counter increment, especially when you constrain yourself to 64-bit keys, if I'm reading the code correctly. I think the same math from my analysis of JAX's PRNG splitting applies (the only real difference is that tf.random.Generator will generate the new keys at whatever counter it is currently on rather than JAX always starting at 0, but that doesn't affect the non-invertible mapping argument).

From a user perspective, specifically someone writing libraries which want to support arbitrary array types, I don't see the problem with carrying the random state separately from the random namespace. It is not the slickest interface, but it can be implemented today:
# file: random_numpy.np

def standard_normal(rng, shape=()):
    return rng, rng.standard_normal(size=shape)

def poisson(rng, lam, shape=()):
    return rng, rng.poisson(lam, size=shape)

# file: random_jax.py

from jax import random

def standard_normal(key, shape=()):
    key, subkey = random.split(key)
    return key, random.normal(subkey, shape)

def poisson(key, lam, shape=()):
    key, subkey = random.split(key)
    return key, random.poisson(subkey, lam, shape)

# file: test.py

def random_namespace(rs):
    import sys
    if 'numpy' in sys.modules:
        import numpy as np
        if isinstance(rs, np.random.Generator):
            return __import__('random_numpy')
    if 'jax' in sys.modules:
        import jax
        if isinstance(rs, jax.Array):
            return __import__('random_jax')

def my_function(lam, rs):
    random = random_namespace(rs)
    rs, rv1 = random.standard_normal(rs, shape=(4,))
    rs, rv2 = random.poisson(rs, lam, shape=(4,))
    return rv1 + rv2

import numpy as np
rng = np.random.default_rng()
print(my_function(1.0, rng))
# [ 1.25035394 -0.11511349  1.87203598  2.55088409]

import jax
key = jax.random.PRNGKey(42)
print(my_function(1.0, key))
# [0.43244982 0.8856307  0.06793922 1.4641162 ]

For anything more complicated than sampling random variates, particularly anything that requires knowledge of the implementation details of the random state, we accept that we will always have to handle each framework separately.

The main difference is that rng in numpy and key in JAX are fundamentally different kinds of objects. In the numpy example, the call to my_function mutates rng in-place, so that subsequent calls will return different random values. In JAX, functions are pure, and so the call to my_function cannot mutate key, and subsequent calls with the same key will produce identical values to the first call:
import numpy as np
rng = np.random.default_rng()
print(my_function(1.0, rng))
# [ 1.25035394 -0.11511349  1.87203598  2.55088409]
print(my_function(1.0, rng))
# [3.15990919 1.07582056 1.09202392 0.33987543]

import jax
key = jax.random.PRNGKey(42)
print(my_function(1.0, key))
# [-0.5675502   1.8856307   0.06793922  3.464116  ]
print(my_function(1.0, key))
# [-0.5675502   1.8856307   0.06793922  3.464116  ]

Yes, there is probably no universal API for situations where it matters whether or not we are dealing with a stateful RNG or a stateless key.
My point is that it does not preclude us from having a universal (functional) API that can generate random numbers. In my experience, that's also the only situation where you want such an API. For everything more complicated, you need special cases anyway.

Given lack of ecosystem agreement, we are not likely to forge a path forward for standardizing a PRNG API in the array API specification at this time. As such, I will go ahead and close this issue.
We can reopen/revisit if and when we have greater community consensus.


Add Temurin Case Study Banner and as part of the documentation

The Temurin Security case study went live this week (April 16) https://outreach.eclipse.foundation/adoptium-temurin-supply-chain-security
We want to promote the Case Study using Adoptium.net:

Add a Banner on the Home page: https://adoptium.net/
Add it as part of the "Secure Software" Documentation content at https://adoptium.net/docs/  Title "Temurin Security Case Study"

The link for now will be: https://outreach.eclipse.foundation/adoptium-temurin-supply-chain-security pending to confirm with Outreach team.

There is another Banner added yesterday. When do you need this one to be online?

@xavierfacq  after the release period will be ok! Thank you!

The right  URL is: https://outreach.eclipse.foundation/adoptium-temurin-supply-chain-security?utm_campaign=Temurin Case Study&utm_source=website&utm_medium=adoptium docs

This would be the message:

Case Study: Building the World's Most Secure OpenJDK Distribution
Find out how the Eclipse Foundation and Adoptium Working Group are pioneering software supply chain security with Eclipse Temurin.

In the banner, where do you want the link to be? somewhere on the given text or on a subtext like:
Read more about ...

Add a Download now linked to: https://outreach.eclipse.foundation/adoptium-temurin-supply-chain-security?utm_campaign=Temurin Case Study&utm_source=website&utm_medium=adoptium docs

is that ok for you?

You can check here: https://deploy-preview-2811--eclipsefdn-adoptium.netlify.app/fr/docs/

Can we skip the date, and Bold this phrase: Case Study: Building the World's Most Secure OpenJDK Distribution? thank you!

It's ready: https://deploy-preview-2811--eclipsefdn-adoptium.netlify.app/fr/


Rewrite NotificationHubInstallationAdapter to use Volley

This change removes the App Center Push HttpClient, and replaces it with Android Volley and a custom request on top of it.
This will offload some of the work of ensuring we are correctly negotiating TLS, and reduce the maintenance burden of this library. Additionally, no new dependencies will be added to end-user applications. This is because Volley is already included with the google-services/firebase-messaging.

Closing for now. I'll be reopening this PR from a new branch that doesn't contain the new Network implementation.


No matching global declaration available for the validation root

XML parsing error. The bug is triggered if there is no xmlns for schema 4: xmlns="http://datacite.org/schema/kernel-4", so the following namespaces generate an error:

http://datacite.org/schema/kernel-2.2
http://datacite.org/schema/kernel-3
http://datacite.org/schema/kernel-4.0
http://datacite.org/schema/kernel-4.1

@mfenner,
We're seeing this exception when going to https://mds.test.datacite.org on some but not all of our test boxes. We noticed it 2 days ago. Would this issue account for that? Is there anything we can do to work around it or should we wait for a fix?

This has been fixed. Please let us know if you still have issues with this.


Fix warnings on the latest nightly

This fixes warnings due to new clippy lints added by https://github.com/rust-lang/rust-clippy/pull/3766.

Oh, there also seem to be warnings due to incomplete_features became lint by https://github.com/rust-lang/rust/pull/63095.

😕
$ rustup target add thumbv7m-none-eabi
info: downloading component 'rust-std' for 'thumbv7m-none-eabi'
error: component download failed for rust-std-thumbv7m-none-eabi
info: caused by: could not download file from 'https://static.rust-lang.org/dist/2019-08-02/rust-std-nightly-thumbv7m-none-eabi.tar.xz' to '/home/travis/.rustup/downloads/ac33d8fd5a4b68735a9762b26807ab273e8f155557002c5388dddd5e22335cb7.partial'
info: caused by: failed to make network request
info: caused by: https://static.rust-lang.org/dist/2019-08-02/rust-std-nightly-thumbv7m-none-eabi.tar.xz: timed out
The command "rustup target add thumbv7m-none-eabi" failed and exited with 1 during .

Great, thanks!


removed duplications & implemented when-let and if-let macros

I understand that you don't want to add additional dependencies so I implemented those macros for you :)

That definitely solves the dependency issue, but it also means we are adding ~35 lines of macros that I will need to maintain in perpetuity, and whose purpose is only to flatten a few nested expressions elsewhere in the codebase. At the moment I am skeptical that it is a worthwhile tradeoff. I really appreciate the effort.


Search dropdown doesn't work with JSX option text

Steps
Have a Search Dropdown that uses formatted content for an option
Expected Result
Searching works
Actual Result
Searching doesn't work for elements that are not plain text
Version
0.79.1
Testcase
https://codesandbox.io/s/zk32l4zrm
(try searching for Foo)

According to the TypeScript definitions the text of the option is SemanticShorthandContent which is React.ReactNode so I'd expect it to work...

You're looking for the content prop for the options.
item.text
The text prop only accepts a string.  It is used when searching. Note the console errors thrown by the prop types checker.
item.content
This allows you to control a dropdown item's rendered value in the dropdown menu.  This is separate from the text.  The text is used for search and is the value shown in the dropdown when the item is active.
https://react.semantic-ui.com/modules/dropdown#dropdown-example-item-content


Create a basic Program Interface

Description
Adds a very basic interface for programs that only allows getting and create (basic).
Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Issue(s)
Fixes #98

For conversation history: https://github.com/seattle-uat/universal-application-tool/pull/117


Restructure MTC Python Documentation

Description
Currently, the documentation for the the python interface of the moveit task constructor mixes usage examples with api reference. This makes it hard to find code snippets and generally clutters up the documentation.  Additionally, it would be great to have tutorials, guiding the reader through the first steps of using the moveit task constructor.
This PR aims to split up the documentation and structure it in the following way:

Api Reference
Tutorials
How-To Guides
Topic Guides

I would really appreciate some feedback and would love to incorporate that and any additional ideas in the tutorial!

Thanks for this restructuring. Looks really good. I rebased your changes and merged them into wip-python-api-doc.


Is MSAL specific to Azure services, or is it compatible with AspNet Core Identity / IdentityServer4?

Hello,
Is MSAL specific to Azure services, or is it compatible with AspNet Core Identity / IdentityServer4? I'm looking for browser libraries to use with our AspNet Core Identity / IdentityServer4 back-end. I was looking at oidc-client, but I also knew about MSAL. Some documentation pages make MSAL sound like it works with any OpenID / OAuth back-end, but then others make it sound specific to Azure (B2C, etc).
Will MSAL work with our Identity / IdentityServer4 back-end?

@jennyf19 This looks like a .Net question. Could you take a look?

@jennyf19 This looks like a .Net question. Could you take a look?

Sorry for my unclear post. It’s not really about .net.
We use MSAL.js to authenticate against Azure B2C for a React single page web app. We actually decided to stop using B2C and instead chose to code and host our own identity provider server. We are using Microsoft’s built in AspNet Core Identity for user management and IdentityServer4 for OpenId / OAuth work flows. In essence it’s the same or similar to B2C.
My question is just whether MSAL.js can be used for non-Azure OpenId providers like IdentityServer and AspNet Core Identity?
The docs make it sound like it can on some pages but like it can’t on others.

@ryancole Gotcha. Theoretically it could work if you set the validateAuthority flag to false. However, this would not be officially supported by us. Any alterations you would need to make to the code in order to make it work would be up to you.

@DarylThayil @jasonnutter can you provide any guidance to @ryancole on his inquiry ->
"My question is just whether MSAL.js can be used for non-Azure OpenId providers like IdentityServer and AspNet Core Identity?"

@jennyf19 @ryancole I don't believe we support other OpenID providers as first-class scenarios. As @tnorling mentions, you could attempt to use them and see how things go, but I don't believe we would prioritize fixing incompatibilities (esp. for non-MSFT products). That said, PRs are welcome!

@jasonnutter @jennyf19 @DarylThayil
Here is my feeedback on this, after spending some weeks working on authorization and authentication for my company's products.
Since the microsoft docs state that Azure AD 2.0 is compliant with with OAUTH2 and OIDC, compatibility with these standards should be a supported scenario. In my opinion, supporting these standards should be a goal for the AzureAD and MSAL teams.
This would greatly increase trust in the products. It would convey that we are all going in the same direction, and converging to a standard as much as possible.
Let me explain my scenario. We run multiple IdentityServer4 instances and one AzureAD v2.0 instance. We build many javascript (react, mobile) apps to login to these services (with code + PKCE flow). I would like to use only one client to connect to both of these services. My preference would be to use msal-browser.js, due to a cleaner interface, but it cannot correctly work with IdentityServer4. So I have to use both clients.
The reasons that msal-browser.js cannot connect to IdentityServer4 are small implementation choices, not pertaining to the main functionality.
Today I have spent some hours investigating this and I gave up. Some issues I have encountered (I would probably consider them bugs):

msal-browser.js does not support a basic url for the authorization server, one that is missing the tenant part that is specific to Azure AD 2.0. If I set my authority url to something like www.identitysrf.com it will fail ("url_parse_error", it does not work without a tenant in the path. if I set my authority url to something like www.identitysrf.com/authpath it passes that check, but this requires routing hacks on the IdentityServer4 server)
DEFAULT_AUTH_ENDPOINT_PATH and DEFAULT_TOKEN_ENDPOINT_PATH are non standard path artefacts - but the authorizationEndpoint() method concatenates these to the authority url, thus forcing you tu use a certain url path, and there is no way to configure this. again, this requires routing hacks on the server

I for one love the simplicity of use with the new msal-browser client (works great with Azure AD 2.0) and I am dissapointed to see that there are some very small obstacles in the way of using it with IdentityServer4 (which is considered a very accurate implementation of the standards for the NET community)
I hope I have provided some information useful for improving the client.
Best regards,
Adrian

@jmprieur @hamiltonha fyi
@adriannasui I would suggest opening a new issue w/this information, so it's not buried here and the team can respond more easily. Thanks for your time, input, and investigation, much appreciate.

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/2120


How should I use frame encryption on Android, is there any demo code？

No description provided.

Hello, I have encountered the same problem. Do you know how to use it now

FrameCryptor is fairly low level. We use this functionality in LiveKit's SDKs.
Here's the implementation in Android: https://github.com/livekit/client-sdk-android/blob/main/livekit-android-sdk/src/main/java/io/livekit/android/e2ee/E2EEManager.kt
and example app usage: https://github.com/livekit/client-sdk-android/blob/ce0cb61619d8cc78376566d0bf8e10e493c45612/sample-app-common/src/main/java/io/livekit/android/sample/CallViewModel.kt#L90


Re-running on the same Dockerfile causes PDF file to change

I have committed and pushed the Dockerfile.pdf to my git repo.
Now when I run the same command on the same Dockerfile, there are changes in git.
docker run \
  --rm \
  --user "$(id -u):$(id -g)" \
  --workdir /workspace \
  --volume "$(pwd)":/workspace \
  ghcr.io/patrickhoefler/dockerfilegraph:alpine

It's also worth noting that I move the generated .PDF to another directory after the command is done:
mv Dockerfile.pdf ./docs/

Do you know why the Dockerfile.pdf is changing even though my Dockerfile has not? Could the library include a timestamp?
Not sure if this helps at all, but the binary changed near the bottom of the RAW binary code.
Before binary:
stream
x�5�=�0����u1yS?ZݺH���!h�B1����r�q����/sP����
�)�W�_�a�7�B��m� Vׁ��^;D���%T$9���e-9�qj�~M�3q|�8��d�Vy��-��'�RAR���#��F���mM �hW�G_'a4�
endstream
endobj

After binary:
stream
x�5�=�0����u1yS?P�E�.R:�t�P��8�߷F��p�s<�(C���欮��U������y�����
�P�v_<�5M zg�}�ѠfgA	I�h�~�*�Ck�Z�y��L�7N+?ۥS^#�*)�E�T���,���4j�Wok�@��1�'4~
endstream

Hey @jamesone, thanks for raising this issue! 🙂

Could the library include a timestamp?

You are absolutely correct:
❯ exiftool -all Dockerfile.pdf
ExifTool Version Number         : 12.40
File Name                       : Dockerfile.pdf
[...]
Page Count                      : 1
Producer                        : cairo 1.17.6 (https://cairographics.org)
Create Date                     : 2023:04:17 20:23:55Z

Unfortunately I am not aware of a way to tell graphviz not to include any metadata when generating the PDF via the cairo renderer.
To make things worse, it seems to be anything but trivial to remove PDF metadata after it's been created. exiftool, for example, intentionally does not include this functionality.
In my quick preliminary tests, mat2's --lightweight mode looked promising:
❯ mat2 --lightweight --verbose Dockerfile.pdf
DEBUG: Cleaning Dockerfile.pdf…
INFO: Rendering page 1/1

Unfortunately, including mat2 more than doubles the size of the Ubuntu-based container image, and on Alpine it's so far only available on Edge in the testing repo.
Anyway, I hope this information helps, and any ideas how to improve the situation are always more than welcome 🙂

Thanks a lot, I appreciate your instant reply on this @patrickhoefler At this rate I can configure my dockerfilegraph script to run in a git commit hook whenever the Dockerfile has a change. This should be able to handle this issue. I will close this as it's quite clear that it's not trivial and that there are ways around it (i.e. like the one I explained).
|


Adding WebdriverIO as recommended tool for component testing

The current list of recommend tools is a bit behind of what is currently possible in the testing ecosystem. Many browser automation frameworks, including WebdriverIO now offer component testing capabilities which might be a better alternative for many users given it comes much closer to the real world with just minimal speed detriments. For pure component tests I personally would not advice to use JSDOM at all given that:

it lacks in certain features (e.g. triggering pseudo states) and has some known caveats
it completely ignores the interactivity state of elements, e.g. if my component hides a button or an input is disabled, many user interactions are still possible within JSDOM and non-organic interactions via JS clicks
mounting and rendering components in an actual browser allows the use of common developer debugging tools like DevTools rather than using e.g. screen.debug() to print the DOM tree providing a much better DX
speed advancements are just minimal, starting a headless browser is almost as fast

I know that a lot of folks are working on the new React docs and I asked a question whether there will be a testing section for it as well, I am happy to contribute to that too.

Closing in favor of #5675. I forgot I had this open already but like the wording of the new PR.


Wazuh dashboard should use a GIF file as loading screen logo

Description

Currently, the Wazuh dashboard loading screen logo is static and hardcoded in the template.js file.
https://github.com/wazuh/wazuh-packages/blob/4.4/stack/dashboard/base/files/etc/template.js#L60-L75

  const openSearchLogo = /*#__PURE__*/_react.default.createElement("svg", {
    width: "64",
    height: "64",
    viewBox: "0 0 64 64",
    fill: "none",
    xmlns: "http://www.w3.org/2000/svg"
  }, /*#__PURE__*/_react.default.createElement("path", {
    d: "M61.7374 23.5C60.4878 23.5 59.4748 24.513 59.4748 25.7626C59.4748 44.3813 44.3813 59.4748 25.7626 59.4748C24.513 59.4748 23.5 60.4878 23.5 61.7374C23.5 62.987 24.513 64 25.7626 64C46.8805 64 64 46.8805 64 25.7626C64 24.513 62.987 23.5 61.7374 23.5Z",
    fill: "#005EB8"
  }), /*#__PURE__*/_react.default.createElement("path", {
    d: "M48.0814 38C50.2572 34.4505 52.3615 29.7178 51.9475 23.0921C51.0899 9.36725 38.6589 -1.04463 26.9206 0.0837327C22.3253 0.525465 17.6068 4.2712 18.026 10.9805C18.2082 13.8961 19.6352 15.6169 21.9544 16.9399C24.1618 18.1992 26.9978 18.9969 30.2128 19.9011C34.0962 20.9934 38.6009 22.2203 42.063 24.7717C46.2125 27.8295 49.0491 31.3743 48.0814 38Z",
    fill: "#003B5C"
  }), /*#__PURE__*/_react.default.createElement("path", {
    d: "M3.91861 14C1.74276 17.5495 -0.361506 22.2822 0.0524931 28.9079C0.910072 42.6327 13.3411 53.0446 25.0794 51.9163C29.6747 51.4745 34.3932 47.7288 33.974 41.0195C33.7918 38.1039 32.3647 36.3831 30.0456 35.0601C27.8382 33.8008 25.0022 33.0031 21.7872 32.0989C17.9038 31.0066 13.3991 29.7797 9.93694 27.2283C5.78746 24.1704 2.95092 20.6257 3.91861 14Z",
    fill: "#005EB8"
  }));

It is necessary to modify it so that said image is not hardcoded in the file itself but is obtained from an external file, in this way it is possible to modify the logo in an easier way from the construction of the package.
Also, this new image must not be static, but must be replaced by a dynamic image in which the blue dot is jumping, like the one shown here:

Tasks

[ ] Modify the template.js file to use an external SVG image.
[ ] Make the necessary changes to use a GIF file and not an SVG file.

Use the GIF file shown in this issue, if not, ask @wazuh/marketing team.

[ ] Adjust the logo of the loading screen to a smaller size in reference to the title Loading Wazuh.

This must be validated by the team.

[ ] Validate changes.

Validation

[ ] The template.js file accepts a GIF file external to it.
[ ] The loading screen shows a moving logo.
[ ] The size of the logo is adequate with respect to the lower title.
[ ] The logo is displayed smoothly in both light mode and dark mode.
[ ] The light mode of the Wazuh dashboard uses a logo on the loading screen with dark letters.
[ ] If issue https://github.com/wazuh/wazuh-packages/issues/1924 has been completed:

[ ] The dark mode of the Wazuh dashboard uses a logo on the loading screen with light letters.

PR was merged


Laravel 5.3 support?

Support for laravel 5.3 will be released when?

PRs welcome. There are several changes which need to be made when someone has time to support self hosted Parse instances
El 20 sept 2016, a las 12:52, Samuel Carvalho <notifications<EMAIL_ADDRESS>escribi?:
Support for laravel 5.3 will be released when?

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/HipsterJazzbo/LaraParse/issues/52, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG-F1xIwHlMqm4KkNNGlRTcnh05Bxo6gks5qr7rFgaJpZM4KBfCW.


Add warnings via Warnf to the debug log

What does this PR change? What problem does it solve?
Warnings messages printed via Warnf are not automatically added to the debug log. This can complicate debugging. #4222 might be an example of this.
This PR is more of a stopgap than a proper solution. The latter would require a large overhaul of the logging in restic.

Was the change previously discussed in an issue or on the forum?
No.

Checklist

[x] I have read the contribution guidelines.
[x] I have enabled maintainer edits.
[ ] I have added tests for all code changes.
[ ] I have added documentation for relevant changes (in the manual).
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
[x] I have run gofmt on the code in all commits.
[x] All commit messages are formatted in the same style as the other commits in the repo.
[x] I'm done! This pull request is ready for review.

LGTM.


Build release zip on CI instead of locally

Fixes https://github.com/CesiumGS/cesium-omniverse/issues/237
This can be reviewed commit by commit:

Add packaging step to our GitHub Actions workflow that builds the package target and publishes the .zip to S3
Add new GitHub Action configuration for Docker CentOS builds
Update the release guide with instructions to download packages from S3 instead of building locally

I have quite a few questions, including some initial questions:

Do we always publish to S3 on every build?

If yes, do we actually need to?
If yes, does the current versioned build on S3 get overwritten with every build?

Can we set this up to only execute on a release tag?

@weegeekps yeah that's a good idea

For some reason the 0.4.0 build wasn't able to pick up the git tag. It was working locally... I'll need to investigate why this didn't happen on CI.
For now I manually edited the name of the zip file from CesiumForOmniverse-Windows-8832399.zip to CesiumForOmniverse-Linux-v0.4.0.zip


Fix potential empty chunks when creating DataFrame from pandas

What do these changes do?

This PR fixed potential empty chunks when creating DataFrame from pandas.
Related issue number

Fixes #2985 .
Check code requirements

[x] tests added / passed (if needed)
[x] Ensure all linting tests pass, see here for how to run them

This bug is introduced in #1522 .


chore: update travis to only run unit tests

Pull Request Test Coverage Report for Build 175

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.774%

Totals

Change from base Build 163:
0.0%

Covered Lines:
23

Relevant Lines:
23

💛  - Coveralls