docs: add documentation on NEAR_WALLET_ENV in the Getting Started section

This PR adds a blurb explaining the need for a valid NEAR_WALLET_ENV environment variable. Now that we have feature flags in the repo this variable is required.

Would it make sense to have a .env.sample file in frontend the way we do in near-contract-helper?

I don't think it's critical, but you raise a good point about discoverability of supported env vars.
What do you think about us updating this note in the readme in #2299 to also describe that you that you can use a .env file to set any of the environment variables that are referenced in the new configFromEnvironment.js files that @esaminu has added there?  Then we won't have to keep a sample .env file updated as we add/remove env vars.


Gotcha: Redirect can break Route

Suppose I want to display a user table at /users/ and if someone lands in my spa without the trailing slash, I want to automatically add it.
(additionally there are pages like /users/alexa.siri/profile/)
This works:
const Router = (props) => <Switch props={props}>
  <Route path="/users/" component={ListUsers}/>
</Switch>;

This doesn't work (redirect works, but component is never displayed):
const Router = (props) => <Switch props={props}>
  <Redirect exact from="/users" to="/users/"/>
  <Route path="/users/" component={ListUsers}/>
</Switch>;

And this works again:
const Router = (props) => <Switch props={props}>
  <Redirect exact strict from="/users" to="/users/"/>
  <Route path="/users/" component={ListUsers}/>
</Switch>;

I'm sure I just had to read the docs more carefully, but it seems it's the 3rd time I'm bitten by this in a year, because I recall having to add strict before 😭
I'm not sure what's best technically, but please save us poor devs from such dev UX 🙏

Feel free to open up a PR to add something about this to the docs.

This is basically the same as #4841


feat: BYOB streams

gecko-dev PR: https://github.com/bytecodealliance/gecko-dev/pull/2
Spidermonkey PR: https://github.com/fastly/spidermonkey-wasi-embedding/pull/12
Adds a new CLI flag - --enable-experimental-byob-streams which enables BYOB stream features and globals. Experimental status is primarily because we are currently only at 70% web platform test support, while it should be enough for practical use cases already.
Integration tests included for standard usage and react server rendering.
We can unflag when the web platform tests support reaches a high enough level of stability.
Current Test Status

WPT Test Suite
Passing

readable-byte-streams/bad-buffers-and-views.any.js
24 / 24

readable-byte-streams/construct-byob-request.any.js
16 / 16

readable-byte-streams/general.any.js
73 / 99

readable-byte-streams/respond-after-enqueue.any.js
3 / 3

readable-byte-streams/tee.any.js
10 / 38

Total:
126 / 180 (70%)

Managed to get WPT wired in, currently at about 50%.

The wpt fails in debug mode on this MOZ_ASSERT:
https://github.com/bytecodealliance/gecko-dev/blob/97a1afb3bd89e9c9295ebc17eb19cf669e18e9f3/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp#L1024
The message in the logs was this:
2023-04-07T00:06:10.3331352Z viceroy stderr: Assertion failure: firstPendingPullInto->readerType() == ReaderType::Default, at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp:1024
2023-04-07T00:06:10.8891837Z viceroy stderr: 2023-04-07T00:06:10.888291Z ERROR request{id=121}: WebAssembly trapped: error while executing at wasm backtrace:
2023-04-07T00:06:10.8913726Z     0: 0x8fca6c - js::ReadableByteStreamControllerEnqueue(JSContext*, JS::Handle<js::ReadableByteStreamController*>, JS::Handle<JSObject*>)
2023-04-07T00:06:10.8915416Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp:1024:9
2023-04-07T00:06:10.8916401Z     1: 0x8f2013 - ReadableByteStreamController_enqueue(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8917864Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamController.cpp:772:8
2023-04-07T00:06:10.8918856Z     2: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8919968Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8921168Z     3: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8922275Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8923085Z     4: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8924119Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8924914Z     5: 0x4b2f8b - js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)
2023-04-07T00:06:10.8926152Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:619:10              - Interpret(JSContext*, js::RunState&)
2023-04-07T00:06:10.8927113Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:3362:16
2023-04-07T00:06:10.8928023Z     6: 0x4a9f3e - js::RunScript(JSContext*, js::RunState&)
2023-04-07T00:06:10.8928817Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:431:13
2023-04-07T00:06:10.8929871Z     7: 0x4d0b98 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8930742Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:579:13
2023-04-07T00:06:10.8931714Z     8: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8932532Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8933690Z     9: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8934592Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8936555Z    10: 0x7c526a - js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8937555Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/SelfHosting.cpp:1488:10
2023-04-07T00:06:10.8938308Z    11: 0x5cfe69 - AsyncFunctionResume(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, ResumeKind, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8939043Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:149:8
2023-04-07T00:06:10.8939787Z    12: 0x5cfa87 - js::AsyncFunctionAwaitedFulfilled(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8940526Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:190:10
2023-04-07T00:06:10.8941217Z    13: 0x759cc0 - AsyncFunctionPromiseReactionJob(JSContext*, JS::Handle<PromiseReactionRecord*>)
2023-04-07T00:06:10.8942299Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2111:12              - PromiseReactionJob(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8943106Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2174:12
2023-04-07T00:06:10.8943829Z    14: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8944528Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8945217Z    15: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8945913Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8946534Z    16: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8947189Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8947955Z    17: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8948676Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8949420Z    18: 0x5f6d8b - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8950161Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/CallAndConstruct.cpp:117:10
2023-04-07T00:06:10.8950924Z    19: 0x6a2ca4 - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8951869Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/obj-debug/dist/include/js/CallAndConstruct.h:110:10              - js::InternalJobQueue::runJobs(JSContext*)
2023-04-07T00:06:10.8952685Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:893:14
2023-04-07T00:06:10.8953191Z    20: 0x6a24c3 - js::RunJobs(JSContext*)
2023-04-07T00:06:10.8953798Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:825:17
2023-04-07T00:06:10.8954318Z    21: 0x19781 - process_pending_jobs(JSContext*, double*)
2023-04-07T00:06:10.8955146Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:441:5              - js_compute_runtime_serve
2023-04-07T00:06:10.8955917Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:506:5
2023-04-07T00:06:10.8956377Z    22: 0xe40ed9 - __main_argc_argv
2023-04-07T00:06:10.8956934Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/impl/main.cpp:10:3
2023-04-07T00:06:10.8957378Z    23: 0xec2edf - <unknown>!__main_void
2023-04-07T00:06:10.8957692Z    24: 0x19387 - __wizer_resume()
2023-04-07T00:06:10.8958280Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:401:1
2023-04-07T00:06:10.8958571Z
2023-04-07T00:06:10.8958684Z Caused by:
2023-04-07T00:06:10.8958989Z     wasm trap: wasm `unreachable` instruction executed
2023-04-07T00:06:10.8959731Z viceroy stdout: 2023-04-07T00:06:10.888582Z  INFO request{id=121}: request completed using 9.0 MB of WebAssembly heap
2023-04-07T00:06:10.8960303Z 2023-04-07T00:06:10.888593Z  INFO request{id=121}: request completed in 1s
2023-04-07T00:06:10.8961136Z viceroy stderr: 2023-04-07T00:06:10.888998Z ERROR There was an error handling the request error while executing at wasm backtrace:
2023-04-07T00:06:10.8961908Z     0: 0x8fca6c - js::ReadableByteStreamControllerEnqueue(JSContext*, JS::Handle<js::ReadableByteStreamController*>, JS::Handle<JSObject*>)
2023-04-07T00:06:10.8962803Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp:1024:9
2023-04-07T00:06:10.8963555Z     1: 0x8f2013 - ReadableByteStreamController_enqueue(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8964331Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamController.cpp:772:8
2023-04-07T00:06:10.8965122Z     2: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8965829Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8966529Z     3: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8967224Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8967843Z     4: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8968499Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8969112Z     5: 0x4b2f8b - js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)
2023-04-07T00:06:10.8969965Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:619:10              - Interpret(JSContext*, js::RunState&)
2023-04-07T00:06:10.8970747Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:3362:16
2023-04-07T00:06:10.8971298Z     6: 0x4a9f3e - js::RunScript(JSContext*, js::RunState&)
2023-04-07T00:06:10.8971925Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:431:13
2023-04-07T00:06:10.8972609Z     7: 0x4d0b98 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8973586Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:579:13
2023-04-07T00:06:10.8974199Z     8: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8974853Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8975629Z     9: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8976347Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8977151Z    10: 0x7c526a - js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8977960Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/SelfHosting.cpp:1488:10
2023-04-07T00:06:10.8978817Z    11: 0x5cfe69 - AsyncFunctionResume(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, ResumeKind, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8979556Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:149:8
2023-04-07T00:06:10.8980312Z    12: 0x5cfa87 - js::AsyncFunctionAwaitedFulfilled(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8981048Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:190:10
2023-04-07T00:06:10.8981731Z    13: 0x759cc0 - AsyncFunctionPromiseReactionJob(JSContext*, JS::Handle<PromiseReactionRecord*>)
2023-04-07T00:06:10.8982694Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2111:12              - PromiseReactionJob(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8983520Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2174:12
2023-04-07T00:06:10.8984235Z    14: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8984933Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8985614Z    15: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8986310Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8986927Z    16: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8987582Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8988345Z    17: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8989066Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8989790Z    18: 0x5f6d8b - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8990512Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/CallAndConstruct.cpp:117:10
2023-04-07T00:06:10.8991371Z    19: 0x6a2ca4 - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8992303Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/obj-debug/dist/include/js/CallAndConstruct.h:110:10              - js::InternalJobQueue::runJobs(JSContext*)
2023-04-07T00:06:10.8993110Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:893:14
2023-04-07T00:06:10.8993604Z    20: 0x6a24c3 - js::RunJobs(JSContext*)
2023-04-07T00:06:10.8994200Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:825:17
2023-04-07T00:06:10.8994719Z    21: 0x19781 - process_pending_jobs(JSContext*, double*)
2023-04-07T00:06:10.8995430Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:441:5              - js_compute_runtime_serve
2023-04-07T00:06:10.8996311Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:506:5
2023-04-07T00:06:10.8996773Z    22: 0xe40ed9 - __main_argc_argv
2023-04-07T00:06:10.8997338Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/impl/main.cpp:10:3
2023-04-07T00:06:10.8997779Z    23: 0xec2edf - <unknown>!__main_void
2023-04-07T00:06:10.8998086Z    24: 0x19387 - __wizer_resume()
2023-04-07T00:06:10.8998666Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:401:1

The wpt fails in debug mode on this MOZ_ASSERT: https://github.com/bytecodealliance/gecko-dev/blob/97a1afb3bd89e9c9295ebc17eb19cf669e18e9f3/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp#L1024
The message in the logs was this:
2023-04-07T00:06:10.3331352Z viceroy stderr: Assertion failure: firstPendingPullInto->readerType() == ReaderType::Default, at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp:1024
2023-04-07T00:06:10.8891837Z viceroy stderr: 2023-04-07T00:06:10.888291Z ERROR request{id=121}: WebAssembly trapped: error while executing at wasm backtrace:
2023-04-07T00:06:10.8913726Z     0: 0x8fca6c - js::ReadableByteStreamControllerEnqueue(JSContext*, JS::Handle<js::ReadableByteStreamController*>, JS::Handle<JSObject*>)
2023-04-07T00:06:10.8915416Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp:1024:9
2023-04-07T00:06:10.8916401Z     1: 0x8f2013 - ReadableByteStreamController_enqueue(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8917864Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamController.cpp:772:8
2023-04-07T00:06:10.8918856Z     2: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8919968Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8921168Z     3: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8922275Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8923085Z     4: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8924119Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8924914Z     5: 0x4b2f8b - js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)
2023-04-07T00:06:10.8926152Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:619:10              - Interpret(JSContext*, js::RunState&)
2023-04-07T00:06:10.8927113Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:3362:16
2023-04-07T00:06:10.8928023Z     6: 0x4a9f3e - js::RunScript(JSContext*, js::RunState&)
2023-04-07T00:06:10.8928817Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:431:13
2023-04-07T00:06:10.8929871Z     7: 0x4d0b98 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8930742Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:579:13
2023-04-07T00:06:10.8931714Z     8: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8932532Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8933690Z     9: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8934592Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8936555Z    10: 0x7c526a - js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8937555Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/SelfHosting.cpp:1488:10
2023-04-07T00:06:10.8938308Z    11: 0x5cfe69 - AsyncFunctionResume(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, ResumeKind, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8939043Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:149:8
2023-04-07T00:06:10.8939787Z    12: 0x5cfa87 - js::AsyncFunctionAwaitedFulfilled(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8940526Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:190:10
2023-04-07T00:06:10.8941217Z    13: 0x759cc0 - AsyncFunctionPromiseReactionJob(JSContext*, JS::Handle<PromiseReactionRecord*>)
2023-04-07T00:06:10.8942299Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2111:12              - PromiseReactionJob(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8943106Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2174:12
2023-04-07T00:06:10.8943829Z    14: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8944528Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8945217Z    15: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8945913Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8946534Z    16: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8947189Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8947955Z    17: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8948676Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8949420Z    18: 0x5f6d8b - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8950161Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/CallAndConstruct.cpp:117:10
2023-04-07T00:06:10.8950924Z    19: 0x6a2ca4 - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8951869Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/obj-debug/dist/include/js/CallAndConstruct.h:110:10              - js::InternalJobQueue::runJobs(JSContext*)
2023-04-07T00:06:10.8952685Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:893:14
2023-04-07T00:06:10.8953191Z    20: 0x6a24c3 - js::RunJobs(JSContext*)
2023-04-07T00:06:10.8953798Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:825:17
2023-04-07T00:06:10.8954318Z    21: 0x19781 - process_pending_jobs(JSContext*, double*)
2023-04-07T00:06:10.8955146Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:441:5              - js_compute_runtime_serve
2023-04-07T00:06:10.8955917Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:506:5
2023-04-07T00:06:10.8956377Z    22: 0xe40ed9 - __main_argc_argv
2023-04-07T00:06:10.8956934Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/impl/main.cpp:10:3
2023-04-07T00:06:10.8957378Z    23: 0xec2edf - <unknown>!__main_void
2023-04-07T00:06:10.8957692Z    24: 0x19387 - __wizer_resume()
2023-04-07T00:06:10.8958280Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:401:1
2023-04-07T00:06:10.8958571Z
2023-04-07T00:06:10.8958684Z Caused by:
2023-04-07T00:06:10.8958989Z     wasm trap: wasm `unreachable` instruction executed
2023-04-07T00:06:10.8959731Z viceroy stdout: 2023-04-07T00:06:10.888582Z  INFO request{id=121}: request completed using 9.0 MB of WebAssembly heap
2023-04-07T00:06:10.8960303Z 2023-04-07T00:06:10.888593Z  INFO request{id=121}: request completed in 1s
2023-04-07T00:06:10.8961136Z viceroy stderr: 2023-04-07T00:06:10.888998Z ERROR There was an error handling the request error while executing at wasm backtrace:
2023-04-07T00:06:10.8961908Z     0: 0x8fca6c - js::ReadableByteStreamControllerEnqueue(JSContext*, JS::Handle<js::ReadableByteStreamController*>, JS::Handle<JSObject*>)
2023-04-07T00:06:10.8962803Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamControllerOperations.cpp:1024:9
2023-04-07T00:06:10.8963555Z     1: 0x8f2013 - ReadableByteStreamController_enqueue(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8964331Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/streams/ReadableByteStreamController.cpp:772:8
2023-04-07T00:06:10.8965122Z     2: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8965829Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8966529Z     3: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8967224Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8967843Z     4: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8968499Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8969112Z     5: 0x4b2f8b - js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)
2023-04-07T00:06:10.8969965Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:619:10              - Interpret(JSContext*, js::RunState&)
2023-04-07T00:06:10.8970747Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:3362:16
2023-04-07T00:06:10.8971298Z     6: 0x4a9f3e - js::RunScript(JSContext*, js::RunState&)
2023-04-07T00:06:10.8971925Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:431:13
2023-04-07T00:06:10.8972609Z     7: 0x4d0b98 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8973586Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:579:13
2023-04-07T00:06:10.8974199Z     8: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8974853Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8975629Z     9: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8976347Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8977151Z    10: 0x7c526a - js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8977960Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/SelfHosting.cpp:1488:10
2023-04-07T00:06:10.8978817Z    11: 0x5cfe69 - AsyncFunctionResume(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, ResumeKind, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8979556Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:149:8
2023-04-07T00:06:10.8980312Z    12: 0x5cfa87 - js::AsyncFunctionAwaitedFulfilled(JSContext*, JS::Handle<js::AsyncFunctionGeneratorObject*>, JS::Handle<JS::Value>)
2023-04-07T00:06:10.8981048Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/AsyncFunction.cpp:190:10
2023-04-07T00:06:10.8981731Z    13: 0x759cc0 - AsyncFunctionPromiseReactionJob(JSContext*, JS::Handle<PromiseReactionRecord*>)
2023-04-07T00:06:10.8982694Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2111:12              - PromiseReactionJob(JSContext*, unsigned int, JS::Value*)
2023-04-07T00:06:10.8983520Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/builtin/Promise.cpp:2174:12
2023-04-07T00:06:10.8984235Z    14: 0x4d134b - CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)
2023-04-07T00:06:10.8984933Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:459:13
2023-04-07T00:06:10.8985614Z    15: 0x4d0a05 - js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)
2023-04-07T00:06:10.8986310Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:547:12
2023-04-07T00:06:10.8986927Z    16: 0x4c9607 - InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)
2023-04-07T00:06:10.8987582Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:614:10
2023-04-07T00:06:10.8988345Z    17: 0x4d2064 - js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
2023-04-07T00:06:10.8989066Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/Interpreter.cpp:646:8
2023-04-07T00:06:10.8989790Z    18: 0x5f6d8b - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8990512Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/CallAndConstruct.cpp:117:10
2023-04-07T00:06:10.8991371Z    19: 0x6a2ca4 - JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)
2023-04-07T00:06:10.8992303Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/obj-debug/dist/include/js/CallAndConstruct.h:110:10              - js::InternalJobQueue::runJobs(JSContext*)
2023-04-07T00:06:10.8993110Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:893:14
2023-04-07T00:06:10.8993604Z    20: 0x6a24c3 - js::RunJobs(JSContext*)
2023-04-07T00:06:10.8994200Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/spidermonkey/gecko-dev/js/src/vm/JSContext.cpp:825:17
2023-04-07T00:06:10.8994719Z    21: 0x19781 - process_pending_jobs(JSContext*, double*)
2023-04-07T00:06:10.8995430Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:441:5              - js_compute_runtime_serve
2023-04-07T00:06:10.8996311Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:506:5
2023-04-07T00:06:10.8996773Z    22: 0xe40ed9 - __main_argc_argv
2023-04-07T00:06:10.8997338Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/impl/main.cpp:10:3
2023-04-07T00:06:10.8997779Z    23: 0xec2edf - <unknown>!__main_void
2023-04-07T00:06:10.8998086Z    24: 0x19387 - __wizer_resume()
2023-04-07T00:06:10.8998666Z                     at /home/runner/work/js-compute-runtime/js-compute-runtime/c-dependencies/js-compute-runtime/js-compute-runtime.cpp:401:1

I believe this is triggered by the tests in streams/readable-byte-streams/general.any.js

Thanks @JakeChampion I've traced down the issue to the implementations historical conflation of read and readInto requests. A simple mode check added to this should resolve the issue I believe, I'll aim to get the fix together on Monday.

Please ignore my previous comment, the edge cases were all just down to new spec paths that needed following. We now have only 4 tests passing on the general BYOB tests and those are all just for transfer streams. That is we have 82% support now, and the edge cases are just transfer and tee cases. I'm not sure if we'll be able to support transfer given we don't have any multi-realm support? Tee streams can be worked through given a little more implementation work.


ARXIVNG-204 implemented config-driven URL builder for base templates

@eawoods This is to address building URLs for things in the base templates. It seems that the biggest constraint on this functionality is that it needs to be possible to make changes to these URLs without touching code (since base will be almost everywhere). The most straightforward way to do this is via configuration. So in this implementation, a function called config_url(target: str) -> str gets injected into the template context; it looks for and returns a configuration variable called ARXIV_[TARGET]_URL.

Yes. To add a new URL, you would add to configy.py:
ARXIV_COOL_URL = os.environ.get('ARXIV_COOL_URL', '/cool/default/url')

and then you should be able to use it in the template with:
Cool


Bug in build_classes.dart file

Describe the bug
There are many bugs in lib\widgets\build_classes.dart file
Prerequisites

I am running the latest version
I checked the documentation and found no answer
I checked to make sure that this issue has not already been filed
I'm reporting the issue to the correct repository (for multi-repository projects)

Expected behavior
Code without any errors successfully compiles and runs as expected.

Heyy @avinashkranjan Please review my Pull request #247
Thank you


feature: Back links!

Is your feature request related to a problem? Please describe.
I'd like to propose a new option at the bottom of the documentation for an object with backlinks to all the places that link to that object.
I think this would make understanding libraries and navigating documentation significantly more powerful.
I'd go so far as to say this would be a "killer feature ™".
Describe the solution you'd like
I'm sure you can design the look better than me, but I'd propose just a list of bullet points linking to both other code options that link to that object and sections of the documentation which link to it.
I assume since we're talking about square bracket links, this shouldn't be too hard? 🤞
Describe alternatives you've considered
We could do some kind of regex for this, but it would be pretty ugly.
Additional context
In https://ai.pydantic.dev/ I make very heavy use of mkdocstrings links.

Hey @samuelcolvin, thanks for the request!

I'd go so far as to say this would be a "killer feature ™".

Definitely! I found myself in situations where this would have been extremely useful, and that drove me to open https://github.com/mkdocstrings/python/issues/153 :smile: We can keep this issue open too, for general visibility (though I suspect this is highly specific to each language handler).

I'm sure you can design the look better than me, but I'd propose just a list of bullet points linking to both other code options that link to that object and sections of the documentation which link to it.

You overestimate my CSS skills :joy: Lets go with a unordered list :slightly_smiling_face:

Linking back to code objects: definitely doable.
Linking back to sections in Markdown pages: will need some thinking (not sure yet how we can do that).

I assume since we're talking about square bracket links, this shouldn't be too hard?

The issue here is that to render cross-references (square bracket links), we first need to render the API docs (so that we know where each object is). But to render backlinks in API docs we'd first need to render cross-references :dizzy_face: I suppose there's a way to add a temporary HTML span or something after each object, and post-process it like we post-process cross-references (which are custom HTML autoref elements).


bug: fix verification fail when policy contains multiple pubkeys

The DSSE code failed early if a verifier failed to successfully verify
an envelope. This caused the policy verification code to incorrectly
report that the policy failed verification.
Signed-off-by: Mikhail Swift<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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 27.002%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
118

Relevant Lines:
437

💛  - Coveralls

Fixed in https://github.com/testifysec/go-witness/commit/1c32945b00c883d6f60646dfa16182abe08448ab
This PR adds additional tests to catch this error and bumps the go.mod to update to<EMAIL_ADDRESS>which includes the above commit

Fixes #194


New release

When's the next release planned? I think this mochajs/mocha@039a8a7 would deserve a point release soonish...

Just put out a new release

Wow, that was quick! Thanks a lot.


pull request for e2e test at 02/04/2017 17:45:07

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


consider renaming Sequential and Dynamic

I haven't seen these terms used to refer to audio (or image/video) buffers in other contexts. What "Sequential" does is more commonly called "planar", which I think would be a good name for the struct.
"Dynamic" kinda implies that the others are "static", but they all allow resizing both the number of frames and channels. "Disjoint" would describe how "Dynamic" organizes memory, but that feels like an awkward name...

Planar seems like a good change. I'd mourn the loss of inherent comprehension. It's specialised terminology that in my mind is harder to grok without looking at reference documentation, but it is what pcm buffers with a linear channel topology tends to be called elsewhere.

Dynamic I'm not entirely sure about. I have half a mind yeeting the type myself, since I only introduced it because it mimics the default topology in rubato (Vec<Vec>) but I don't think the behavior is super useful. I.e. spurious resizes are really not a thing once you look into it and other types can largely cope.

I've also been trying to come up with a real world use case for Dynamic and... I can't think of one. Even if a strange use case involved resizing a buffer more frequently than reading or writing it, resizing Dynamic requires a reallocation for every channel. By contrast, Sequential and Interleaved only require a single reallocation to resize, which I would think would be substantially faster.

Yeah, it really is all about having a type which can ensure that it's compatible with rubato's output. But since I haven't found the use for it anywhere I'm very sceptical as well.

Even if a strange use case involved resizing a buffer more frequently than reading or writing it, resizing Dynamic requires a reallocation for every channel. By contrast, Sequential and Interleaved only require a single reallocation to resize, which I would think would be substantially faster, even though data has to be copied around within the memory.

There's two aspects to resizing: growing / shrinking and topology changes.

A planar buffer requires a lot of work when changing the number of samples per channel where potentially a lot of things need to be copied around.
An interleaved channel requires a lot of copying on topology changes (change in number of channels).

Dynamic only requires additional work when growing the number of samples beyond it's current capacity (which grows by a factor for low amortized overhead), everything else is "free" including shrinking since that doesn't touch the allocation.

A planar buffer requires a lot of work when changing the number of samples per channel where potentially a lot of things need to be copied around.

Sequential could be implemented such that it doesn't move data when shrinking the number of frames and keeps track of the distance in memory between channels separately from the current frames per channel, like Vec. I doubt that's worth the implementation complexity and spreading out the data more in memory (potentially worse cache locality) to optimize resizing, which is generally done much less frequently than reading/writing.

Yeah, it really is all about having a type which can ensure that it's compatible with rubato's output.

FWIW, I got Sequential to work with Rubato's next-0.13 branch (https://github.com/HEnquist/rubato/pull/45) which has the API introduced by https://github.com/HEnquist/rubato/pull/50. However, this required some ugly hacks creating arrays of LinearChannels/mut slices. If I didn't assume the number of channels, creating an array for that wouldn't be possible and a Vec or something would be needed on the heap somewhere. I considered using rsor inside Sequential to return a slice of slices, but still, that would require storing an rsor::Slice inside Sequential and resizing the rsor::slice when Sequential's number of channels changes. That didn't seem worthwhile just to satisfy the current API of Rubato considering the Rubato maintainer has already expressed support for using audio::Buf in https://github.com/HEnquist/rubato/issues/51.


BBQ - Temperature indicates BBQ in use

Triggers when BBQ rises above a certain temperature.
To avoid multiple notifications the BBQ must no already be in-use.
Send a notification to share the progress of the BBQ temperature.
Change the state of the BBQ to be in-use.
Increment a usage counter.

Relates to #21


ble connect err (IDFGH-8769)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
the idf is 4.41 and the chip as ble host.
lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
W (42572) BT_HCI: DiscCmpl evt: hdl=0, rsn=0x3e
I (42650) state machin: interram  mini 46247
lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
W (42662) BT_HCI: DiscCmpl evt: hdl=0, rsn=0x3e
lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
W (42752) BT_HCI: DiscCmpl evt: hdl=0, rsn=0x3e
lld_pdu_get_tx_flush_nb HCI packet count mismatch (0, 1)
W (42842) BT_HCI: DiscCmpl evt: hdl=0, rsn=0x3e
W (42843) BT_APPL: gattc_conn_cb: if=3 st=0 id=3 rsn=0x3e
I (42847) ble host manager: ESP_GATTC_DISCONNECT_EVT, reason = 62

there is the log.
ble connect err.txt

What is the probability of this issue?
0x3e error code is Connection failed to be established.  An occasional failure may be normal, but it should be analyzed if it is repeated in a certain scenario.

I have a similar issue with 100% probability.
W (6616) BT_HCI: DiscCmpl evt: hdl=1, rsn=0x3e
W (6796) BT_HCI: DiscCmpl evt: hdl=1, rsn=0x3e
W (6966) BT_HCI: DiscCmpl evt: hdl=1, rsn=0x3e
W (7146) BT_HCI: DiscCmpl evt: hdl=1, rsn=0x3e
W (7146) BT_APPL: gattc_conn_cb: if=1 st=0 id=1 rsn=0x3e

Hi, @yaniron Does this problem still exist in the latest IDF version? Could you please provide the capture file of the air packets?

Thanks for reporting, will close due to inactivity, feel free to reopen with more updates.


Performance issues with this lib and ramda

🐞 Bug Report
Performance of DefinitelyTyped/ramda has suffered significantly with a recent upgrade (which relies on this library heavily now)
Describe the bug

Upgrading from<EMAIL_ADDRESS>to<EMAIL_ADDRESS>also upgrades ts-toolbelt from 3.8.4 to 4.7.7. In my project, which uses Ramda frequently but not in any crazy manner, this one change in my project.json doubles my project's TS type checking time from ~25sec to ~60-70sec.
Expected behavior

There is not such a significant slowdown of type-checking when using this library/ @types/ramda.
Additional context

Using the latest TS, 3.6.3

further testing:
<EMAIL_ADDRESS>is the latest update I can use w/o a significant increase in type-checking times. that version asks for<EMAIL_ADDRESS>which resolves to 3.14.0.
<EMAIL_ADDRESS>causes the slowdown, presumably because of the change to ask for<EMAIL_ADDRESS>instead (currently resolves to 4.8.23).
I also tried adding a [selective dependency resolution[(https://yarnpkg.com/lang/en/docs/selective-version-resolutions/) to see if the problem arose between 4.3.0 and 4.8.23 or if it came up before/at 4.3.0:
"resolutions": {
    "@types/ramda/ts-toolbelt": "4.3.0"
  }

This locks ts-toolbelt to the earliest version it needs (4.3.0), which still causes slowdowns, so it looks like the change from v3 to v4 is the main culprit. That's about as specific as I've narrowed the issues down so far.

Hi @ekilah, thanks for reporting this. I'll investigate this.
Would you mind listing which ramda functions you use?
(And if possible, the code that is causing the problems)

@pirix-gh It's a big project so I don't think it comes down to one piece of code over another, so it'd be hard to say exactly what code the issue is manifesting at, but a doubling (actually, a bit more) of type-checking time makes me at least guess it's more to do with how often we use Ramda vs one block of code?
I have a gut feeling the change has to do with the mergeDeepLeft/Right and mergeLeft/Right but that's just because those improved a lot between these versions of ts-toolbelt (I know this from our conversation over on https://github.com/DefinitelyTyped/DefinitelyTyped/pull/38419 ). And, we do use those somewhat often, it looks like:
mergeRight - 48
contains - 27
test - 25
map - 23
pick - 21
equals - 16
filter - 15
repeat - 14
range - 13
prop - 12
forEachObjIndexed - 12
omit - 11
find - 10
sortBy - 10
any - 10
keys - 9
mapObjIndexed - 9
all - 8
values - 8
mergeDeepRight - 7
isNil - 7
take - 6
forEach - 6
nth - 6
mergeDeepLeft - 5
sortWith - 5
isEmpty - 5
flatten - 5
takeLast - 5
last - 5
mergeDeepWith - 5
identity - 5
reduce - 4
clone - 4
chain - 4
descend - 4
groupBy - 4
reject - 4
ascend - 3
invert - 3
fromPairs - 3
times - 2
splitAt - 2
clamp - 2
has - 2
splitEvery - 2
includes - 2
recipientName - 2
concat - 1
invites - 1
findLastIndex - 1
findIndex - 1
indexOf - 1
pipe - 1
reverse - 1
max - 1
toLower - 1
partition - 1
remove - 1
takeWhile - 1
anyPass - 1
compose - 1
complement - 1
dissoc - 1
none - 1
prepend - 1
evolve - 1
insert - 1
without - 1
toPairs - 1
not - 1
split - 1
pickBy - 1
drop - 1

I could somewhat easily remove all of our uses of mergeRight and see what that does to the time it takes for the type-checker to run, since that function can just be replaced with the object spread operator - if you think that sort of test would be useful / if you agree that these merge functions might be the core of the problem, I can give that a go later, it'll just take some time to change all 48 uses hah.

Thanks! This is what I was asking for on gitter. I also think it is to do with merge.

Summarizing our findings so far:
using yarn run tsc --extendedDiagnostics, we saw that the Check time was around 52 seconds long in my prohect with these newest types for ramda. By only changing the return type on mergeRight we saw that time go down to 26 seconds!
So, I started to narrow down the 48 usages of mergeRight to see which of them were causing issues. While removing several usages initially, I was seeing mostly negligible differences in "Check time", with a reduction of roughly 4 seconds after 15 usages were removed.
Then, I was able to shave 15 seconds or so of this off just by removing 7 usages that all looked like this:
             <FontAwesomeIcon
               icon={faArrowCircleUp}
               className={className}
-              style={R.mergeRight(
-                {
-                  width: '17px',
-                  height: '17px',
-                },
-                style
-              )}
+              style={{
+                width: '17px',
+                height: '17px',
+                ...style,
+              }}
             />
           )
         }

The style prop on <FontAwesomeIcon> and the local var style (a local function parameter style: React.CSSProperties = {}) are of type React.CSSProperties which is quite a large type with lots of keys...

 A mapped type in a mapped type... So for an object of 500 properties, it escalated 500 iterations to 250000.
Thanks to this, I went through the whole codebase and optimized other types that are used everywhere (like ...Keys types). This should provide better performance overall (but not tremendous improvements).
Let me know of the new statistics for your project, and I hope that webpack module will do the job for you & your org.

today (ts-toolbelt@4.9.32):
Files:                       1735
Lines:                     275980
Nodes:                     988213
Identifiers:               318230
Symbols:                   595394
Types:                     292563
Memory used:              741845K
Assignability cache size:  184768
Identity cache size:        11600
Subtype cache size:         24148
I/O Read time:              0.51s
Parse time:                 1.71s
Program time:               3.69s
Bind time:                  1.27s
Check time:                27.09s
transformTime time:         2.12s
Source Map time:            0.44s
commentTime time:           0.46s
I/O Write time:             0.75s
printTime time:             6.81s
Emit time:                  6.81s
Total time:                38.86s
✨  Done in 39.62s.

which is great. I can save 3 more seconds by removing those R.mergeRights still though, so I'll still leave them out, but that's a major improvement nonetheless.

Hi @ekilah, is there a regression again?

Oh I see, not a regression. I'll try to allocate some time in the future to see if this type can be shortened. Not sure it can, though. I'll let you know

oh, no, sorry, I just wanted to show the conclusion for anyone seeing this issue later!

Just to ping, I successfully improved performance of MergeUp (again) as well as type correctness (where it had an unsound behavior for one edge-case).
So if you feel like you want to update, feel free to do it. However, I don't think the performance will change very much, it's more about the better (100%) type-safety.


Migrate to AndroidX

The AndroidX bindings official in release.
Android part of FlexiMVVM must be migrated to AndroidX instead of Support libraries to support new Android features and fixes of existing features.

All packages support for AndroidX for now.


Lack of HTTPS for the website

Has anyone in the project taken a look at https://netlify.com to switch from Github Pages? It's free, offers HTTPS, and a few other neat things.

Is there any reason why static html pages would need ssl?
IIRC cloudflare also offers free certificates + ssl + other stuff.

Actually, yes there are quite a few reasons. With HTTPS being used in search ranking and Google planning on marking all HTTP sites an insecure fairly soon, those should be enough to convince you.

That last reason, that chrome is actually going to mark all http sites as insecure is a good reason (eavsdropping etc. really is not an issue with knex doc pages also ISPs can do evil stuff even if one is using HTTPS e.g. dns requests are not encrypted).
Using letsencrypt is not that easy choise directly (at least when I tried that last time) thats the reason I would prefer cloudflare or some other service that handles providing lets encrypt related stuff internally and ”just work”.
I need to evaluate different options, maybe netlify is good. Anyways if chrome is going to criple all github pages, I hope that github is going to offer some standard/recommended solution which would be my choice number 1.
Need to investigate further when Im on laptop.

As of May 1, Github added SSL for custom domains on Github pages. I just triggered the cert generation process, they say it should be good within 24 hours.

Might take a little bit for the forced redirect http -> https

@tgriesser I think this might not be working anymore. In this age, whenever I come across any website which is not SSL secured, I feel that this website/product is of low quality due to the way browsers present these non-SSL sites.
Same thing happened with me today, when I came from google to http://knexjs.org.
Later I realized that knexjs is a huge library for nodejs db after looking at your github. But just from the first look, I might've missed your library.

https://hstspreload.org/?domain=knexjs.org doesn't show the site being preloaded nor redirecting from HTTP, as well. Though in Firefox it redirected to HTTPS. The preloading is still a good idea though.


feat(frontend): Cache request data

End-user friendly description of the problem this fixes or functionality that this introduces
We made too many frequent calls to our API, some which may trigger rate limits

[ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

Give a summary of what the PR does, explaining any non-trivial design decisions

Create a cache that stores data in local storage

Default TTL is 5 minutes

Cache relevant response data from the OpenHands API
All cache data is cleared on /logout client action

IMPORTANT NOTES:

I did not cache the direct requests to the GitHub API since those are already cached for 60 seconds (not to be confused with our authenticate endpoint which we do cache)
We should probably move to caching data through Cache-Control headers but for some reason was unsuccessful, might be our current request method. Since I already implemented Cache, I decided to save time and roll with it for now 🙃

Link of any specific issues this addresses

To run this PR locally, use the following command:
docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:89c2bf7-nikolaik   --name openhands-app-89c2bf7   docker.all-hands.dev/all-hands-ai/openhands:89c2bf7

@tofarr I've looked into it a while back, the problem is that you'd use the query hooks to handle data fetching, but a lot of our React Router / Remix handling is done outside components in the route data loaders.
Either we break practice of React Query or React Router, but I did see somewhere we can make them work together somehow with some annoyance in between. Definitely worth investigating further though


Tutorial: How to support object-fit: contain and object-fit: cover

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.
I noticed reading other issues (https://github.com/niklasvh/html2canvas/issues/2541, https://github.com/niklasvh/html2canvas/issues/2442, https://github.com/niklasvh/html2canvas/issues/725) that this property was not supported.
Here is the diff that solved my problem:
diff --git a/node_modules/html2canvas/dist/html2canvas.js b/node_modules/html2canvas/dist/html2canvas.js
index 84cb30d..8b8bc50 100644
--- a/node_modules/html2canvas/dist/html2canvas.js
+++ b/node_modules/html2canvas/dist/html2canvas.js
@@ -3028,6 +3028,22 @@
         }
     };

+    var objectFit = {
+        name: 'object-fit',
+        initialValue: 'fill',
+        prefix: false,
+        type: 2 /* IDENT_VALUE */,
+        parse: function (_context, overflow) {
+            switch (overflow) {
+                case 'contain':
+                    return "contain" /* BREAK_WORD */;
+                case 'cover':
+                default:
+                    return "cover" /* NORMAL */;
+            }
+        }
+    };
+
     var paddingForSide = function (side) { return ({
         name: "padding-" + side,
         initialValue: '0',
@@ -3665,6 +3681,7 @@
             this.overflowX = overflowTuple[0];
             this.overflowY = overflowTuple[overflowTuple.length > 1 ? 1 : 0];
             this.overflowWrap = parse(context, overflowWrap, declaration.overflowWrap);
+            this.objectFit = parse(context, objectFit, declaration.objectFit);
             this.paddingTop = parse(context, paddingTop, declaration.paddingTop);
             this.paddingRight = parse(context, paddingRight, declaration.paddingRight);
             this.paddingBottom = parse(context, paddingBottom, declaration.paddingBottom);
@@ -6803,13 +6820,52 @@
             });
         };
         CanvasRenderer.prototype.renderReplacedElement = function (container, curves, image) {
+            const objectFit = container.styles.objectFit;
+
             if (image && container.intrinsicWidth > 0 && container.intrinsicHeight > 0) {
                 var box = contentBox(container);
                 var path = calculatePaddingBoxPath(curves);
                 this.path(path);
                 this.ctx.save();
                 this.ctx.clip();
-                this.ctx.drawImage(image, 0, 0, container.intrinsicWidth, container.intrinsicHeight, box.left, box.top, box.width, box.height);
+
+                let newWidth;
+                let newHeight;
+                let newX = box.left;
+                let newY = box.top;
+
+                function getObjectFitSize(contains /* true = contain, false = cover */, containerWidth, containerHeight, width, height) {
+                    var doRatio = width / height;
+                    var cRatio = containerWidth / containerHeight;
+                    var targetWidth = 0;
+                    var targetHeight = 0;
+                    var test = contains ? (doRatio > cRatio) : (doRatio < cRatio);
+
+                    if (test) {
+                        targetWidth = containerWidth;
+                        targetHeight = targetWidth / doRatio;
+                    } else {
+                        targetHeight = containerHeight;
+                        targetWidth = targetHeight * doRatio;
+                    }
+
+                    return {
+                        width: targetWidth,
+                        height: targetHeight,
+                        x: (containerWidth - targetWidth) / 2,
+                        y: (containerHeight - targetHeight) / 2
+                    };
+                }
+
+                if (objectFit === 'contain' || objectFit === 'cover') {
+                    const { width, height, x, y } = getObjectFitSize(objectFit === 'contain', box.width, box.height, image.width, image.height);
+                    newWidth = width;
+                    newHeight = height;
+                    this.ctx.drawImage(image, 0, 0, container.intrinsicWidth, container.intrinsicHeight, newX + x, newY + y, newWidth, newHeight);
+                } else {
+                    this.ctx.drawImage(image, 0, 0, container.intrinsicWidth, container.intrinsicHeight, box.left, box.top, box.width, box.height);
+                }
+
                 this.ctx.restore();
             }
         };

This issue body was partially generated by patch-package.

Thanks a lot, Actually this solved the object-fit problem because i changed directly in the node_modules.
But the the problem when i deployed on vercel that these changes aren't applied.
note : using Next js

@Oussama-El-Benney you need to use patch-package with a postinstall script, so the changes are applied every time you (or vercel) does a postinstall

@Oussama-El-Benney you need to use patch-package with a postinstall script, so the changes are applied every time you (or vercel) does a postinstall

thanks, i'll try this

every good work, make my code rotate,love from china!

could we get this merged?

any chance to merge this? ty

https://www.npmjs.com/package/html2canvas-pro supports object-fit

Hi, I tried to change it like this, but it didn't take effect

Hi, I tried to change it like this, but it didn't take effect

try npmjs.com/package/html2canvas-pro, this supports object-fit

Hi, I tried to change it like this, but it didn't take effect

try npmjs.com/package/html2canvas-pro, this supports object-fit

Hum, I see that the commit history has been completely erased which is very shady. https://github.com/yorickshan/html2canvas-pro/commits/main/
I strongly recommend anyone to AVOID your html2canvas-pro,  we don't know what you changed, there could be a backdoor or something like that.
Please do a clean fork with commit history 🙏

Hi, I tried to change it like this, but it didn't take effect

try npmjs.com/package/html2canvas-pro, this supports object-fit

Hum, I see that the commit history has been completely erased which is very shady. yorickshan/html2canvas-pro@main (commits)
I strongly recommend anyone to AVOID your html2canvas-pro, we don't know what you changed, there could be a backdoor or something like that.
Please do a clean fork with commit history 🙏

Well, no backdoor or anything like that, just a suggestion in good faith.


[Android Huawei P30 lite] on-screen-keyboard loses connection to TextField after locking and unlocking the screen

Steps to reproduce

launch the app on a Huawei P30 lite
select the TextField (the keyboard opens)
lock the screen
unlock the screen (the keyboard should still be visible and the TextField should still be selected)
input text on the keyboard

Expected results
Typing on the on-screen keyboard should add text to the text field
Actual results
After unlocking the screen, the keyboard is still visible and the TextField still selected, but typing does not update the TextField.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Text Field Test',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: Scaffold(
        appBar: AppBar(
          backgroundColor: Theme.of(context).colorScheme.inversePrimary,
          title: const Text("Text Field Test"),
        ),
        body: const Center(
          child: TextField(),
        ),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration
Before locking the screen
https://github.com/flutter/flutter/assets/15897701/42434fe6-3550-459a-8344-6ef005bef01a
After unlocking the screen again
https://github.com/flutter/flutter/assets/15897701/1956ca94-1378-4a0f-937f-1d4331dccb15

Logs
Logs
Before locking the screen
Launching lib\main.dart on MAR LX1A in debug mode...
√  Built build\app\outputs\flutter-apk\app-debug.apk.
Connecting to VM Service at ws://<IP_ADDRESS>:11434/k_pHqcWAYyU=/ws
D/AwareBitmapCacher(31034): handleInit switch not opened pid=31034
I/DecorView[](31034): pkgName:com.example.text_field_test old windowMode:1 new windoMode:1, isFixedSize:false
W/Gralloc3(31034): mapper 3.x is not supported
I/HwViewRootImpl(31034): removeInvalidNode jank list is null
I/Hwaps   (31034): APS: EventAnalyzed: initAPS: version is <IP_ADDRESS>
D/Hwaps   (31034): Fpsrequest create,type:EXACTLY_IDENTIFY
D/Hwaps   (31034): Fpsrequest create,type:EXACTLY_IDENTIFY
D/Hwaps   (31034): Fpsrequest create,type:OPENGL_SETTING
D/Hwaps   (31034): FpsController create
D/Hwaps   (31034): APS: EventAnalyzed: reInitFpsPara :mBaseFps = 60; mMaxFps = 60
W/Settings(31034): Setting device_provisioned has moved from android.provider.Settings.Secure to android.provider.Settings.Global.
V/HiTouch_HiTouchSensor(31034): User setup is finished.
W/HwApsManager(31034): HwApsManagerService, registerCallback, start !
D/Hwaps   (31034): APS: EventAnalyzed: registerCallbackInApsManagerService, mPkgName:com.example.text_field_test; result = true
W/InputMethodManager(31034): startInputReason = 4
W/HwRemoteInputMethodManager(31034): isCasting false because IHwDistributedWindowManager is invalid.
I/InputMethodManager(31034): showSoftInput
I/HwViewRootImpl(31034): removeInvalidNode all the node in jank list is out of time
I/AssistStructure(31034): Flattened final assist data: 468 bytes, containing 1 windows, 3 views
D/InputConnectionAdaptor(31034): The input method toggled cursor monitoring on
I/InputMethodManager(31034): showSoftInput
I/InputMethodManager(31034): showSoftInput
I/InputMethodManager(31034): showSoftInput
I/InputMethodManager(31034): showSoftInput
I/InputMethodManager(31034): showSoftInput

After unlocking the screen again
W/InputMethodManager(31034): startInputReason = 8
W/HwRemoteInputMethodManager(31034): isCasting false because IHwDistributedWindowManager is invalid.
W/IInputConnectionWrapper(31034): requestCursorAnchorInfo on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextAfterCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): getSelectedText on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): requestCursorAnchorInfo on inactive InputConnection
E/RtgSchedManager(31034): endActivityTransaction: margin state not match
E/RtgSchedManager(31034): endActivityTransaction: margin state not match
E/RtgSchedManager(31034): endActivityTransaction: margin state not match
W/libEGL  (31034): EGLNativeWindowType 0x7044b62010 disconnect failed
W/HwRemoteInputMethodManager(31034): isCasting false because IHwDistributedWindowManager is invalid.
I/HwViewRootImpl(31034): removeInvalidNode all the node in jank list is out of time
W/libEGL  (31034): EGLNativeWindowType 0x70a9158c10 disconnect failed
I/ActivityThread(31034): Handle window ActivityRecord{98c7745 token=android.os.BinderProxy@688a3c7 {com.example.text_field_test/com.example.text_field_test.MainActivity}} visibility: false
E/RtgSchedManager(31034): endActivityTransaction: margin state not match
D/DecorView(31034): showOrHideHighlightView: hasFocus=false; winMode=1; isMrgNull=true
I/RmeSchedManager(31034): init Rme, version is: v1.0
D/ZrHung.AppEyeUiProbe(31034): not watching, wait.
W/IInputConnectionWrapper(31034): requestCursorAnchorInfo on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): getTextBeforeCursor on inactive InputConnection
W/IInputConnectionWrapper(31034): requestCursorAnchorInfo on inactive InputConnection
D/ActivityThread(31034): Won't deliver top position change in state=5
D/ZrHung.AppEyeUiProbe(31034): restart watching
I/RmeSchedManager(31034): init Rme, version is: v1.0
I/RtgSchedEvent(31034): current pid:31034 AppType:-1
D/mali_winsys(31034): EGLint new_window_surface(egl_winsys_display *, void *, EGLSurface, EGLConfig, egl_winsys_surface **, EGLBoolean) returns 0x3000
D/mali_winsys(31034): EGLint new_window_surface(egl_winsys_display *, void *, EGLSurface, EGLConfig, egl_winsys_surface **, EGLBoolean) returns 0x3000
D/DecorView(31034): showOrHideHighlightView: hasFocus=true; winMode=1; isMrgNull=true
W/InputMethodManager(31034): startInputReason = 1
W/HwRemoteInputMethodManager(31034): isCasting false because IHwDistributedWindowManager is invalid.
W/IInputConnectionWrapper(31034): requestCursorAnchorInfo on inactive InputConnection
I/RmeSchedManager(31034): init Rme, version is: v1.0
I/RtgSchedEvent(31034): current pid:31034 AppType:-1

Flutter Doctor output
Doctor output
[√] Flutter (Channel stable, 3.16.5, on Microsoft Windows [Version 10.0.22621.2861], locale de-DE)
    • Flutter version 3.16.5 on channel stable at D:\dev\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 78666c8dc5 (2 weeks ago), 2023-12-19 16:14:14 -0800
    • Engine revision 3f3e560236
    • Dart version 3.2.3
    • DevTools version 2.28.4

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
    • Android SDK at D:/dev/Android/sdk
    • Platform android-33, build-tools 33.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-b2043.56-10550314)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[X] Visual Studio - develop Windows apps
    X Visual Studio not installed; this is necessary to develop Windows apps.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components

[√] Android Studio (version 2023.1)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-b2043.56-10550314)

[√] VS Code, 64-bit edition (version 1.84.2)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.78.0

[√] Connected device (5 available)
    • MAR LX1A (mobile)          • L2NDU20213003967 • android-arm64  • Android 10 (API 29)
    • sdk gphone x86 64 (mobile) • emulator-5554    • android-x64    • Android 13 (API 33) (emulator)
    • Windows (desktop)          • windows          • windows-x64    • Microsoft Windows [Version 10.0.22621.2861]
    • Chrome (web)               • chrome           • web-javascript • Google Chrome 120.0.6099.130
    • Edge (web)                 • edge             • web-javascript • Microsoft Edge 120.0.2210.91

[√] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

Thanks for the report. This occurs on my device Realme 6, Android 11 as well. And this is a known issue being tracked at https://github.com/flutter/flutter/issues/137667. You can try the workaround at https://github.com/flutter/flutter/issues/137667#issuecomment-1788758324 until it has a fix for that issue.
Closing this issue as a duplicate, so please follow up on it for further updates.


storybook Component

what does this PR do?

Storybook component
Button component
Button color stories

how this should be test manually?

run npm install
run npm run storybook
go and check how is your component is looking

ch[storybook-component]
screenshot
Button storybook on colors

Button storybook on sizes

Dear @Evaristekanova,  help can me to run this for reviewing ??

You may ignore pushing some files and they are automatically created when specified  commads  in PR message runs.


[Question] Using Bot Token and Deleteting All Messages

WARNING: Github Issues are publicly visible, do not post sensitive information here.
You may want to use the "Screenshot mode" before taking screenshots or copying logs.

Describe what your question is, try to give as much detail as possible so I can help you.
Post screenshots if applicable.
How do I use this with a bot token? To avoid self-botting.
The bot has access to all messages, how to also delete all those messages or specific (ex. from webhooks).

Discord doesn't care about self botting unless it's destructive (mass advertising), so you shouldn't even worry about that. Also it's impossible to tell it was a selfbot and not a human deleting a ton of messages so you would have an almost 0% risk of getting termed. But if you really want to use the bot just try putting the bot token and seeing what happens, do keep in mind it might not work. Some api endpoints are only accessible by users and some only by bots, if this project is programmed to use user endpoints then a bot might not be able to run it. Also I'm not sure if this project deletes just your messages or all messages, so it my not delete anything with a bot. Finally if you just want to wipe a discord channel then you can just get a nuke bot (clones the channel and deletes the old one)


ports: Python 3.11

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.
FreeBSD ports is still on 3.9 but 3.11 should be a lot faster and there is no reason not to try early.
Describe the solution you like
If the test is ok move a 24.1.x to Python 3.11. Perhaps one or two ports have issues?
Describe alternatives you considered
Waiting for FreeBSD ports to make the move.
Additional context
N/A

3.11 is currently the oldest bugfix release https://devguide.python.org/versions/
We could aim for 3.12 but the more we move ahead the riskier the upgrade in general.


Code assistance context menu is missing

What happened?
DartPad appears to have been updated in a major way. I noticed that following the update, the code assistance context menu for Flutter (with commands like "Wrap in SizedBox", "Remove widget", "Swap with parent", etc) is no longer accessible.
Steps to reproduce problem
Open DartPad, switch to a Flutter sample, position the cursor on a widget constructor and press Opt-Enter (for Mac, may vary by OS).
Browser
Browser: Chrome
Version: 121.0.6167.160
Are you using any extensions/plugins that affect website behavior
(particularly those that affect iframes, such as ad blockers)? No
Are there any warnings or errors in your browser's JavaScript console? No
Machine
Operating system: MacOS
Version: Sonoma 14.3.1

It works similarly in VS Code and AndroidStudio when using the Flutter plugins.

I think the issue is that keybinding changed - it's now command-. (visible from the keybindings shortcut action in the bottom left).

It may be that we should alias the keyboard shortcut?

Oh interesting. I guess this changed from the AndroidStudio key binding to the VS Code keybinding. It would be much appreciated if you could support both!

It works similarly in VS Code and AndroidStudio when using the Flutter plugins.

Right, but one big difference is that they show a small UI element (in code it's a lightbulb) to let the user know that this menu exists. I've love to see something similar in DartPad.

That's true.


Update the game over message

Update the game over message so people know how to play again!

j;

'

i;

;


feat(deps): update listener-radio dependencies (feat/renovate-precommit)

This PR contains the following updates:

Package
Update
Change

ghcr.io/graphops/subgraph-radio
patch
0.1.6 -> 0.1.7

us-docker.pkg.dev/oplabs-tools-artifacts/images/proxyd
minor
v4.2.5 -> v4.3.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: charts/subgraph-radio/Chart.yaml
Command failed: bash scripts/renovate.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    80  100    80    0     0    400      0 --:--:-- --:--:-- --:--:--   400

100    75  100    75    0     0    154      0 --:--:-- --:--:-- --:--:--   154

  1 63.5M    1 1167k    0     0  1514k      0  0:00:42 --:--:--  0:00:42 1514k
 48 63.5M   48 30.5M    0     0  17.2M      0  0:00:03  0:00:01  0:00:02 29.4M
 98 63.5M   98 62.3M    0     0  22.5M      0  0:00:02  0:00:02 --:--:-- 30.6M
100 63.5M  100 63.5M    0     0  22.5M      0  0:00:02  0:00:02 --:--:-- 30.5M
go: downloading github.com/norwoodj/helm-docs v1.11.2
go: downloading github.com/sirupsen/logrus v1.2.0
go: downloading github.com/spf13/cobra v0.0.5
go: downloading github.com/spf13/viper v1.4.0
go: downloading github.com/Masterminds/sprig/v3 v3.2.2
go: downloading github.com/gobwas/glob v0.2.3
go: downloading gopkg.in/yaml.v3 v3.0.0-20200615113413-eeeca48fe776
go: downloading github.com/fsnotify/fsnotify v1.4.7
go: downloading github.com/hashicorp/hcl v1.0.0
go: downloading github.com/magiconair/properties v1.8.0
go: downloading github.com/mitchellh/mapstructure v1.1.2
go: downloading github.com/pelletier/go-toml v1.2.0
go: downloading github.com/spf13/afero v1.1.2
go: downloading github.com/spf13/cast v1.3.1
go: downloading github.com/spf13/jwalterweatherman v1.0.0
go: downloading github.com/spf13/pflag v1.0.3
go: downloading gopkg.in/yaml.v2 v2.3.0
go: downloading golang.org/x/crypto v0.0.0-20200414173820-0848c9571904
go: downloading k8s.io/helm v2.14.3+incompatible
go: downloading github.com/Masterminds/goutils v1.1.1
go: downloading github.com/Masterminds/semver/v3 v3.1.1
go: downloading github.com/google/uuid v1.1.1
go: downloading github.com/huandu/xstrings v1.3.1
go: downloading github.com/imdario/mergo v0.3.11
go: downloading github.com/mitchellh/copystructure v1.0.0
go: downloading github.com/shopspring/decimal v1.2.0
go: downloading golang.org/x/sys v0.0.0-20220330033206-e17cdc41300f
go: downloading golang.org/x/text v0.3.0
go: downloading github.com/mitchellh/reflectwalk v1.0.0
Error: Template file 'README.md.gotmpl' not found.

File name: charts/proxyd/Chart.yaml
Command failed: bash scripts/renovate.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    80  100    80    0     0    467      0 --:--:-- --:--:-- --:--:--   467

100    75  100    75    0     0    174      0 --:--:-- --:--:-- --:--:--   174

 10 63.5M   10 6975k    0     0  7140k      0  0:00:09 --:--:--  0:00:09 7140k
 59 63.5M   59 37.7M    0     0  19.1M      0  0:00:03  0:00:01  0:00:02 30.9M
 91 63.5M   91 57.9M    0     0  19.4M      0  0:00:03  0:00:02  0:00:01 25.5M
100 63.5M  100 63.5M    0     0  20.2M      0  0:00:03  0:00:03 --:--:-- 26.2M
Error: Template file 'README.md.gotmpl' not found.


Actions improvement and UX improvement when Actions is running

Hello! This is the prull request to update our Actions or our data update system.
Fire a message when the update Action is running
Close #158

When the system detect that the Actions is running on updating the beatmap metadata system, the system will notified user so if user feel interruption on the beatmap card the user will now know that it's because the update system. I think the message can be better...
Make admin cannot run the Actions script when same Actions is running
Close #157

To make the server is not loading too much due to a lot of Actions, if the system detect that it has the Actions that is running with the same name it will block from starting the new worker with a same Actions scheme.
I also adding a block on the launch view to avoid user running it via the view or URL that we set.
Add the delete Actions log button
Close #156

Add the delete log button to avoid the Actions page not have too much log on one page. As before, the button will update real-time when the status of the worker is change.
Security method
I have added to protect the log deletion when that log is bind with the worker that is running or in the idle state to avoid the error.
Other improvement

Fix method to fetch log url cannot handle error when no log file
Delete unused code
Add error handle when the action finish but cannot calculate time due to no finish time

Please try on it before approve. Thanks!

Let's merge it!


Japanese Translation Layout is collapsing

Japanese Translation Layout is collapsing in the image of "How can I use managed identities for Azure resources?".
https://docs.microsoft.com/ja-jp/azure/active-directory/managed-identities-azure-resources/overview#how-can-i-use-managed-identities-for-azure-resources

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

ID: 72861cc1-7081-cf6e-b7f9-e700a16faa9a
Version Independent ID: c870872d-0559-6b77-280f-f478e8c84776
Content: Managed identities for Azure resources
Content Source: articles/active-directory/managed-identities-azure-resources/overview.md
Service: active-directory
Sub-service: msi
GitHub Login: @barclayn
Microsoft Alias: barclayn

@kota-yamada Thank you for your feedback . We will get this checked and update the thread.

@kota-yamada  I hope you are talking about the below . We will get this checked internally with the content team and update.

@kota-yamada We have reported this internally to the team and they will check and update the content layout for the japanese version.

Yes, the image is what I am talking about.


桑基图节点很小时，link展示中断

Version
4.2.1
Reproduction link
https://www.echartsjs.com/gallery/editor.html?c=sankey-energy
Steps to reproduce
桑基图节点很小时，link展示中断
What is expected?
桑基图节点很小时，link展示不要中断
What is actually happening?
桑基图节点很小时，link展示中断

Same here, looking forward to any update.

We seem to solve this problem before, and it works normally on my computer.  Do you still have this problem?

Tried several sankey graph just now,  didn't reproduce.
Not sure if it's solved or just not the right data to reproduce.
I'll post again if it happens.
thanks deqing!

@helloNLw @Boxie5  I will close this issue, if your still have any problem, feel free to reopen this issue.


🐞 Bug: simulator cannot load data to RAM/EEPROM with BitWidth > 30

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
If you try to Load Data to a RAM o EEPROM element with BitWidth > 30 the load does not work.
To be more precise, it rejects any value when BitWidth = 31 and it only accepts zero as value when BitWidth = 32.

Steps To Reproduce

Launch the Simulator
Add a RAM element to the circuit.
Select the RAM and set BitWidth = 32 for it.
Click Load Data.
Enter a list of natural numbers, at least one positive. For example 0 0 5.
Click OK.
The unexpected error Address X: Y is too large is generated.

Expected Behavior
It should accept any number in the range [0, 2^BitWidth - 1].
Screenshots
No response
Device Information [optional]
No response
Additional context
No response
Are you working on this issue?
Yes

cc @pulkit-30 @Prerna-0202

Are you not merging this simple and necessary fix?

@jluini Sorry for keep you waiting, we will soon review the issue and PR!
PS: most of the maintainers are students or working professionals. We work on our free time to contribute to CircuitVerse. It might took sometime for us to response. Also, GSoC coding period have started, we are busy with that too. I hope you understand. Thankyou!

@vedant-jain03 thank you and sorry for my impatient-looking message. I just was wondering if there's anything wrong with my PR.
The bug is pretty relevant, and the solution is almost trivial and can be tested in the JS console in 1 min.
Thanks and sorry again.


Add Tim, remove Bruno from build related emails

My mailbox will miss the morning workout.

@bbguimaraes I'll still forward you buildvm-maint errors if you start missing them too much :)


Negative Put Prices

The library produces negative prices for put options having small delta. Calls don't have this behaviour (price tends to zero, as expected).
i.e compare:
BlackScholesCall(4600, 0.19, 4400, float(5)/365, 0.01).price # 201.4
BlackScholesPut(4600, 0.19, 4400, float(5)/365, 0.01).price # -190.6

or see (where price and delta columns are derived from q-fin BlackScholesPut)

I'm wondering what I should make of this -- whether there's an error with the library, or a quirk of BS model (in which case I can take a floor of zero of put price value).

I've just tried the same with py-vollib. The price seems more normal, indicating a bug with q-fin.

Hey there thank you for raising this issue!  The library was using d2 and d1 backward for Black-Scholes puts, rolling out an updated version of QFin fixing this now!


Add support for slang

You might also want to checkout slang

slang is a software library that provides various components for lexing, parsing, type checking, and elaborating SystemVerilog code. It comes with an executable tool that can compile and lint any SystemVerilog project, but it is also intended to be usable as a front end for synthesis tools, simulators, linters, code editors, and refactoring tools.
Full documentation is available on the website: https://sv-lang.com

I have started working on support for slang, thanks for the suggestion! Development is happening in the slang branch. As of now I think I have slang talking with the linter properly, but I still have to iron out some details.

I've now ironed out the issues I found, and published a new minor release with support for slang (952b73f).


math: Add fixed point approximation for natural log

Problem
Natural logs are not possible to calculate in fixed-point terms.
Solution
Add an approximation for ln using a Taylor approximation (probably only possible with PreciseNumber around 1), or using linear interpolation.

I'd like to work on this

Great, feel free to submit a draft pull request if you want to discuss anything


Ianvs prettier plugin sort imports

I edited this in GH so commits aren't squashed, but yolo.
@ianvs/prettier-plugin-sort-imports fork has been better and preserves order of side-effect imports.

Will take a look at this soon. It doesn't appear to work in the tests so there might be something else going on or the test needs to be tweaked for this plugin.

Will take a look at this soon. It doesn't appear to work in the tests so there might be something else going on or the test needs to be tweaked for this plugin.

Awesome.  Yeah, normally I would have contributed to this on my machine but I've been away for a while and busy with various things.  I don't think I'll have time to fix it any time soon.
To be honest, it sort of bugs me when someone forks something to add their feature then keep adding to it without contributing to the original fork. :(. But it does have a feature that is really important for a lot of people.  We use side-effect imports at a top level to prepare environment variables, etc.  Most use it for polyfils, etc, so it should really exist in the original sorting plugin.
Thanks for taking a look at it.

Alright I figured out what was wrong there. We were testing using import "./foo" which is a side-effect import ovbs so I tweaked the tests to account for that. Thanks!

Haha, that makes sense.  Well this is awesome to see.  Thanks so much.
Cheers!

To be honest, it sort of bugs me when someone forks something to add their feature then keep adding to it without contributing to the original fork.

@thecrypticace I would normally agree. However, the trivago plugin is barely maintained, so improving it was not really possible. By working on the fork, we can keep pushing forward and give people options of which one to use.
Glad you've found it useful!  We're about to release a breaking change to simplify options and improve defaults. Would love if you were willing to try it out by installing it with @next.  And please submit any questions or issues you come across.


issue while loading Arabic language

I have integrated example of jquery-i18n-properties.
It's working fine for Messages.properties and Messages_es_ES.properties.
But when I tried to load arabic then it shows ?????? symbol.
I have created Messages_ar.properties file with arabic content in it. when I pass value ar to language then it shows me ????? only..
Am I missing something ?

Hello, it was IDE problem. I have to set utf-8 at file level as well.


Term provenance broken?

When I lookup a certain version for a term the replaces field points me to the exact same version:
http://rs.tdwg.org/dwc/terms/version/minimumDepthInMeters-2023-06-28.htm
I would have expected the previous version to be linked instead or nothing if there wasnt any (which maybe should be highlighted )
Similar cases:

http://rs.tdwg.org/dwc/terms/version/minimumElevationInMeters-2023-06-28.htm
http://rs.tdwg.org/dwc/terms/version/minimumDistanceAboveSurfaceInMeters-2023-06-28.htm

same is true in json or rdf: http://rs.tdwg.org/dwc/terms/version/minimumElevationInMeters-2023-06-28.json

The older versions do correctly link: http://rs.tdwg.org/dwc/version/terms/2021-07-15.htm

Thanks, @mdoering  Something's wrong in the term replacements table. I will try to figure out what's wrong and how it happened.


Metrics doesn't work in a keycloak cluster

If you setup a keycloak cluster with two or more nodes, when you ask to node1 you get X number of logins and when you ask to node2 you can get X-2 number of logins.
This it's because you put a loadbalancer in front with a round-robin  balance and you ask to each node independently.
There's any plan to store and read this data from the database or at least share the data between nodes?

We have the same problem. A solution to this would be to add support for pushing to a prometheus pushgateway.


Make:Code Extension Approval?

Hello,
Thanks for sharing your work. I'm a teacher and have been fighting with a different rotary encoder extension on Make:Code for quite a while before following a trail to your extension, which just works.
For our students, it's a tiny bit nicer to be able to search the extension straight from Make:code rather than having to enter a repo URL. Would you consider submitting this extension for official approval? Alternatively, if you would prefer I could fork this repo and do the work of going through those steps. I'm not so experienced in this area, but I am sure I can figure it out. I drew up a little card for the extension too.

Hello,
feel free to use it and to let approve it. The image is quite nice!
Michael


Add documentation on multiple backend pattern

One pattern that is emerging pretty heavily in Artichoke is the idea of swappable backends:

Regexp and MatchData can be implemented with either the onig or regex crates.
Filesystem access can either be via a fake in-memory filesystem or the system filesystem.
The VM backend is swappable by implementing artichoke-core.
The C API is swappable and multiple backends can implement multiple C APIs.

Document this approach.

The work on the spinoso crates is moving away from this toward having multiple source-compatible backends. For example spinoso_array::Array and spinoso_array::SmallArray that backends would select at compile-time using Cargo features.
Closing WONTFIX.