Add pthread support for Emscripten build.

I opened a pull request [#841] before seeing the note regarding the preference for issues.
The current CMakeLists.txt doesn’t include the required flags for Emscripten’s pthread support, which causes the built .wasm file to fail the MultithreadingTest when run in a browser (tested in Chrome, Safari, and Firefox for MacOS). Adding these flags results in all tests passing when running in a browser environment.

Are trying to build the unit tests in WASM? Did you actually get performance gains compiling enkiTS in WASM?
This does not appear to be a supported platform for enkiTS. https://github.com/dougbinks/enkiTS
I don't think it makes sense for me to try to support this without a github action that verifies it builds and runs correctly. You might also work with the enkiTS team so they run tests in WASM. I don't see such a target:
https://github.com/dougbinks/enkiTS/blob/master/.github/workflows/build.yml

Yes, I was trying to build the unit tests in WASM as the first step in writing WASM bindings for this library (similar to [https://github.com/Birch-san/box2d-wasm] for Box2D 2.x). Despite enkiTS not specifying it is WASM compatible, it appears to be with the changes I made to the Emscripten build script in [#841], as the unit tests run successfully in most modern browsers with the change. The change to the build script enables pthread support [https://emscripten.org/docs/porting/pthreads.html], which is all that seems to be necessary to get enki’s TaskScheduler working as expected in WASM. However, I aim to dig deeper into this as I look at writing bindings for the WASM version.
One more caveat, Emscriptens implementation for pthread requires SharedArrayBuffer [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer] in a browser context, which has been sandboxed due to timing attacks in Spectre. So, in order to successfully load the WASM into a browser you need to do it via a web server with the page embedding the code served with the correct CORS settings. I have a working version of this using NPM and Express [https://github.com/expressjs/express]. Would it be helpful to provide a repo with this setup?
The following is the console output from Chrome Version 131.0.6778.86 (Official Build) (arm64) for MacOS both before and after the changes to the Emscripten build process enabling pthread support. The MultithreadingTest that was failing before this change now passes, which is why I am assuming enkiTS’s TaskScheduler is successfully compiled to WASM.
Before (failing):
test.js:546 Aborted(native code called abort())
test.js:564 Uncaught (in promise) RuntimeError: Aborted(native code called abort())
at abort (http://localhost:3000/js/test.js:564:11)
at __abort_js (http://localhost:3000/js/test.js:1060:7)
at test.wasm.abort (http://localhost:3000/js/test.wasm:wasm-function[1175]:0xdb538)
at test.wasm.std::__2::__throw_system_error(int, char const*) (http://localhost:3000/js/test.wasm:wasm-function[1180]:0xdb60f)
at test.wasm.std::__2::thread::thread<void (&)(enki::ThreadArgs const&), enki::ThreadArgs, void>(void (&)(enki::ThreadArgs const&), enki::ThreadArgs&&) (http://localhost:3000/js/test.wasm:wasm-function[885]:0xca7b9)
at test.wasm.enki::TaskScheduler::StartThreads() (http://localhost:3000/js/test.wasm:wasm-function[877]:0xc9c89)
at test.wasm.enki::TaskScheduler::Initialize(enki::TaskSchedulerConfig) (http://localhost:3000/js/test.wasm:wasm-function[967]:0xd0794)
at test.wasm.enkiInitTaskSchedulerWithConfig (http://localhost:3000/js/test.wasm:wasm-function[1044]:0xd3a59)
at test.wasm.TiltedStacks (http://localhost:3000/js/test.wasm:wasm-function[21]:0x3bcc)
at test.wasm.MultithreadingTest (http://localhost:3000/js/test.wasm:wasm-function[19]:0x2321)
After (passing):
test.js:2077 Starting Box2D unit tests
test.js:2077 ======================================
test.js:2077 test passed: BitSetTest
test.js:2077   subtest passed: AABBTest
test.js:2077 test passed: CollisionTest
test.js:2659 run complete
test.js:2660 Object
test.js:2659 run complete
test.js:2660 Object
test.js:2659 run complete
test.js:2660 Object
test.js:2077   subtest passed: MultithreadingTest
test.js:2077 step = 281, hash = 0x7efc22e7
test.js:2077   subtest passed: CrossPlatformTest
test.js:2077 test passed: DeterminismTest
test.js:2077   subtest passed: SegmentDistanceTest
test.js:2077   subtest passed: ShapeDistanceTest
test.js:2077   subtest passed: ShapeCastTest
test.js:2077   subtest passed: TimeOfImpactTest
test.js:2077 test passed: DistanceTest
test.js:2077 test passed: IdTest
test.js:2077 test passed: MathTest
test.js:2077   subtest passed: ShapeMassTest
test.js:2077   subtest passed: ShapeAABBTest
test.js:2077   subtest passed: PointInShapeTest
test.js:2077   subtest passed: RayCastShapeTest
test.js:2077 test passed: ShapeTest
test.js:2077 set: count = 50086, b2ContainsKey = 0.00000 ms, ave = 0.00000 us
test.js:2077 item count = 50086, probe count = 15540, ave probe count 0.31
test.js:2077 test passed: TableTest
test.js:2077   subtest passed: TestForAmy
test.js:2077   subtest passed: HelloWorld
test.js:2077   subtest passed: EmptyWorld
test.js:2077   subtest passed: DestroyAllBodiesWorld
test.js:2077   subtest passed: TestIsValid
test.js:2077   subtest passed: TestWorldRecycle
test.js:2077 test passed: WorldTest
test.js:2077 ======================================
test.js:2077 All Box2D tests passed!

I think it makes sense to run the unit tests on WASM. I would like to know if building Box2D for WASM with enkiTS yields better performance than single threaded. If not, I could simply add a cmake option to exclude enkiTS from the unit test build.
It is also not clear to me if enkiTS is a good choice of a task schedular for WASM. Maybe there are other options that work better.
Maybe @dougbinks has thoughts on this.

@erincatto I'm afraid I know very little about WASM. If it supports threads and atomics (as it seems to from @aleph1's tests ) then there is little reason why it would not give a similar performance boost to enkiTS on a native platform.

Until I write the bindings for the new version of Box2D it’s not easy to determine, unless I write some additional performance tests in C/C++ and also compile this to WASM. I would assume with the tests passing in the browser this is working as expected. I can try to look at the test code for Box2D and see if they can be profiled for performance in the browser? Most of the tests don’t seem to include information pertaining to code execution time, and I can’t actually compile for single thread successfully, but at least if we had execution time for native C and WASM it would give people considering using the library for WASM purposes some clarity.
My aim is to start to run at the WASM bindings over the next couple of months. I currently use Rapier in my game prototyping stack which is primarily JavaScript and TypeScript based, so having a WASM build that is easy to use would mean I could try swapping Rapier for Box2D as well as releasing it to the community.

On Nov 30, 2024, at 11:50 AM, Doug Binks @.***> wrote:

@erincatto I'm afraid I know very little about WASM. If it supports threads and atomics (as it seems to from @aleph1's tests ) then there is little reason why it would not give a similar performance boost to enkiTS on a native platform.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

If you are able to build the unit tests on WASM, you should also be able to build the benchmark application. This allows you to specify a thread count and generates csv results.

I have managed to get the benchmarks compiling as WASM, however, there are two distinct issues:

The logging seems suspect in that run durations are always reported as 0 (ms), and fps as inf. The same is true when running the compiled tests in Chrome and Firefox.

Log from Chrome Version 131.0.6778.86 (Official Build) (arm64) on MacOS 12.7.4 (21H1123):
Starting Box2D benchmarks
benchmark.js:2224 ======================================
benchmark.js:2224 benchmark: joint_grid, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 100 / shape 100 / contact 0 / joint 180 / stack 24192
benchmark.js:2224
benchmark.js:2224 benchmark: large_pyramid, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 211 / shape 211 / contact 590 / joint 0 / stack 99136
benchmark.js:2224
benchmark.js:2224 benchmark: many_pyramids, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 1376 / shape 1380 / contact 3625 / joint 0 / stack 609024
benchmark.js:2224
benchmark.js:2224 benchmark: rain, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 67 / shape 681 / contact 0 / joint 60 / stack 20288
benchmark.js:2224
benchmark.js:2224 benchmark: smash, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 201 / shape 201 / contact 712 / joint 0 / stack 52288
benchmark.js:2224
benchmark.js:2224 benchmark: spinner, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 501 / shape 860 / contact 80 / joint 1 / stack 130016
benchmark.js:2224
benchmark.js:2224 benchmark: tumbler, steps = 10
benchmark.js:2224 thread count: 1
benchmark.js:2224 run 0 : 0 (ms), inf (fps)
benchmark.js:2224 run 1 : 0 (ms), inf (fps)
benchmark.js:2224 run 2 : 0 (ms), inf (fps)
benchmark.js:2224 run 3 : 0 (ms), inf (fps)
benchmark.js:2224 body 402 / shape 404 / contact 0 / joint 1 / stack 105056
benchmark.js:2224
benchmark.js:2224 ======================================
benchmark.js:2224 All Box2D benchmarks complete!
Log from Firefox 133.0 (aarch64) on MacOS 12.7.4 (21H1123):
Starting Box2D benchmarks benchmark.js:2224:16
====================================== benchmark.js:2224:16
benchmark: joint_grid, steps = 10 benchmark.js:2224:16
thread count: 1 benchmark.js:2224:16
run 0 : 0 (ms), inf (fps) benchmark.js:2224:16
run 1 : 0 (ms), inf (fps) benchmark.js:2224:16
run 2 : 0 (ms), inf (fps) benchmark.js:2224:16
run 3 : 0 (ms), inf (fps) benchmark.js:2224:16
body 100 / shape 100 / contact 0 / joint 180 / stack 24192 benchmark.js:2224:16
 benchmark.js:2224:16
benchmark: large_pyramid, steps = 10 benchmark.js:2224:16
thread count: 1 benchmark.js:2224:16
run 0 : 0 (ms), inf (fps) benchmark.js:2224:16
run 1 : 0 (ms), inf (fps) benchmark.js:2224:16
run 2 : 0 (ms), inf (fps) benchmark.js:2224:16
run 3 : 0 (ms), inf (fps) benchmark.js:2224:16
body 211 / shape 211 / contact 590 / joint 0 / stack 99136 benchmark.js:2224:16
 benchmark.js:2224:16
benchmark: many_pyramids, steps = 10 benchmark.js:2224:16
thread count: 1 benchmark.js:2224:16
run 0 : 0 (ms), inf (fps) benchmark.js:2224:16
run 1 : 0 (ms), inf (fps) benchmark.js:2224:16
run 2 : 0 (ms), inf (fps) benchmark.js:2224:16
run 3 : 0 (ms), inf (fps) benchmark.js:2224:16
body 1376 / shape 1380 / contact 3625 / joint 0 / stack 609024 benchmark.js:2224:16
 benchmark.js:2224:16
benchmark: rain, steps = 10 benchmark.js:2224:16
thread count: 1 benchmark.js:2224:16
run 0 : 0 (ms), inf (fps) benchmark.js:2224:16
run 1 : 0 (ms), inf (fps) benchmark.js:2224:16
run 2 : 0 (ms), inf (fps) benchmark.js:2224:16
run 3 : 0 (ms), inf (fps) benchmark.js:2224:16
body 67 / shape 681 / contact 0 / joint 60 / stack 20288 benchmark.js:2224:16
 benchmark.js:2224:16
benchmark: smash, steps = 10 benchmark.js:2224:16
thread count: 1 benchmark.js:2224:16
run 0 : 0 (ms), inf (fps) benchmark.js:2224:16
run 1 : 0 (ms), inf (fps) benchmark.js:2224:16
run 2 : 0 (ms), inf (fps) benchmark.js:2224:16
run 3 : 0 (ms), inf (fps) benchmark.js:2224:16
body 201 / shape 201 / contact 712 / joint 0 / stack 52288 benchmark.js:2224:16
 benchmark.js:2224:16
benchmark: spinner, steps = 10 benchmark.js:2224:16
thread count: 1 benchmark.js:2224:16
run 0 : 0 (ms), inf (fps) benchmark.js:2224:16
run 1 : 0 (ms), inf (fps) benchmark.js:2224:16
run 2 : 0 (ms), inf (fps) benchmark.js:2224:16
run 3 : 0 (ms), inf (fps) benchmark.js:2224:16
body 501 / shape 860 / contact 80 / joint 1 / stack 130016 benchmark.js:2224:16
 benchmark.js:2224:16

There seems to be a conflict between specifying the number of threads that the Emscripten compiled WASM should use -s PTHREAD_POOL_SIZE=number and the code that limits the max number of threads in (https://github.com/erincatto/box2d/blob/main/benchmark/main.c). It would seem the GetNumberOfCores function should include a check for EMSCRIPTEN and pass the number of threads from PTHREAD_POOL_SIZE.

I'm guessing b2Timer is not getting implemented for emscripten. You could try changing this line to:
#elif defined( __linux__ ) || defined( __APPLE__ ) || defined(__EMSCRIPTEN__)

https://github.com/erincatto/box2d/blob/41e067c6d11f214a6ef1700361c5f27657575c73/src/timer.c#L79
Similar for GetNumberOfCores. I simply haven't tested this stuff on WASM.

Making that change and modifying the following to include  || defined(__EMSCRIPTEN__) seems to result in things running as expected in WASM in the browser:
https://github.com/erincatto/box2d/blob/2c939c287bfcffcd9ae12ce34db486f6e0bd17e2/include/box2d/base.h#L118-L120
Are these changes something you would be willing to commit if I update the pull request or would I need to maintain a fork?

I can add your changes to cmake, but I will leave a note that they are not supported until I have an emscripten build in GitHub actions. There current build script is here: https://github.com/erincatto/box2d/blob/main/.github/workflows/build.yml
Did you run the benchmarks again? Are you seen performance improve with threading?

I am getting improved results. I temporarily hardcoded a value for GetNumberOfCores when EMSCRIPTEN is defined in  as I don’t think sysconf can be relied upon, and the Emscripten setting -s PTHREAD_POOL_SIZE=number should probably be used instead.
The following are is the log from Chrome with the WASM compiled with support for 4 threads running on my M1 MacBook Pro. The only result that seems strange is the benchmark for smash, as it still reports 0 for ms and inf for fps.
Starting Box2D benchmarks
benchmark.js:2244 ======================================
benchmark.js:2244 benchmark: joint_grid, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 13 (ms), 769.231 (fps)
benchmark.js:2244 run 1 : 13 (ms), 769.231 (fps)
benchmark.js:2244 run 2 : 13 (ms), 769.231 (fps)
benchmark.js:2244 run 3 : 13 (ms), 769.231 (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 8 (ms), 1250 (fps)
benchmark.js:2244 run 1 : 8 (ms), 1250 (fps)
benchmark.js:2244 run 2 : 8 (ms), 1250 (fps)
benchmark.js:2244 run 3 : 8 (ms), 1250 (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 8 (ms), 1250 (fps)
benchmark.js:2244 run 1 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 2 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 3 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 1 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 2 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 3 : 5 (ms), 2000 (fps)
benchmark.js:2244 body 100 / shape 100 / contact 0 / joint 180 / stack 24192
benchmark.js:2244
benchmark.js:2244 benchmark: large_pyramid, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 106 (ms), 94.3396 (fps)
benchmark.js:2244 run 1 : 105 (ms), 95.2381 (fps)
benchmark.js:2244 run 2 : 104 (ms), 96.1538 (fps)
benchmark.js:2244 run 3 : 105 (ms), 95.2381 (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 61 (ms), 163.934 (fps)
benchmark.js:2244 run 1 : 60 (ms), 166.667 (fps)
benchmark.js:2244 run 2 : 60 (ms), 166.667 (fps)
benchmark.js:2244 run 3 : 61 (ms), 163.934 (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 57 (ms), 175.439 (fps)
benchmark.js:2244 run 1 : 52 (ms), 192.308 (fps)
benchmark.js:2244 run 2 : 49 (ms), 204.082 (fps)
benchmark.js:2244 run 3 : 50 (ms), 200 (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 40 (ms), 250 (fps)
benchmark.js:2244 run 1 : 44 (ms), 227.273 (fps)
benchmark.js:2244 run 2 : 47 (ms), 212.766 (fps)
benchmark.js:2244 run 3 : 49 (ms), 204.082 (fps)
benchmark.js:2244 body 211 / shape 211 / contact 590 / joint 0 / stack 99136
benchmark.js:2244
benchmark.js:2244 benchmark: many_pyramids, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 607 (ms), 16.4745 (fps)
benchmark.js:2244 run 1 : 626 (ms), 15.9744 (fps)
benchmark.js:2244 run 2 : 612 (ms), 16.3399 (fps)
benchmark.js:2244 run 3 : 616 (ms), 16.2338 (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 325 (ms), 30.7692 (fps)
benchmark.js:2244 run 1 : 327 (ms), 30.581 (fps)
benchmark.js:2244 run 2 : 326 (ms), 30.6748 (fps)
benchmark.js:2244 run 3 : 327 (ms), 30.581 (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 235 (ms), 42.5532 (fps)
benchmark.js:2244 run 1 : 250 (ms), 40 (fps)
benchmark.js:2244 run 2 : 262 (ms), 38.1679 (fps)
benchmark.js:2244 run 3 : 263 (ms), 38.0228 (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 231 (ms), 43.29 (fps)
benchmark.js:2244 run 1 : 242 (ms), 41.3223 (fps)
benchmark.js:2244 run 2 : 239 (ms), 41.841 (fps)
benchmark.js:2244 run 3 : 246 (ms), 40.6504 (fps)
benchmark.js:2244 body 1376 / shape 1380 / contact 3625 / joint 0 / stack 609024
benchmark.js:2244
benchmark.js:2244 benchmark: rain, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 13 (ms), 769.231 (fps)
benchmark.js:2244 run 1 : 12 (ms), 833.333 (fps)
benchmark.js:2244 run 2 : 10 (ms), 1000 (fps)
benchmark.js:2244 run 3 : 10 (ms), 1000 (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 1 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 2 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 3 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 1 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 2 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 3 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 1 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 2 : 7 (ms), 1428.57 (fps)
benchmark.js:2244 run 3 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 body 67 / shape 681 / contact 0 / joint 60 / stack 20288
benchmark.js:2244
benchmark.js:2244 benchmark: smash, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 0 (ms), inf (fps)
benchmark.js:2244 run 1 : 0 (ms), inf (fps)
benchmark.js:2244 run 2 : 1 (ms), 10000 (fps)
benchmark.js:2244 run 3 : 0 (ms), inf (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 1 (ms), 10000 (fps)
benchmark.js:2244 run 1 : 0 (ms), inf (fps)
benchmark.js:2244 run 2 : 0 (ms), inf (fps)
benchmark.js:2244 run 3 : 0 (ms), inf (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 0 (ms), inf (fps)
benchmark.js:2244 run 1 : 0 (ms), inf (fps)
benchmark.js:2244 run 2 : 0 (ms), inf (fps)
benchmark.js:2244 run 3 : 0 (ms), inf (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 0 (ms), inf (fps)
benchmark.js:2244 run 1 : 0 (ms), inf (fps)
benchmark.js:2244 run 2 : 1 (ms), 10000 (fps)
benchmark.js:2244 run 3 : 0 (ms), inf (fps)
benchmark.js:2244 body 201 / shape 201 / contact 712 / joint 0 / stack 52288
benchmark.js:2244
benchmark.js:2244 benchmark: spinner, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 21 (ms), 476.19 (fps)
benchmark.js:2244 run 1 : 21 (ms), 476.19 (fps)
benchmark.js:2244 run 2 : 20 (ms), 500 (fps)
benchmark.js:2244 run 3 : 20 (ms), 500 (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 17 (ms), 588.235 (fps)
benchmark.js:2244 run 1 : 18 (ms), 555.556 (fps)
benchmark.js:2244 run 2 : 17 (ms), 588.235 (fps)
benchmark.js:2244 run 3 : 17 (ms), 588.235 (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 17 (ms), 588.235 (fps)
benchmark.js:2244 run 1 : 16 (ms), 625 (fps)
benchmark.js:2244 run 2 : 15 (ms), 666.667 (fps)
benchmark.js:2244 run 3 : 15 (ms), 666.667 (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 15 (ms), 666.667 (fps)
benchmark.js:2244 run 1 : 15 (ms), 666.667 (fps)
benchmark.js:2244 run 2 : 16 (ms), 625 (fps)
benchmark.js:2244 run 3 : 16 (ms), 625 (fps)
benchmark.js:2244 body 501 / shape 860 / contact 80 / joint 1 / stack 130016
benchmark.js:2244
benchmark.js:2244 benchmark: tumbler, steps = 10
benchmark.js:2244 thread count: 1
benchmark.js:2244 run 0 : 8 (ms), 1250 (fps)
benchmark.js:2244 run 1 : 8 (ms), 1250 (fps)
benchmark.js:2244 run 2 : 9 (ms), 1111.11 (fps)
benchmark.js:2244 run 3 : 8 (ms), 1250 (fps)
benchmark.js:2244 thread count: 2
benchmark.js:2244 run 0 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 1 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 2 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 run 3 : 6 (ms), 1666.67 (fps)
benchmark.js:2244 thread count: 3
benchmark.js:2244 run 0 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 1 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 2 : 4 (ms), 2500 (fps)
benchmark.js:2244 run 3 : 4 (ms), 2500 (fps)
benchmark.js:2244 thread count: 4
benchmark.js:2244 run 0 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 1 : 4 (ms), 2500 (fps)
benchmark.js:2244 run 2 : 5 (ms), 2000 (fps)
benchmark.js:2244 run 3 : 5 (ms), 2000 (fps)
benchmark.js:2244 body 402 / shape 404 / contact 0 / joint 1 / stack 105056
benchmark.js:2244
benchmark.js:2244 ======================================
benchmark.js:2244 All Box2D benchmarks complete!

I managed to compile a release build, but in order to do so I had to add another compiler setting for Emscripten -s ALLOW_MEMORY_GROWTH, otherwise the an error is thrown while attempting to run the first test, abortOnCannotGrowMemory. My CMakeLists.txt now includes this for Emscripten:
if(EMSCRIPTEN)
    set(EMSCRIPTEN_PTHREADS_COMPILER_FLAGS "-pthread -s USE_PTHREADS=1")
    set(EMSCRIPTEN_PTHREADS_LINKER_FLAGS "${EMSCRIPTEN_PTHREADS_COMPILER_FLAGS} -s ALLOW_MEMORY_GROWTH")
    string(APPEND CMAKE_C_FLAGS " ${EMSCRIPTEN_PTHREADS_COMPILER_FLAGS}")
    string(APPEND CMAKE_CXX_FLAGS " ${EMSCRIPTEN_PTHREADS_COMPILER_FLAGS}")
    string(APPEND CMAKE_EXE_LINKER_FLAGS " ${EMSCRIPTEN_PTHREADS_LINKER_FLAGS}")
endif()

There is a significant improvement in performance when more than a single thread is used.

Very exciting! I definitely want to support this. For comparison here are the M2 results.

https://box2d.org/files/benchmark_results.html

Great! Would you prefer I start a separate repo for creating WASM bindings to try to get better performance when calling Box2D from external javascript? Please let me know if there is anything else I can do to help with Emscripten.

On Dec 4, 2024, at 3:43 PM, Erin Catto @.***> wrote:

Very exciting! I definitely want to support this. For comparison here are the M2 results.
image.png (view on web)
https://box2d.org/files/benchmark_results.html
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

Yeah, something to help people get going with WASM would be great. I will add your changes to the CMake files.

in main, it looks like pthreads are only enabled when building (BOX2D_UNIT_TESTS OR BOX2D_SAMPLES OR BOX2D_BENCHMARKS).
what about library builds?
my use-case is to build & distribute box2d as a WASM library. is there a way for me to expose threading APIs somehow?
or is it the case that there's nothing inside box2d that uses pthreads? thread management is done by the calling code outside the library, such as EnkiTS in unit tests?
wondering what I should be trying to expose to give a NodeJS or Web user access to threading. they'll write their demos in JS, so… do I expose WASM bindings for EnkiTS APIs? or maybe ignore EnkiTS and pthreads altogether? instead, roll some original code on top of SharedArrayBuffer and Web Workers?

ah, looks like task creation is mostly just wiring; maybe the user writing the game in JS doesn’t need any ability to specify how tasks are created. maybe I can just offer WASM callbacks into C++ code which enqueues tasks the same way that the unit tests do (EnkiTS wiring).
if that’s how it works, then might also be able to offer wiring based on WASM Worker APIs rather than emscripten’s pthread handling.

Correct, box2d as a convention will never create threads. It relies on the user to provide them. In this case the user is the benchmark, unit test, or samples app using enkiTS.


Verify .msi/.exe launchers included in the release on the release pipeline

The Scala CLI native package for Windows (.msi) is currently being verified with the following procedure:
https://github.com/VirtusLab/scala-cli/blob/main/.github/release/windows-antimalware-analysis.md
The downside of it is that it has to be done manually, as well as the verification on Microsoft's side can take up to 30 days.
We need to find a way to expediate this process, and optimally to automate the submission process on the CI.

This currently blocks https://github.com/scala/scala3/issues/20378
and is necessary for https://github.com/scala/scala3/issues/20098

This issue itself is blocked due to Microsoft's lack of api. I don't think that we need it since we republish the same executable as the one we download from the last scala-cli release. This process will therefore have to be performed by the scala-cli team (unless we decide to build the executable in this repository)
@Gedochao should we close it ?

There's still one way to do this I'd like us to explore, but that might take a couple months before we see if it's feasible.
I'll keep it open for some more, until I'm sure we won't find a way to do it.
But yeah, for now we'll rely on the manual verification + workaround (using >30 day old *.exe launchers).
I'll take it off the board for now, too.


Make ArraysAsListSerializer not immutable

Being immutable is incorrect because elements of it may be mutable.
Closes #46

@magro It looks like your Travis CI config hasn't been updated in a while which caused the builds to fail. Have you considered getting rid of the libs folder, replacing Maven with the Gradle build system, and declaring all transitive dependencies?


It is no executed when focus the items in header's menu bar of Firefox Nightly browser during do automation testing

Steps to reproduce
Tell us about your environment:

Puppeteer version: 5.5.0
Platform / OS version: macOS High Sierra 10.13.6
URLs (if applicable):
Node.js version:v12.16.1

What steps will reproduce the problem?
1)focus the items in header's menu bar of Firefox Nightly browser during do automation testing
2)It is pending when run below 2 lines' code in Firefox Nightly browser:
await page.keyboard.press('Tab');
let node = await page.$(":focus");
Please include code that reproduces the issue.
1.await page.keyboard.press('Tab');
2.let node = await page.$(":focus");
3.
What is the expected result?
It should be executed like that in Chromium browser
What happens instead?
1.The issue can not reproduced when focus the items in  of firefox nightly browser

It would be great to get a trace log attached. Therefore please set the dumpio option to true when launching the browser, and also set the Firefox preference remote.log.level to Trace. Then run your test again and attach the log output to this issue. Thanks!

The log is attached.
log 2.txt

Sorry that this issue was forgotten. I had a look again and preventing interaction with the browser while puppeteer is running is nothing we will fix. If focus is important you might want to run your tests in headless mode instead. Closing issue.


toofake fermé

l'application ne marche plus, meme hébergé sur vercel, a t'elle été fermé de force sous pression des développeurs comme pour befake ?

the application no longer works, even hosted on vercel, was it closed by force under pressure from the developers as for befake?

It stopped working like 5 hours ago. Anyone has an idea how to fix it or where the issue is? Did bereal make the api more secure?

should be working again due to a fix from another community member. A lot of other functionality is broken though

Thank you! I still can't login, I get this error. I'm from switzerland:
ERROR: {"statusCode":400,"errorKey":null,"data":null,"fields":null,"timestamp":"2024-01-18T12:26:16.786Z","requestId":"632961c380f3d4453fafabe701257752"}
Failed with Vonage login provider, re-trying to login with Firebase...

Anyone has a fix to this? It neither sends a OPT code on vercel nor on my local hosted instance

I believe this has never worked for swiz phone numbers unfortunately


[CH-202] Support condition expression, include if/else and case/when

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

@lviiii  Can you help seeing the velox issue.  Likely related to velox memory manager.

Please ignore the CI issue in latest run. It's unrelated and I am working on a fix.

@zhixingheyi-tian please help to review, thanks.

Hi @taiyang-li ,
Would you add custom UTs. Similar to https://github.com/oap-project/gluten/blob/main/backends-velox/src/test/scala/io/glutenproject/execution/VeloxFunctionsValidateSuite.scala
Because Spark UTs may skip Backends and fallback sometimes.

I've tested if/else and case/when in Velox backend, and it works well. However, these expressions are better to be verified on column-based query, as shown above. Please add some custom UTs.

@zhixingheyi-tian  @lviiii  Thanks for your advice, I'll try.

LGTM


undefined cookie value

I just tried to use the latest version of the library and noticed that the cookie value is not properly set. This results in the missing value of the csrf token.
next: 15.4.1
Please find screenshoots below:
Chrome:

Console:

Also, I noticed a warning from next: Middleware is returning a response body (line: 13), which is not supported.
Learn more: https://nextjs.org/docs/messages/returning-response-body-in-middleware
I hope my feedback helps! Thank you for your work on this library!

Error: A middleware can not alter response's body. Learn more: https://nextjs.org/docs/messages/returning-response-body-in-middleware

Just found the experimental parameter: allowMiddlewareResponseBody.
That removed the warning, but the cookie values are not properly set.

Thanks for your note about the middleware response. I added a note to the README to help others who run into the same issue. They just enabled that feature by default in Next.js 13.1 so hopefully it won't be a problem in the future.
About the undefined cookie, I just checked again and it's working for me in Chrome with Next.js 13.0 and 13.1. Also, there are unit tests that check cookie response values (https://github.com/amorey/edge-csrf/blob/main/test/index.test.ts#L191-L236) and they're passing too so I'm not sure what the issue is. Can you describe your setup in more detail? Also, can you try the example app to see if it's working there?

@AndriiTsok Just wanted to follow up - have you had a chance to look at this again? Let me know how to reproduce the problem so I can debug it.

I'm facing the same issue. My cookie is undefined (same as the picture). Seems like the problem lays in these lines:
 if (secretStr === undefined) {
      secret = createSecret(config.secretByteLength)
      const cookie = Object.assign({value: utoa(secret)}, config.cookie);
      response.cookies.set(cookie);
 }

I believe it should be this way:
 if (secretStr === undefined) {
      secret = createSecret(config.secretByteLength)
      response.cookies.set(config.cookie.name,  utoa(secret) , config.cookie);
 }

Thank you in advance!

Thanks for providing more details about the problem! Which version of Next.js are you using? The code you highlighted should work in Next.js v13.1.0+ because cookie is an object like the one in the example here and, in addition, that code is unit tested here.
Is the problem intermittent? Any other info you can provide me would be very helpful in debugging this problem.

Is the library supported in Next.js v12? If so, what version should I install?

Yes, version 0.2.2 works with Next.js v12: https://www.npmjs.com/package/edge-csrf/v/0.2.2
Let me know if that fixes the problem!

That fixed my problem! Thank you!

Great! Let me know if you run into any other issues.


ci: add develop-release GH action

Updates submodules to the release branch.

bors merge

bors merge


Update buffer.rb to recovery memory leak

Update buffer.rb to recovery memory leak when using @copy

Which issue(s) this PR fixes:
Fixes #
memory leak in my environment
What this PR does / why we need it:
when new emit requests come,first judge if queue size is less than limit. if exceed limit, raise error.
Docs Changes:
No
Release Note:
can release new version for v0.12

dup https://github.com/fluent/fluentd/pull/2376


Add webrick for Ruby 3

I think this will fix the problem @JasnaMRB ran into trying to run the site using bundler directly (#378).  Jasna is on Ruby 3, and I am on Ruby 2.  I don't know what I'm doing, but I think Jasna's problem is https://github.com/jekyll/jekyll/issues/8523.

Sneaking a test in before my flight ✈  success! https://gist.github.com/JasnaMRB/efd25da776c863895e1878017e9ded29


[Discussion] Working on Wayland with Proton 9.0-2!

Tested it out on Arch Linux with KDE Plasma 6 running Wayland (And subsequently Steam/Proton within XWayland)
Highlights and control work as expected.
https://github.com/madewokherd/xalia/assets/841440/8dee85b0-0e7f-42bc-a3db-96d95d4c2167

Proton runs Xalia inside Wine, so it'd be going through win32 stuff and probably winex11.drv into xwayland.
Where I expect problems is trying to use this with native Linux apps running in Wayland, and possibly also winewayland.drv.

Oh! I didn't realize this had a native mode (I had just assumed it was only for the WINE subsystem)
I'll see if I can get the build working and will report back.
Thank you!

Ok yeah zero luck there as suspected. Binary is running (dotnet 8.0) but seemingly nothing happening. I'll dig into Plasma/AT-SPI/X11 support and see what I can find.

After some quick testing on the Plasma X11 session, buttons sending keyboard events works but the highlight never appears, so navigation is not possible. I tried with the QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 with the same result either way.

The problem I know you'll run into is lack of window coordinates that work across different clients. We currently rely solely on AT-SPI for this (but we're going to need window-system-specific code, as this also doesn't work with GTK3). There's been some work on this: https://lwn.net/Articles/971541/
I'm not sure if it's worth paying much attention to Wayland until "Newton" is stable and we can start using it. (Actually, it may be worth trying to use it on Windows/Wine too. Using process hooks to translate the existing APIs to a "push" architecture would likely be easier than working with comctl32/msaa/uia is turning out to be. But I'd much rather do that in a common way and not invent my own serialization protocol.)
That said, there may be other obstacles (like getting something to render on the screen above other apps) independent of the accessibility technology.

Maybe I should repurpose this as a general "Wayland support" issue?

Sure, that would be fine.

Ok so some progress. I have the same limited key event functionality in Wayland. I missed the sharing input dialog the first time I had tried it.
So I can send button events on Plasma Wayland but still have the issue of no element highlighting.

Here's what that looked like

It's surprising to me that even that much works. Sending input is implemented via Win32 in Win32WindowingSystem and xtest in X11WindowingSystem. So that implies that we're using X11WindowingSystem even on wayland for some reason.

If you are talking to AT-SPI maybe that is handling the event translation? Is XTEST always used on X11 or is that a fallback?

Sending events through the AT-SPI connection isn't implemented, so I think it has to be using xtest.


web-directory: Replace "private message" and "PM" with "direct message".

See relevant CZO conversation.
This takes care of instances of "private message" and "PM" in the web/ directory, except for:

any uses of "PM" that refer to time, e.g. "5:30 PM"

Notes:

The majority of these changes are updates to comments / doc-strings in the various files in the web/ directory.
The first commit updates the string for opts.trigger when the New direct message button is clicked in the web app.
The next three commits update some constants and data structures that used "PM" or "PrivateMessage".
The commits that update the tests (node and puppeteer) change some test names and strings, as well as comments.

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Wow. Some tedious work here.  I've reviewed only the commits and changes here, but I did note files like pm_conversations.test.js that still have some private_message and pm references, but perhaps those (like the pm_ prefix to the filename itself) are planned for another PR?

Updates:

Fixed conflict, which was an updated comment in the final commit (web/shared directory) from another pull request that was merged last week.

Nice, merged, thanks for doing this cleanup @laurynmm! I know we still have a lot to do to complete this rename -- there's still 600 references to private_m -- but this already makes a big difference in how digested this transition feels.


Dialog in foreground

This first try to fix this issue.
There are several things in this pull request I'm not happy with:

The correct behaviour is tested only in the KDE-Windowmanager. Other platforms need testing, too
I couldn't find a way to test the bug/bugfix. Support here is greatly appreciated.

Pull request was merged via rebase
https://github.com/otto-de/logsmith/commit/2fe3964df4f593dca2e16c135fd764e89ee7dff7

Pull request was merged via rebase
https://github.com/otto-de/logsmith/commit/2fe3964df4f593dca2e16c135fd764e89ee7dff7


"Olteni" , "Bogdănești" , "Bujoreni" , "Gura Văii" , "Lunca" , "Malu Alb" , "Malu Vârtop" are listed in the drop-down menu

The villages are listed in the drop-down menu alongside its corresponding county and city, according to the law
Preconditions : the  website is up and runing. After every step delete the text you typed from the search bar.

Step 1
Write in the search bar "Olteni"

Expected results
The location appears in the drop-down menu as "Sat Olteni, VÂLCEA (Bujoreni)"

Step 2
Write in the search bar "Bogdănești"

Expected results
The location appears in the drop-down menu as "Sat Bogdănești, VÂLCEA (Bujoreni)"

Step 3
Write in the search bar "Bujoreni"

Expected results
The location appears in the drop-down menu as "Sat Bujoreni, VÂLCEA (Bujoreni)"

Step 4
Write in the search bar "Gura Văii"

Expected results
The location appears in the drop-down menu as "Sat Gura Văii, VÂLCEA (Bujoreni)"

Step 5
Write in the search bar "Lunca"

Expected results
The location appears in the drop-down menu as "Sat Lunca, VÂLCEA (Bujoreni)"

Step 6
Write in the search bar "Malu Alb"

Expected results
The location appears in the drop-down menu as "Sat Malu Alb, VÂLCEA (Bujoreni)"

Step 7
Write in the search bar "Malu Vârtop"

Expected results
The location appears in the drop-down menu as "Sat Malu Vârtop, VÂLCEA (Bujoreni)"


utilize transfer of stakes between vaults

Unaudited sample. Takes advantage of the transfers of locked stakes on Fraxfarm, allowing transfer between Convex vaults. Only implemented in the StakingProxyConvex.sol
Depends upon this: https://github.com/FraxFinance/frax-solidity/pull/165

Testing completed, performed in separate repository so that FraxFarm modifications could be tested in tandem with the vault changes.
The poolRegistry constant in the vault should be changed to an input parameter within the initialize call, which will require changes to the booster and also circle back to updating the testing. PoolRegistry is absolutely critical so that transfers can verify if a receiver is also a valid convex vault.
Additionally, the poolId/_pid can be passed in as an initialize parameter so the initializer doesn't have to call out to obtain it and record it locally (for the above mentioned vaultMap lookups.


[22.11] process-compose: 0.24.1 -> 0.29.7

Description of changes
backporting #209287 to fix https://github.com/F1bonacc1/process-compose/issues/38
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Unfortunately NixOS 22.11 has reached its end-of-life status on 2023-06-30, one month after the release of NixOS 23.05.
I'm closing this pull request, since we do not accept any changes to its branches anymore.


Add query functions to the DB that are able to handle branching

Currently, we only have a query for finalized state, i.e. provided by finalized blocks.
We want to be able to query state for blocks that have not yet been finalized.
This could be enabled by requiring that users specify a HEAD or "block address" from which the query begins and recurses through parents until it reaches the finalized table. By specifying an address (rather than a number), we can avoid the issue where there might be multiple blocks for the same number, and we can avoid branching issues as each block address is unique and can only have one parent block.

Partially done by https://github.com/essential-contributions/essential-node/pull/127


nixos/quorum: fix geth args, fix test

nixos/quorum: update geth flags

upstream commit changing ws args:
https://github.com/Consensys/quorum/commit/c989bca173681f4462985cec2d30616aa0774edd
upstream commit changing minerthreads arg:
https://github.com/Consensys/quorum/commit/f0998415ba9a73f0add32f9b5aed2aec98b9a7f3

nixos/tests/quorum: fix test

add services.quorum.genesis.config.homesteadBlock = 1. Without it test fails with error:

quorum-pre-start[822]: Fatal: Failed to write genesis block: unsupported fork ordering: homesteadBlock not enabled, but eip150Block enabled at 1

Description of changes
Fixes nixosTests.quorum (fails since 2023-09-30):
https://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.quorum.x86_64-linux
https://hydra.nixos.org/build/272043647
Error log:
machine # [   34.242043] quorum-pre-start[848]: Fatal: Failed to write genesis block: unsupported fork ordering: homesteadBlock not enabled, but eip150Block enabled at 1
machine # [   34.261231] systemd[1]: quorum.service: Control process exited, code=exited, status=1/FAILURE
machine # [   34.263964] systemd[1]: quorum.service: Failed with result 'exit-code'.
machine # [   34.271125] systemd[1]: Failed to start Quorum daemon.
machine # [   34.274217] systemd[1]: quorum.service: Consumed 1.430s CPU time, 26.3M memory peak.
machine # Job for quorum.service failed because the control process exited with error code.

with homesteadBlock added to test config geth errors on incorrect args:
vm-test-run-quorum> machine # [   16.256542] geth[838]: Incorrect Usage. flag provided but not defined: -minerthreads
vm-test-run-quorum> machine # [   49.213644] geth[1026]: Incorrect Usage. flag provided but not defined: -wsaddr

nixos/quourum module commit fixes it, updating args to new ones.
Listed test maintainer:
@mmahut
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

@ofborg test quorum


Create checklist for including new components or sections in Aurora

Create a checklist of what needs to be done to add a component to our design system. This checklist can then be added to the Overview section of Aurora or the CONTRIBUTING file (or both).
Ideas to start with:

[ ] design and add to UI kit
[ ] design documentation
[ ] HTML documentation
[ ] built component
[ ] add to React library / NPM package

Discussion set for Thursday, April 25


EndConversation not found in Microsoft.Bot.Connector.DirectLine

I try to send EndConversation request by using DirectLineClient, but I can not find any method, or the bot-side will automatically end this conversation with timeout?

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

ID: 174f2cb3-cad3-7d6b-3682-6fae14b1f632
Version Independent ID: 2f9132db-9d77-0a7a-d6d1-ba140354b388
Content: End a conversation - Bot Service
Content Source: articles/rest-api/bot-framework-rest-direct-line-3-0-end-conversation.md
Product: bot-framework
GitHub Login: @RobStand
Microsoft Alias: kamrani

@Wenfengcheng Is this implemented in your bot file?

@CathyQian
No, the only thing I can do is to implement the api request of end conversation by myself.
But I doubt whether the Bot side will automatically end conversation after the application side lose websocket connecton.


[Feature Request] Add tooltips to certain buttons and/or icons

In the above example, some users might become confused with the "75%" feature; consider adding a tooltip for clarification when the user hovers over the icon.

Same with these +/- buttons--need to clarify when the user hovers over the icon. (Does it add a new semester? Or a new credit/course?)

Action Items
Product

Make a list of buttons and/or icons to add tooltips for
Create descriptions for each tooltip
Question: do we want to have tooltip icons or just tooltips?

Design

Design a generic component for tooltip
Design how the tooltip should appear on UI

Engineering

Create a generic Planner tooltip component
Add tooltips to all buttons/icons listed

Will move this somewhere else besides an issue


fix(bug): Check if quick selection has nrql or workload

TODO: title, description, and a way to validate that this fix works.


feat(fields): add hood and fold with IDs

The only thing I can say: tests are missing 😂 Despite that, it looks almost perfect 😎


Set up GitHub Actions

Also pretty close to Scala 3.0.0 but there are some issues with circe-generic in the tests that I don't want to deal with right now.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@b3dfcc9). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #228   +/-   ##
=========================================
  Coverage          ?   95.31%
=========================================
  Files             ?        6
  Lines             ?       64
  Branches          ?        0
=========================================
  Hits              ?       61
  Misses            ?        3
  Partials          ?        0

Continue to review full report at Codecov.

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


Implement draw & marbles highlighting

Implement draw & marbles highlighting

[x] If nobody won because both players have aligned marbles, show "It's a draw !"
[x] in case of alignment, add a little animation to scale marbles

Nice effect


Allow gunicorn timeout setting to be set in pcconfig.py and environment variables

All Submissions:

[x] Have you followed the guidelines stated in CONTRIBUTING.md file?
[x] Have you checked to ensure there aren't any other open Pull Requests for the desired changed?

Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

New Feature Submission:

[x] Does your submission pass the tests?
[x] Have you linted your code locally prior to submission?

Changes To Core Features:

[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your core changes, as applicable?
[x] Have you successfully ran tests with your changes locally?

After these steps, you're ready to open a pull request.
a. Give a descriptive title to your PR.

b. Describe your changes.

c. Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such).

closes #1190

The change requires an update of the documentation https://pynecone.io/docs/api-reference/config


Remove MustSortJson

Description

closes: #3917
Commit Message / Changelog Entry
type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #5379 (cd50ce3) into main (3e1998f) will not change coverage.
Report is 2 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5379   +/-   ##
=======================================
  Coverage   80.07%   80.07%
=======================================
  Files         189      189
  Lines       13106    13106
=======================================
  Hits        10495    10495
  Misses       2199     2199
  Partials      412      412

Files
Coverage Δ

...odules/apps/27-interchain-accounts/types/packet.go
88.63% <100.00%> (ø)

can you merge to the tip of main @expertdicer? (or allow us write permissions) Thanks

can you merge to the tip of main @expertdicer? (or allow us write permissions) Thanks

I have updated your write permission. TYSM


Back not work.

When we use Vue Router we can use back and forward buttons of browser but in F7-Vue it doesn't work.
Please fix this issue.

@AGhasemzadeh For back button support, you need to to enable history mode using this options: (Assuming using v2, v1 usage is in the docs)
view: {
 main: true,
 pushState: true,
}

Also passing same props to the main <view> component may help to resolve some inconsistencies.
Another suggestion is using Nuxt7 which is supporting both v2 and history/push state and is being used for some production projects :)


Look into Ventura API improvements

Mostly relating to anything involving AVPlayer and AppKit. I don't want to sacrifice my prod Mac for Ventura so uh...

Share popover in menu (see #25)
Use the new form insets, maybe with SwiftUI (see #13)
Variable SF Symbols (use current code on Big Sur/Monterey)

Interesting talks:

https://developer.apple.com/videos/play/wwdc2022/10074/
https://developer.apple.com/videos/play/wwdc2022/10075/

There's an AVPlayerItem nowPlayingInfo, but it's not clear why this is. Better than using the NPIC?


Possibly a performance improvement

In the plain_modpow function, there are a lot of bitshifts and no comments, combined with the fact that I am more a mathematician than a programmer, I don't really know if this method of optimization is already implemented there, because I don't completely understand the code, so if it is, just close this issue.
Here is the optimization:
Since we are looking at the residue class ring (Z/(m), +, *) where m refers to the modulo inside the equivalence classes, we say that an integer a in Z/(m) to the power of a natural number b is defined as the repeated multiplication of a b-times to itself so a*a*a*..*a b-times = a^b. Thus if we find the smallest natural number c <= b which has the property that a^c = 1, the neutral element of multiplication (this is especially fast with small sets that form the ring and large exponents). We firstly find out the result of b mod c =: d. Now we declare an integer e such that c * e +d = b. We can calculate this integer with the following formula e := floor(b/c) where "/" refers to division in the rationals and floor to the largest integer smaller than (or equal to) b/c with the classical order relation on the rationals.
We arrive at the following identity: a^b = (a^c)^e * a^d = (1)^e * a^d = a^d since b = c*e+d.
Quick proof for b=c*e+d:
e is defined as e = floor(b/c), thus  floor(b/c) <=  b/c with the property that floor(b/c) is the largest such integer. floor(b/c) <= b/c is equivalent to  floor(b/c)*c <= b = b/c * c. It follows from the definition of floor(), that this floor(b/c)*c is the largest integer less than or equal to b that can be divided by c. From the definition of modulus we know that d (which is b mod c) is the residue of the division of b with c. It follows from those two properties that b = c*e+d.
Q.E.D.
For this method to be useful the exponents have to be sufficiently large and the identity that has to be computed has to be known beforehand (especially efficient if we have rings that are often used) or the ring has to be sufficiently small.  Note that here "sufficient small" can be considered quite huge numbers for humans.

In the plain_modpow function, there are a lot of bitshifts and no comments, combined with the fact that I am more a mathematician than a programmer, I don't really know if this method of optimization is already implemented there, because I don't completely understand the code, so if it is, just close this issue.

It's basically just exponentiation by squaring, so the bitshifting is extracting powers of 2 from the exponent. This gives us O(log e) mul-mod operations for exponent e.

Thus if we find the smallest natural number c <= b which has the property that a^c = 1

OK, sure, this looks like Euler's theroem.

For this method to be useful the exponents have to be sufficiently large and the identity that has to be computed has to be known beforehand (especially efficient if we have rings that are often used) or the ring has to be sufficiently small. Note that here "sufficient small" can be considered quite huge numbers for humans.

This is where I'm not sure it's an optimization we should directly implement. Knowing beforehand implies that we're caching known values, which I don't think we should do implicitly. Calculating it on the fly would only make sense if you can do this faster than what you'll save in that O(log e) complexity.
Maybe this exponent reduction should just be suggested in documentation? That if you're repeating modpow many times with the same modulus, calculating that identity may be worth it to reduce the overall computation.

This is where I'm not sure it's an optimization we should directly implement. Knowing beforehand implies that we're caching known values, which I don't think we should do implicitly. Calculating it on the fly would only make sense if you can do this faster than what you'll save in that O(log e) complexity.
That is true, maybe an option would be to cache it explicitly.

This requires calculating φ(m), Euler's totient function. That is in general a much harder problem than exponentiating, since it requires factoring m into primes. So it's not really an optimization in general, even if you're calculating with the same m many times, except in some special cases.

maybe an option would be to cache it explicitly or provide a function to do the reduction manually.

There already is a way to do this manually: if you know that gcd(a, m) = 1 and you know what φ(m) is, calculate b % φ(m).


Conflicting constified module enum/rustified enum regex leads to compile error when C enum has non-unique discriminant values

Input C/C++ Header
typedef enum MyDupeEnum {
	A = 0,
	A_alias = 0,
	B,
} MyDupeEnum;

Bindgen Invocation
$ bindgen input.h test-constify-mod-enum.h --rustified-enum '.*' "--constified-enum-module" ".*"

Actual Results
/* automatically generated by rust-bindgen */

pub const MyDupeEnum_A_alias: MyDupeEnum::Type = MyDupeEnum::A;
#[repr(u32)]
#[repr(C)]
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
pub enum MyDupeEnum {
    A = 0,
    B = 1,
}

and/or
error[E0223]: ambiguous associated type
 --> /tmp/a.rs:3:31
  |
3 | pub const MyDupeEnum_A_alias: MyDupeEnum::Type = MyDupeEnum::A;
  |                               ^^^^^^^^^^^^^^^^ ambiguous associated type
  |
  = note: specify the type using the syntax `<MyDupeEnum as Trait>::Type`

error: aborting due to previous error

Expected Results
There are several possibilities for correct behavior:

Error out immediately because regex passed to --rustified-enum/--constified-enum-module overlap.
Define the precedence of enum strategies (rustified, constified module, and constified).
Support a more complete way for users to convey what enum strategy is used for a given enum. For example, bindgen could take a callback or struct that implements a ConveysEnumStrategy trait).
Whichever regex is passed first has precedence (the order of arguments/builder pattern calls matters). This would complicate the internal bindgen logic.

Example of behavior 2:
/* automatically generated by rust-bindgen */

#[repr(u32)]
#[repr(C)]
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
pub enum MyDupeEnum {
    A = 0,
    A_alias = 0,
    B = 1,
}

When can we expect a new bindgen release? I want to release a new version of capstone-sys that takes advantage of these bug fixes.

Thanks!
On Sun, Mar 25, 2018 at 2:23 PM, Emilio Cobos Álvarez <
<EMAIL_ADDRESS>wrote:

I just bumped the version, will publish it in a sec.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rust-bindgen/issues/1198#issuecomment-375991811,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFBYuBmJcQOJh1J630Be-e3Lr0hKAfMzks5th-CTgaJpZM4RMezT
.


MODULES-236

This looks good.  Can you squash it down to one commit (whose message includes the JIRA ID)?  Then I will merge.

Done


Holding shift should make you go father in the chart editor (READ POST)

What feature do you want to get added on the base engine?
While holding shift and pressing A or D, you should move 4 sections instead of 1.
To test your sight, and reliability, please select the option of what should NOT be requested.
Stage Editor, 6K+ support, and winning icons.

This already exists and works literally the same way you said.


Using AUTOCOMMIT=False breaks enqueuing jobs from management commands

I'm currently doing this as a work around: I run my workers / management commands with a WORKER env var defined, and so in settings.py:
RQ = {
    'AUTOCOMMIT': True if bool(environ.get('WORKER')) else False,
}

You can also use django_rq.get_queue(autocommit=True).

Cool, thanks!


Add Toxiproxy latency experiment

This PR adds a latency experiment using Toxiproxy. The setup creates and deletes the toxy.
Base on issue #15, the latency and jitter are hardcoded. Once it is fixed, the experiment will be updated.

Hi @joaoasrosa , if you can push this fix in (assuming you agree with it), I'm happy to do the merge.

Later in the day, but yes I'm fine with it! :)


UIViewController does not conform to protocol QRCodeReaderViewControllerDelegate

Hi I have the error
UIViewController does not conform to protocol QRCodeReaderViewControllerDelegate

While I have implemented every required method
func reader(reader: QRCodeReaderViewController, didScanResult result: String) {
    self.dismissViewControllerAnimated(true, completion: { [unowned self] () -> Void in
        let alert = UIAlertController(title: "QRCodeReader", message: result, preferredStyle: .Alert)
        alert.addAction(UIAlertAction(title: "OK", style: .Cancel, handler: nil))

        self.presentViewController(alert, animated: true, completion: nil)
        })
}

func readerDidCancel(reader: QRCodeReaderViewController) {
    self.dismissViewControllerAnimated(true, completion: nil)
}

What could be the problem here?

Hi,
Have you asked your viewController to conform the protocol?
class YourViewController: UIViewController, QRCodeReaderViewControllerDelegate {
   // ...
}


Fix cmake object libraries in static build

Hi again,
SAIL's static build was sadly broken for me since commit ce0e3d2824936013083fdc8219a1f3916cc3ebbc. SAIL could still be built statically but the sail-codecs-objects archive produced by the build didn't contain the private bmp-common library that's shared by the BMP and ICO codecs. That meant linking with SAIL failed because the symbols from bmp-common were missing.
I've tried to fix this by making common libraries like bmp-common build as object libraries as well, just like the codecs themselves. This fixes the static build for me.
I'm not sure if I broke other things in the process though so I'd be quite happy if you could review my changes when you have time!

Hi! Thanks for the pr.
What's your OS, compiler, and the cmake command line? The issue is very suspicious. SAIL is successfully used by the static vcpkg builds.

It's Debian Testing (bookworm), GCC 11.2, and I define the following cmake options:
                    "-DSAIL_BUILD_EXAMPLES:BOOL=OFF"
                    "-DSAIL_BUILD_TESTS:BOOL=OFF"
                    "-DSAIL_COLORED_OUTPUT:BOOL=OFF"
                    "-DSAIL_STATIC:BOOL=ON"
                    "-DSAIL_ONLY_CODECS:STRING=png|jpeg|bmp"
                    "-DSAIL_THIRD_PARTY_CODECS_PATH:BOOL=OFF"

The exact issue lies here:
# src/sail-codecs-archive/CMakeLists.txt

    # Link all the enabled codecs dependencies into sail-codecs
    #
    foreach(codec ${ENABLED_CODECS})
        get_target_property(CODEC_LINK_LIBRARIES sail-codec-${codec} LINK_LIBRARIES)
        target_link_libraries(sail-codecs PRIVATE ${CODEC_LINK_LIBRARIES})
    endforeach()

The bmp codec depends on bmp-common, so bmp-common ends up being linked to sail-codecs in this foreach loop. However, this means that it is left as a separate file and sail-codecs.a points to bmp-common.a. (The --whole-archive library copying trick also doesn't work reliably as evidenced by the fact that you're currently installing sail-codecs-objects as well even though it should've been copied into sail-codecs.)
All of the codecs already turn into object libraries in a combined codec build, which means that their source files are just directly compiled into the sail-codecs archive. bmp-common should therefore be an object library too when combining codecs; only external dependencies should be linked to sail-codecs with target_link_libraries. That makes the whole build more consistent: When building separate codec binaries, everything is linked via static libs. When building combined codecs, all codec source files are thrown together and compiled into a single library, including the common stuff.
This also makes it possible to get rid of this "library copying" stuff with --whole-archive since no static libraries have to be copied into sail-codecs; it is instead fully built from source files.

I see, thanks! I'll look into this more.

After investigating the issue, I have the following proposal in mind. Since I statically link common codecs into every codec where they're needed, I can achieve the same with make the common codec OBJECT library instead of STATIC. This way we can easily link against common codecs with target_link_libraries when SAIL_STATIC is OFF, and pull these OBJECT dependencies when SAIL_STATIC is ON.
Could you please test the attached patch (rename to .diff or .patch and git apply it)? It works fine on my Windows and Linux installation. it's not final. I'm thinking about a recursive search for OBJECT dependencies.
common-codecs-as-object-libs.txt

I'm not quite sure that this patch will work on every platform - you still need the common codecs to be STATIC when you build the codecs as separate dynamic libraries. (That's because linking against an object library with target_link_libraries doesn't work since there's no archive to link.) That's why I introduced the sail_codec_common macro in my PR: It creates a STATIC library for the common codec when building the codecs separately and an OBJECT library when the codecs will be combined.
You're also currently missing a call to list(REMOVE_DUPLICATE ...) to deduplicate the list of object libraries. This is critical because otherwise cmake will compile and link the common source files multiple times, leading to duplicate symbols. (OBJECT libraries are just lists of source files, if you don't deduplicate them, you'll specify the same source file multiple times.)
If you implement these changes, you'll basically arrive at the code in this pull request.
The only additional change I made is that I removed sail-codecs-objects because that library is redundant when all codec source files are compiled directly into the sail-codecs library. (At least I think so. Why did you introduce sail-codecs-objects in the first place? Right now the code around it seems a little weird to me, it gets built only to be integrated into sail-codecs.)
I'm also not quite sure if the recursive search is required. Object libraries should propagate their dependencies.

That's because linking against an object library with target_link_libraries doesn't work since there's no archive to link - it's a no-op

The main idea behind my patch is to implement the simplest fix. And the magic here is that linking against object libs works similar to linking against STATIC common codecs. Ref: https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries Normal libraries and executables may link to Object Libraries to get their objects and usage requirements. Continuing the above example, the code.
The patch is not ready yet, but the main idea is already there. Not sure if we need to have sail_codec_common for now, as common-bmp is currently the only place where we used it. Also, we don't use complex configuration to add a common codec, just add_library.

You're also currently missing a call to list(REMOVE_DUPLICATE ...) to deduplicate the list of object libraries

Sure, totally true :+1:

The only additional change I made is that I removed sail-codecs-objects because that library is redundant when all codec source files are compiled directly into the sail-codecs library

Agree, it looks over-complicated. But this is the only I found that works on all platforms. Since I don't refer to symbols in codecs via linker, a compiler is totally free to throw them away. That's why I force compiler to include the codecs symbols into the final linking command line with whole-arhive. Why not to use a single sail-codec-objects then? Good question, not sure if I remember the reason behind that :smile:

I'm also not quite sure if the recursive search is required. Object libraries should propagate their dependencies.

For static builds, we add a static library sail-codec-objects with real codecs objects. Propagation doesn't work here. We need to specify the exact list of objects to add into sail-codec-objects with all their dependencies.
Thanks for your great ideas :+1: :+1:

You're right, I must've missed that in CMake's documentation! Then the solution is even simpler. I just did that change in my fork. It does however mean that common libraries can't depend on other common libraries (because target_link_libraries only includes the objects from the immediately specified libraries and not those of transitive dependencies).
One more thing that came to my mind: You also have to separate object libraries from regular libraries. When you add an object library in add_library(sail-common /* ob lib here */), you may not also link against it using target_link_libraries because then you'd get duplicate symbol definitions again. I think the code in this PR should do this correctly.

Maybe I can take the responsibility over the final patch and we can review it together in a different PR.

Of course! :+1:

It does however mean that common libraries can't depend on other common libraries (because target_link_libraries only includes the objects from the immediately specified libraries and not those of transitive dependencies)

Yeah, and I truly hope we will not need such a complex mechanism :smile:


->update_html halts

I have next Mojolicious helper:
sub html2pdf {
	my $chrome =  shift->chrome;
	my $html =  shift;
	$chrome->update_html( $html );
	return $chrome->content_as_pdf( format => 'A4' );
}

it halts execution of script, but if I provide string to update_html method, then works fine:
$chrome->update_html( $html );

How to reproduce:
$html = '<b>Hi</b>';
$chrome->update_html( "$html" ); # works
$chrome->update_html(  $html  ); # halted

Is this issue still open? I've added tests and they always pass for me.

I can not reproduce the issue on 0.44 version

For reference: commit: 77877ee8


--staged option

It would be cool if there was a --staged option, like https://github.com/azz/pretty-quick so I don't have to add a pre-commit hook to a project that the team doesn't want hooks on.

Yes, PR is welcome! (it should use lint-staged underneath so partially staged files are supported)

Similar --changed and --since flags has been introduced in 13.0.0
For now you can use lint-staged to get your behavior

Would --changed --since HEAD~1 Do the trick?

prettier-standard --changed is enough, but it would also format non-stashed changes.
if you want to format just stashed changes please use lint-staged for now

Also remember that prettier currently has some servere issues with range formatting:

https://github.com/prettier/prettier/issues/4926
https://github.com/prettier/prettier/issues/6428

Because of this --since HEAD should be currently more stable than --changes, but it formats whole contents of changed files, not only changed lines.


Prepare nbs to ydb#1784

We are going to disable PROTOC_TRANSITIVE_HEADERS in ydb/core/protos in https://github.com/ydb-platform/ydb/pull/1784 to make this transition smooth for you I added additional include which brings back old behavior.
In case you want to speed up your builds as well you can remove this include and replace it with includes really needed.

It's temporary on hold. Seem's that ymake don't understand conditional includes, so I have to think about different approach

Okay, I found workaround for this -- we will just ignore it with Y_IGNORE. It won't break anything as long as we ignore main header in same file

@qkrorlqr Could we discuss this change? It is blocking us

@qkrorlqr Could we discuss this change? It is blocking us

I don't see any results indicating that this activity improves something (build time?). Here https://github.com/ydb-platform/ydb/pull/1784 I see lots of failed tests and builds in most of those PR-checks - I don't understand, how can we draw conclusions from such unstable measurements.


go vet -mod=vendor break if GOFLAGS env sets mod too

What version of Go are you using (go version)?

$ go version
go version go1.13 linux/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/tnozicka/.cache/go-build"
GOENV="/home/tnozicka/.config/go/env"
GOEXE=""
GOFLAGS="-mod=vendor"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/tnozicka/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/tnozicka/lib/go1.13"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/tnozicka/lib/go1.13/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build193936079=/tmp/go-build -gno-record-gcc-switches"

What did you do?
$ env | grep GOFLAGS
GOFLAGS=-mod=vendor

$ ~/lib/go1.13/bin/go vet -mod=vendor ./...
go vet: mod flag may be set only once
run "go help vet" for more information

What did you expect to see?
No error, since the flag is specified only once on the command line. Other commands work fine in this configurations.
As a library author providing the build system I want to enforce vendoring mode using the -mod=vendor and I can't influence what user has in set in his env. The general rule is also that flags win over env, but in this case I think it is really just about handling it gracefully in the implementation internals.
What did you see instead?
go vet: mod flag may be set only once

I'm pretty sure this is a duplicate of https://github.com/golang/go/issues/32471, but cc-ing @bcmills just in case.

Agreed.

Duplicate of #32471


Cannot change Vite dev server URL for inspector

Describe the bug
When using a separate server that Vite has been integrated into, the open-in-editor command will always be sent to the wrong address.
The plugin uses the Vite config base to determine where to send the command but even if a full URL is specified, e.g.
export default defineConfig(() => ({
  plugins: [svelte()],
  base: 'http://localhost:3001/wah',
  server: { port: 3001, strictPort: true },
}));

Vite normalizes it, and everything except the path gets removed, this is how the above resolves in the plugin:

With the application running on a different port from the Vite dev server, this leads to the open-in-browser command being sent to the wrong endpoint.
The plugin probably should take Vite's server options into account to make sure the correct port is used or offer a way to explicitly set the endpoint (though that would lead to redundancy on the side of the user).
Reproduction URL
https://github.com/brunnerh/vite-plugin-svelte-inspector-port-issue
Reproduction
Run scripts in two separate terminals:
npm run server
npm run vite

Open http://localhost:3000 in your browser.
Ctrl + Shift click an element on the page.
Observe __open-in-editor command being sent to http-server rather than vite.
Logs
Requests to http-server:
[2023-07-07T08:42:31.783Z]  "GET /" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36"
[2023-07-07T08:42:32.162Z]  "GET /src/assets/vite.svg" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36"
[2023-07-07T08:42:32.166Z]  "GET /src/assets/svelte.svg" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36"
[2023-07-07T08:44:09.458Z]  "GET /__open-in-editor?file=src%2FApp.svelte%3A8%3A3" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36"
[2023-07-07T08:44:09.459Z]  "GET /__open-in-editor?file=src%2FApp.svelte%3A8%3A3" Error (404): "Not found"

System Info
System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
    Memory: 6.83 GB / 31.69 GB
  Binaries:
    Node: 18.16.0 - ~\AppData\Local\Programs\NodeJS\node.EXE
    Yarn: 1.22.19 - ~\AppData\Local\Programs\NodeJS\yarn.CMD
    npm: 9.5.1 - ~\AppData\Local\Programs\NodeJS\npm.CMD
  Browsers:
    Edge: Spartan (44.22000.120.0), Chromium (114.0.1823.67)
    Internet Explorer: 11.0.22000.120
  npmPackages:
    @sveltejs/vite-plugin-svelte: ^2.4.2 => 2.4.2
    svelte: ^4.0.3 => 4.0.4
    vite: ^4.4.0 => 4.4.1

The vite client itself also uses config.base from resolved config: https://github.com/vitejs/vite/blob/abf536f920c32db1b96f6b4cabb510281e5170f5/packages/vite/src/node/plugins/clientInjections.ts#L27
not only having an absolute base but also running 2 servers and loading the vite client from the other one is quite an uncommon setup. I think for complete integration of vite, you are responsible for forwarding __openInEditor requests from that server to the vite devserver instance. (this would work ootb if you loaded vite as a middleware into eg express)

Of course Vite uses the base, but it's just a path; if you look at the surrounding lines, it uses the server config to build a full URL:
 const resolvedServerHostname = (await resolveHostname(config.server.host))
        .name
const resolvedServerPort = config.server.port!
const devBase = config.base

const serverHost = `${resolvedServerHostname}:${resolvedServerPort}${devBase}`

I think the inspector should do the same.

This kind of dual setup is unfortunately required for any incompatible backend; in my case the server is ASP.NET-based. Just migrating large, existing applications to Node is often not viable, so I do not think this should be considered an edge-case.
(Of course it would not make much sense to use http-server in conjunction with Vite like in my reproduction example.)

devBase is used to replace BASE in the overlay
where it is then prepended.
the code you showed is used by the vite devserver itself, not to reference the __openInEditor endpoint later on.

Oh, that looks like a bug then. I have never actually interacted with that overlay before.
I should test that and report an analogous issue in Vite if the links break in a scenario where the dev server is integrated instead of stand-alone.

Yeah we're following with Vite behaviour here. I don't think it's a bug in Vite either because the base is not always used to configure your local URL, but also for the prod domain, which is often added like base: "https://foo.github.io/project". So fixing this would break those projects.
The best workaround for now is to setup a proxy to redirect /__open-in-editor requests to Vite. I don't think a new option is needed here.

Bumping this as I am facing similar issue. It's not realistic for my app to proxy the open-in-editor requests as my app lives inside another. Would the maintainers be open to adding an "overrideBaseUrl" option to the plugin?

https://github.com/sveltejs/vite-plugin-svelte/issues/685#issuecomment-1628387095 still stands
no plans to introduce an option that serves a very low number of users and has a reasonable workaround (which would also be needed to make the vite error overlay stacktrace links work btw)

The origin of the stack trace links have been fixed after I reported the problem (vitejs/vite/issues/13770), they now use import.meta.url as base argument for the constructed URL. Tried this fix for the inspector and it would also lead to the correct origin.
I also would not exactly call it "reasonable" to be required to integrate proxying into an application to work around a bug in a development-only tool. This is especially true if you have a bunch of different applications.

svelte inspector has been built to be used within a vite devserver. Custom servers can be expected to provide the same environment as said devserver, or risk not having working tools not built for their custom server. We cannot service all custom integrations out there. If there is a fix for this that does not require adding an option and it keeps working in regular dev server use, i am happy to accept a PR. otherwise it is the responsibility of the custom server to provide the environment needed.


Add a Gitter chat badge to README.md

fre5h/transliteration now has a Chat Room on Gitter
@fre5h has just created a chat room. You can visit it here: https://gitter.im/fre5h/transliteration.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Coverage remained the same at 100.0% when pulling e5b6ab92e4dcb048013f657b2b7b4fca909b39d5 on gitter-badger:gitter-badge into 019f6df5afa891b6bb21f07a0e0257f3de8cd2a7 on fre5h:master.


Fix unnecessary dereferencing

Problem: compilation may fail due to unnecessary dereferencing.
Solution: remove the dereferencing.

Hint: use rust >= 1.52


Fix so a default PriorityClass can be used

https://github.com/redhat-cop/proactive-node-scaling-operator/issues/3
Currently the operator can not be used when setting a default PriorityClass for your regular workloads.
If your "normal workloads" have a priority of for example 1000 and you set this to globalDefault: true the cluster expects you to use a priorityClassName for priority. The integer "priority" value is not allowed. This happens because the global default uses the priorityClassName which you can override if you provide it in the pod spec.
If you don't, the following appears:
the integer value of priority (0) must not be provided in pod spec; priority admission controller computed 1000 from the given PriorityClass name
Because the "low-priority" pods have a fixed priority of 0 they will stay pending and never get scheduled with above error message. Changing it to priorityClassName: low-priority fixes this and allows the pods to be scheduled.

can you change this so that both priority (integer) and priority class can be set. If priority class is specified, it takes precedence.

can you change this so that both priority (integer) and priority class can be set. If priority class is specified, it takes precedence.

I don't think you're ever supposed to reference the priority in integer in a pod spec, as it's intended to derive the value from the name of the defined priority classes.
https://docs.openshift.com/container-platform/4.7/nodes/pods/nodes-pods-priority.html

I looked at the problem and I think you are right. So, now we need to fix the docs and say that one needs to create a low priority class with a given name we can default to. you opted for low-priority but this does not feel good an administration  might need it for something else. Let's use something like proactive-node-autoscaling-pods. Also let's add in the docs a step to create this priority class. Do you mind making these changes?

Done, changed the default priorityclass to proactive-node-autoscaling-pods and adjusted the docs / example YAML. :)


Dragging is not working when we use custom column header template - 'ngx-datatable-header-template'

[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter
Current behavior
When we use custom template for ngx-datatable-column.
Example : Your own implementation & demo :
https://github.com/swimlane/ngx-datatable/blob/master/demo/templates/template-dom.component.ts
&
https://swimlane.github.io/ngx-datatable/#inline
donot permit dragging for columns Name and Gender but only allow for Age ( which doesn't have a custom ng-template within ngx-data-datatable-column.
Expected behavior
Drag and repositioning of columns should work with inline templates as well
Reproduction of the problem
Please refer below links and try dragging columns other than Age.
https://github.com/swimlane/ngx-datatable/blob/master/demo/templates/template-dom.component.ts
&
https://swimlane.github.io/ngx-datatable/#inline
What is the motivation / use case for changing the behavior?
Dragging should work for custom column  headers as well
Please tell us about your environment:
VS Code

Table version: 0.8.x
Yes with most recent version

Angular version: 2.0.x
4.0

Browser: [all ]

Language: [all]

Never mind. Figured on my own. column header template should have 'draggable' class like this :
<ng-template let-column="column" let-sort="sortFn" ngx-datatable-header-template>                          {{column.name}}             </ng-template>
I would advise you to please improve your documentation to cover these gotchas.


Add JavaScript linting.

Using Eslint and Airbnb's styleguide.

This issue has been closed because it has been inactive for > 240 days.
You may reopen this issue if it has been closed in error.


⚠ Bofrost.at has degraded performance

In 98dd3e3, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1773 ms

Resolved: Bofrost.at performance has improved in f5d236a after 6 minutes.


Fix bug with quadratic objective and conic constraints

Description
Adds special case handling for power in the objective for the quadratic objective + conic constraints canonicalization path.
Issue link (if applicable): #2059
Type of change

[ ] New feature (backwards compatible)
[ ] New feature (breaking API changes)
[x] Bug fix
[ ] Other (Documentation, CI, ...)

Contribution checklist

[x] Add our license to new files.
[x] Check that your code adheres to our coding style.
[x] Write unittests.
[x] Run the unittests and check that they’re passing.
[x] Run the benchmarks to make sure your change doesn’t introduce a regression.

Tests are passing. Red mark is from SonarCloud.

@SteveDiamond The low coverage is only because the numpy/scipy version pinned in the config we use to run the coverage (macOS 3.8) is not compatible with SCS 3. The test is run successfully in other configs.


IE10 callback/promise issue in  setupFakeWorkerGlobal function

Hi,
I am facing issue to return promise of worker setup function in IE10. in other browser like IE9, IE11 & chrome it's working fine but in IE10 pdf is not rendering in HTML canvas and XHR service call not going to read pdf file.
I have already added compatibility.js
PDF.js / Line no 9581
function setupFakeWorkerGlobal() {
var WorkerMessageHandler;
if (!fakeWorkerFilesLoadedCapability) {
fakeWorkerFilesLoadedCapability = createPromiseCapability();
var loader = fakeWorkerFilesLoader || function (callback) {
Util.loadScript(getWorkerSrc(), function () {
Note: In IE10 callback called before return promise.
callback(window.pdfjsDistBuildPdfWorker.WorkerMessageHandler);
});
};
loader(fakeWorkerFilesLoadedCapability.resolve);
}
return fakeWorkerFilesLoadedCapability.promise;
}

_setupFakeWorker: function PDFWorker_setupFakeWorker() {
                    setupFakeWorkerGlobal().then(function (WorkerMessageHandler) {

***** inside then Code not calling in IE10. **
if (this.destroyed) {
this._readyCapability.reject(new Error('Worker was destroyed'));
return;
}
***So service call not going to read pdf file.
}.bind(this));
},
Thanks You...

This issue will be closed as incomplete in its current form. Please provide all information requested in the issue template (https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md) and make sure that you provide a runnable example for us to test with. We cannot debug the issue with just code snippets.

No in IE10 console not giving any error or warning.
Configuration:
Web browser and its version:   64 bit IE V.10
Operating system and its version: Windows 7 Enterprise  64-bit
PDF.js version:    var pdfjsVersion = '1.5.188';
Is an extension:   No
Steps to reproduce the problem:
step 1.
in getDocument() function creating new worker instance. (line # 8766)
step 2.
During PDFWorker initialize  _setupFakeWorker function called (line # 9748)
step 3.
in setup fake worker, SetupFakeWorkerGlobal() function called with promise.(line # 9757)
step 4.
Code between SetupFakeWorkerGlobal(),then({}) not executed in IE10 as loader(fakeWorkerFilesLoadedCapability.resolve) returns before return promise (line# 9590)
What is the expected behavior? (add screenshot)
First promise must return from SetupFakeWorkerGlobal() & then call back function called once Util.loadscript() function load worker script. (line # 9595)
What went wrong? (add screenshot)
pdf.worker.js file load from server but after that XHR service call not going to Read/Load PDF file. Problem is in IE 10 only. might be loader function create issue ?
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Hi Tim,
During Analysis i found that there was one existing library in my project having code for promise/polyfill which was creating issue in our promise in IE10. after removing that code currently its working fine in all browser which we are currently supported.
Thank you so mush for your kind support & such good library which helps a lot.


Would you accept some help on this project?

Hi :)
You did an amazing work with this project! I also developed a similar tool (php7-checker). When I started it, the goal was mainly to give a try to the PhpParser project and it was some fun to do it.
Sadly, I didn't find your library before I started mine. But as your library is far more advanced, I propose to deprecate my project in favor of yours. Would you accept some help on php7cc? I can already see some improvements that could be done like:

increase list of functions removed
improve the console output (with some colors fe).

Hello, @pyrech. Thank you for your interest.
Sure, any help is always appreciated. There are no "official" contributing guidelines currently, but please format the code according to PSR2. If you are adding something non-trivial, it would be great if you could also write tests for it.
For relatively minor features and impovements like you've listed in your original post, you can submit pull requests directly. If you are planning on doing something that requires a lot of changes and/or big refactoring, please open an issue first so we can discuss it.

Ok, cool, thanks. I will try to do some small fixes this weekend ;)


Windows defender marking NodistSetup-v0.8.7.exe as a virus

The following error occurred: Error code 0x80508023. The program could not find the malware and other potentially unwanted software on this computer.
Category: Trojan
Description: This program is dangerous and executes commands from an attacker.
Recommended action: Remove this software immediately.
Items:
file:C:\Users\Justin\Downloads\NodistSetup-v0.8.7.exe
webfile:C:\Users\Justin\Downloads\NodistSetup-v0.8.7.exe|https://github-cloud.s3.amazonaws.com/releases/4850299/c7d74b06-994c-11e6-8ac1-6a271d5b4635.exe?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20161206%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20161206T221743Z&X-Amz-Expires=300&X-Amz-Signature=bd613babd82efa8ce376f39accf8a518c7afed7bc666bb44b31252c6e5a904b2&X-Amz-SignedHeaders=host&actor_id=1547881&response-content-disposition=attachment%3B%20filename%3DNodistSetup-v0.8.7.exe&response-content-type=application%2Foctet-stream|chrome.exe
Get more information about this item online.
https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3AWin32%2FDetplock&threatid=2147680291&enterprise=0

Thanks for reporting. I will submit a report to Microsoft using their form.
Can you provide the windows version? Could you retry after updating the definitions and if that doesn't help paste the definitions version here?

In your Microsoft security software, click the arrow next to the Help button and then click About
Select the definition information and press Ctrl+C.
Paste the information on the text box on the right.

Also, the exact scan result would be helpful:

In your Microsoft security software, click on the History tab.
Click on All detected items.
Copy the name of the detection into the text box on the right.

Thank you! :)

Got a detection myself just now, with a different antivirus vendor. I will check with virustotal.com

Can't reproduce with the latest version and all anti virus updates, plus virustotal.com lists only 5 false positives from afaict minor vendors (not Microsoft, oddly enough), so I'm closing this as a won't fix.

It probably does that to all nullsoft installers. They are used to
distribute lots of mal and spy ware.
On Dec 16, 2016 3:57 PM, "Marcel Klehr"<EMAIL_ADDRESS>wrote:
Can't reproduce with the latest version and all anti virus updates, plus
virustotal.com lists only 5 false positives from afaict minor vendors (not
Microsoft, oddly enough), so I'm closing this as a won't fix.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/marcelklehr/nodist/issues/187#issuecomment-267716373,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACNr31xHKI-yeJTwRc6Ny6LwD8di-0Slks5rIxdigaJpZM4LF9UC
.

Sorry for the delayed response. What I posted above was the exact response in Windows Defender. After updating to the latest, it went away. If it happens again, I'll let you know

Great! thanks for the feedback. :)


Custom Scrollbar added

Scrollbar with same theme added to enhance the UI.

Thank you for submitting your pull request! 🙌 We'll review it as soon as possible. In the meantime, please ensure that your changes align with our CONTRIBUTING.md. If there are any specific instructions or feedback regarding your PR, we'll provide them here. Thanks again for your contribution! 😊


dispatchEvent submit does not work in ie11

Prerequisites

[x] I have read the documentation;
[x] In the case of a bug report, I understand that providing a SSCCE example is tremendously useful to the maintainers.
[x] Ideally, I'm providing a sample JSFiddle or a shared playground link demonstrating the issue.

Description
In Internet Explorer when attempting to submit the form, the following error occurs:

Steps to Reproduce
Submit a form.
Expected behavior
The form to submit.
Actual behavior
Error in ie11.
Version
Latest
I'll probably have to come up with a way of polyfilling the Event on the form but I'm wondering why dispatchEvent was chosen in the first place over calling .submit directly on the form element?

Not sure, it seems to have been added in by @sunweiye #1058.
If we can just call .submit directly and not lose any functionality, then I'm all for it.

I'm having a deeper look now - looks like Internet Explorer 11 doesn't support creating Event's ... I'll get back to this issue once (if) I've got a neat solution.

Thanks for looking into the fix. Is there an ETA on when this is targeted for merge and release creation ?

For anyone else having this issue, this is how I am resolving it
(function () {   if (typeof Event !== 'function') {     window.Event = CustomEvent;   } })();


Name for Stack, Services and sidekicks should be limited to 63 characters

Version Master with latest reskin UI
Comments:
The name fields are currently set to allow 255 characters.  This should be brought down to 63.

They need to be <= 63 characters to be valid DNS labels.

Verified with latest UI (11/24 evening)


 is not working

It is entering into the function but not navigation to other components.

<Switch> takes the first route or redirect that matches. So it will take your route for SpeechListForm and will not try your redirect.

@MeiKatz  I tried removing the switch. Or else it there anything should I modify?

Also, please don't ignore and erase the issue template.


Password confirmation validation message does not vanish when password text field changes

When entering a password and confirm password field information on the azure arc data controller create screen, if a user enters a password incorrectly then upon trying to navigate to next page, an error shows up as below. However, this error does not vanish as the user starts typing in new password information. It gets revalidated only when the user tries to navigate out of that page again.

@ranasaria is this needed for Nov and is the fix on track for end of week?

No. Moved it.

The message is updated as the user types - removing it once the two fields match.
(this should really be using the inputbox validation but that's a separate issue)


⚠ ClamAV has degraded performance

In 72ce7d8, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 600 ms

Resolved: ClamAV performance has improved in 8edfc82.