runtime/pprof: TestCPUProfileMultithreadMagnitude flaky due to Linux kernel bug

2021-10-19T07:45:46-ee92daa/linux-386-longtest
2021-10-18T21:21:54-6c0daa7/linux-386-longtest
2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
2021-10-15T20:29:48-85cbdda/linux-riscv64-jsing
2021-10-12T20:20:41-d032b2b/linux-amd64-wsl
2021-10-11T12:53:11-34f7b1f/linux-riscv64-unmatched
2021-10-08T17:32:31-d7ba1d2/linux-riscv64-unmatched
2021-10-08T14:08:12-5b9206f/linux-riscv64-unmatched
2021-10-06T16:11:20-aecf4b1/linux-riscv64-unmatched
2021-10-05T16:06:49-060cd73/linux-riscv64-unmatched
2021-10-02T13:52:59-07a7c6f/linux-riscv64-unmatched
2021-10-01T17:27:29-3357624/linux-riscv64-unmatched
2021-10-01T17:27:24-952df98/linux-riscv64-jsing
2021-10-01T04:30:22-822f349/linux-amd64-wsl
2021-09-30T16:43:32-9112d29/linux-riscv64-unmatched
2021-09-27T18:58:36-5b90958/linux-amd64-longtest
2021-09-27T18:58:36-5b90958/linux-amd64-wsl
2021-09-27T18:58:29-8cfd8c3/linux-amd64-longtest
2021-09-27T18:58:29-8cfd8c3/linux-amd64-wsl
Note that many of these include other profiling test failures which may indicate an issue with profiling beyond a fragile test.
cc @rhysh

Thank you for the links. Here's what I've found so far in the 386 and amd64 (not WSL, not RISC-V) logs.
The failing test results for TestCPUProfileMultithreadMagnitude on those platforms all look like "got full profiling info, but only from a subset of threads", followed by some number of tests that get a very small number of profile samples—often 0, sometimes 1, sometimes dozens—when the tests expect several hundred. The samples that do appear come from the runtime, in the scheduler or scavenger, in functions that might run on otherwise-idle threads.

386

2021-10-19T07:45:46-ee92daa/linux-386-longtest
HOSTNAME=buildlet-linux-stretch-morecpu-rn873c60c, which per https://farmer.golang.org/builders is "Debian Stretch, but on e2-highcpu-16", which per https://cloud.google.com/compute/docs/general-purpose-machines#e2-high-cpu is 16 vCPUs and 16 GB memory.
    pprof_test.go:541: runtime/pprof.cpuHog1: 498
    pprof_test.go:541: runtime/pprof.cpuHog3: 3471
    --- FAIL: TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof (0.00s)
        pprof_test.go:179: compare 1m19.558967s vs 34.71s
        pprof_test.go:191: CPU usage reports are too different (limit -10.0%, got -56.4%)

The single-goroutine portion of TestCPUProfileMultithreadMagnitude saw 4.98 seconds of samples (in a 5-second test). The parallel portion (using GOMAXPROCS goroutines) also ran for 5 seconds, during which the OS reported 79.56 seconds of user+system time in rusage but the runtime only saw 34.71 seconds worth of samples. That looks like "the cliff at 2.5 that we got with setitimer is now present at 7 vCPU, sometimes".
The failure in that test run of TestCPUProfileMultithreadMagnitude is followed by failures in TestCPUProfileInlining, TestCPUProfileRecursion, TestMathBigDivide, TestMorestack, TestCPUProfileLabel, and TestTimeVDSO. All of those have "total 0 CPU profile samples collected" except for TestCPUProfileInlining which got a single sample (below the minimum of 125 and target of 500).

2021-10-18T21:21:54-6c0daa7/linux-386-longtest
HOSTNAME=buildlet-linux-stretch-morecpu-rnce27d47, so GOMAXPROCS=16 again.
    pprof_test.go:541: runtime/pprof.cpuHog1: 499
    pprof_test.go:541: runtime/pprof.cpuHog3: 2994
    --- FAIL: TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof (0.00s)
        pprof_test.go:179: compare 1m19.983449s vs 29.94s
        pprof_test.go:191: CPU usage reports are too different (limit -10.0%, got -62.6%)

The single-goroutine portion saw 4.99 seconds of samples, and the parallel portion saw 29.94 seconds of samples. This looks like "the cliff at 2.5 that we got with setitimer is now present at 6 vCPU, sometimes".
The failure in that test run of TestCPUProfileMultithreadMagnitude is followed by failures in TestCPUProfileRecursion, TestMathBigDivide, TestMorestack, TestCPUProfileLabel, and TestTimeVDSO. Again all of those failures were with "total 0 CPU profile samples collected" except for TestCPUProfileRecursion and TestMorestack which got a single sample each (vs min of 125 and target of 500).

amd64

2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
No environment header at the top of this log.
    pprof_test.go:541: runtime/pprof.cpuHog1: 500
    pprof_test.go:541: runtime/pprof.cpuHog3: 4987
    --- FAIL: TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof (0.00s)
        pprof_test.go:179: compare 1m19.876446s vs 49.87s
        pprof_test.go:191: CPU usage reports are too different (limit -10.0%, got -37.6%)

The single-goroutine portion saw 5.00 seconds of samples, and the parallel portion saw 49.87 seconds of samples. This looks like "the cliff at 2.5 that we got with setitimer is now present at 10 vCPU, sometimes".
Followed by failure of TestMorestack (10 samples, 0 where expected), TestCPUProfileLabel (22 samples, 0 where expected), and TestTimeVDSO (9 samples, 0 where expected).

2021-09-27T18:58:36-5b90958/linux-amd64-longtest
HOSTNAME=buildlet-linux-stretch-morecpu-rn83cdb7c, so GOMAXPROCS=16.
    pprof_test.go:541: runtime/pprof.cpuHog1: 502
    pprof_test.go:541: runtime/pprof.cpuHog3: 5050
    --- FAIL: TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof (0.00s)
        pprof_test.go:179: compare 1m19.992473s vs 50.5s
        pprof_test.go:191: CPU usage reports are too different (limit -10.0%, got -36.9%)

The single-goroutine portion saw 5.02 seconds of samples (ran a little long!), and the parallel portion saw 50.50 seconds of samples (also ran a little long, but on fewer than GOMAXPROCS threads?). This could look like "the cliff at 2.5 that we got with setitimer is now present at 10 vCPU, sometimes" ... at least, 50.50 seconds is only slightly above 10 x 5.00 seconds.
There were no other failures in this run.

2021-09-27T18:58:29-8cfd8c3/linux-amd64-longtest
HOSTNAME=buildlet-linux-stretch-morecpu-rn6ff4f0f, so GOMAXPROCS=16.
    pprof_test.go:541: runtime/pprof.cpuHog1: 500
    pprof_test.go:541: runtime/pprof.cpuHog3: 5083
    --- FAIL: TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof (0.00s)
        pprof_test.go:179: compare 1m19.99259s vs 50.83s
        pprof_test.go:191: CPU usage reports are too different (limit -10.0%, got -36.5%)

The single-goroutine portion saw 5.00 seconds of samples, and the parallel portion saw 50.83 seconds of samples (ran a little long, but on fewer than GOMAXPROCS threads?). This could look like "the cliff at 2.5 that we got with setitimer is now present at 10 vCPU, sometimes" ... at least, 50.83 seconds is only slightly above 10 x 5.00 seconds.
There were no other failures in this run.

These failures look like three problems:

The failures on linux/amd64 for 8cfd8c3 and 5b90958 (both on 2021-09-27) are because I put the test too early in the CL chain. We discussed at https://github.com/golang/go/issues/35057#issuecomment-928212995. The first WSL failures are on those two commits as well.
Failures in TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof. These appear on linux-riscv64, linux-amd64-wsl, and linux-ppc64. The first of these was 2021-09-30T16:43:32-9112d29, and they've occured regularly since.
Failures in TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof, coupled with failures in other CPU-profiling-related test cases. These appear on linux-amd64-longtest and linux-386-longtest. The first of these was 2021-10-18T19:46:27-394a1ad`

Problem 1 is a couple bad commits while the CL stack was landing. I'll filter those out of the results.
$ grep -r -l 'FAIL\truntime/pprof' . | egrep '2021-(09|10)' | grep '/linux-' | egrep '(8cfd8c3|5b90958)' | xargs grep -H 'FAIL:' | grep -v TestBlockProfile | sed -n -e 's,:[ ]*--- FAIL:,,p' | awk '{print $2,$1}' | sort | column -t
TestCPUProfileMultithreadMagnitude                                 ./2021-09-27T18:58:29-8cfd8c3/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-09-27T18:58:29-8cfd8c3/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude                                 ./2021-09-27T18:58:36-5b90958/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-09-27T18:58:36-5b90958/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-09-27T18:58:29-8cfd8c3/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-09-27T18:58:29-8cfd8c3/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-09-27T18:58:36-5b90958/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-09-27T18:58:36-5b90958/linux-amd64-wsl

Problem 2 often shows garbage-collection-related functions in the profile. If the GC is running during the test, it would increase the CPU time for the whole process as reported by getrusage(2) without increasing the amount of time in the cpuHog functions that the test examines. I plan to update the test to disable the GC while it runs.
$ grep -r -l 'FAIL\truntime/pprof' . | egrep '2021-(09|10)' | grep '/linux-' | egrep -v '(8cfd8c3|5b90958)' | xargs grep -H 'FAIL:' | grep -v TestBlockProfile | sed -n -e 's,:[ ]*--- FAIL:,,p' | awk '{print $2,$1}' | sort | column -t | grep -v longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-09-30T16:43:32-9112d29/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-01T04:30:22-822f349/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude                                 ./2021-10-01T17:27:24-952df98/linux-riscv64-jsing
TestCPUProfileMultithreadMagnitude                                 ./2021-10-01T17:27:29-3357624/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-02T13:52:59-07a7c6f/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-05T16:06:49-060cd73/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-06T16:11:20-aecf4b1/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-08T14:08:12-5b9206f/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-08T17:32:31-d7ba1d2/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-11T12:53:11-34f7b1f/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude                                 ./2021-10-12T20:20:41-d032b2b/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude                                 ./2021-10-15T20:29:48-85cbdda/linux-riscv64-jsing
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T18:56:08-07e5527/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T21:05:11-1b24c9e/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T22:47:48-2be5b84/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T05:28:45-b091189/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T20:58:15-73652af/linux-ppc64-buildlet
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-09-30T16:43:32-9112d29/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-01T04:30:22-822f349/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-01T17:27:24-952df98/linux-riscv64-jsing
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-01T17:27:29-3357624/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-02T13:52:59-07a7c6f/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-05T16:06:49-060cd73/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-06T16:11:20-aecf4b1/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-08T14:08:12-5b9206f/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-08T17:32:31-d7ba1d2/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-11T12:53:11-34f7b1f/linux-riscv64-unmatched
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-12T20:20:41-d032b2b/linux-amd64-wsl
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-15T20:29:48-85cbdda/linux-riscv64-jsing
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-19T18:56:08-07e5527/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-19T21:05:11-1b24c9e/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-19T22:47:48-2be5b84/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-20T05:28:45-b091189/linux-riscv64-unleashed
TestCPUProfileMultithreadMagnitude/serial_execution_OS_vs_pprof    ./2021-10-20T20:58:15-73652af/linux-ppc64-buildlet

Problem 3 is new in the last few days. When it shows up, it affects the single-goroutine CPU profiling tests too. It's only appeared on the longtest builders. Those have 16 hyperthreads / GOMAXPROCS=16.
The failures in single-goroutine tests take the form of zero or near-zero samples in the desired functions, and the failures in TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof take the form of the CPU profile reporting only 6 to 14 threads worth of CPU time. (The tests expects 16 threads worth of reporting, and its 10% error margin means that reports from 15 threads worth of work would be considered a success.)
It's interesting that the amount of CPU time reported in the profile is always very close to an integer number of threads (each running for 5 seconds). It's also interesting that the smallest report is 6 out of the 16 threads. I disabled the new timer_create-based profiler and ran the test on the linux-386-longtest builder, and found that setitimer is able to deliver enough SIGPROF events to the process to cover the work of 10 threads (https://storage.googleapis.com/go-build-log/d3ff14b2/linux-386-longtest_a3d8929c.log). My working theory on this failure mode is that on some fraction of the process's threads, the kernel delivers the signals from setitimer first, so the deliveries from timer_create are crowded out up to setitimer's maximum signal delivery rate.
I also find it suspicious that this failure mode is new in the last few days, but none of the nearby commits look related and I also haven't been able to reproduce the problem myself.
$ grep -r -l 'FAIL\truntime/pprof' . | egrep '2021-(09|10)' | grep '/linux-' | egrep -v '(8cfd8c3|5b90958)' | xargs grep -H 'FAIL:' | grep -v TestBlockProfile | sed -n -e 's,:[ ]*--- FAIL:,,p' | awk '{print $2,$1}' | sort | column -t | grep longtest
TestCPUProfileInlining                                             ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestCPUProfileInlining                                             ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestCPUProfileInlining                                             ./2021-10-19T18:42:57-7999fd4/linux-386-longtest
TestCPUProfileInlining                                             ./2021-10-19T22:47:48-2be5b84/linux-386-longtest
TestCPUProfileInlining                                             ./2021-10-20T07:49:28-d2ec73c/linux-amd64-longtest
TestCPUProfileInlining                                             ./2021-10-20T19:29:12-4320949/linux-386-longtest
TestCPUProfileInlining                                             ./2021-10-20T20:58:15-73652af/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
TestCPUProfileLabel                                                ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-19T22:47:48-2be5b84/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-20T00:05:22-4cc6a91/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-20T20:39:19-d419a80/linux-386-longtest
TestCPUProfileLabel                                                ./2021-10-20T20:58:15-73652af/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T16:19:27-f92a358/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T17:01:35-254c497/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T18:42:57-7999fd4/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-19T22:47:48-2be5b84/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T00:05:22-4cc6a91/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T07:49:28-d2ec73c/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T19:29:12-4320949/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T20:39:19-d419a80/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T20:39:25-e904928/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-20T20:58:15-73652af/linux-386-longtest
TestCPUProfileMultithreadMagnitude                                 ./2021-10-21T15:42:41-8b0bea9/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-19T16:19:27-f92a358/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-19T17:01:35-254c497/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-19T18:42:57-7999fd4/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-19T22:47:48-2be5b84/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-20T00:05:22-4cc6a91/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-20T07:49:28-d2ec73c/linux-amd64-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-20T19:29:12-4320949/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-20T20:39:19-d419a80/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-20T20:39:25-e904928/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-20T20:58:15-73652af/linux-386-longtest
TestCPUProfileMultithreadMagnitude/parallel_execution_OS_vs_pprof  ./2021-10-21T15:42:41-8b0bea9/linux-386-longtest
TestCPUProfileRecursion                                            ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestCPUProfileRecursion                                            ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestCPUProfileRecursion                                            ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestCPUProfileRecursion                                            ./2021-10-19T22:47:48-2be5b84/linux-386-longtest
TestCPUProfileRecursion                                            ./2021-10-20T00:05:22-4cc6a91/linux-386-longtest
TestCPUProfileRecursion                                            ./2021-10-20T20:58:15-73652af/linux-386-longtest
TestMathBigDivide                                                  ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestMathBigDivide                                                  ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestMathBigDivide                                                  ./2021-10-19T16:19:27-f92a358/linux-386-longtest
TestMathBigDivide                                                  ./2021-10-20T20:58:15-73652af/linux-386-longtest
TestMorestack                                                      ./2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
TestMorestack                                                      ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestMorestack                                                      ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestMorestack                                                      ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestMorestack                                                      ./2021-10-20T20:39:19-d419a80/linux-386-longtest
TestTimeVDSO                                                       ./2021-10-18T19:46:27-394a1ad/linux-amd64-longtest
TestTimeVDSO                                                       ./2021-10-18T21:21:54-6c0daa7/linux-386-longtest
TestTimeVDSO                                                       ./2021-10-19T07:45:46-ee92daa/linux-386-longtest
TestTimeVDSO                                                       ./2021-10-19T11:52:34-bde0463/linux-386-longtest
TestTimeVDSO                                                       ./2021-10-19T16:19:27-f92a358/linux-386-longtest
TestTimeVDSO                                                       ./2021-10-20T00:05:22-4cc6a91/linux-386-longtest
TestTimeVDSO                                                       ./2021-10-21T15:42:41-8b0bea9/linux-386-longtest

$ find . -name linux-386-longtest | egrep -v '(8cfd8c3|5b90958)' | egrep '2021-(09|10)' | sort | xargs egrep 'pprof_test.go.*compare'
./2021-10-18T21:21:54-6c0daa7/linux-386-longtest:        pprof_test.go:179: compare 1m19.983449s vs 29.94s
./2021-10-19T07:45:46-ee92daa/linux-386-longtest:        pprof_test.go:179: compare 1m19.558967s vs 34.71s
./2021-10-19T11:52:34-bde0463/linux-386-longtest:        pprof_test.go:179: compare 1m19.932465s vs 34.89s
./2021-10-19T16:19:27-f92a358/linux-386-longtest:        pprof_test.go:179: compare 1m19.987855s vs 59.95s
./2021-10-19T17:01:35-254c497/linux-386-longtest:        pprof_test.go:179: compare 1m19.980093s vs 1m4.9s
./2021-10-19T18:42:57-7999fd4/linux-386-longtest:        pprof_test.go:179: compare 1m19.950427s vs 1m4.86s
./2021-10-19T22:47:48-2be5b84/linux-386-longtest:        pprof_test.go:179: compare 1m19.920228s vs 1m4.86s
./2021-10-20T00:05:22-4cc6a91/linux-386-longtest:        pprof_test.go:179: compare 1m19.976284s vs 54.89s
./2021-10-20T19:29:12-4320949/linux-386-longtest:        pprof_test.go:179: compare 1m19.86348s vs 59.83s
./2021-10-20T20:39:19-d419a80/linux-386-longtest:        pprof_test.go:179: compare 1m19.975459s vs 1m9.87s
./2021-10-20T20:39:25-e904928/linux-386-longtest:        pprof_test.go:179: compare 1m18.992738s vs 44.33s
./2021-10-20T20:58:15-73652af/linux-386-longtest:        pprof_test.go:179: compare 1m19.982008s vs 1m4.89s
./2021-10-21T15:42:41-8b0bea9/linux-386-longtest:        pprof_test.go:179: compare 1m19.972142s vs 1m4.91s

Thanks @prattmic . I've got 1171 runs and 0 failures now running https://github.com/torvalds/linux/commit/b6b178e38f40f34842b719a8786d346d4cfec5dc plus a patch to clear tsk->posix_cputimers_work.scheduled in copy_process.
What is the right way to move forward on fixing the kernel bug? I don't lurk on LKML, so don't know the norms to follow or to expect there. I'm open to learning, but handing off to someone with more facility there would be fine too.

It looks like tsk->posix_cputimers_work.work gets initialized only once, via posix_cputimers_init_work called by init_timers called by start_kernel. (My test run of b6b178e plus a patch to posix_cputimers_init_work, to set scheduled at the same time as work, continues to see the ~1% failure rate.) So I don't think it's correct to clear the work field at any time. It looks like it's only a function pointer, and that the job itself is an entry in tsk->task_works which as you said gets cleared during copy_process.
More questions I'd have re an LKML conversation are "which function should do the clearing", "or if it's copy_process, where", "or is there a way to keep all the code close to posix-cpu-timers.c, such as recording the thread id where the job is enqueued instead of true/false, so no clearing is required", and "does it need a reproducer written in C".

There's also the question of what this means for Go. Should we disable the tests unconditionally on linux/386 and linux/amd64 (because the kernel feature that introduced the bug is implemented for x86), or is there a good mechanism and precedent for disabling tests on particular kernel versions? Should we disable profiling when we clone threads? Is this worth an update to #13841?
Or: do we expect most distros will pick up the kernel bugfix in the next three months, so this will all shake out before the Go 1.18 release.
I also haven't addressed the flakiness on RISC-V and WSL. Those look related to CPU time spent on GC (which lead to an imbalance between rusage and the expected profile samples for the application code), so I plan to change the test to disable GC.

What is the right way to move forward on fixing the kernel bug? I don't lurk on LKML, so don't know the norms to follow or to expect there. I'm open to learning, but handing off to someone with more facility there would be fine too.

No problem, I will engage with them and CC you on the thread.

Or: do we expect most distros will pick up the kernel bugfix in the next three months, so this will all shake out before the Go 1.18 release.

As you note earlier, this problem affects setitimer as well, so it isn't just a 1.18 problem. If we add a workaround, then it should likely be backported as well. I need to think a bit more about whether this is severe enough for a workaround like disabling profiling during clone.

No problem, I will engage with them and CC you on the thread.

Thanks @prattmic . And yes, the problem continues to reproduce in yesterday's release of 5.15.

I've sent a patch for this upstream<EMAIL_ADDRESS>

That patch has been merged into the -tip tree, timers/urgent branch, so it should be making its way in.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=ca7752caeaa70bd31d1714af566c9809688544af

so... do we think this patch will hit the Go builders soon, or do we need some kind of workaround in the interim?

From discussion today, I'm planning to write a general workaround for tip (but not backport), as the user impact seems fairly minimal.
In addition, we can mark the tests flaky until the workaround is available.

That's great news, nice work on the patch and explanation to LKML. The commit in timers/urgent is working well for me so far:
Linux ip-172-31-61-152 5.15.0-custom-ca7752c #1 SMP PREEMPT Tue Nov 2 16:33:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
7h50m10s: 2778 runs so far, 0 failures

@prattmic , it sounds like you're on top of the whole picture of followup related to the kernel bug. Thank you! Are there parts of it that you're waiting on from me?
For the other half of the flakiness (the serial portion, on RISC-V and WSL), I sent https://golang.org/cl/359934 . I'll ping on that CL for a second reviewer.

Are there parts of it that you're waiting on from me?

No, though I'm working on a workaround to disable the timers during clone and would like your review of that once it is ready.

Does the kernel bug also explain the recent flakes in TestCgoPprof?
greplogs --dashboard -md -l -e '(?ms)FAIL: TestCgoPprof.*cpuHog traceback missing' --since=2020-06-16

2021-11-04T23:56:29-0e5f287/linux-amd64-buster
2021-11-02T21:18:44-80065cf/linux-amd64-staticlockranking
2021-11-02T16:12:23-599de4b/linux-amd64-sid
2021-10-14T21:08:35-440b63b/linux-amd64-staticlockranking
2021-10-06T19:45:35-e38ec96/linux-ppc64le-buildlet
2021-10-04T17:17:11-cc5e3de/linux-amd64-longtest
2021-09-28T20:54:26-b8a6017/linux-amd64-jessie

(The symptoms of these failures match #37201, but that appeared to have been fixed in May 2020.)

@bcmills this particular kernel bug wouldn't explain the failure on linux-amd64-longtest on October 4 (well before October 18).
Yes, those failures look like what's described in #37201. That issue closed when a particular source of signals was eliminated; there may be another (less frequent) source of signals.
The October 4 failure shows Duration: 200.88ms, Total samples = 10ms ( 4.98%). Stopping the CPU profiler seems to involve 200ms worth of sleeps, so I take that to mean that it got stopped almost immediately, and due to the "traceback function called 2 times"  condition rather than "test ran for one second" (https://github.com/golang/go/blob/cc5e3de593afca73cf1b4d732ddceffb2837b390/src/runtime/testdata/testprogcgo/pprof.go#L89). Samples covering 10ms, at 100Hz, means 1 sample. That's consistent with the process receiving signals in addition to SIGPROF, causing the test to exit early.

Turning the GC off during the test didn't resolve all sources of flakes on riscv64: https://build.golang.org/log/088b21dcceb4774c2f5ed27a7929611730fc0192 is a recent failure that shows 39 samples in 0x77188 (runtime.sigtramp:429).
That seems like a strange function to show up in CPU profiles (https://github.com/golang/go/blob/6ba68a0581d537edfd6eb2e5675c408f18eb4eed/src/runtime/sys_linux_riscv64.s#L429). How would it be able to get a signal while already handling a signal?
I also see that it's a single PC. Maybe it's in the profile via sigprofNonGoPC (https://github.com/golang/go/blob/6ba68a0581d537edfd6eb2e5675c408f18eb4eed/src/runtime/signal_unix.go#L429), which would mean g==nil. FWIW, that also means (from validSIGPROF) that it's from setitimer rather than timer_create.
If that's the case, what would get in the way of finding g in signal handlers on riscv64? The PC isn't in the VDSO: we see the result of c.sigpc() (0x77188), and if inVDSOPage works correctly that should return false when sigFetchG calls it. So the g should come from getg(). It looks like that's X27 (https://github.com/golang/go/blob/go1.17.3/src/cmd/compile/internal/ssa/gen/RISCV64Ops.go#L27), which is supposed to get preserved across calls / not clobbered (if I've found the right doc and am reading it correctly: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc#integer-register-convention).
I'm not sure where to go from here. Are there RISCV or ABI experts who might have a theory, or is there a way I can access hardware to debug?

Are there parts of it that you're waiting on from me?

No, though I'm working on a workaround to disable the timers during clone and would like your review of that once it is ready.

I tried this out, but unfortunately, it does not actually work. Just looking at clearing ITIMER_PROF, the behavior is:

setitimer sets tsk->signal->posix_cputimers.bases[CPUCLOCK_PROF].nextevt = 0 and tsk->signal->it[CPUCLOCK_PROF].
In the timer interrupt, run_posix_cpu_timers will call __run_posix_cpu_timers, setting tsk->posix_cputimers_work.scheduled = true as long there is a single tick of user/system time.

Note here that expiry_cache_is_inactive looks for nextevt == U64_MAX, not 0.

This is normally fine, as handle_posix_cpu_timers won't actually send a signal since tsk->signal->it[CPUCLOCK_PROF] is cleared, but simply scheduling the work is sufficient for this bug.
As an alternative to disabling the timers around clone, one wonders if perhaps we can set them to an extremely high value so that fastpath_timer_check will determine that none have expired? No, unfortunately not, as setting the timer only changes nextexp if the new value is less than the old value (to avoid walking the entire linked list to search for the next expiration time). Instead, the timer work is scheduled whenever the next expiration would occur, at which point the list is walked and next expiration updated.
Thus, I don't currently have a workaround idea beyond setting the timers and spinning until the next expiration before clone (which is obviously unacceptable). I'm all ears to other ideas, otherwise I'll just disable this test for now.

I see some options to hit the bug less often, but not to work around it entirely.
First of all, the initial timer expiration in the new profiler is chosen from a uniform random distribution in the range [1, 10_000_000] ns. In TestCPUProfileMultithreadMagnitude, many goroutines are ready to work right away, so we expect the runtime to create new threads, for each new thread to create a profiling timer for itself, and then to immediately create an additional new thread (until there's an M for each P). In that scenario, pushing back the earliest possible timer_create expiration (e.g. uniformly distributed over 10–90% of the 10ms target instead of 0–100%, keeping the mean the same) could make the expiration less likely to coincide with a call to clone for that type of workload.
Another option, we could use the template thread every time the runtime needs a new M (and not enable per-thread profiling for that thread). That thread would still be at risk of doing the buggy bookkeeping for the process-wide setitimer. And there's probably a good performance reason to not do this all the time already.

re @rhysh
Similar to your option (1), we do have a few tests that use runtime_test.warmupScheduler to get the thread count up before starting tests. We could do that for TestCPUProfileMultithreadMagnitude, but I don't think it is worth it vs just waiting.
Re: option (2), again since that is only a partial mitigation, I'd rather avoid making such a change unless this becomes really problematic.

With http://golang.org/cl/363214 submitted, I believe we have addressed the flakiness on builders due to the Linux issue.
Additionally, all failures not related to the Linux kernel bug have been split into other issues (please correct me if I forgot some, in which case they should be moved).
Thus, this issue is done for now, but I'll leave open to track the upstream Linux fix rollout and ultimately dropping/adjusting the kernel version checks.

Patch update: my upstream patch has been merged into Linus' tree and queued for backport to 5.10 and 5.14.

This fix is now released in:

5.10.80
5.14.19
5.15.3

For reference, I took a look at some distros that I expect off the top of my head are widely used. Reminder this bug affects Linux 5.9 through 5.15 inclusive.

RHEL 8: Linux 4.18, unaffected.
Debian oldstable (buster): Linux 4.19, unaffected
Debian stable (bullseye): Linux 5.10.70 currently, appears to update patch release every ~3 months.
Debian testing (bookworm): Linux 5.14.16 currently, appears to update patch release monthly.
Ubuntu 20.04 LTS: Linux 5.4, unaffected
Ubuntu 22.10: Linux 5.13. This is no longer supported upstream, so it was not patched. It is unclear what their backport policy is, but the release notes do list all the changes they integrate.
Amazon Linux 2: Linux 4.14, unaffected.
Google Container-Optimized OS M93 LTS: Linux 5.10.68 currently. Updates patch release in "LTS Refresh" releases every 3 months.
Google Container-Optimized OS M89 LTS: Linux 5.4, unaffected.

Overall this looks pretty promising to me that most of the ecosystem should get the patches fairly quickly.

Do we also need to apply the test-skip to some of the other runtime and/or runtime/pprof tests mentioned in https://github.com/golang/go/issues/49065#issuecomment-946825081?
For example, I still see some recent TestMorestack failures, and there was a large uptick in those starting Oct. 18 as well:
greplogs --dashboard -md -l -e 'FAIL: TestMorestack' --since=2021-07-01

2021-11-18T02:16:39-353cb71/linux-386-longtest
2021-11-11T20:25:07-eb68e33/linux-amd64-longtest
2021-11-10T20:45:04-a881409/linux-386-longtest
2021-11-10T18:06:32-097aaa9/linux-386-longtest
2021-11-09T22:11:33-4aa0746/linux-386-longtest
2021-11-09T20:10:44-74b9939/linux-386-longtest
2021-11-09T18:03:59-36dbf7f/linux-386-longtest
2021-11-08T21:45:43-cc49178/linux-amd64-longtest
2021-11-08T18:54:21-830b393/linux-386-longtest
2021-11-07T04:57:22-9e6ad46/linux-amd64-longtest
2021-11-06T19:41:10-565f457/linux-amd64-longtest
2021-11-05T22:56:55-2f71c86/linux-amd64-longtest
2021-11-05T22:30:17-b07c41d/linux-386-longtest
2021-11-05T19:14:22-fa16efb/linux-386-longtest
2021-11-05T17:46:59-e48e4b4/linux-amd64-longtest
2021-11-05T00:52:04-1c4cfd8/linux-amd64-longtest
2021-11-04T21:40:51-2c32f29/linux-amd64-longtest
2021-11-04T15:43:59-6ba68a0/linux-386-longtest
2021-11-04T02:57:37-9e4e23c/linux-386-longtest
2021-11-04T00:46:41-e72d715/linux-386-longtest
2021-11-04T00:15:44-91962df/linux-386-longtest
2021-11-03T05:00:00-519c0a2/linux-386-longtest
2021-11-02T18:35:29-433ba58/linux-386-longtest
2021-11-02T15:15:09-da7173a/linux-386-longtest
2021-11-02T01:28:01-a59e332/linux-386-longtest
2021-11-01T16:31:02-2bcf1c0/linux-386-longtest
2021-11-01T16:30:49-80bedb8/linux-386-longtest
2021-10-31T02:24:29-0bef30d/linux-386-longtest
2021-10-30T18:30:05-f582778/linux-386-longtest
2021-10-29T23:15:00-8dfb447/linux-386-longtest
2021-10-29T18:34:24-903f313/linux-386-longtest
2021-10-26T22:05:53-80be4a4/linux-386-longtest
2021-10-25T17:02:16-52b10ab/linux-386-longtest
2021-10-23T20:23:35-8dbf3e9/linux-386-longtest
2021-10-23T16:18:19-16318df/linux-386-longtest
2021-10-22T21:12:07-76dd01f/linux-386-longtest
2021-10-20T20:39:19-d419a80/linux-386-longtest
2021-10-19T11:52:34-bde0463/linux-386-longtest
2021-10-19T07:45:46-ee92daa/linux-386-longtest
2021-10-18T21:21:54-6c0daa7/linux-386-longtest
2021-10-18T19:46:27-394a1ad/linux-amd64-longtest

Yes, we probably should. TestMorestack for example probably doesn't create as many threads as TestCPUProfileMultithreadMagnitude, but it could still be affected if unlucky.
Most of the pprof tests are probably at least theoretically affected, but I think we only want to add skips to tests that are particularly affected, lest we lose all pprof coverage.
Perhaps better would be to pin the builders to COS M89, which is unaffected, until M93 is updated to include the patch.

Perhaps better would be to pin the builders to COS M89, which is unaffected, until M93 is updated to include the patch.

@golang/release, is that feasible to do in the short term?

IIUC, that could be achieved by changing https://cs.opensource.google/go/x/build/+/master:buildlet/gce.go;l=461;drc=05d22632dd9ae9f87a48a12960617e223cecdf9c?ss=go from cos-stable to cos-89-lts (https://cloud.google.com/container-optimized-os/docs/release-notes#lts_image_families), though that would affect every single builder using COS, which may or may not be desirable.

Is there anything left to do on this now that the builders are updated? @dmitshur points out it might deserve a release note.

There is no remaining immediate work to be done beyond tracking rollout of upstream fixes.
Perhaps adding a release note would be a good place to note this bug, though I want to emphasize that this is not a new issue with Go 1.18. It affects old releases as well.

Feel free to send a release note :)
Closing this then.

As of 2022-01-18 all of the distros I tracked in https://github.com/golang/go/issues/49065#issuecomment-973203258 have released a fixed kernel.
As a summary, this bug was:

Introduced in Linux 5.9.
Fixed in Linux 5.10.80.
Fixed in Ubuntu's Linux 5.13.0-24.24.
Fixed in Linux 5.14.19.
Fixed in Linux 5.15.3.
Fixed in Linux 5.16+.


Glitch in Simple Waterfall POwer BI - Datanomy Limited

Simple Waterfall is getting disabled on focus mode of any Visual in dashboard.
Suppose if we are entering in the focus mode of any other visual and then coming back, Waterfall chart disappears and it reappears again when we click at any other place on the dashboard
Simple Waterfall bug.pdf

Can you remove and install the visual again and see if the issue disappears

Hi @nishantjainuk,
Thanks for providing the workaround. Could you please let us now which browsers this visual supports because we are also facing the same issue which Kajal mentioned  in Edge browser as well.
Regards,
Jai

Hi @nishantjainuk ,
I have removed the visual still showing the same issue. The visual gets disappears . Though it is working fine in Power BI desktop version . On Workspace , this is creating issue.
Can you please look into this?

@jaikumar1234 @Kajal911
I am not facing the same issue and it is working fine for me.
I have tested in Edge and Chrome. The compatibility is not something that I can control as it is managed by Microsoft.
Are you using the latest browser version?


cannot ready to see the code

Could you please share your code?

Hi, we will release the code online recently. Thanks for your interests.

Hi @frank-xwang,
Thanks for the nice work! Do you have the schedule to release the code? I'm very interested in this work. Thanks in advance!

Hi @ha-lins, thank you for your interest in our work! Since our paper is still under review, we plan to wait for the review results before publishing the code. Thank you for your understanding. The current plan is to release it around mid-February 2021.

Codes are available now.


Local paths

Add local video paths to video model
As a result, video indexing is now much more flexible


Add deleteState, addReceiptData, and addEvent methods

Enabled checkstyle for transaction-processor module
style: some whitespace corrected, and imports ordering corrected
Added deleteState, addReceiptData, and addEvent methods and implementation as requested in https://jira.hyperledger.org/browse/STL-1175

This is great closing up this functionality gap on the java SDK.
Could you please add corresponding unit tests the new methods?
Unfortunately the existing TP SDK methods lack these unit tests but the signing SDK has unit tests you could look at.

Right thing to do here is to unit test the ZmqContext class since it is the major substantive concrete class.  https://jira.hyperledger.org/browse/STL-1172 discusses this a tad.  I'll  have a look at mocking up the ZMQ stream in order to do it right.

@dcmiddle took a pretty good swipe at adding unit test to the Context class. Let me know what you think.


Claim generation

Adds claim generators. Fixes #82

ooops... fixed random in Erlang 17 but Travis is failing for 18 now. Strange error. Please do not merge it yet. I will take a look what is going on in Travis (my branch passed so I expected it to pass on joken too).

The Travis error was a failed attempt of downloading mix from s3 at setup. Not sure why but it seems they were updating it.
I guess this is safe to merge. I could not reproduce any errors locally.

Awesome!


CircleCI artifact link updated again

Hi there,
I think CircleCI has updated their artifact links again, and am happy to submit a pull request to fix this, but wanted to check in with you first (in case I've got a setting wrong and this can be fixed in a different way).
I am on version 0.5.5.
I have CIRCLE_PROJECT_ID set.
The report link that is being posted into slack is something like this:
https://2334-92384-gh.circle-artifacts.com/0/cypress/reports/mocha-report/mochawesome-report/mochawesome.html

But the only way that I can access the report is via something like this:
https://2334-92384-gh.circle-artifacts.com/0/~/project/test/cypress/reports/mocha-report/mochawesome-report/mochawesome.html

So the generated link is missing this bit: ~/project/test/
My package.json is at the same level as that cypress folder.
Would it make sense to add an extra environment variable (or setting) to allow specifying this prefix?

Hey thanks for the report,
I may be because I used to get the current working directory and prefixed onto the reportDir path.
https://github.com/YOU54F/cypress-slack-reporter/blob/7fa3c8f0ea9b53fe1e955b18efd995a7e84898e0/src/index.ts#L30
You can pass your full path with -- report-dir command line option.
Please feel free to submit a PR, I will test out the current state of circles api in the morning.

Unfortunately, the artifact link works with
https://2334-92384-gh.circle-artifacts.com/0/~/project/test/cypress/reports/mocha-report/mochawesome-report/mochawesome.html

But if we replace ~ with /home/circleci it doesn't reach the artifact, which means that process.env.PWD won't build the correct link.
In addition, if I pass ~/project/test/cypress/reports/mocha-report/mochawesome-report as reportDir (with no quotes), the path ends up being resolved to the home dir, and I end up with a link that looks like https://2334-92384-gh.circle-artifacts.com/0/home/circleci/project/test/cypress/reports/mocha-report/mochawesome-report/mochawesome.html.
If I pass it with quotes, cypress-slack-reporter fails, saying that it was unable to resolve the path.
This is where I am no, but didn't have much time today, so will have a look later!

For those who are looking for the solution, there is a workaround by setting a destination option in store_artifacts job in config.yml (CircleCI).
- store_artifacts:
          path: ~/path/to/cypress/videos
          destination: cypress/videos

will allow you to access artifacts through
https://${CI_BUILD_NUM}-${CI_PROJECT_ID}-gh.circle-artifacts.com/0/cypress/videos/some_test_result.mp4
This is what it says on CircleCI Documentation:
Currently, store_artifacts has two keys: path and destination.

path is a path to the file or directory to be uploaded as artifacts.
destination (Optional) is a prefix added to the artifact paths in the artifacts API. The directory of the file specified in path is used as the default.

Thank you very much @rostradamus, worked perfectly!

thanks @rostradamus
Any of you kind chap and chapettes care to make a PR to update the readme? It would be very much apprieciated

will it help setting custom URL? you can pass it from the CLI itself?
cause this link seems like it is not static and consistent at all. and we already have custom option, not sure if that will help!

@claudiamatosa @rostradamus now added instructions to README, thank you very much all. hope this addresses this issue, and you are happy with it being closed. If not, give us a shout :)


New version

Hi,
Here is a proposed new version of the script.
The major changes is that we can now install the scraper with pip if you agree to publish it.
Then it creates a kijiji command, shortcut for main.py basically.
Also some options are configurable with CLI options, useful if we have several different searches to do.

Oh and other thing, in order to be have kijiji command in the PATH, the database is now stored by default in ~/.kijiji_scraper/ads.json or %APPDATA%/.kijiji_scraper/ads.json on Windows.
Please try out the feature and let me know if it's ok to merge ! :)

If you do not wish to publish it on PyPi , it's ok too. You can just remove the part regarding Pypi install in the readme

Thanks for the work you put in on this! I quickly skimmed over the code and it looks good so far.
I'll test it out tonight and merge the PR if everything works.

Great thanks.
May be I'll add a note about how to safely run several searches at the same time. The trick is to initiate a ads.json file in your current directory and assign as many ads.json files as searches config.
I currently have 4 processes of kijiji that runs into screens with their own ads.json file, different urls and emails.
If we leave several processes use the defaults file, it will cause concurrent accesses at some point as corrupt the json file.

Also please tell me if your ok publishing the package on PyPi. Here is an example script to add in the project folder to publish rapidly.
#! /bin/bash
python3 setup.py build check sdist bdist_wheel
twine upload --verbose dist/*
python3 setup.py clean
rm -rf ./dist
rm -fr ./build
rm -fr ./kijiji_scraper.egg-info

I'm going to try using this package to store the ads as it should solve the issue you mentioned with running multiple concurrent scripts.
I am also okay with publishing the package to PyPi and I will create a github action to do that.

@CRutkowski yes it could work but having one specific file per searches is also useful. For exemple, friends are looking for appartements with différents criterial that overlaps sometimes . And I want to make sure everyone get the all ads emailed.


Deleting Paymowidget

deleting this app since it seems to be replaced by Paymo Plus.
App seems to have been replaced by Paymoplus

Output of `brew cask  --verbose`
$ brew cask fetch --download paymowidget --verbose
==> Downloading external files for Cask paymowidget
==> Downloading https://app.paymoapp.com/desktop-apps/paymowidget/PaymoWidget_mac_4.0.16.dmg
/usr/bin/curl --remote-time --location --user-agent Homebrew/1.1.11 (Macintosh; Intel macOS 10.12.3) curl/7.51.0 --fail https://app.paymoapp.com/desktop-apps/paymowidget/PaymoWidget_mac_4.0.16.dmg -C 0 -o /Users/gobinathm/Library/Caches/Homebrew/Cask/paymowidget--4.0.16.dmg.incomplete
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found
Error: Download failed on Cask 'paymowidget' with message: Download failed: https://app.paymoapp.com/desktop-apps/paymowidget/PaymoWidget_mac_4.0.16.dmg
The incomplete download is cached at /Users/gobinathm/Library/Caches/Homebrew/Cask/paymowidget--4.0.16.dmg.incomplete
Error: Kernel.exit

Closing in favour of https://github.com/caskroom/homebrew-cask/pull/30788.

@miccal don't we want to remove this obsolete cask ?

You have removed it in your other PR.


Broken Enchant Table & Recall Interface

Some players on my server and myself have noticed tabs are now missing from the wand enchanting/spell upgrading interface and locations for recall no longer show up.

Are you using custom wands, or just the builtin survival configs?

What changed to cause this issue? Did you update the plugin?

Before now I haven't attempted to upgrade any spells or use this interface since before updating, which I did early October.

I figured out the issue - incompatibility with the plugin 'itemjoin' which caused a PLETHORA of issues with my server, sorry to have bothered you!


reconciler error during certificate renewal

I am using version 0.6.2 against along with cert-manager 1.11.0 .
During a certificate renewal attempt ca-issuer plugin logs the below error message , any idea what could be the reason for this ? or what to be adjusted to fix the issue .
"msg"="Reconciler error" "error"="Operation cannot be fulfilled on certificaterequests.cert-manager.io \"tls-keys-75glc\": the object has been modified; please apply your changes to the latest version and try again" "certificateRequest"={"name":"tls-keys-75glc","namespace":"istio-egress"} "controller"="certificaterequest" "controllerGroup"="cert-manager.io" "controllerKind"="CertificateRequest" "name"="tls-keys-75glc" "namespace"="istio-egress" "reconcileID"="7a29c165-01e9-438a-98c4-fb2eeb2a3f70"
I could see that after few seconds it pick the same certificate request  (seems by the time CR approval is done) and certificate is successfully issued
controller/CertificateRequest "msg"="Initialising Ready condition" "certificaterequest"={"Namespace":"istio-egress","Name":"tls-keys-75glc"}

potentially log severity to be changed to info instead of error in such cases ?

In https://github.com/cert-manager/google-cas-issuer/pull/109, we refactored this issuer to use issuer-lib.
issuer-lib uses Server Side Apply and will prevent these "the object has been modified" warnings from happening.


[Impeller] add OpenGL GPU tracing to devicelab tests.

Adds the metadata key required to enable OpenGLES GPU tracing. This is off by default because the API crashes on some GPU models, but it should be safe on the Pixel 7 (others TBD based on testing results).

I'm not sure I understand your point. We want to measure GPU performance in our benchmarks

I'm not sure I understand your point. We want to measure GPU performance in our benchmarks

With the name "trace" I thought this was related to the logging work that was discussed elsewhere, not measurement.

Oh sorry, this is addition of GPU frame time measurements that we've already done for metal and vulkan. The OpenGLES APIs we use for these are crashy though, so its off by default for users.


Did you confirm all files can use?

You should set up a complete running file.
If you feel finished to set up, please let me know.

I think so, I have sent you messages on Mattermost.


How do you keep the app up-to-date?

Complete newb when it comes to coding and using github, and I appreciate the work you all do. I was wondering how I would keep this up to date when a new update is pushed. Do i rebuild the package then re-run it on the vision pro?
Thanks!

General procedure is:
In Terminal.app, go to the directory where you cloned, and run git pull origin main, then rebuild ALVR
cd alvr-visionos
git pull origin main
zsh ./build_and_repack.sh

Then run the Xcode build instructions again.
If it complains about uncommitted changes, just run
git stash

I updated the Building wiki to include those instructions ^^

Thank you all so much. I will try this next time i see an update to the codebase. Appreciate all the hard work, keep on trucking yall 👍


[SiVal] Test plan update for flash_ctrl

Added list of features to the flash_ctrl specification.
Moved flash_ctrl chip tests to chip_flash_ctrl_testplan.hjson
Added si_stage: SV* test cases to cover functionality enumerated in the list of features.
Updated the pre-silicon test cases with relevant SV* labels.

Tests for following features are not ready due to it doesn't exist or implemented under sim_dv

FLASH_CTRL.ESCALATION
FLASH_CTRL.INFO.ISOLATED_PARTITION
FLASH_CTRL.INIT.SCRAMBLING_KEYS
FLASH_CTRL.MEM_PROTECTION
FLASH_CTRL.RMA

CHANGE AUTHORIZED: hw/ip/flash_ctrl/data/flash_ctrl.hjson

CHANGE AUTHORIZED: hw/ip/flash_ctrl/data/flash_ctrl.hjson

why am I still getting this?


Not downloading all pictures/ videos

Discussed in https://github.com/taux1c/onlyfans-scraper/discussions/14

Originally posted by jamesle3199 August 28, 2022
Hey I'm trying to scrape a whole profile but it doesn't seem to be downloading all the photos and videos. Here's what I'm getting, I don't know where the db files are either so I'm unable to clear it and try again..
[?] Which area(s) would you like to scrape? (Press ENTER to continue)  [All]
Name: ✨ 𝑃𝑟𝑒𝑔𝑛𝑎𝑛𝑡 𝐿𝑖𝑣 ♡ 💋 | Username: vintagebarbiex | ID: 50198059 | Joined: July 12, 2           02
- 1125 posts
 -- 4195 photos
 -- 185 videos
 -- 0 audios
- 391 archived posts
 + Getting pinned media...
 + Getting timeline media...
 + Getting archived media...
 + Getting highlights...
 + Getting messages...
Progress: (1133 photos, 8 videos, 0 skipped || 1.55 GB): 100%|█████████████████████| 1143/1143 [05:02<00:00,  3.77it/s]

Using profile: main_profile
? What would you like to do?  Download content from a user
? Choose one of the following options:  Enter a username
? Enter a model's username:  vintagebarbiex
[?] Which area(s) would you like to scrape? (Press ENTER to continue)  [All]
Name: ✨ 𝑃𝑟𝑒𝑔𝑛𝑎𝑛𝑡 𝐿𝑖𝑣 ♡ 💋 | Username: vintagebarbiex | ID: 50198059 | Joined: July 12, 2           020
- 1125 posts
 -- 4195 photos
 -- 185 videos
 -- 0 audios
- 391 archived posts
 + Getting pinned media...
 + Getting timeline media...
 + Getting archived media...
 + Getting highlights...
 + Getting messages...
Progress: (0 photos, 0 videos, 0 skipped || 0): 100%|████████████████████████████████████| 2/2 [00:00<00:00,  4.15it/s]</div>

The more I look into this the more I find.
I ran some debug script and the number of media urls returned vs the number downloadable has some discrepancies. I am also able to see the media on the page. I haven't had time to do much work on this yet. I also ran the like all posts and got a lot of 404 errors and am now getting some 404 errors when I try to download some of the media.
 | Liking posts... « 138/143 » [0.8321 it/s]                           STATUS CODE 404: Post not found, post at https://onlyfans.com/125368153/jaytoy15
 - Liking posts... « 138/143 » [0.8271 it/s]                           STATUS CODE 429: , post at https://onlyfans.com/125368153/jaytoy15
 / Liking posts... « 139/143 » [0.8281 it/s]                           STATUS CODE 404: Post not found, post at https://onlyfans.com/122995497/jaytoy15
 \ Liking posts... « 139/143 » [0.8232 it/s]                           STATUS CODE 429: , post at https://onlyfans.com/122995497/jaytoy15
 / Liking posts... « 141/143 » [0.824 it/s]                           STATUS CODE 404: Post not found, post at https://onlyfans.com/101991925/jaytoy15
 \ Liking posts... « 141/143 » [0.8192 it/s]                           STATUS CODE 429: , post at https://onlyfans.com/101991925/jaytoy15
 - Liking posts... « 142/143 » [0.8203 it/s]                           STATUS CODE 404: Post not found, post at https://onlyfans.com/69504864/jaytoy15
 | Liking posts... « 142/143 » [0.8155 it/s]                           STATUS CODE 429: , post at https://onlyfans.com/69504864/jaytoy15
 + Liking posts... « 143/143 » [0.8144 it/s]


Enhance double-click

Need to track double click better. The button should retain state when first clicked then track send click.

This has been fixed.


Milestone 3 Feedback

Great work with testing and code coverage, no issues at all.
Missing example in compress and sharpen docstrings. Missing toy data for shrink, so example can't be reproduced. Same with usage examples.

@yavyx  Thank you for the feedback, we have addressed all these issues in our latest release!


#final:Submission for Reproducible analytical pipelines workshop

Hello @b-rodrigues,
Thank your email. As you told me that this is enough for now, so it's my final submission of my work.
I'll follow your advice on the second version of this app.
Have a nice day.

👍


.NET 8:  All issues for ASP.NET Core 8.0

All issues except for Blazer, gRPC, & SignalR.

What’s new in .NET 8 Preview 1 && ASP.NET Core roadmap for .NET 8 on GitHub
What’s new in .NET 8 Preview 2

[ ] #28598 and #28600 maybe #28599
[x] New analyzers for API development - ASP0014 - ASP0019 #27366
[x] #28742 #28744 #28745 #28746 #28747
[ ] #28754 #28755
[ ] #28664 #28656

@Rick-Anderson, I think these two (which I just opened) should go on this list too:
https://github.com/dotnet/AspNetCore.Docs/issues/28934
https://github.com/dotnet/AspNetCore.Docs/issues/28935


Merging Master to Published

Deploy preview for docsdocker ready!
Built with commit 1da1049b36108972d54633d4007e23d53e5f5dfd
https://deploy-preview-9462--docsdocker.netlify.com


Can't download models

When I try python3 -m merged_depth.utils.download_models, following errors occurred
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/me/merged_depth/merged_depth/utils/download_models.py", line 65, in <module>
    main()
  File "/home/me/merged_depth/merged_depth/utils/download_models.py", line 62, in main
    extract_models(pretrained_models)
  File "/home/me/merged_depth/merged_depth/utils/download_models.py", line 56, in extract_models
    with zipfile.ZipFile(file, 'r') as zip_ref:
  File "/usr/lib/python3.8/zipfile.py", line 1269, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.8/zipfile.py", line 1336, in _RealGetContents
    raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file

The content of pretrained/pretrained.zip is

<TITLE>Not Found</TITLE>

Not Found

Error 404

How can I get the model?
Thanks!

Thanks for updating the pretrained.zip. The python script doesn't work with the URL but downloading it manually (constructing the URL manually) works just fine.
Using cache found in C:\Users\Dean/.cache\torch\hub\rwightman_gen-efficientnet-pytorch_master
Loading base model ()...Done.
Removing last two layers (global_pool & classifier).
Building Encoder-Decoder model..Done.
Using cache found in C:\Users\Dean/.cache\torch\hub\rwightman_gen-efficientnet-pytorch_master
Loading base model ()...Done.
Removing last two layers (global_pool & classifier).
Building Encoder-Decoder model..Done.
Loading weights:  ./pretrained/MiDaS_f6b98070.pt
Downloading: "https://github.com/facebookresearch/WSL-Images/archive/master.zip" to

Unfortunately https://github.com/facebookresearch/WSL-Images/archive/master.zip is now a 404 file.

Thank you for uploading the file!
Unfortunately I'm also experiencing the same problem as canadacow.

I also see a 404 for the WSL-images zip. Were either of you able to resolve the issue?

It seems the models are now available in torch.hub.
One would have to acquire them like so:
model = torch.hub.load('facebookresearch/WSL-Images', 'resnext101_32x16d_wsl')

Thanks for the quick reply.  It looks like the code is already trying to load the models from torch.hub but the repository has moved. I submit a PR #11 with the updated repository, which fixes the 404 issue for me.


[Improve][Connector-v2][JdbcSink]Fix max_retries default value.

Purpose of this pull request

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

Merge dev branch in your branch and try againe. Every pull reqeust before merged should pass all CI/CD.

Merge dev branch in your branch and try againe. Every pull reqeust before merged should pass all CI/CD.

Before submitted the pr, I already pulled the branch created by the latest code.

@TyrantLucifer @Hisoka-X @ic4y @ashulin PTAL.

If the JDBC sink is IS_EXACTLY_ONCE, max_retries=0 is required, so the default value is 0.
https://github.com/apache/incubator-seatunnel/blob/40699b660cfecb5cffb2da0a94dc1bbd29a19579/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/sink/JdbcExactlyOnceSinkWriter.java#L77-L87
You need to think about this.

If the JDBC sink is IS_EXACTLY_ONCE, max_retries=0 is required, so the default value is 0.
https://github.com/apache/incubator-seatunnel/blob/40699b660cfecb5cffb2da0a94dc1bbd29a19579/seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/sink/JdbcExactlyOnceSinkWriter.java#L77-L87
You need to think about this.

The default value in the document is 3,  the document is wrong, and the document needs to be modified.

@lightzhao You are right, you can submit another pr to fix it

@lightzhao You are right, you can submit another pr to fix it

ok


Adding additional/custom headers

The class WebSocketClient from the underlying Java-WebSocket has the constructor WebSocketClient( URI serverUri, Map<String,String> httpHeaders) that takes additional http headers as an argument. Is it possible to do something similar with MatlabWebSocket? It seems like this isn't exposed in the API, but maybe I just didn't find it. A common use case would be authentication, i.e. sending a username and password hash when establishing a connection.
I would be willing to work on this if you consider such a feature useful and in scope for MatlabWebSocket.

Hey, yes I would certainly find this useful. As long as the argument is optional that would be fine.

Okay, cool. I will have a deeper look then and start working on something.


fix(plugin): fix handling of files with dotted suffixes, thx to @gnaegi

closes issue #258

Please note that this change reveals a behavior divergence between suffix and folder structures which I'll have to think about more deeply and find a solution to before merging.


MatchError when creating a User-defined function.

In this snippet, it is assumed that a keyspace named example was created using SimpleStrategy and a replication factor of 3.
{:ok, conn} = Xandra.start_link(nodes: ["localhost:9042"])
statement = Xandra.prepare!(conn, "CREATE FUNCTION example.downcase ( arg text ) RETURNS NULL ON NULL INPUT RETURNS text LANGUAGE java AS $$ return arg.toLowerCase(); $$")
Xandra.execute!(conn, statement)

The resulting traceback looks like
** (MatchError) no match of right hand side value: <<0, 0>>
    (xandra 0.13.1) lib/xandra/protocol/v3.ex:689: Xandra.Protocol.V3.decode_change_options/2
    (xandra 0.13.1) lib/xandra/protocol/v3.ex:642: Xandra.Protocol.V3.decode_result_response/4
    (db_connection 2.2.2) lib/db_connection.ex:1177: DBConnection.decode/4
    (db_connection 2.2.2) lib/db_connection.ex:596: DBConnection.execute/4
    (xandra 0.13.1) lib/xandra.ex:962: anonymous fn/4 in Xandra.execute_without_retrying/4
    (db_connection 2.2.2) lib/db_connection.ex:716: DBConnection.run/3
    (xandra 0.13.1) lib/xandra.ex:841: Xandra.execute!/3

This test was done using the official docker image for Cassandra.

Hey @cjayross, thanks for the report! That's a good catch. I have zero time to work on this for the next few weeks. Any chance you could investigate and submit a fix? Thanks for the patience :)

@whatyouhide, unfortunately, I don't have much time either. Perhaps a new issue should be posted in search for an additional maintainer? Any idea if there are some forums to advertise the need?

@cjayross I don't really know where to post it, no. :) Will think about it.


Batch ONNX: example code on how to run it on a batch of images?

Hello everyone! 👋
I've been tinkering with the ONNX model, specifically for inferring on a batch of images.
There's a great example for batch processing in this pytorch notebook, but it seems that the ONNX notebook doesn't offer a similar one.
Could anyone who worked with onnx batch processing share their insights or maybe even extend the ONNX notebook to also illustrate this usecase?
Thanks a ton! 💙🖖

I  have modified a little base on the notebook, and test batch processing ,the result like this


Support for tel and other link types in external link form

It would be nice if the UI for adding links allowed for non http/ftp links to be added. Currently you get a validation error when trying to add tel/maps/etc...

Closing as per https://github.com/torchbox/wagtail/issues/490#issuecomment-53415721 - I don't think there's a legitimate use for these link types within rich text. Special-purpose pages that use them, such as contact pages, should build them into their data model / template instead.


Styling the landing page

As you can see, the landing page looks pretty plain. I would Like someone skilled in CSS/ HTML. To come up with a good style for the landing page. Something that will not contrast a lot with the theme colours, and is minimalistic.
Also if you can find a way to reduce the height of the navbar then that will be a huge win.

Hey, I would love to work on this issue.

I'd like to work on this; Would you kindly assign it to me?

Hi, I would like to work on this

I have added assigned you.

Since we are like several of us on this issue, you can send me your discord usernames so that I can invite you to the thread I just created for this roject, and we can share ideas on how we are going to achieve this

The thread is called Soko-Laravel-VueHTML-CSS-Bootstrap

Quirky#9453

sutti-san#7195


OpenSource free Vision model use Instead of openAI

Is your feature request related to a problem? Please describe.
The current reliance on OpenAI for vision models poses limitations and concerns regarding accessibility and transparency due to its proprietary nature.
Describe the solution you'd like
I propose integrating an open-source vision model into the project to replace the dependency on OpenAI. This solution would ensure greater accessibility, transparency, and long-term sustainability.
Describe alternatives you've considered
Alternative solutions include continuing to use OpenAI, but this maintains the issues of proprietary technology and potential barriers to access for users. Another option is developing a custom vision model, but this could be time-consuming and resource-intensive.
Additional context
Incorporating an open-source vision model aligns with the principles of open access and transparency, fostering community engagement and innovation. It offers benefits such as greater customization, flexibility, and trust within the user community.

That is the plan. Thank you ashan3219

Hi @ahsan3219 @Real-Experienes  there is an open-source model available to use in the project. Check out the Llava section in the README.md: https://github.com/OthersideAI/self-operating-computer?tab=readme-ov-file#locally-hosted-llava-through-ollama.
Let me know if you have any questions about it!

@joshbickett
It is only for Linux and macOS. No option available for windows

@ahsan3219, oh ok. We can reopen this issue in that case. I noticed it didn't mention Windows specifically in the initial issue creation. It may be helpful to create a new issue that mentions Windows specifically so that the open-source community can quickly understand and address this issue specifically

Hi @ahsan3219 @Real-Experienes  there is an open-source model available to use in the project. Check out the Llava section in the README.md: https://github.com/OthersideAI/self-operating-computer?tab=readme-ov-file#locally-hosted-llava-through-ollama.
Let me know if you have any questions about it!

Thanks @joshbickett !! I'm on it!


API — Input Validation Not Validating

There seems to be some gaps in the input validation when posts include HTML. When originally posting this Quotation the embedded code was not scrubbed out.
This is clearly a problem, as it bypassed the existing checks that look for <script> tags. A better validator will be required.

Done and done. Input is validated a little more intelligently, though there's still room for improvement.
Closing Ticket.


[Map] DM-Hell_Raisers_Caverns

Hash: d8ccdb3932c77c0cf54fd00ab7ba0acfccfbb018
Current name: DM-Hell_Raisers_Caverns
From the readme, the author's name is Francois Lacombe
He also used the aliases
Orion(Co30)
Mouse(Co30)
and these may appear in various combinations with  Francois Lacombe

Fixed with an aliases file for the author.


feat(asset): allow non-existent url

Description
Fixes #4308
Allow non-existent urls in new URL(..., import.meta.url) if it needs to be resolved in runtime.
Additional context

What is the purpose of this pull request?

[ ] Bug fix
[x] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

The issue I see is that we are no longer going to inform the user of typos when building the app. How usual it is to have URL that aren't known during build time? I think that we should allow them, but maybe we could log a message for them? Something like:
{nonExistentUrl} doesn't exist at build time, it will remain unchanged to be resolved at runtime

That's sounds like a fair thing to do. If someone wants to turn that off, we could explore vite-ignore in the future too.

Added a log. It doesn't look that great:
vite v2.9.0-beta.0 building for production...
transforming (1) index.htmlnew URL('non-existent', import.meta.url) doesn't exist at build time, it will remain unchanged to be resolved at runtime
✓ 20 modules transformed.
dist/foo/assets/asset.b9f46fb3.png            12.47 KiB
dist/foo/assets/fragment.d2571ff2.svg         1.11 KiB
dist/foo/assets/Inter-Italic.bab4e808.woff2   105.64 KiB
dist/foo/assets/fragment-bg.c8ba701c.svg      1.13 KiB
dist/foo/assets/Inter-Italic.7b187d57.woff    140.11 KiB
dist/foo/index.html                           20.05 KiB
dist/foo/manifest.json                        0.38 KiB
dist/foo/assets/index.70c90341.js             12.41 KiB / gzip: 4.92 KiB
dist/foo/assets/index.69eb903c.css            19.58 KiB / gzip: 3.90 KiB

It doesn't go in a new line, and I don't think there's a pattern like this too in the codebase (?). Perhaps this is still acceptable.

Uh, merged before seeing your comment, we should later fix the new line


Only raise leaked widgets errors in tests if no other exception was raised

Description
People seem to gravitate to the "leaked widgets" error in tests, before looking at other test errors.  And if another exception has occurred,  widget cleanup fails and leaks tend to happen.  Point is, leaked widgets don't matter if you had other errors... This PR makes it so that leaked widget errors only get raised if no other error was raised in the test

Looks like the current test fails here will be fixed by #2044, I'll can get that merged and then we update this PR accordingly.


WIP: feat: server use exclusive poll

What type of PR is this?

What this PR does / why we need it (en: English/zh: Chinese):

en:
zh:
Which issue(s) this PR fixes:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


accessToken is not a valid jwt?

First off, to even get accessToken to be defined, you have to pass just true into the useAuth hook. Passing in an object with audience doesn't appear to have any effect. Even when accessToken IS defined, it isn't a valid jwt, so you can't use it as a Bearer token in any API calls to other Auth0-wrapped backends. Is this library supposed to be production ready?

It should work when you pass useAuth({audience:"YOUR-API-AUDIENCE",scope:""}), where "YOUR-API-AUDIENCE" is a custom API, which you made in Auth0. So the application settings alone won't generate a valid jwt access token but an opaque access token. If you define the audience to be your custom api, then auth0 will send you a valid jwt access token.
Read it here: https://auth0.com/docs/tokens/guides/get-access-tokens


cards service

In GitLab by @lakhoune on May 18, 2020, 24:27
make cards service independant from http service

In GitLab by @lakhoune on May 18, 2020, 10:29
assigned to @lakhoune

In GitLab by @lakhoune on May 18, 2020, 10:52
mentioned in commit 4542a60073746d748e6e08fc2a5cbae0d8d73d9b

In GitLab by @lakhoune on May 18, 2020, 10:53
closed


DevToys 2.0 Preview UI bug: title bar overlapping with app name and "Back button"

Current behavior
When focused (light and dark Windows modes respectively):

When not focused:

This is only an UI issue - the "Back" button is working, even if the upper part, overlapping with the title bar, is clicked
How to reproduce it (as minimally and precisely as possible)
OS: Windows 11.

Enable the "Show accent color on title bars and windows borders" option in Settings -> Personalization -> Colors.
Open DevToys 2.0 Preview.
Look at the top left corner of the app. Focus and unfocus the app to see the difference.

Expected behavior
App name "DevToys" slightly upper, entirely on the title bar.
"Back" ( [<-] ) button slightly lower, entirely below the title bar. It can be moved down, but it would require moving the "Menu" button ( [≡] ) and the menu itself down too.
Screenshots
No response
Workaround
No response
Affected platforms
Windows
Affected DevToys kind
DevToys (app with GUI)
DevToys Version
Version 2.0-preview.2
Relevant Assets/Logs
No response

Duplicate with #1228


Add image dimensions

Would it be possible to add the image dimensions when adding the img tags?

Of course, I will do it!

Ready


'load_diffusion_model_state_dict

got prompt
[rgthree] Using rgthree's optimized recursive execution.
[rgthree]
First run patching recursive_output_delete_if_changed and recursive_will_execute.
[rgthree] Note: If execution seems broken due to forward ComfyUI changes, you can disable the optimization from rgthree settings in ComfyUI.
[Impact Pack] Wildcards loading done.
[Impact Pack] Wildcards loading done.
[Impact Pack] Wildcards loading done.
[Impact Pack] Wildcards loading done.
[Impact Pack] Wildcards loading done.
Using xformers attention in VAE
Using xformers attention in VAE
D:\ComfyUI-aki-v1.3\custom_nodes\ComfyUI-GGUF\ops.py:21: UserWarning: The given NumPy array is not writable, and PyTorch does not support non-writable tensors. This means writing to this tensor will result in undefined behavior. You may want to copy the array to protect its data or make it writable before converting it to a tensor. This type of warning will be suppressed for the rest of this program. (Triggered internally at ..\torch\csrc\utils\tensor_numpy.cpp:212.)
data = torch.from_numpy(tensor.data)
ggml_sd_loader:
GGMLQuantizationType.F16      476
GGMLQuantizationType.Q4_0     304
!!! Exception during processing!!! module 'comfy.sd' has no attribute 'load_diffusion_model_state_dict'
Traceback (most recent call last):
File "D:\ComfyUI-aki-v1.3\execution.py", line 152, in recursive_execute
output_data, output_ui = get_output_data(obj, input_data_all)
File "D:\ComfyUI-aki-v1.3\execution.py", line 82, in get_output_data
return_values = map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True)
File "D:\ComfyUI-aki-v1.3\execution.py", line 75, in map_node_over_list
results.append(getattr(obj, func)(**slice_dict(input_data_all, i)))
File "D:\ComfyUI-aki-v1.3\custom_nodes\ComfyUI-GGUF\nodes.py", line 51, in load_unet
model = comfy.sd.load_diffusion_model_state_dict(
AttributeError: module 'comfy.sd' has no attribute 'load_diffusion_model_state_dict'
提示：Python 运行时抛出了一个异常。请检查疑难解答页面。
Prompt execu
Thanks sir, how can I solve this problem?

Update ComfyUI

As @Fannovel16 says above, you need to be on a recent enough version to support those changes - this is also mentioned in the readme:

Make sure your ComfyUI is on a recent-enough version to support custom ops when loading the UNET-only.


README cleanups

Mostly just wanted to fix up the URL for filing an issue, but took the opportunity to do a few other copy-edits and remove some old stuff.

/cc @albertinad

Great! thanks!


Change direction API to have chaining options

Resolved by https://github.com/ember-theater/ember-theater/commit/bbd2452b0fc2837793ed9715cbc99c4e4eba0a40


Improve reproducibility of the workflows

[ ] instead of pulling the latest docker images, we should use SHA, and ideally tags, to ensure the same version of the image is used
[ ] workflows currently refer to the notebooks from "main" branch; instead we should use git tags and refer to tagged notebooks
[ ] parameterize papermill with the variable to pass the tag, and refer to the tagged versions of the artifacts from the notebook
[ ] remove all branches from the repository so that the users of Dockstore are not confused
[ ] before running the analysis, create a new release/tag, and use the specific Dockstore workflow releases for the run

We can also consider encoding the specific version of the workflow in the SEG/SR objects created, but I want to discuss this with David C first.

workflows currently refer to the notebooks from "main" branch; instead we should use git tags and refer to tagged notebooks
parameterize papermill with the variable to pass the tag, and refer to the tagged versions of the artifacts from the notebook

@vkt1414 I thought about this, and here's how I think we could do it:

for non-tagged releases, just use "main"
whenever we want to have a tagged release, rewrite all URLs to substitute "main" with the planned tag name, make a commit, and then tag that commit with the name that was used during rewriting URLs.
on the following commit after the tagged one, rewrite the URLs again to use "main"
instead of checking out individual artifacts from URLs in the notebooks, add a variable that would be initialized to "main" or tag name at the top of the notebook, check out the entire repository using main or tag, and refer to the files from the checked out repository tree in the following cells. This way we can get a bit close to versioning notebooks when they are executed outside of papermill.

If you have better ideas, let's discuss here before implementing!

I do not have a complete plan yet but two things worry about the workflow you suggested.
We use URLs at a lot of places. Links to image sources and config files in notebooks, and links to the notebooks in the wdl and cwl files. Chaning them manually I think poses a lot of room for errors, especially when I revisit the repo after a few months of no activity.
Secondly, I'm wary about cloning the entire git repo as we will be running thousands of workflows in parallel and that would mean we rely even more on github. We never faced an issue so far with individual artifacts but I do not think it may be a good idea.
What I have in mind currently is to use a github action that can take care of updating the branch/tag references. We already have bits and pieces of this in several repos now (idc-index, browser, and tutorials) and it should not take a while to come up with one.
The gha should recognize tag and run a python script that will use a regex express to identify main branch and replace them with the tag. Otherwise, we always refer to main branch as you also suggested.
What are your thoughts?

Chaning them manually I think poses a lot of room for errors

I agree - I didn't mean to do it manually, it can be done with a script.

What I have in mind currently is to use a github action that can take care of updating the branch/tag references. We already have bits and pieces of this in several repos now (idc-index, browser, and tutorials) and it should not take a while to come up with one.

For this kind of tasks, I think it is easier to have a script that can be run locally, and then whoever ran it an easily review all the changes and confirm that modifications make sense.


Vercel and Sentry configurations for the Dictionary project

https://github.com/raviqqe/dictionary

Superseded by #45, #47, and #44.


Boid getBoid(int i) should return a reference not a copy.

 Boid getBoid(int i); returns a copy of the boid which makes it impossible change. If this was intended maybe adding a getter for both read only and read/write would be good.
should be:
 Boid &getBoid(int i);
with the definition being:
Boid &Flock::getBoid(int i)
{
    return flock[i];
}

To be honest, Flock::getBoid() should not even exist, because the vector<Boid> flock is anyways public.

To be honest, Flock::getBoid() should not even exist, because vector<Boid> flock is anyways public.

Right but the issue is its used elsewhere in the code. So it should be made private along with the suggested code above.

I understand where you are coming from, but when I see the code, all the uses of getBoid() are valid, because none of them is trying to modify the returned boid. Returning unnecessary copies is bad, but returning a non-const reference to internal data is worst IMHO.
But in any case, since you already know what you want, maybe you should create a pull-request with the change you are suggesting. Maintainer are the best judge for such changes.

To be honest, Flock::getBoid() should not even exist, because vector<Boid> flock is anyways public.

Right but the issue is its used elsewhere in the code. So it should be made private along with the suggested code above.

Btw, I am working on re-creating this project with better architecture here: https://github.com/ufrshubham/Boids-SFML

To be honest, Flock::getBoid() should not even exist, because vector<Boid> flock is anyways public.

Right but the issue is its used elsewhere in the code. So it should be made private along with the suggested code above.

Btw, I am working on re-creating this project with better architecture here: https://github.com/ufrshubham/Boids-SFML

Awesome. I think it would be cool to some food to the simulation also. I'm using this project as part of a larger evolution style project that I am working on. The biggest issue I have with this project is the movement. I think a better way to structure the Boid movement would be to have a flock leader and align the direction of all bonds to that leader and allow the leader a larger scope for movement. As it stands right now, the bonds move in the same direction and rarely change to go in the opposite direction.

Hey, thanks for the comments. This project was originally made in college while first learning C++ so there's a lot of noob mistakes. I personally have no issues with refactoring code or reviewing pull requests as long as it improves the codebase :)

Hey, thanks for the comments. This project was originally made in college while first learning C++ so there's a lot of noob mistakes. I personally have no issues with refactoring code or reviewing pull requests as long as it improves the codebase :)

Awesome. Sounds good. It's a nice project. I'm using it right now for an evolution based simulation I'm working on. I'll send you the link to the project when it's done. I've added credits to each of my headers file linking to the code of yours that I've used.

Yep, thanks for adding these small fix-ups. Sorry about the delay, the end of the semester is always a crazy time. Will merge your pull request. #4


Minor issue: classic-omnibox adds shadows to context menus

Describe the bug
Minor issue: if #classic-omnibox is enabled, main menu and context menus start looking suspiciously similar to those in win11.
To Reproduce
Steps to reproduce the behavior:

Enable #classic-omnibox
Context menus have rounded corners and shadows

Expected behavior
Context menu design should still stay the same. If not, the flag description probably could indicate that it also changes context menu design, or an additional flag could be included to give design choice.
Screenshots

Desktop (please complete the following information):

OS: Windows 10 22H2
64 bit
122.0.6261.152 (R4)

I will split the context menu corner radius from the omnibox address bar/suggestion area radius.


fix(ui): authentication-03 input classNames

Correct Tailwindcss classes for input with label

same as #3101

same as #3101


Can't compile 2.3.x no GDAL C++ Library

Whoops posted this in the wrong spot...
just ignore this and I will close it...

closed now


benchmark of validx library

Comparing similar libraries is encouraged on pydantic benchmark page https://pydantic-docs.helpmanual.io/benchmarks/
Change Summary

test_validx.py added to compare performance of validx library against pydantic
datetime.now() replaced by time.perf_counter (see https://docs.python.org/3/library/time.html#time.perf_counter)

Related issue number
closes #1816
Checklist

[x] Unit tests for the changes exist
[x] Tests pass on CI and coverage remains at 100%
[x] Documentation reflects the changes where applicable
[x] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)

Sorry for the slow response, and sorry to disappoint, but  I'm afraid I'm not accepting benchmarks for libraries that are significantly less popular than pydantic itself, see https://github.com/samuelcolvin/pydantic/issues/1939#issuecomment-695799667 for an explanation, see also #1525.
Now that I've made that rule and refused a number of other libraries, I can't really accept validx.

happy to accept a tweak to the wording on the benchmarks page to make this clear, so people don't waste their time.
I feel really bad closing pull requests like this.


Right click on bar throws error

A freshly installed addon throws following error when I right-click the bar:
Message: Interface\AddOns\Experiencer\modules\reputation.lua:488: bad argument #1 to 'tinsert' (table expected, got nil)
Time: Mon Jul 31 08:50:06 2017
Count: 1
Stack: Interface\AddOns\Experiencer\modules\reputation.lua:488: bad argument #1 to 'tinsert' (table expected, got nil)Interface\SharedXML\SharedBasicControls.lua:204: in function `origErrorHandler'
...rface\AddOns\TradeSkillMaster\Debug\ErrorHandler.lua:317: in function <...rface\AddOns\TradeSkillMaster\Debug\ErrorHandler.lua:300>
[C]: ?
[C]: in function `tinsert'
Interface\AddOns\Experiencer\modules\reputation.lua:488: in function `GetReputationsMenu'
Interface\AddOns\Experiencer\modules\reputation.lua:372: in function `GetOptionsMenu'
Interface\AddOns\Experiencer\core.lua:1243: in function `OpenContextMenu'
Interface\AddOns\Experiencer\core.lua:1309: in function <Interface\AddOns\Experiencer\core.lua:1285>

Locals: errorMessage = "Interface\AddOns\Experiencer\modules\reputation.lua:488: bad argument #1 to 'tinsert' (table expected, got nil)"
DisplayMessageInternal = <function> defined @Interface\SharedXML\SharedBasicControls.lua:187
MESSAGE_TYPE_ERROR = 0

Seems there is an error with reputation menu generation logic.
What reputations does your character have, is it a brand new character? It's a little weird that I haven't encountered this myself yet.

I created a new character which is now level 2. After that, I installed experiencer and got the error.
As you suspected, the error doesn't occur with "older" characters.
Thanks for the tip, I can now configure it while logged in with another character! :-)

Trying to replicate the error, what was the character in question, like the race and the class?

It was a Tauren Druid. The problem still occurs now, I'm level 11...
2017-07-31 21:00 GMT+02:00 Sonaza<EMAIL_ADDRESS>
Trying to replicate the error, what was the character in question, like
the race and the class?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Sonaza/Experiencer/issues/8#issuecomment-319164248,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADSVlDD4aJj36oVw4iyR3bVLVwdItotDks5sTiRTgaJpZM4On97C
.

Seems the error is related to weird reputation category listing on the tauren character. API says a reputation category header is a subheader when the primary header is still missing. What I mean, when you discover more factions the "Classic" category header will appear and will separate reputations from later expansions.
It is fixable when I have the time to look into it but as a temporary fix you could try and see if discovering new "non-classic" reputations will help for the time being.

The problem went away around level 12 I think, so I don't see this as a
major bug...
2017-08-02 8:48 GMT+02:00 Sonaza<EMAIL_ADDRESS>
Seems the error is related to weird reputation category listing on the
tauren character. API says a reputation category header is a subheader when
the primary header is still missing. What I mean, when you discover more
factions the "Classic" category header will appear and will separate
reputations from later expansions.
It is fixable when I have the time to look into it but as a temporary fix
you could try and see if discovering new "non-classic" reputations will
help for the time being.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Sonaza/Experiencer/issues/8#issuecomment-319583632,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADSVlEuC9_LvJ1V-1CYwj6ofTEfdi6mfks5sUBu3gaJpZM4On97C
.

Fixed this in update 2.3.1 now.


Multiple git hooks of same type; predefined hooks

Feature Description
This is really a two-part request, but I'd imagine their incorporation would be changing much of the same code.
Multiple same-type git hooks
It is beneficial to be able to create/specify multiple git hooks of the same type (such as gitolite) - this would change the "Git Hooks" configuration options for a repository to contain an orderable list for each hook type supported, and each item in the list would be a specific hook. Hooks would be executed in their specified order upon the relevant action being triggered.
Predefined hooks
Often one may want to define a hook once and then be able to use it for multiple (but not all) repositories. Currently this necessitates copying the hook to each repository - this is particularly a high maintenance cost. Using the concept of system-wide (or perhaps org-wide) git hooks, it allows for changing the hook/maintaining it in a single place and have all usages of it updated at once by reference.
Screenshots
No response

Whoa. I just started using gitolite myself as an alternative git server and, despite it taking a bit to get going (the docs are really well done, just requires a substantial amount of reading and possible rage when you make a mistake that breaks it), once I got it going, I found that using a cron job to push to it on timer as a backup was the route I had to go. This would honestly be a great addition. Good luck

I think this exists now?

Is this very new? Did this not exist last year?

Apparently this was added in #10546, a few years ago now.

I think he means git hooks but not webhooks.


blockName input is unnecessarily small

Payload Version: 1.2.1.
This is super minor, but when adding a new block, the auto-generated blockName input is pretty small and does not expand as the input does. This makes it hard to enter and edit medium-to-long sized titles. (And to get even more nit-picky, it's not vertically aligned with the other items in the section header :)

@zerovox, can you give me a sample config to recreate this issue? I am unable to replicate on my end.
What browser? What OS?

Ah, Firefox on Windows. This config repros for me:
const QuoteBlock: Block = {
  slug: "quote",
  fields: [
    {
      name: "quote",
      type: "richText",
    },
  ],
};

const Thing: CollectionConfig = {
  slug: "thing",
  access: {
    read: () => true,
  },
  fields: [
    {
      name: "extracts",
      type: "blocks",
      minRows: 0,
      blocks: [QuoteBlock],
    },
  ],
};

export default Thing;

In Safari (at least v16.4) we still need this:
.blocks-field__block-header {
    width: 100%;
}
.section-title {
    flex-grow: 1;
}


Instantiate Column and Row with children

Instantiate a Column or a Row with children. A compliment to the existing push functions.
Duplicates the default values of the new function, save for children.

Great changes. Thank you 🎉


Updated and organised Readme

Updated the Readme. Now it looks better.
closes #2

updaTED SOME NEW THINGS


Add a way to tests logs

Currently, logs are tested by comparing with == two strings (generated logs and expected logs), which makes it quite hard to debug.
It think we should implement a thing to parse the logs, so when performing a comparison one would be able to precisely knwo what differ (i:e which line, etc) between two logs.
Or maybe we should save logs to a JSON/CSV file, to make it even easier.
Thoughts ?

Ooof parsing logs is a Whole Thing.
My suggestion for now would be to compare certain properties of the log files instead of just comparing the strings. I would start by comparing the number of lines and the text without whitespace.
Other than that, if a comparison with == fails, we can output a prettier diff rather than pytest's ugly stacktrace.
On top of that... I feel like parsing logs is going to become a real chore. Unless there's a ready-made library that can handle this for us, I'd be weary of going there.

I agree, but if we could parse logs before the output for example with a logger or rich option, it would be very good.

Other than that, if a comparison with == fails, we can output a prettier diff rather than pytest's ugly stacktrace.

Yes, we could do that, although it can quickly become a mess with all the regex.

Closing in favour of #365


feat: update to track latest spec changes

Automated changes after Neon spec has been updated

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


⚠ Turnos 24x7 has degraded performance

In 88e7f54, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 1129 ms

Resolved: Turnos 24x7 performance has improved in 27d53e0.


Call to a member function processInsertGetId() on null

Which may be the source of this error?

try $insertar->save() and return, and does not work...

I needed the \ Orientdb in the model, but now I have another error:

Which Laravel version you are using ?

I am using, Laravel 5.2.31

This is also my issue now. I don't know why. We have the same issue with gburu98.
At first I also have that processInsertGetId issue but then I just changed it to "extends \Orientdb" and everything went well. But then this simplePaginate becomes the new issue. Any help guys?

Ok, so I already solved it! I'm using windows and my laravel version is 5.3 (it also works on version 5.2)
Go to this file: vendor\sgpatil\oriquent\src\Sgpatil\Orientdb\Eloquent\Builder.php
Line: 371 paste the code below
public function simplePaginate($perPage = null, $columns = ['*'], $pageName = 'page', $page = null)
So basically, what I did was to add the $page=null on the parameter. Hope this helps anyone

Closing this as the issue has been resolved in latest release.


PR: Update Changelog, Announcements and metadata files for 6.0.2

Issue(s) Resolved

Fixes #22751
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: dalthviz

@meeseeksdev please backport to 6.x