run_criteria/yes/101_systems                             1.14     96.6±8.29µs        ? ?/sec      1.00     84.5±3.39µs        ? ?/sec
run_criteria/yes_using_query/001_systems                 1.65      6.2±0.22µs        ? ?/sec      1.00      3.8±0.13µs        ? ?/sec
run_criteria/yes_using_query/006_systems                 1.48     12.8±0.38µs        ? ?/sec      1.00      8.6±0.37µs        ? ?/sec
run_criteria/yes_using_query/011_systems                 1.46     18.4±1.22µs        ? ?/sec      1.00     12.6±0.63µs        ? ?/sec
run_criteria/yes_using_query/016_systems                 1.47     24.0±2.52µs        ? ?/sec      1.00     16.3±0.71µs        ? ?/sec
run_criteria/yes_using_query/021_systems                 1.40     28.4±2.53µs        ? ?/sec      1.00     20.3±1.07µs        ? ?/sec
run_criteria/yes_using_query/026_systems                 1.37     33.3±2.84µs        ? ?/sec      1.00     24.2±0.98µs        ? ?/sec
run_criteria/yes_using_query/031_systems                 1.35     38.7±1.96µs        ? ?/sec      1.00     28.7±1.26µs        ? ?/sec
run_criteria/yes_using_query/036_systems                 1.31     42.7±2.93µs        ? ?/sec      1.00     32.5±1.31µs        ? ?/sec
run_criteria/yes_using_query/041_systems                 1.33     48.1±3.20µs        ? ?/sec      1.00     36.2±1.66µs        ? ?/sec
run_criteria/yes_using_query/046_systems                 1.29     51.1±3.71µs        ? ?/sec      1.00     39.7±1.25µs        ? ?/sec
run_criteria/yes_using_query/051_systems                 1.31     57.0±4.18µs        ? ?/sec      1.00     43.4±1.48µs        ? ?/sec
run_criteria/yes_using_query/056_systems                 1.21     58.6±5.94µs        ? ?/sec      1.00     48.5±1.58µs        ? ?/sec
run_criteria/yes_using_query/061_systems                 1.21     62.6±5.36µs        ? ?/sec      1.00     51.8±2.32µs        ? ?/sec
run_criteria/yes_using_query/066_systems                 1.25     69.6±4.94µs        ? ?/sec      1.00     55.6±2.17µs        ? ?/sec
run_criteria/yes_using_query/071_systems                 1.24     73.0±6.70µs        ? ?/sec      1.00     58.9±2.33µs        ? ?/sec
run_criteria/yes_using_query/076_systems                 1.21     76.1±8.62µs        ? ?/sec      1.00     62.9±3.02µs        ? ?/sec
run_criteria/yes_using_query/081_systems                 1.25     81.9±7.86µs        ? ?/sec      1.00     65.7±3.12µs        ? ?/sec
run_criteria/yes_using_query/086_systems                 1.16     82.8±8.81µs        ? ?/sec      1.00     71.4±4.13µs        ? ?/sec
run_criteria/yes_using_query/091_systems                 1.17    86.8±10.23µs        ? ?/sec      1.00     74.4±3.26µs        ? ?/sec
run_criteria/yes_using_query/096_systems                 1.10     90.9±6.76µs        ? ?/sec      1.00     82.3±4.09µs        ? ?/sec
run_criteria/yes_using_query/101_systems                 1.12     94.0±8.51µs        ? ?/sec      1.00     84.2±3.37µs        ? ?/sec
run_criteria/yes_using_resource/001_systems              1.61      6.0±0.29µs        ? ?/sec      1.00      3.7±0.20µs        ? ?/sec
run_criteria/yes_using_resource/006_systems              1.40     12.2±0.74µs        ? ?/sec      1.00      8.7±0.20µs        ? ?/sec
run_criteria/yes_using_resource/011_systems              1.38     17.8±1.95µs        ? ?/sec      1.00     12.9±0.46µs        ? ?/sec
run_criteria/yes_using_resource/016_systems              1.40     23.5±2.12µs        ? ?/sec      1.00     16.8±0.58µs        ? ?/sec
run_criteria/yes_using_resource/021_systems              1.33     27.8±2.66µs        ? ?/sec      1.00     20.9±0.75µs        ? ?/sec
run_criteria/yes_using_resource/026_systems              1.33     33.5±2.79µs        ? ?/sec      1.00     25.1±0.93µs        ? ?/sec
run_criteria/yes_using_resource/031_systems              1.32     38.4±3.51µs        ? ?/sec      1.00     29.1±0.84µs        ? ?/sec
run_criteria/yes_using_resource/036_systems              1.27     42.2±3.24µs        ? ?/sec      1.00     33.3±1.34µs        ? ?/sec
run_criteria/yes_using_resource/041_systems              1.29     47.0±3.85µs        ? ?/sec      1.00     36.4±1.34µs        ? ?/sec
run_criteria/yes_using_resource/046_systems              1.27     51.3±3.60µs        ? ?/sec      1.00     40.5±1.31µs        ? ?/sec
run_criteria/yes_using_resource/051_systems              1.24     54.7±5.04µs        ? ?/sec      1.00     44.2±1.20µs        ? ?/sec
run_criteria/yes_using_resource/056_systems              1.27     59.9±6.51µs        ? ?/sec      1.00     47.1±2.40µs        ? ?/sec
run_criteria/yes_using_resource/061_systems              1.22     62.6±7.94µs        ? ?/sec      1.00     51.4±1.97µs        ? ?/sec
run_criteria/yes_using_resource/066_systems              1.23     67.7±5.80µs        ? ?/sec      1.00     55.2±2.12µs        ? ?/sec
run_criteria/yes_using_resource/071_systems              1.21     71.4±5.93µs        ? ?/sec      1.00     58.8±2.72µs        ? ?/sec
run_criteria/yes_using_resource/076_systems              1.26     80.5±7.30µs        ? ?/sec      1.00     64.0±3.40µs        ? ?/sec
run_criteria/yes_using_resource/081_systems              1.17     79.6±5.45µs        ? ?/sec      1.00     68.1±2.01µs        ? ?/sec
run_criteria/yes_using_resource/086_systems              1.18     84.9±6.54µs        ? ?/sec      1.00     72.0±2.20µs        ? ?/sec
run_criteria/yes_using_resource/091_systems              1.12     85.3±6.39µs        ? ?/sec      1.00     76.3±3.38µs        ? ?/sec
run_criteria/yes_using_resource/096_systems              1.11     89.6±7.13µs        ? ?/sec      1.00     80.5±2.98µs        ? ?/sec
run_criteria/yes_using_resource/101_systems              1.08     92.3±5.49µs        ? ?/sec      1.00     85.6±3.18µs        ? ?/sec
run_criteria/yes_with_labels/001_systems                 1.59      5.9±0.17µs        ? ?/sec      1.00      3.7±0.19µs        ? ?/sec
run_criteria/yes_with_labels/006_systems                 1.24     11.0±0.69µs        ? ?/sec      1.00      8.9±0.20µs        ? ?/sec
run_criteria/yes_with_labels/011_systems                 1.23     16.2±1.53µs        ? ?/sec      1.00     13.2±0.43µs        ? ?/sec
run_criteria/yes_with_labels/016_systems                 1.26     20.9±1.89µs        ? ?/sec      1.00     16.6±2.19µs        ? ?/sec
run_criteria/yes_with_labels/021_systems                 1.18     25.2±2.47µs        ? ?/sec      1.00     21.4±0.89µs        ? ?/sec
run_criteria/yes_with_labels/026_systems                 1.17     29.8±1.84µs        ? ?/sec      1.00     25.6±1.05µs        ? ?/sec
run_criteria/yes_with_labels/031_systems                 1.15     33.2±2.60µs        ? ?/sec      1.00     28.8±1.61µs        ? ?/sec
run_criteria/yes_with_labels/036_systems                 1.15     37.4±2.68µs        ? ?/sec      1.00     32.5±1.25µs        ? ?/sec
run_criteria/yes_with_labels/041_systems                 1.13     41.0±2.71µs        ? ?/sec      1.00     36.3±1.49µs        ? ?/sec
run_criteria/yes_with_labels/046_systems                 1.14     44.8±2.43µs        ? ?/sec      1.00     39.4±1.46µs        ? ?/sec
run_criteria/yes_with_labels/051_systems                 1.10     49.4±2.97µs        ? ?/sec      1.00     44.8±1.33µs        ? ?/sec
run_criteria/yes_with_labels/056_systems                 1.14     53.9±3.28µs        ? ?/sec      1.00     47.2±1.82µs        ? ?/sec
run_criteria/yes_with_labels/061_systems                 1.10     56.6±3.12µs        ? ?/sec      1.00     51.5±2.06µs        ? ?/sec
run_criteria/yes_with_labels/066_systems                 1.14     64.0±4.34µs        ? ?/sec      1.00     56.2±2.04µs        ? ?/sec
run_criteria/yes_with_labels/071_systems                 1.11     65.6±5.71µs        ? ?/sec      1.00     59.3±1.52µs        ? ?/sec
run_criteria/yes_with_labels/076_systems                 1.06     67.0±5.02µs        ? ?/sec      1.00     63.0±1.99µs        ? ?/sec
run_criteria/yes_with_labels/081_systems                 1.09     71.8±4.10µs        ? ?/sec      1.00     66.1±2.04µs        ? ?/sec
run_criteria/yes_with_labels/086_systems                 1.08     75.8±4.21µs        ? ?/sec      1.00     70.2±1.81µs        ? ?/sec
run_criteria/yes_with_labels/091_systems                 1.05     78.4±4.85µs        ? ?/sec      1.00     74.9±2.17µs        ? ?/sec
run_criteria/yes_with_labels/096_systems                 1.00     81.8±6.04µs        ? ?/sec      1.01     82.3±2.73µs        ? ?/sec
run_criteria/yes_with_labels/101_systems                 1.02     85.5±9.67µs        ? ?/sec      1.00     83.7±2.77µs        ? ?/sec
schedule/base                                            1.05     38.1±2.98µs        ? ?/sec      1.00     36.4±2.35µs        ? ?/sec

Alright I think I've reached the limit of what is doable without writing our own lock free queues. There are some other optimizations I want to try out, but this PR is demonstrably significantly better than the status quo on main.

I'd like to see the "real app stage timings" tested again (both on main and with this pr rebased on main), just to prove that real apps see improvements with the final result.

I'd like to see the "real app stage timings" tested again (both on main and with this pr rebased on main), just to prove that real apps see improvements with the final result.

I'll reply with more complete results later, but I don't think any of examples we have (including the many_* stress tests) push my home computer hard enough to make too big of a difference:. Anecdotally, it doesn't seem to make too big of a difference. I'll try with more constrained task pool configuration later.
Unfortunately, while looking into this, I found the sleeper split also broke thread utilization, which likely means a lot of those perf gains on paper were just from lowered contention. I implemented tokio's search throttling into the executor to cut down on contention and it seems like it's about on-par with an unconstrained ComputeTaskPool (using 100% of the threads available on my PC, instead of allocating 25%/25% to the other pools) on main.
I'll test 3d_scene to ensure that the low-scale scenes aren't negatively impacted by this change.
Even if this is a net-zero for normal apps, I still think this PR is worth merging, both for the potential perf gains in more constrained systems with fewer hardware cores, and the actual code changes here make it easier to further optimize/customize the implementation for our needs, as well as enabling platform specific optimizations like #4803 or enabling thread priority.

I'll test 3d_scene to ensure that the low-scale scenes aren't negatively impacted by this change.

Yeah this was what I had in mind in my previous comment (i should have called that out explicitly).

Even if this is a net-zero for normal apps, I still think this PR is worth merging, both for the potential perf gains in more constrained systems with fewer hardware cores, and the actual code changes here make it easier to further optimize/customize the implementation for our needs, as well as enabling platform specific optimizations like https://github.com/bevyengine/bevy/issues/4803 or enabling thread priority.

I do think we're on the right track here (and I like that this opens the doors to fine-tuning), but I'd also prefer to manifest clear wins for real / common scenarios first, and be certain that we're testing the "right things". These changes are pretty uninvasive for user-facing apis, so I feel comfortable with taking our time here. This is so low in the stack (and has enough variables in the mix, as evidenced by the various discovered "thread contention" measurement questions that have come up) that it feels like a "measure 1000 times, cut once" scenario.

OK finally got around to measuring this after a few more optimizations. Recorded the results for many_cubes and 3d_scene with this latest commit and main. Overall, it seems like this would be a perf regression in the default case, but when you compare it to the case where we dedicate all of the threads to the compute task pool on main, it's a relative gain.
That said I think it's worth taking the results for stages with little to zero work in systems (First, AssetEvents, etc), as the majority of the work done in these stages when measuring with tracy is the tracing/profiling overhead which does artificially add contention.
In the many_cubes case, this doesn't speed up the PostUpdate stage primarily because of the contention over the internal channel it uses to communicate the results to the origin thread. If something like #4661 is merged, this contention should largely evaporate, which would likely put this PR's perf over main's due to the higher thread availability.
I think this does put us roughly in the same perf ballpark as before this PR, but removes the prior task assignment limitations for apps with heavier compute (provided they have don't have heightened contention internally), as well as allow more first party systems in the engine itself to go wide without too much concern.

3d_scene

stage
main (default)
main (all threads)
this PR

full frame
6.76ms
7.03ms
6.79ms

First
394.91us
385.31us
401.89us

LoadAssets
191.13us
1843.91us
197.91us

PreUpdate
89.55us
84.47us
94.77us

Update
32.6us
30.91us
32.06us

PostUpdate
268.29us
283.02us
263.73us

AssetEvents
178.38us
169.07us
178.22us

Last
27.09us
23.82us
23.82us

Extract
385.23s
367.78us
400.25ms

Prepare
272.84ms
257.43us
254.88ms

Queue
135.78us
133.23us
134.82us

Sort
78.82us
79.53us
81us

Render
4.57ms
4.7ms
4.61ms

Cleanup
34.93us
34.05us
32.28us

many_cubes

stage
main (default)
main (all threads)
this PR

full frame
19.94ms
19.74ms
19.65ms

First
411.71us
424.24us
420.79us

LoadAssets
193.32us
193.32us
207.15us

PreUpdate
95.6us
96.03us
101.51us

Update
53.52us
56.31us
56.31us

PostUpdate
3.32ms
3.34ms
3.36ms

AssetEvents
185.73us
189.78us
196.68us

Last
25.94us
27.12us
27.11us

Extract
3.7ms
3.67ms
3.62ms

Prepare
2.64ms
2.54ms
2.46ms

Queue
956.72us
938.45us
906.47us

Sort
993.08us
976.6us
991.65us

Render
7.49ms
7.28ms
7.24ms

Cleanup
38.46us
37.06us
36.4us

Found the source of the regression. We were eagerly notifying lower priority task groups if a higher priority one was already notified. This wasn't causing additional contention, but it was causing lower priority threads to be notified around the same time or even before higher priority threads were notified. Said lower priority threads were stealing higher priority tasks (up to half of them in the queue) before the higher priority threads had an opportunity to steal within the group. As higher priority task groups cannot steal from lower priority threads, these tasks, as mentioned above, were getting stuck in smaller thread groups, which was limiting parallelism.
The fix to this was just to avoid notifying lower priority threads if there were available threads in the current priority group that were waiting to be awoken. I also added a cap on the number of tasks that lower priority threads can steal, up to the total number of threads in the lower priority group. This setup prohibits unbounded stealing from higher priority thread groups, but allows stealing just enough to keep all of the local group busy.

3d_scene

stage
main (default)
main (all threads)
this PR

full frame
2.47s
2.44ms
2.44ms

First
368.33us
354.91us
352.67us

LoadAssets
175.49us
170.1us
166.71us

PreUpdate
82.73us
81.21us
81.25us

Update
29.96us
30.15us
28.11us

PostUpdate
241.24us
266.66us
264.42us

AssetEvents
166.01us
164.67us
158.21us

Last
24.33us
25.05us
24.22us

Extract
362.56s
354.93us
347.22ms

Prepare
247.4us
234.53us
245.85s

Queue
128us
127.45us
126.74us

Sort
77.58us
75.71us
73.72us

Render
430.2us
427.65us
419.83us

Cleanup
29.36us
29.44us
28.31us

many_cubes

stage
main (default)
main (all threads)
this PR

full frame
19.94ms
19.74ms
19.92ms

First
411.71us
424.24us
368.75us

LoadAssets
193.32us
193.32us
180.50us

PreUpdate
95.6us
96.03us
89.25us

Update
53.52us
56.31us
51.1us

PostUpdate
3.32ms
3.34ms
3.29ms

AssetEvents
185.73us
189.78us
174.02us

Last
25.94us
27.12us
25.52us

Extract
3.7ms
3.67ms
3.47ms

Prepare
2.64ms
2.54ms
2.53ms

Queue
956.72us
938.45us
916.92us

Sort
993.08us
976.6us
959.32us

Render
7.49ms
7.28ms
7.41ms

Cleanup
38.46us
37.06us
36.37us

@hymm @cart I think this is ready for another pass. The perf/overhead concerns seem to be largely addressed, showing some small gains for small scale apps too.

@hymm @cart I think this is ready for another pass. The perf/overhead concerns seem to be largely addressed, showing some small gains for small scale apps too.

Did you update the results in your earlier post or will you post them again?

Did you update the results in your earlier post or will you post them again?

The latest post I made with the perf results are the most up to date one so far. The commits following it are largely code quality updates that realistically have no impact on the perf of your typical operations.

@cart @hymm I've mostly updated the PR and this is once again up for review. After #4466, this added an unusual interaction since we need a temporary Executor, which I originally made with the assumption that it would be static and never be dropped. There were a few optimizations that definitely decrease overhead when (re)scheduling tasks. I can make another "SimpleExecutor" (as a Send-only MPSC executor) for this case that resolves this, but the problem remains that Executor is not meant to handle being dropped.
Should we:

Take the perf hit and revert those changes, supporting dropping Executor and by proxy TaskPool?
Or go all in on a global TaskPool and keep the optimizations?

2 would move us closer to a tokio-esque implementation where there's a single global runtime, while 1 would keep what we have and retain the approach that bevy_tasks has had thus far. Which one should we pursue? I'm personally inclined to push for 2 since it lets us make those assumptions and cut more overhead out, allows for more ergonomic initialization (i.e. #[tokio::main] style #[bevy::main]), and this PR reduces/removes the need to pass around &TaskPool or some newtype of it.

We don't necessarily need a temporary executor. We just need a way of running tasks that only run on the thread the scope is running on. This could potentially be a thread local storage queue that can't be stolen from.
A consideration here is that in https://github.com/bevyengine/bevy/pull/6503, I removed the temporary executor for a global main thread executor that has run time checks to only allow it to be ticked on the main thread. But not sure if that is going to get merged or not.

I'm leaning towards option 2. Seems like there isn't much need for users to construct their own taskpools now that we're using global task pools. The one issue might be if users will want to reconfigure the number of threads or thread distribution during execution.
On another note, it might be a good idea to port the micro benchmarks over from async_executor to get a better idea of how the current executor compares to the original.

Will this completely block us off from using the tokio ecosystem forever on our task pools? Or would we still be able to switch the tokio executor into our task pools somehow even if it doesn't have all the niceties (priorities)?

My biggest problem with reviewing this PR is that I have no idea how to understand the changes that were made to the async executor. I can look at the diff https://github.com/james7132/bevy/compare/b5fc0d2..task-pool-internalization and figure out what it's doing, but I have no context for why some things were changed. If you could port over the tests and benches from async executor I would have a lot more confidence that things are working as they're supposed to. Bonus points if you can get loom working somehow.

Just something to note: this sort of PR, where we have very tricky performance implications due to multithreading, different CPU cores being involved, etc, can be very sensitive to CPU hardware boost behaviors and such!
I am worried that there is a high risk of benchmarks being wildly inaccurate (when it comes to judging how much more/less efficient bevy's scheduling has become), due to different thread utilization, causing different boost clocks of different CPUs, etc. The benchmark results may therefore be skewed because of the particular CPU model of the computer they are run on.
I recommend, if possible, to benchmark this PR (and other multithreading/scheduling things) on a machine where all CPU cores can be forced to run at the same clock speeds (via BIOS settings, etc, to disable boost and clock frequency scaling).
Otherwise we can't really know how much we actually win/lose due to better multithreading / thread utilization, and how much of it was due to the particular CPU hardware boosting differently due to its cores being loaded differently.
This kind of thing is important in general, but for these sorts of PRs especially so. I would not trust benchmarks that were not done that way.

I recommend, if possible, to benchmark this PR (and other multithreading/scheduling things) on a machine where all CPU cores can be forced to run at the same clock speeds (via BIOS settings, etc, to disable boost and clock frequency scaling).

i have a machine with 272 threads, where the cores are all running the same speed, and as long as at least 3 cores are active then there is only 100mhz difference between base and boost clocks (1400MHz vs 1500MHz; 1600 is possible with 2 or fewer cores active), and i may be able to disable boost entirely.
i also have a simulation workload for that machine, which is affected by #1907, with rather severe underutilization of threads compared to what i would hope for.
i will test this PR with that machine/workload and share the results.

Going to return to the drawing board on this one. Taking on an entire fork of async_executor might not be in our interests. In the meantime, I'm potentially looking to experiment with switchyard, which provides better per-thread control over task allocation.


Segmentation fault (core dumped)

python -m mani_skill.examples.demo_random_action -e PickCube-v1
output:
opts: [] env_kwargs: {} Segmentation fault (core dumped)
GPU:RTX 3090
How can I solve this problem? Thank you for your reply!

Can you share the result of nvidia-smi, pip list, and what linux system you are on?

Can you share the result of nvidia-smi, pip list, and what linux system you are on?
Thank you for your reply.
I had this problem at the beginning of the step, I don't know what is the reason? mani-skill2 has the same problem.
I'm using Ubuntu 20.04 LTS on the server side (GNU/Linux 5.4.0-174-generic x86_64).
nvidia-smi:
`
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3090        Off |   00000000:1A:00.0 Off |                  N/A |
| 30%   31C    P8             31W /  350W |      14MiB /  24576MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA GeForce RTX 3090        Off |   00000000:1B:00.0 Off |                  N/A |
| 30%   30C    P8             20W /  350W |      14MiB /  24576MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   2  NVIDIA GeForce RTX 3090        Off |   00000000:3D:00.0 Off |                  N/A |
| 30%   27C    P8             18W /  350W |      14MiB /  24576MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   3  NVIDIA GeForce RTX 3090        Off |   00000000:3E:00.0 Off |                  N/A |
| 30%   29C    P8             21W /  350W |      14MiB /  24576MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   4  NVIDIA GeForce RTX 3090        Off |   00000000:88:00.0 Off |                  N/A |
| 65%   58C    P2            229W /  350W |   15461MiB /  24576MiB |    100%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   5  NVIDIA GeForce RTX 3090        Off |   00000000:89:00.0 Off |                  N/A |
|  0%   52C    P2            226W /  350W |   15939MiB /  24576MiB |    100%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   6  NVIDIA GeForce RTX 3090        Off |   00000000:B1:00.0 Off |                  N/A |
| 51%   52C    P2            229W /  350W |   16203MiB /  24576MiB |    100%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   7  NVIDIA GeForce RTX 3090        Off |   00000000:B2:00.0 Off |                  N/A |
| 52%   51C    P2            230W /  350W |   15839MiB /  24576MiB |     89%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    1   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    2   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    3   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    4   N/A  N/A   1900905      C   ...gzhou/anaconda3/envs/tc2/bin/python       6584MiB |
|    4   N/A  N/A   2032157      C   ...gzhou/anaconda3/envs/tc2/bin/python       8850MiB |
|    4   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    5   N/A  N/A   1900906      C   ...gzhou/anaconda3/envs/tc2/bin/python       6550MiB |
|    5   N/A  N/A   2032158      C   ...gzhou/anaconda3/envs/tc2/bin/python       9362MiB |
|    5   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    6   N/A  N/A   1900907      C   ...gzhou/anaconda3/envs/tc2/bin/python       6982MiB |
|    6   N/A  N/A   2032159      C   ...gzhou/anaconda3/envs/tc2/bin/python       9194MiB |
|    6   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
|    7   N/A  N/A   1900908      C   ...gzhou/anaconda3/envs/tc2/bin/python       6758MiB |
|    7   N/A  N/A   2032160      C   ...gzhou/anaconda3/envs/tc2/bin/python       9054MiB |
|    7   N/A  N/A   3955805      G   /usr/lib/xorg/Xorg                              8MiB |
+-----------------------------------------------------------------------------------------+
conda list
Package                  Version

asttokens                2.4.1
certifi                  2024.7.4
charset-normalizer       3.3.2
cloudpickle              3.0.0
contourpy                1.2.1
cycler                   0.12.1
dacite                   1.8.1
decorator                5.1.1
docstring_parser         0.16
eval_type_backport       0.2.0
exceptiongroup           1.2.2
executing                2.0.1
Farama-Notifications     0.0.4
fast_kinematics          0.2.2
filelock                 3.15.4
fonttools                4.53.1
fsspec                   2024.6.1
gitdb                    4.0.11
GitPython                3.1.43
gymnasium                0.29.1
h5py                     3.11.0
huggingface-hub          0.23.5
idna                     3.7
imageio                  2.34.2
imageio-ffmpeg           0.5.1
importlib_metadata       8.0.0
importlib_resources      6.4.0
ipython                  8.18.1
jedi                     0.19.1
Jinja2                   3.1.4
kiwisolver               1.4.5
lxml                     5.2.2
mani_skill               3.0.0b5
markdown-it-py           3.0.0
MarkupSafe               2.1.5
matplotlib               3.9.1
matplotlib-inline        0.1.7
mdurl                    0.1.2
mplib                    0.1.1
mpmath                   1.3.0
networkx                 3.2.1
numpy                    2.0.0
nvidia-cublas-cu12       <IP_ADDRESS>
nvidia-cuda-cupti-cu12   12.1.105
nvidia-cuda-nvrtc-cu12   12.1.105
nvidia-cuda-runtime-cu12 12.1.105
nvidia-cudnn-cu12        <IP_ADDRESS>
nvidia-cufft-cu12        <IP_ADDRESS>
nvidia-curand-cu12       <IP_ADDRESS>
nvidia-cusolver-cu12     <IP_ADDRESS>
nvidia-cusparse-cu12     <IP_ADDRESS>
nvidia-nccl-cu12         2.20.5
nvidia-nvjitlink-cu12    12.5.82
nvidia-nvtx-cu12         12.1.105
opencv-python            <IP_ADDRESS>
packaging                24.1
parso                    0.8.4
pexpect                  4.9.0
pillow                   10.4.0
pip                      24.0
prompt_toolkit           3.0.47
psutil                   6.0.0
ptyprocess               0.7.0
pure-eval                0.2.2
Pygments                 2.18.0
pyparsing                3.1.2
pyperclip                1.9.0
python-dateutil          2.9.0.post0
PyYAML                   6.0.1
requests                 2.32.3
rich                     13.7.1
Rtree                    1.3.0
sapien                   3.0.0b1
scipy                    1.13.1
setuptools               69.5.1
shtab                    1.7.1
six                      1.16.0
smmap                    5.0.1
stack-data               0.6.3
sympy                    1.13.0
tabulate                 0.9.0
toppra                   0.6.0
torch                    2.3.1
torchaudio               2.3.1
torchvision              0.18.1
tqdm                     4.66.4
traitlets                5.14.3
transforms3d             0.4.2
trimesh                  4.4.3
triton                   2.3.1
typing_extensions        4.12.2
tyro                     0.8.5
urllib3                  2.2.2
wcwidth                  0.2.13
wheel                    0.43.0
zipp                     3.19.2
`

I hope the bug is not related to having 8 connected GPUs (we have not tested on such a setup before).
A few possible ideas:

Install a older version of numpy (1.26.4 works)
Install a older version of torch (2.2.1 works)

Just realized with the new numpy release I need to pin our numpy dependency to <2.0.0 probably.
If the two other installs do not fix it, there may be a chance your nvidia driver is too new (550). 535.183.01 and cuda version 12.2 is what I run now (535.X should work). You can try downgrading the driver (if you use apt, make sure you install nvidia-driver-xxx without the word server or headless in its name).
Can you also run ldconfig -p | grep libGLX_nvidia?

ldconfig -p | grep libGLX_nvidia
output:
libGLX_nvidia.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libGLX_nvidia.so.0
I tried to lower the numpy and torch versions, but it didn't work, it was still a Segmentation fault (core dumped). Has anyone else had this problem? I was afraid to drop the driver version because others were sharing the server. What is the fault caused by this [Segmentation fault (core dumped)], which is strange, and nothing else is reported?

@fbxiang any idea? The driver version is very new and I have not used it before so I suspect it might be that.

Actually @baiyu858 can you run
python -m sapien.example.hello_world

Actually @baiyu858 can you run 你能跑吗?
python -m sapien.example.hello_world

python -m sapien.example.hello_world
output:
Segmentation fault (core dumped)

Another option is to try and pull the docker image and run the example code from there? You will need to setup nvidia docker containers if you haven't done so before. https://maniskill.readthedocs.io/en/latest/user_guide/getting_started/docker.html

@baiyu858 try to downgrade your numpy to 1.26

@baiyu858 try to downgrade your numpy to 1.26

This makes a lot of sense.

I asked the user to downgrade earlier to 1.26 but they said it did not work

try reinstalling vulcan, and also follow the vulcan trouble shooting guide on our docs (make sure those icd files are there)

Closing the issue as it is stale


O.Optional removes non optional properties

I think this is something new since the latest version
type AAA = O.Optional<
{
  values: number[],
  optValues: number[]
},
"optValues"
>

this only yields optValues?: number[] | undefined; and removes values

Thank you, I'm looking into it.

And another bug is gone, thank you!


Chronometer alarm usually continues playing continually until stopped manually

I've found an issue where most of the time, Chronometer alarms that have activated will keep playing continuously, until they're stopped manually, rather than stopping when they reach the expected duration.
The first time the alarm runs after Rainmeter starts (or the first time it runs after the Chronometer Settings widget is opened... which makes testing difficult because I can only test every 24 hours), it usually works as expected - the problem seems to happen more consistently on subsequent runs. Refreshing the skin manually doesn't seem to make a difference.
I've tried watching the skin measures under Rainmeter/Open Log/Skins, but I can't see anything odd to indicate why it isn't happening. The MeasureAlarm[1|2]Loop loop seems to go through the cycle as expected, so I don't know why IfTrueAction4 isn't working. (Edit: for the first time tonight I had this open prior to the alarm starting, and this time MeasureAlarm1Loop stayed disabled when the alarm started, but I've never seen this before.
Chronometer.ini and ChronometerSettings.inc attached.
Chronometer.ini
ChronometerSettings.inc

Update: behaviour seems to have changed, I'm not sure if this is due to updates in Rainmeter itself? It now looks like on the first run, the loop runs fine - but on subsequent runs, MeasureAlarm[1|2]Loop is stuck on zero and so never reaches the counter. (I've been gradually learning more about logging etc. to try and solve it.)
I've tried inserting a command to reset the measure via MeasureAlarm[1|2]Diff - e.g. in MeasureAlarm1Diff, I've added a Reset command into IfTrueAction (bolded below):
New version:
[MeasureAlarm1Diff]
Measure=Uptime
Format=%4!i!d %3!i!h %2!i!m %1!i!s
SecondsValue=([MeasureAlarm1Time:TimeStamp] - [MeasureLocalTimeOfDay:TimeStamp])
DynamicVariables=1
Disabled=(#enableAlarm1# = 0)
IfCondition=MeasureAlarm1Diff = 0
IfTrueAction=[!CommandMeasure MeasureAlarm1Loop Reset][!EnableMeasure MeasureAlarm1Loop]
This seems to have the desired effect - the loop is running as expected and the alarm is stopping at the expected time.

FIxed in #272


Normals don't seem to change when I rotate a mesh

The title says it all, basically.  When you rotate an object, shouldn't its normals change?

I think you're right, I've added a fix for it: https://github.com/WoLpH/numpy-stl/commit/c1c63e5f7caad80c864000933b3ce4da2f7a82bc
Can you try if that works for you? If so, I'll push out a new release


Attach BTF to generated BPF programs

Modern BPF programs loaded through libbpf should include BTF information describing their structure and data. This is required for some BPF features such as subprograms or kernel functions (kfuncs) to work. It is also a necessary prerequisite for #2334.
This PR is the first step for doing this in bpftrace. We produce standard (DWARF) debug info for our probes which LLVM then converts into proper BTF sections. These are then passed to libbpf upon bpf_prog_load. At the moment, this doesn't add any value but we at least check that libbpf doesn't reject our produced BTF info.
This is the second part of #2710 posted separately to simplify reviewing.
Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

I rebased to the current master to run tests with the CI libbpf. I'll wait 24 hours and then merge this, unless there are objections.


build: depend stopwatch in sources

The upstream suffers from:
the following packages contain code that will be rejected by a future version of Rust: rustc-serialize v0.3.24

... which is introduced by old versioned "num" that is brought by stopwatch. Given that stopwatch is no longer maintained, we can copy its source and depend it in source form. I properly handled the LICENSE issue.

@PierreZ maybe you can trigger test once more.


Add initial implementation to support DO LoadBalancers

Description of your changes
Add initial implementation to have DO LoadBalancers in crossplane provider DO
also:

fix a small bug in the compute when creating the resource

Future work

add support to add more Foward rules
add support for other options
integrate that with the compute, so can create compute resources and attach that in the LB
Add tests

Please let me know what you think about this. all feedback is welcome.
/assign @hasheddan
$ kubectl get lbs
NAME   READY   SYNCED
test   False   True

...after a few minutes

$ kubectl get lbs
NAME   READY   SYNCED
test   True   True

I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

@hasheddan gently ping, also feel free to close if don't want to add this at this moment

Hello @cpanato 👋  we merged some changes that fixes the issues stopping this and updates a few things. If you could pull those changes and double check that everything still works I believe we can get this merged!

@ADustyOldMuffin done

Thanks for your patience!


Lower GLIBC requirements by using building linux natives on ubuntu 18.04 docker

alternative to https://github.com/libgdx/libgdx/pull/7177
https://github.com/theofficialgman/libgdx/actions/runs/5470509920
I personally prefer the GLIBC reversion script since it allows us to continue using github actions runners (and all the dependencies that are pre-installed). This PR has the same minimum GLIBC requirements (GLIBC 2.17)
I would attempt using musl to build the debs which would have an advantage of being able to statically link (no glibc) however its very difficult to compile projects using its (since everything including a projects dependencies need to be compiled with musl) (see https://github.com/desktop/dugite-native/pull/502#discussion_r1253754491 for my struggles with anothe project doing that)

@Berstanio no issues have been brought up. please merge this and https://github.com/libgdx/Jamepad/pull/23

It has the neccessary approvals, merging.

Thank you very much for merging this. Just as a note, a similar change will probably be needed for jamepad, box2d, bullet, and freetype native binaries.

Thank you very much for merging this. Just as a note, a similar change will probably be needed for jamepad, box2d, bullet, and freetype native binaries.

jamepad is the only (that I am aware of) in development library that requires natives that is currently affected, there is a PR open (see two posts above). eg: box2d has natives but has not been built since 2020 (github actions 16.04 was used to build it)


Help

fca problem i think

yes, and the current fix for this is to switch to another account

have you found the solution? same thing happened for me, tried on 2 accounts


Many errors when downloaded through CocoaPods

Many errors regarding the Attributed strings in Swift 4

I have used this library in my project and thats very helpful @victorBaro  Please take a look and update this for swift 4 .

@tapizquent @hanandev sorry guys. Totally understand. I am a bit overload with work at the moment. Will update asap.

@victorBaro Thanks for your prompt reply we will wait for the next release

Fixing it now. Uploading version 0.6


reset user token after failed checkAuth() method in AuthClient

Codecov Report

Merging #326 (b44a9bd) into main (d9b1efa) will decrease coverage by 0.00%.
The diff coverage is 46.66%.

@@            Coverage Diff             @@
##             main     #326      +/-   ##
==========================================
- Coverage   11.61%   11.60%   -0.01%
==========================================
  Files         537      537
  Lines       38662    38665       +3
  Branches     1127     1127
==========================================
- Hits         4490     4487       -3
- Misses      33738    33744       +6
  Partials      434      434

Impacted Files
Coverage Δ

src/core/auth/client/AuthClient.ts
0.00% <0.00%> (ø)

src/core/url_store/URLStore.ts
0.00% <0.00%> (ø)

src/core/apiClientInstance.ts
92.30% <33.33%> (-7.70%)
:arrow_down:

src/core/api_client/apiClient.ts
75.29% <75.00%> (ø)

src/core/api_client/types.ts
97.04% <100.00%> (-0.06%)
:arrow_down:


[BUG] No Amp Models??

Hello,
im New to NAM and im very interested to play it in my DAW or as a Stanalone Version, but sadly i dont have any Amp Models or Profiles that are should be included directly after i downloaded it??
Pls help, idk what to do.
Love to hear some Answers and Results!!!
Thank You!

There are a few public repositories available.
https://www.tonehunt.org/
http://coginthemachine.ddns.net/mnt/nam/

Hello Atkinson,
thank you, the Tonehub one was very helpful.
Kind Regards
Am Di., 24. Sept. 2024 um 09:24 Uhr schrieb 38github <
@.***>:

There are a few public repositories available.
https://www.tonehunt.org/
http://coginthemachine.ddns.net/mnt/nam/
—
Reply to this email directly, view it on GitHub
https://github.com/sdatkinson/neural-amp-modeler/issues/471#issuecomment-2370405035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BLQO3ZWEACA2KKL6RIGX66DZYEHS5AVCNFSM6AAAAABOV7Q33GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZQGQYDKMBTGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

It looks like you're looking for NeuralAmpModelerPlugin, but as it just so happens, this is the repository with the code that makes the models!
You should give it a try! 🙂

Thank you for helping me, it worked!
kind regards
Steven Atkinson @.***> schrieb am Fr. 27. Sep. 2024 um
17:40:

It looks like you're looking for NeuralAmpModelerPlugin, but as it just
so happens, this is the repository with the code that makes the models!
You should give it a try! 🙂
—
Reply to this email directly, view it on GitHub
https://github.com/sdatkinson/neural-amp-modeler/issues/471#issuecomment-2379570520,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BLQO3ZTO4XW2QHYBAPABWNDZYV36ZAVCNFSM6AAAAABOV7Q33GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZZGU3TANJSGA
.
You are receiving this because you authored the thread.Message ID:
@.***>


added UART logging to BSP_CAN

This is the modified version of the BPS code I want to run for the fully day test on Wednesday. I don't actually plan on merging this (unless we want to enable something like this in debug mode), but I'm opening a pull request to get some code reviews

I think it would be nice if we could have something like this in debugging mode (at least until CLI is finished). Could we just surround this in an ifdef in case we wanted to leave it in master?

This was throttling the system when we tried to run it on test day because UART is slower than CAN, and we send a lot of CAN messages, so I think we should not do this


Empty Message passed in the chat

Description
The Input field is not checking whether the input message is empty.
Screenshots

Additional information
No response
🥦 Browser
Google Chrome
👀 Have you checked if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read and understood the rules in the Contributing Guidelines

Are you willing to work on this issue ?
Yes I am willing to submit a PR!

I want to work on this issue :)

I want to work on this issue :)

Definitely, thanks for wanting to contribute, Make sure you follow the rules 👉🏽here👈🏽, else your PR will not be accepted and will be closed. Good Luck


jetty: 9.4.39.v20210325 -> 9.4.41.v20210516

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/jetty/versions.
meta.description for jetty is: "A Web server and javax.servlet container"
meta.homepage for jetty is: "https://www.eclipse.org/jetty/"
meta.changelog for jetty is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 9.4.41.v20210516 in filename of file in /nix/store/hjgzxb4n8r0f25sqmyd5xcn0gwkk0s0c-jetty-9.4.41.v20210516

directory tree listing: https://gist.github.com/4cb99196c27cac651f37d6de6d904a00

du listing: https://gist.github.com/8fddd179dd2ffec18e8c15dcd76804d6

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
jetty

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/hjgzxb4n8r0f25sqmyd5xcn0gwkk0s0c-jetty-9.4.41.v20210516 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A jetty https://github.com/r-ryantm/nixpkgs/archive/8bfc237eb3bf79b42def350c5cf8b7c673deda79.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hjgzxb4n8r0f25sqmyd5xcn0gwkk0s0c-jetty-9.4.41.v20210516
ls -la /nix/store/hjgzxb4n8r0f25sqmyd5xcn0gwkk0s0c-jetty-9.4.41.v20210516/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

jetty

Maintainer pings
cc @emmanuelrosa for testing.

Result of nixpkgs-review pr 123563 at 8bfc237e run on x86_64-linux 1

2 packages built successfully:

jetty
tests.trivial

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/servers/http/jetty/default.nix:13:3:
   |
13 |   installPhase = ''
   |   ^


Missing API_BASE leads to IOError when hitting /

https://gist.github.com/anonymous/19bd2386b12c1f416b92
README should include how to set the API_BASE so regulations-site knows where to get data from. We can use atf-eregs as an example.
$ echo "API_BASE = 'https://atf-eregs.apps.cloud.gov/api/'" >> local_settings.py

This was added #489


Check beaver cost model

Quoting an author (I think):

Great work, this is an long due effort in this field. Though it's a bit unexpected to see beaver-cost model performed poorly on safety-related dataset. Have you checked if you have got the signs worked out? Because in our setting negative reward means safer and should be chosen.

Thanks for the quick fix!! (cc: @XuehaiPan)


Add stream selection support for tf.contrib.ffmpeg.decode_audio

This fix tries to address the issue raised in #16073 where it was not possible to selectively decode a perticular stream with tf.contrib.ffmpeg.decode_audio.
This fix adds an additional attribute stream which could be used to specify the stream to decode (e.g., stream="1"). By default stream="" which leaves the decision to ffmpeg.
This fix fixes #16073.
Signed-off-by: Yong Tang<EMAIL_ADDRESS>

The PR #16696 adds the stream selection support for tf.contrib.ffmpeg.decode_video.


[stable/grafana] DataSource provising using config-map is buggy

Version of Helm and Kubernetes:
Using minikube (but also reproducable in real k8s cluster)
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Which chart:
Grafana 1.12.0
What happened:
When changing datasources for provisioning the changes are not applied in grafana
What you expected to happen:
When i change my datasources config map the changes should be applied in grafana
How to reproduce it (as minimally and precisely as possible):

Deploy a grafana chart with configmaps for datasources.
Then check grafana -> datasource is configured
Update datasources configmap
Then check grafana -> datasource has not changed (This is normal because grafana seems to do provisioning of datasources only at startup
Restart/kill grafana pod so it will come up again
Check grafana -> datasource still not changes or even not there

Anything else we need to know:
I've figured out a workaround for this issue.
Exec into the grafana container and kill grafana (kill 1). Then only the grafana container will be recreated. And afterwards the datasource config map changes are applied.
So i guess there is an timing issue when the sidecar for datasources and grafana are starting in parallel. Maybe the sidecar needs to be enforced to start first and only when this sidecar is running grafana will start?
Or can the sidecar trigger a restart of grafana when changes are found?
Thanks

Maybe it would be enough to not use a sidecar for datasources but use a configmapoverride like the prometheus chart has?

Necromancing this. The sidecar for datasources shouldn't be an init-container, it doesn't support the use case above, and is open to race conditions if the configmap doesn't exist. Ideally I guess it should be implemented as a permanent container / sidecar as the dashboards one is?


Fix licenses on scala and java files.

Some new scala files were added with the old license.

Thanks @rabbah ... I pulled down the PR code and ran the latest scancode util. against it and it passed all checks (as visual inspection also indicated it would).


Use the cache when downloading with wandb-core

Description

Fixes WB-NNNNN
Fixes #NNNN

What does the PR do? Include a concise description of the PR contents.

[ ] I updated CHANGELOG.md, or it's not applicable

Testing
How was this PR tested?

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#7351  👈
#7348 : 1 other dependent PR (#7349 )
#7342
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @moredatarequired and the rest of your teammates on  Graphite


Backend logic

Applied all backend logic: controllers, retry/requeue handlers, ...
Also added code styling / grumphp conventions.

Looks good! :)


Multiple definition of type_info

Since the update 2 days ago, I get multiple definition errors when linking. I'm using CLion and cmake 3.26 with C++ 23. pulling the repo like in the example.
C:\Program Files\JetBrains\CLion 2023.2.1\bin\mingw\bin/ld.exe: C:/Program Files/JetBrains/CLion 2023.2.1/bin/mingw/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0\libstdc++.a(tinfo.o):(.text$_ZNKSt9type_infoeqERKS_+0x0): multiple definition of `std::type_info::operator==(std::type_info const&) const'; _deps/safetyhook-build/libsafetyhook.a(vmt_hook.cpp.obj):C:/Program Files/JetBrains/CLion 2023.2.1/bin/mingw/lib/gcc/x86_64-w64-mingw32/13.1.0/include/c++/typeinfo:194: first defined here
After a bit of research, this seems to be an issue with static linking in C++ 23.
https://github.com/skeeto/w64devkit/issues/86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572

Maybe I'm not understanding the issue fully as I don't typically use mingw but is this a problem with GCC or something I need to fix in safetyhook because it's wrong? If it's a problem with GCC I don't mind working around the issue by making a change, but only if necessary.

I'll look at the code introduced with the new commit to try to narrow down the issue. Thanks

I moved to MSVC compiler, and the release works. The new workflow is better, I'm not looking back so I'm closing this for now. Maybe if someone else sees it, they can open it. Thanks, I love this library


build a referral mechanism

an account with a validated email (and phone number) should be illegible to share "invite user referrals". Users joining with a referral are then illegible to receive a reward (some PACT tokens) after signing a specific message.
See the design for more insights.
Relates to https://github.com/impactMarket/libera/issues/243

https://www.figma.com/file/D7Ugm0leO5iqP8cS1ipZX3/Libera-App?node-id=2041-19493&t=5aEjSMIM616Blaa2-0


Add gemini_http

@cyevgeniy I copied your changes into master because there were conflicts. I hope you are ok with it. Thanks for your contribution! 🌈


--debug option

It is difficult to debugging xpanes due to the complexity of the code is getting big.
--debug option to show the debug message is necessary.

This feature is released at v3.1.0


[Bug] tvmc failed on onnx with google.protobuf.message.DecodeError: unexpected end-group tag

Expected behavior
tvmc compile --target "llvm" --output compiled_module.tar resnet50-v2-7.onnx should works.
Actual behavior
It fails with the following error:
google.protobuf.message.DecodeError: unexpected end-group tag

See: https://openqa.opensuse.org/tests/2219126#step/tvm/15
Environment
openSUSE Tumbleweed with TVM 0.8.0
Steps to reproduce
Try to run tvmc compile --target "llvm" --output compiled_module.tar resnet50-v2-7.onnx  on openSUSE Tumbleweed.
protobuf 3.19.4 is used.

@ggardet Hi. I can't reproduce this issue either on tag v0.8.0 or HEAD. Could you please confirm which TVM code (packaging) or hash is used in your test, if possible?

tvm version 0.8.0
protobuf 3.19.4
expat version 2.4.6

@gromero Could you tell me which version of protobuf you are using, please?

@ggardet Sure, it's protobuf                       3.19.4
Some logs:
gromero@amd:~/git/tvm$ git log -p -1
commit 7b3a22e465dd6aca4729504a19beb4bc23312755 (HEAD, tag: v0.8.0.rc0, tag: v0.8.0, shukun/v0.8, origin/v0.8)
Author: Tianqi Chen<EMAIL_ADDRESS>Date:   Fri Nov 12 16:24:02 2021 -0500

    Update license file to note libbacktrace

diff --git a/LICENSE b/LICENSE
index 18718f986..345026985 100644
--- a/LICENSE
+++ b/LICENSE
@@ -242,4 +242,5 @@ The Unlicense
 BSD 3-Clause "New" or "Revised" License
 ---------------------------------------

-3rdparty/cutlass
\ No newline at end of file
+3rdparty/cutlass
+3rdparty/libbacktrace
gromero@amd:~/git/tvm$ cd ~/scripts
gromero@amd:~/scripts$ alias tvmc="python3 -m tvm.driver.tvmc"
gromero@amd:~/scripts$ pip3 list | fgrep proto
protobuf                       3.19.4
gromero@amd:~/scripts$ tvmc compile --target "llvm" --output compiled_module.tar resnet50-v2-7.onnx
[15:46:01] /home/gromero/git/tvm/src/target/target_kind.cc:164: Warning: Unable to detect CUDA version, default to "-mcpu=sm_20" instead
[15:46:01] /home/gromero/git/tvm/src/target/target_kind.cc:190: Warning: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[15:46:01] /home/gromero/git/tvm/src/target/target_kind.cc:204: Warning: Unable to detect ROCm version, assuming >= 3.5
[15:46:01] /home/gromero/git/tvm/src/target/target_kind.cc:164: Warning: Unable to detect CUDA version, default to "-mcpu=sm_20" instead
[15:46:01] /home/gromero/git/tvm/src/target/target_kind.cc:190: Warning: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[15:46:01] /home/gromero/git/tvm/src/target/target_kind.cc:204: Warning: Unable to detect ROCm version, assuming >= 3.5
[15:46:07] /home/gromero/git/tvm/src/target/target_kind.cc:164: Warning: Unable to detect CUDA version, default to "-mcpu=sm_20" instead
[15:46:07] /home/gromero/git/tvm/src/target/target_kind.cc:190: Warning: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[15:46:07] /home/gromero/git/tvm/src/target/target_kind.cc:204: Warning: Unable to detect ROCm version, assuming >= 3.5
One or more operators have not been tuned. Please tune your model for better performance. Use DEBUG logging level to see more details.
gromero@amd:~/scripts$ cat /etc/issue
Ubuntu 21.04 \n \l

gromero@amd:~/scripts$

However there other pieces that can be relevant here, like the config.cmake used to build TVM and the commit hash you're using. It was never clear to me here 1) what's the commit hash being built and tested, 2) what/how is the being built.

@ggardet Hi. I can't reproduce this issue either on tag v0.8.0 or HEAD. Could you please confirm which TVM code (packaging) or hash is used in your test, if possible?

This is with the source archive from https://github.com/apache/tvm/releases/tag/v0.8.0

Got it. OK. that's the one I tested too and was not able to reproduce in my environment. What's the config.cmake being used?  Is there a CI I can take a look to check the build artifact,  config.cmake etc? I confess I have never tried TVM on OpenSUSE.

@ggardet @DimStar77 Folks, sorry, I really can't reproduce the issue here reported, so I can't help further.
I've set a OpenSUSE env and I still get the same result on Ubuntu (no failure), also using protobuf 3.19.4.
Some logs in case that helps:
gromero@gromero4:~/git/tvm> git --no-pager log --oneline -1
7b3a22e46 (HEAD, tag: v0.8.0, origin/v0.8) Update license file to note libbacktrace
gromero@gromero4:~/git/tvm> cd ~/scripts
gromero@gromero4:~/scripts> wget https://media.githubusercontent.com/media/onnx/models/main/vision/classification/resnet/model/resnet50-v2-7.onnx
--2022-03-15 20:25:26--  https://media.githubusercontent.com/media/onnx/models/main/vision/classification/resnet/model/resnet50-v2-7.onnx
Resolving media.githubusercontent.com (media.githubusercontent.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to media.githubusercontent.com (media.githubusercontent.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 102442450 (98M) [application/octet-stream]
Saving to: ‘resnet50-v2-7.onnx’

resnet50-v2-7.onnx                              100%[=====================================================================================================>]  97.70M  11.1MB/s    in 8.8s

2022-03-15 20:25:38 (11.1 MB/s) - ‘resnet50-v2-7.onnx’ saved [102442450/102442450]

gromero@gromero4:~/scripts> tvmc compile --target "llvm" --output compiled_module.tar resnet50-v2-7.onnx
[20:26:28] /home/gromero/git/tvm/src/target/target_kind.cc:164: Warning: Unable to detect CUDA version, default to "-mcpu=sm_20" instead
[20:26:28] /home/gromero/git/tvm/src/target/target_kind.cc:190: Warning: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[20:26:28] /home/gromero/git/tvm/src/target/target_kind.cc:204: Warning: Unable to detect ROCm version, assuming >= 3.5
[20:26:28] /home/gromero/git/tvm/src/target/target_kind.cc:164: Warning: Unable to detect CUDA version, default to "-mcpu=sm_20" instead
[20:26:28] /home/gromero/git/tvm/src/target/target_kind.cc:190: Warning: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[20:26:28] /home/gromero/git/tvm/src/target/target_kind.cc:204: Warning: Unable to detect ROCm version, assuming >= 3.5
[20:26:31] /home/gromero/git/tvm/src/target/target_kind.cc:164: Warning: Unable to detect CUDA version, default to "-mcpu=sm_20" instead
[20:26:31] /home/gromero/git/tvm/src/target/target_kind.cc:190: Warning: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[20:26:31] /home/gromero/git/tvm/src/target/target_kind.cc:204: Warning: Unable to detect ROCm version, assuming >= 3.5
One or more operators have not been tuned. Please tune your model for better performance. Use DEBUG logging level to see more details.
gromero@gromero4:~/scripts> pip3 list | fgrep proto
protobuf                       3.19.4
gromero@gromero4:~/scripts> cat /etc/issue
Welcome to openSUSE Tumbleweed 20220313 - Kernel \r (\l).

enp1s0: \4{enp1s0} \6{enp1s0}

gromero@gromero4:~/scripts>


[Request/Bug] disable pull down to refresh

Describe the bug
My web pages will often refresh due to the pull down to refresh feature when I'm using web pages with scroll features (either the app does it when I'm trying to scroll, like a bug, or I just get to the top of the scroll and I refresh).
If we could get an option to disable it (because I find it more annoying than useful) that would be swell.
How to Reproduce

Use a web page with a long scroll area
Go to bottom of scroll page, then scroll quickly up by swiping several times
Sometimes, the webpage will refresh before it hits the top of the scroll area

Expected behavior
I want it to stop refreshing pages on pull altogether, but fixing the refresh big would be fine I suppose.
Environment
- DDG App Version: 5.209.2
- Device: Pixel 5a
- OS: Android

Thanks for the report, would you be able to share a website where this can be reproduced?

Hello everyone :)
I am Rohit, an Android Developer and I am willing to contribute to this project. However, most of the issues are labeled as needs triage none of them are labeled as help wanted. Could you please tell me @marcosholgado, if I am allowed to work on any of the issues?

Same. It's a nightmare to have this feature. There should be an option to disable pull to refresh just like in Firefox. Any site, let's say Duck.ai for example, you do a lot of chatting and scroll up to see something in the top and accidentally scroll a little more, now the page will start refreshing and you will loose everything till now.
This is the case with any site where you input something. Everytime it's giving a mental stress not to scroll a little more after reaching the top and if mistake happens, you will loose all the data you input in the page.
A feature good only for pages where user input nothing but the page content changes frequently, like stock price. Not needed for the rest of the sites. It will be good to have a turn off switch in the app.

Same here. This behaviour is super annoying!
Already lost several texts I wrote, because I accidentally pulled down and all form data of a website was lost.
DuckDuckGo browser has just too little setting options to really be of any value.


Please provide the dense landmarks as mentioned in the paper 679 points rather than just 70 points

Sorry for ckecking it late.
Unfortunately, we don't have plan for dense landmark prediction.
I think you may utilize our code for that with following the instruction about mentioned papers and dataset
I hope it makes you help in some way.
Thank you for your comment


Fix input component interface

Codecov Report

Merging #1065 into master will decrease coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1065      +/-   ##
==========================================
- Coverage   99.81%   99.77%   -0.04%
==========================================
  Files         323      323
  Lines        7990     7994       +4
  Branches     1918     1917       -1
==========================================
+ Hits         7975     7976       +1
- Misses         15       18       +3

Impacted Files
Coverage Δ

src/components/input/Input.tsx
95.83% <100%> (-4.17%)
:arrow_down:

src/components/radio/Radio.tsx
100% <100%> (ø)
:arrow_up:

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 8248ec0...0e62d24. Read the comment docs.

Thanks for this. When will you release a new version containing the changes?


Revive metatrain pet

Contributor (creator of pull-request) checklist

[x] Tests updated (for new features and bugfixes)?
[x] Documentation updated (for new features)?
[ ] Issue referenced (for PRs that solve an issue)?

📚 Documentation preview 📚: https://metatrain--344.org.readthedocs.build/en/344/

How does the new checkpoint_path work? Does that fix the optimizer and scheduler issues on restarting? And how? I see that it's now an argument of PET


How can I call rpc method with named parameters?

For example:
{"jsonrpc":"2.0", "method": "subtract", "params":{"subtrahend": 23, "minuend": 42}, "id": 3}
I don't find such examples in TestClient. Thanks!

You look like you've got it already, that came right out of the examples in the spec. http://www.jsonrpc.org/specification#examples
Anything there should work for you. Are you getting an error?
You can check out the wiki or look on this page: https://github.com/Astn/JSON-RPC.NET/blob/master/AustinHarris.JsonRpcTestN/Test.cs
for "ObjectSyntax"
You will see things like:
[Test()]
       public void TestOptionalParamDouble_2ndPresentObjectSyntax()
       {
           string request = @"{method:'TestOptionalParamdouble_2x',params:{input1:123, input2: 671},id:1}";
           string expectedResult = "{\"jsonrpc\":\"2.0\",\"result\":671.0,\"id\":1}";
           var result = JsonRpcProcessor.Process(request);
           result.Wait();
           Assert.IsFalse(result.Result.Contains("error"));
           Assert.AreEqual(expectedResult, result.Result);
       }

Nice to see your response. I'm developing a c# winform application, which will call a remote json rpc method with named parameters. I saw examples in TestClient, and I found that I could not define the parameter name in the class JsonRequest, which is defined as
public class JsonRequest
{
public JsonRequest();
    [JsonProperty("id")]
    public object Id { get; set; }
    [JsonProperty("method")]
    public string Method { get; set; }
    [JsonProperty("params")]
    public object Params { get; set; }
}

I'm not familiar with JSON-RPC. Look forward to the answer. Thanks.

You should be able to set Params to be a POCO you have created and attributed with JsonProperty attributes. When you have Json.net serialize the JsonRequest it should do the right thigh then.
I'm going to close this issue as its more of a question.  Not really a feature request, or a bug. I suggest Stack overflow if you have more questions


feat: re-port Analysis.Calculus.Darboux

Forward-port leanprover-community/mathlib#19125 by re-porting the file.

bors merge


Break out 'ftw-tools' repo for the CLI?

The purpose of this repo has been expanding - it started as clearly focused on the baseline models, helping people experiment / test. But then we added tools to make it easier to get the data, and then to run the inference, and now starting to be able to turn the inference to polygons & fiboa.
In the last FTW meeting I proposed that we move the Experimentation section to its own document so that the main 'flow' for a non-ML person would be easier to follow along with. But I'm now leaning towards an alternate route - make an ftw-tools repo, where we put the command-line interface to get the data and run inference, and let this repo really be about the 'baseline' models, and make the experiment stuff more prominent.
This seems to lead to some advantages:

Releases are clearer - this repo continues to be the place where new models are released (and then we make them available on hugging face), and ftw-tools is where we do releases for the command-line tool, and make those available on pip.
Readme's are clearer. The ftw-tools readme would focus on the CLI tool and what it enables, likely starting with running inference into fiboa, and then showing how to download the data. And the ftw-baselines talks about experimentation (though it'd include the step to get the data, though it'd just say install ftw-tools and use that to get the data).
More room to expand - ftw-tools can more easily grow into tools to help manage / create FTW datasets. Like to generate splits, or to clean up data - any tool that's helpful for the overall ftw project could fit in.

My proposal would be to move all the code that's in ftw data download, ftw data unpack, ftw inference download, ftw inference run and ftw inference polygonize to ftw-tools (this is assuming an organization like is in #25 PR). I think we'd want to keep ftw model test and ftw model fit in the ftw-baselines repo, and I believe it's possible to have two separate installations share a single click namespace, but should check to be sure (worst case can make like ftw-model fit - just a different cli). Alternatively we could make 'tools' have the full CLI, but it seems like that code has more dependencies and is most focused on baselines.
My only question with this split is if it's important to have inference available in the ftw-baseline repo? Like is it weird to have that in 'tools'? From my 'user' perspective all I'd use that for is to run the model, but not sure if there's reasons to have it in the same repo as the baseline stuff. I do think we'd keep it so the model output from any experiment in baseline would be easy to run inference with, but I currently lean towards having the inference (along with the polygonize) in a ftw-tools repo.

So you want it similar to fiboa CLI - "all in one"? Or more like stactools where additional packages can be installed?

I was thinking sorta in between? Like ftw-tools does data download and inference running (the main operations a normal 'user' of FTW models wants), but you could install an additional package for ftw model fit and ftw model test, that are more used in ftw-baselines. But I think my assumption there is that the 'model' ones need a lot more dependencies and have more code, which may not actually be true (especially since running inference I think likely uses much of the same stuff). So might be simpler to have ftw-tools be all the CLI stuff, but to have it just depend on python modules in ftw-baselines. I don't feel that strongly on it, and lean towards at least 'most in one' for now - I don't see a big ecosystem of different tools being built where it makes sense to do a stactools type thing.

I'm not opposed to this, but some devil's advocate pushback:

If we split then there will likely be code duplication between the two (I'm not sure at first glance how big this would be though -- model definitions?). This might make things harder to maintain.
If there is some maintenance work that gets done, it'd be great if all parts could benefit at once (e.g. tests, CI)
We could also simplify README without splitting into two repos, e.g.:

# Fields of The World
high-level description

Overview:
- [Training new models or reproducing our paper results](training.md)
- [Running our pre-trained models on new Sentinel-2 imagery(inference.md)
- [Information about the dataset itself](dataset.md)

Current Table of Contents should likely be revisited anyway.

I think it can all stay in one codebase similar to fiboa CLI, but in a separate repository. It doesn't seem this has the complexity or number of contributors that stactools has, so multiple packages seems overkill at this point.
Publishing to pip is certainly a good idea.

I think the main issue here is that there's no real versioning and release process for this repository (see #32). That makes it unclear how to improve and release software correctly.
I think all code that is needed to keep this repository working and actually where a close connection between the code version and the model version exists should stay in this repository and should be versioned together. If that's modular and the CLI doesn't contain any actual "business logic", we can just release two pip packages (baseline + tools) and then use the code from baseline in tools. I don't think we would really run into code duplication issues then.
Happy to try this out, but first we probably need to work on #32.


Error: has incompatible types: sql.NullString, interface{}

I have a MySQL query with multiple named parameters. everything is fine but for bellow chunk:
AND (
    sqlc.narg(phone_filter) IS NULL
    OR (
        (
            length (sqlc.narg(phone_filter)) != 11
            OR aes_decrypt (from_base64 (u.phone), sqlc.arg(aes_key)) = sqlc.narg(phone_filter)
        )
        AND (
            length (sqlc.narg(phone_filter)) = 11
            OR aes_decrypt (from_base64 (u.phone), sqlc.arg(aes_key)) LIKE '%' || sqlc.narg(phone_filter) || '%'
        )
    )
)

and for the last line OR aes_decrypt (from_base64 (u.phone), sqlc.arg(aes_key)) LIKE '%' || sqlc.narg(phone_filter) || '%'
I get this error:
# package demorepo error generating code: named param PhoneFilter has incompatible types: sql.NullString, interface{}
any idea how to fix this? thanks

Something that I've found is that sqlc assumes the parameter here at LIKE '%' || sqlc.narg(phone_filter) || '%' to be interface{} and apparently it conflicts with sql.NullString which is assumed in above lines.
So, I was able to pass the error by using a second param like sqlc.narg(phone_filter2) but now my question is why this syntax sqlc.narg(phone_filter2)::varchar/char/text/or whatever does not work as the document mentioned. and in general how can I use casting in MySQL.

solved by not using sqlc.narg or sqlc.arg in LIKE statement.


State constructor should receive arbitrary keywords.

State(foo=1, bar=2, baz=3)

In the example above State will be populated with everything passed to the call.
Test: Arguments are available in story steps.

Superseded by #722


Add Connect support to test-container

Thanks for the reviews. I pushed an update that:

removes StrimziConnectContainer. I kept getWorkers() but it now returns a collection of GenericContainer
adds a new method to StrimziKafkaCluster to get bootstrap servers that can be used from other containers

@katheris Do you have something more on this? Or can we start slowly closing the vote on this proposal? Thanks.


aeronmd: Change aeron_uri_parse to accept len.

When the URI is received in a command over UDP it does not have a trailing null.
The size of the URI is known in the command buffer and does not need to be null terminated.
In some cases aeron_uri_parse is called without a null terminated string so it fails to parse the address, even though the URI is correctly received.

Needs some more work for the other unit tests. I'm onto this now.

Thanks @mianos. I noticed a similar issue just recently and missed fixing this case too. I can pick this up.

I seem to have broken the UDP channel parser but in debugging it I hit this line:
https://github.com/real-logic/aeron/blob/master/aeron-driver/src/test/c/aeron_udp_channel_test.cpp#L85
and I can't figure out why it subtracts one from the string. If you are not going to use this pull request and do it in your own manner go right ahead and I'll use my fixed version with the broken tests until you get yours in master.

I've pushed a fix https://github.com/real-logic/aeron/commit/40fb737fff97a37487a1a5cacedaedf040f3647c
I've no idea why the -1 was there either. Maybe @tmontgomery knows?

The uri_length using strlen - 1 is probably an error. It seems to only be used for doing the copy of the URI for storage as the original URI.

Does this fix pass all the tests now?

@mjpt777 has pushed a fix instead.


TEst Issue

Testing an issue

test to reopen

test

test

run a test

testing to see if this closes and reopens

test to close and stay closed

test to close

test again

test close

closing again to test

test again

test again

test again

test to close

test

test

test comment

test

test

test

test

test

close

test

test again

test

test

test

test again

test

test

test comment AFTER 20 seconds

close this again

close

test

test

test

ok please move this ticket

test

test

test

test

test

test

test

test to stay closed

test


Add Zenko

Source name
Zenko Manga
Source link
https://zenko.online/
Source language
Ukrainian
Other details
18+/NSFW = yes
All the titles could be easily retrieved here:
https://zenko-api.onrender.com/titles?limit=9&offset=18&sortBy=createdAt&order=DESC&ageLimit=18&releaseYearFrom=1980&releaseYearTo=2024
To search just add 'name' parameter as so:
https://zenko-api.onrender.com/titles?limit=12&offset=0&name=it%20was
The response is in JSON.
You should keep ageLimit=18 to enable NSFW.
Limit and offset should work as you would expect from it. You can play around with these filters here:
https://zenko.online/catalog
Each title has it's 'id' (just an integer) which is retrieved from the requests above, to get detailed info about title you can call here: https://zenko-api.onrender.com/titles/997, where 997 is the id of the title.
To get chapter id's you can call here:
https://zenko-api.onrender.com/titles/997/chapters
From the request above you should get array with id's (also just an integer) for the chapter itself and put it here:
https://zenko-api.onrender.com/chapters/16496, where 16496 is the id of the chapter.
It would contain a field 'pages' as an array of objects containing an 'imgUrl' string, which you could get by calling here:
https://zenko.b-cdn.net/7a12b7ad-317d-48e2-8d17-04ef666982ef?optimizer=image&quality=100
where '7a12b7ad-317d-48e2-8d17-04ef666982ef' is that imgUrl string. As I have seen, all the images work in this way.
I've tried to explain as much as I can, but if anything is unclear, I'd be happy to help.
Acknowledgements

[X] I have checked that the extension does not already exist by searching the extension listing and verified it does not appear there.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[X] I will fill out all of the requested information in this form.

Very much needed...

@Lorg0n Don't comment bump, unnecessary email to the author of the issue & pings the server.
There's 400+ issues in the repo with less than a handful of contributors volunteering their own time for these fixes/new extensions. No guarantees for anything, either wait patiently, contribute the extension yourself, or find something else to use.


is it possible to use the imageSlideShow in tableView or collectionView Cell?

i know that i can use it in these cells, but do we have any memory issues or something like that?

Hi, it should work, but I haven't really worked with this case yet. Be sure to enable image caching in the image loading library you use (eg. SDWebImage) since reusing of cells can result in repeated URL requests for same images.

How to solve this problem?


SQL database corruption triggered by Docker container restart

I am considering using the method of replacing only the configuration of the Docker Image published on DockerHub.
docker create -p 9324:9324 -p 9325:9325 -v `pwd`/custom.conf:/opt/elasticmq.conf -v `pwd`/data:/data --name elasticmq softwaremill/elasticmq-native:1.3.9
docker start elasticmq

elasticmq-h2.mv.db was created under pwd/data, and ElasticMQ was successfully started.
restart the container:
docker stop elasticmq
docker start elasticmq

Then an error will appear in the docker logs:
2022-09-18 08:13:13 database: opening /data/elasticmq-h2
org.h2.message.DbException: File corrupted while reading record: "/data/elasticmq-h2.mv.db". Possible solution: use the recovery tool [90030-214]

Is there a correct procedure to "gently" stop a Docker container or what settings are required?

The content of custom.conf is simply this:
include classpath("application.conf")

queues-storage {
  enabled = true
  path = "/data/queues.conf"
}

messages-storage {
  enabled = true
}

Confirmed that the problem has been resolved.


⚠ Jenkins Plugins Artifactory has degraded performance

In 3602e97, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1207 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 03489aa after 12 minutes.


fix: Dialog: Height calculation could be slightly off because of rounding

An issue was reported in #web-platform about a scrollbar appearing for the confirm dialog at large font sizes.  Using getBoundingClientRect().height instead of scrollHeight allow for us to get the demo value.
~I'm going to run this through visual diff before opening it for reviews in order to check if this breaks anything.~ Tests passed

So much for "The scrollHeight value is equal to the minimum height the element would require in order to fit all the content in the viewport without using a vertical scrollbar.".
According to Mozilla, getBoundingClientRect apparently returns a fractional value.  Using ceiling still might be a good idea.


Meta, Title packages from '@angular/platform-browser', not showing title and description in view-source

import { Injectable } from '@angular/core';
import { Meta } from '@angular/platform-browser';
import { Title } from '@angular/platform-browser';
@Injectable()
export class SeoService {
private titleService: Title;
private metaDescriprtion: Meta

constructor(
    private _meta: Meta,
    private _titleService: Title
) {}

public setTitle(newTitle: string) {
    this._titleService.setTitle(newTitle);
}

public setMetaDescription(description: string) {
    this._meta.addTag({name: "description", content: description})
}

}
Above code does't show title and description in view-source.

This does not appear to be Angular CLI related.  A better forum for support concerns would be a site such as StackOverflow.  If the observed behavior is determined to be a defect then opening an issue at core Angular Repository would be the appropriate location.


refactor: remove unused attribute IDs generation

A step closer to removing slug generation service. Now all references to it have been removed.

#411  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


Simple switch to Yarn and an upgrade to alpine

Hey, I'm liking your image, but prefer to use Yarn for speed and consistency.
Also took the opportunity to update the Alpine version.
Thanks!

Thanks for your contribution @edkellena! I apologize for not replying sooner. I have not used yarn yet, so I'll play with it a little first. Otherwise it looks good 👍


feat(client): inline docs

Originally https://github.com/prisma/prisma/pull/9683

Merging with my approval only since @aqrln is sick today

Is there a reason this implements comments with three / instead of the usual two?
Was really confusing when my comments worked but wouldn't show up in the generated types.


Add image requirements metadata

Adding additional image metadata that indicates the requirements the image has, so that LXD can inspect it and check the system and settings for compatibility.
This would be useful for (at least) the following two scenarios:

VM images that require secure boot be disabled.
Container images that use systemd and require the host to have a supported cgroup configuration.

If LXD could access the requirements of the image it could then detect if there are issues that would prevent the instance from working and flag it to the end user.
Otherwise in both scenarios above it is very difficult for the end user to diagnose the fault.

Hi, @hQavi and I are students from University of Texas taking a virtualization class. One of our assignments is to contribute to an open source project and we thought lxd was pretty exciting! Would it be ok if we tried to tackle this issue?

Sure! I've assigned it to you for now. I need to have @hQavi comment in here so I can assign them too.

Done!

Hi, unfortunately we weren't able to tackle to this issue this semester. So it'll be best to let someone else take the issue.
We also wanted to thank the maintainers for letting us contribute to the lxd! It's been a pleasure working on lxd and we might be back in the future. In the meantime, we wish y'all the best!

Thanks, I've cleared the assignee field.

@stgraber could I take a stab at this? I think I have a good diving point into the simplestreams client, probably will have questions as I go along

Sounds good, assigned it to you

Had a few hours to chew on things, definitely want to make sure I am on the right track here.
For the simplestreams client, under ./shared/simplestreams/products.Product (at least I believe I think this is where the additional simplestreams keys would go) I was thinking of using a field with the type map[string]interface{} because each requirement/key could possible require more information aside from what a scalar value could provide. Perhaps this isn't necessary and something more simple could be used instead of an empty interface (e.g. string)? You did mention I can add additional simplestreams keys but if they serve a related purpose, wouldn't it be better to have them under a single map?
To clarify, the purpose of this ticket/issue is to add additional metadata to an image dictating host requirements required before trying to create a container...but would this include adding functionality to LXD for following host requirements mentioned by @tomponline above (e.g. VM images that require secure boot be disabled.)?

I believe I have a rough implementation drafted out. Do we want LXD to still be able to init a instance (e.g. create but not start the instance) even if host has a missing requirement based on the new image metadata (e.g. there exist an invalid cgroup configuration on the host)?

For the simplestreams client, under ./shared/simplestreams/products.Product (at least I believe I think this is where the additional simplestreams keys would go) I was thinking of using a field with the type map[string]interface{} because each requirement/key could possible require more information aside from what a scalar value could provide. Perhaps this isn't necessary and something more simple could be used instead of an empty interface (e.g. string)? You did mention I can add additional simplestreams keys but if they serve a related purpose, wouldn't it be better to have them under a single map?

I think adding a lxd_requirements as map[string]string] should be sufficient here. It should allow for enough flexibility without having to either use a heavy approach with a dedicated struct or the like or one that's hard to parse like using interfaces.

To clarify, the purpose of this ticket/issue is to add additional metadata to an image dictating host requirements required before trying to create a container...but would this include adding functionality to LXD for following host requirements mentioned by @tomponline above (e.g. VM images that require secure boot be disabled.)?

I'd rather not, having an image server or image be able to cause LXD to change instance configuration, while it sounds great can also very quickly turn into a security issue. I think for now, we're effectively looking at adding this data to simplestreams and our parser, then have LXD pick that up and add some instance startup checks to refuse start with a clear error if something is needed.

As for current implementation, the two things I suspect we'll do are:

Label a bunch of container images with map[string]string{"cgroup": "v1"} to indicate that they require cgroupv1 and will not work on a system that has a full cgroupv2.
Label some VM images with map[string]string{"secureboot": "false"} to indicate that the image cannot boot with secureboot enabled.

I'd expect our simplestreams parser to read that lxd_requirements map and then when generating the LXD image data, to turn that into properties, basically giving us additional image properties like:

requirements.cgroup=v1
requirements.secureboot=false

This will then automatically get propagated by LXD from the image to the instance when we copy the image properties.
The instance will therefore end up with those keys in its config:

image.restrictions.cgroup=v1
image.restrictions.secureboot=false

And we can then easily have our Start() function process the requirements and fail startup with a clear error should a requirement not be matched.

We'll need to update doc/image-handling.md to specify the list of restrictions that are supported on images and what they mean, but other than that changes required for this should be pretty minimal overall.

@stgraber @monstermunchkin shall we re-open this issue, or create a new issue(s) in order to track adding the new metadata to the appropriate images?

I've got a card tracking adding the metadata to the publishing scripts.


Can't start runelite

Please check if your issue is not a duplicate by searching existing issues
Describe the bug
Cant start runelite
To Reproduce
Steps to reproduce the behavior:
1.Click
2. doesnt work
Environment (please complete the following information):
Windows 10
Additional context
Add any other context about the problem here, e.g. logs. Your client logs can usually be found in
C:\Users\<your_user_name>\.runelite\logs on Windows and ~/.runelite/logs on Linux and macOS.
2019-03-02 14:10:03 [main] INFO  net.runelite.launcher.Launcher - Setting hardware acceleration to DIRECTDRAW
2019-03-02 14:10:03 [main] ERROR net.runelite.launcher.Launcher - error fetching bootstrap
java.io.IOException: Server returned HTTP response code: 403 for URL: http://static.runelite.net/bootstrap.json
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1894)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at net.runelite.launcher.Launcher.getBootstrap(Launcher.java:264)
at net.runelite.launcher.Launcher.main(Launcher.java:168)

Cloudflare issue, use VPN to start runelite

Could you please let me know how to properly fix it?

Cloudflare issue, use VPN to start runelite

Could you please let me know how to properly fix it?

I dont have a VPN, it worked fine earlier today.

Cloudflare issue, use VPN to start runelite


Add Paychex to Finance section

Add Paychex to Finance section

They don't appear to have any documentation written after they implemented multi-factor authentication, but I have an account there and have set it up on my account and confirmed it available.  What is the appropriate action to show documentation?

Well if you could send a screenshot (with your own private data blurred out) of the TFA login step that would be great.
Then you could just remove the doc link.
And the best thing would be if you contacted Paychex and asked them for a documentation link before removing the doc value.

Thank you.  I have reached out to them and also taken a screenshot.  How would you want the screenshot included?  Thank you for helping me get started with contributing

Here is the screenshot of implementing tfa

There's no need to add website. Just wanted to confirm that your interpretation of those categories is long the lines with our other entries. :)
Hopefully they'll reply to you soon and we'll merge this.

Thanks again.

Okay just remove the doc link and we're good to go.


SAK-44879 Prevent switching rubric if evaluations exist

https://jira.sakaiproject.org/browse/SAK-44879

Just a sidenote this is specific commit for 20.x since the back port of SAK-44879 doesn't work as expected on 20.x.


Gradle Error version.

Sometimes I got this error. Sounds like a parsing error or something like that. The only way I solve it is by restarting my mac. I have tried gradlew clean / rm -rf ~/.gradle/caches but no success.
Have it happened with you guys ?
react-native-config/android/dotenv.gradle' line: 84
> dotenv_eykg5ibwbixjb4p8dhqat3p4q$_run_closure2$_closure8$_closure9$_closure10

I am also facing the same issue. I also had to restart the system to resolve it.
Is there a proper solution to this?

Same issue here. Thanks for reporting, would never have guessed that a reboot would work. Any contributor care to chip in for a better solution?

No idea what's going on, but killing the Gradle daemon also makes the issue disappear (which is notably faster than restarting).
ps aux | grep GradleDaemon
kill <PID>

I had a similar issue where react-native-config was always reading the debug config when running a release build with: react-native run-android --variant=release.
The fix was to stop the gradle daemon with: cd android && ./gradlew --stop

This happened to me. Cleaning didn't work and I ended up finding this issue somehow, despite not working on react-native-config but on another lib. It took me a long time.


Session lost login not shown and user lose data

When I'm working in Sulu and lost the Session, Sulu don't tell me I must login again.
Currently ajax request are then redirect to login page.
We should check if the request is Ajax then don't redirect just send an 403 Forbidden with a specific Code.
When the frontend get this specific 403 with this code, it should show an overlay to login over ajax. This overlay will be closed and then he can continue edit the content and can successfully save the content.
So the user can't lose data because of a lost session.

https://github.com/sulu-io/sulu/issues/1536 is basically the same issue, but in the correct repository, so I am going to close this one as duplicate.

Yay. got it in the right repository. #bigwin :)

#protip: it's almost always sulu-io/sulu ;)


Allow blacklisting of space-age planet specific buildings in settings

With the release of space age and multiple buildings being able to craft the same recipes with different productivity. It has become important to be able to select which building a recipe is crafted in.
This also applies if you haven't been to a specific planet yet and don't have it's buildings.
Such as the cryogenic plant vs chemical plant.
I think a good first pass at this would be to make the buildings section in settings a toggle of "whitelist/blacklist" instead of a "prefer this building" selection.
If I had not been to Aquilo, yet, I would unselect the cyrogenic plant.
If I had not been to Gleba, I would unselect the biochamber
alternately, for each recipe group, the preferred building could be selected.
this works less well than just a blacklist toggle because the chemical plant is superseded by both the bio-chamber and cryogenic plant,
the assembler has some recipies taken by the electromagnetic plant and refinery,
The refinery can replace the furnace with a different recipie path.
The toggle building whitelist/blacklist seems the cleanest implementation to me.

I too would want a way to blacklist buildings to use, or maybe have the planet selectors enable/disable the planets buildings as well.

This would help out so much. The calculator keeps trying to use Cryogenic Plants instead of Chemical Plants, even though I have the Vulcanus planet selected. I don't have access to Cryogenic Plants since Vulcanus is the only planet I've unlocked..

Another reason for this feature request is that the Biochamber requires additional imports (Nutrients) and you may not want to import spoilable products for a small operation.
Oil cracking in the calculator is especially bad for this. For example, let's say you want to produce some plastic on Vulcanus. Ideally, you'd use the Cryogenic plant for the plastic production, but in order to do this you also need Petroleum gas via the oil cracking recipes. By default the calculator uses the Cryogenic plant for the plastic production and the Biochamber for the oil cracking, but if you force it to use the chemical plant you also lose the productivity on the plastic production which in turn greatly increases the number of oil refineries you need, far more than you'd need by just changing the oil cracking to chemical plants. (28 vs 39 oil refineries for 60 plastic per second with full productivity modules)


CREATE SEQUENCE for MSSQL database fails

One of my scripts has a CREATE SEQUENCE sql command and atlas seems to have a problem with it.  It's for a specific schema but so are the tables in script and they have no problem being created (so long as I comment out the sequence statement).
atlas cli v0.19.0
sqldb: docker linux container: mcr.microsoft.com/mssql/server:2019-CU15-ubuntu-20.04
You can replicate with this script using mode=database:
-- atlas:delimiter GO
CREATE SCHEMA [MySchema];
GO
CREATE SEQUENCE [MySchema].[MySequence] AS int START WITH 1 INCREMENT BY 1 NO MINVALUE NO MAXVALUE NO CYCLE;
GO

and the error you should see is:
Error: Drop schema named "MySchema": mssql: Cannot drop schema 'MySchema' because it is being referenced by object 'MySequence'.

Hello, the support for sequence will come soom in late next week. I'll update you when it out.

Thanks @giautm .  Living on the edge :-)