ServiceBus: AMQP Body - Data only

These are the changes I made for multiple AMQP body types, except I removed all the logic related to multiple body types. So, it only contains the logic for cleaning up Data body processing.

/azp run net - servicebus - tests

I removed too much code. Lol. I forgot that the original receiver logic did parse both Data body and Value body. So, I need at minimum those body types.


Respect HTTP Cache-Control

Cache control is not respected for files in $XDG_CACHE_HOME/youtube-viewer - probably causing problems like #70
Example headers of a request that should never be cached to disk (edited for brevity):
https://www.googleapis.com/youtube/v3/playlistItems?key=redacted&maxResults=1&part=contentDetails,snippet&playlistId=redacted&prettyPrint=false
HTTP/1.1 200 OK
Cache-Control: private, max-age=0, must-revalidate, no-transform
ETag: "redacted"
[...]

And an image that should be cached for a specific time:
https://i.ytimg.com/vi/-YaohNgQcY8/mqdefault.jpg
HTTP/1.1 200 OK
Cache-Control: public, max-age=21600
Expires: Thu, 07 May 2015 03:06:49 GMT
Last-Modified: Thu, 01 Jan 1970 00:23:50 GMT
[...]

This issue is a must-fix. I will look into it as soon as possible. Thanks for the report.

Fixed here: https://github.com/trizen/youtube-viewer/commit/38649068926a02c6161fc23a94c9acaf0f309e38


support match groups

As a user of search I would like to be able to take advantage of match groups for more sophisticated searches.  Add Group structure to the returned data structure and populate it from the matches.

https://github.com/imagibee/Gigantor/pull/50


[feat] Implement the functionality of updateProfileMetadata

Down below is the function that is to be implemented in the contract but in cairo.
https://github.com/allo-protocol/allo-v2/blob/4dd0ea34a504a16ac90e80f49a5570b8be9b30e9/contracts/core/Registry.sol#L214C14-L214C35
Resources :
https://book.cairo-lang.org/title-page.html
https://book.cairo-lang.org/ch16-02-02-component-dependencies.html?highlight=compo#component-dependencies
If you have any doubts over on how to implement something similar to this you can try discovering few cairo code bases such as :
Unruggable memecoin : https://github.com/keep-starknet-strange/unruggable.meme/tree/main/packages/contracts/src
Blobstream : https://github.com/keep-starknet-strange/blobstream-starknet/tree/main/src
Exclusively for Starknet India team - To onboard new devs from India
Estimated Time taken to complete - 2-3 days (Max)

can i take this?

Yeah sure, you've been assigned. Less go !

Hey Akash,
I want to try this.


Updated max_retries and timeout params

Updated code for separate the connection timeout with the requests' timeout https://github.com/bulkan/robotframework-requests/issues/60
max_retries code taken from add max_retries support https://github.com/bulkan/robotframework-requests/pull/59

@bulkan Any comments on this PR?

@bulkan Any updates?

Cheers !


cmd/go: trim build cache incrementally

Can't reproduce reliably, but...
After running go test, I am sometimes seeing the test complete successfully (prints "ok ... pkg ... time"), and then it appears to hang for an indefinite period of time. Sending SIGINT does not terminate the process. Sending SIGTERM does. This happens with std lib tests (strings, crypto/x509). Each time I passed the -v flag, although I'm not sure that that is necessary. Using commit 5c13cab36b4667cc1a42667b16b8f049016586e0. This behavior is new, although this is the first time I've run tests in a few days or a week. And it doesn't reproduce 100%, so it's a bit muddled.
I attached lldb to two hung binaries and got similar backtraces from each.

First backtrace

$ lldb -p 55409
(lldb) process attach --pid 55409
Process 55409 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait:
->  0x7fff71de4ce6 <+10>: jae    0x7fff71de4cf0            ; <+20>
    0x7fff71de4ce8 <+12>: movq   %rax, %rdi
    0x7fff71de4ceb <+15>: jmp    0x7fff71de2a89            ; cerror_nocancel
    0x7fff71de4cf0 <+20>: retq
Target 0: (go) stopped.
Executable module set to "/Users/josh/go/tip/bin/go".
Architecture set to: x86_64h-apple-macosx-.
(lldb) bt

thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib__psynch_cvwait + 10 frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib_pthread_cond_wait + 701
frame #2: 0x000000000106ceb0 goruntime.pthread_cond_wait_trampoline + 16 frame #3: 0x000000000106ad8d goruntime.asmcgocall + 173
frame #4: 0x0000000001054c0c goruntime.libcCall + 108 frame #5: 0x00000000010557d9 goruntime.pthread_cond_wait + 57
frame #6: 0x0000000001032dcd goruntime.semasleep + 141 frame #7: 0x000000000100dca7 goruntime.notesleep + 231
frame #8: 0x000000000103c9a5 goruntime.stopm + 197 frame #9: 0x000000000103e15f goruntime.findrunnable + 2687
frame #10: 0x000000000103edd7 goruntime.schedule + 727 frame #11: 0x000000000103f37d goruntime.park_m + 157
frame #12: 0x000000000106933b goruntime.mcall + 91 frame #13: 0x00000000010557d9 goruntime.pthread_cond_wait + 57
frame #14: 0x0000000001032dcd goruntime.semasleep + 141 frame #15: 0x000000000100dca7 goruntime.notesleep + 231
frame #16: 0x000000000103c9a5 goruntime.stopm + 197 frame #17: 0x000000000103e15f goruntime.findrunnable + 2687
frame #18: 0x000000000103edd7 goruntime.schedule + 727 frame #19: 0x000000000103f37d goruntime.park_m + 157
frame #20: 0x000000000106933b goruntime.mcall + 91 frame #21: 0x0000000001032dcd goruntime.semasleep + 141
frame #22: 0x000000000100dca7 goruntime.notesleep + 231 frame #23: 0x000000000103c9a5 goruntime.stopm + 197
frame #24: 0x000000000103e15f goruntime.findrunnable + 2687 frame #25: 0x000000000103edd7 goruntime.schedule + 727
frame #26: 0x000000000103f37d goruntime.park_m + 157 frame #27: 0x000000000106933b goruntime.mcall + 91
frame #28: 0x000000000100dca7 goruntime.notesleep + 231 frame #29: 0x000000000103c9a5 goruntime.stopm + 197
frame #30: 0x000000000103e15f goruntime.findrunnable + 2687 frame #31: 0x000000000103edd7 goruntime.schedule + 727
frame #32: 0x000000000103f37d goruntime.park_m + 157 frame #33: 0x000000000106933b goruntime.mcall + 91
frame #34: 0x000000000103c9a5 goruntime.stopm + 197 frame #35: 0x000000000103e15f goruntime.findrunnable + 2687
frame #36: 0x000000000103edd7 goruntime.schedule + 727 frame #37: 0x000000000103f37d goruntime.park_m + 157
frame #38: 0x000000000106933b goruntime.mcall + 91 frame #39: 0x000000000103e15f goruntime.findrunnable + 2687
frame #40: 0x000000000103edd7 goruntime.schedule + 727 frame #41: 0x000000000103f37d goruntime.park_m + 157
frame #42: 0x000000000106933b goruntime.mcall + 91 frame #43: 0x000000000103edd7 goruntime.schedule + 727
frame #44: 0x000000000103f37d goruntime.park_m + 157 frame #45: 0x000000000106933b goruntime.mcall + 91
frame #46: 0x000000000103f37d goruntime.park_m + 157 frame #47: 0x000000000106933b goruntime.mcall + 91
frame #48: 0x000000000106933b goruntime.mcall + 91 frame #49: 0x000000000101edff goruntime.gcBgMarkWorker + 255
frame #50: 0x000000000106b121 goruntime.goexit + 1 frame #51: 0x000000000106b121 goruntime.goexit + 1
(lldb) ^D

Second backtrace

$ lldb -p 55473
(lldb) process attach --pid 55473
Process 55473 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait:
->  0x7fff71de4ce6 <+10>: jae    0x7fff71de4cf0            ; <+20>
    0x7fff71de4ce8 <+12>: movq   %rax, %rdi
    0x7fff71de4ceb <+15>: jmp    0x7fff71de2a89            ; cerror_nocancel
    0x7fff71de4cf0 <+20>: retq
Target 0: (go) stopped.
Executable module set to "/Users/josh/go/tip/bin/go".
Architecture set to: x86_64h-apple-macosx-.
(lldb) bt

thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib__psynch_cvwait + 10 frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib_pthread_cond_wait + 701
frame #2: 0x000000000106ceb0 goruntime.pthread_cond_wait_trampoline + 16 frame #3: 0x000000000106ad8d goruntime.asmcgocall + 173
frame #4: 0x0000000001054c0c goruntime.libcCall + 108 frame #5: 0x00000000010557d9 goruntime.pthread_cond_wait + 57
frame #6: 0x0000000001032dcd goruntime.semasleep + 141 frame #7: 0x000000000100dca7 goruntime.notesleep + 231
frame #8: 0x000000000103c9a5 goruntime.stopm + 197 frame #9: 0x000000000103e15f goruntime.findrunnable + 2687
frame #10: 0x000000000103edd7 goruntime.schedule + 727 frame #11: 0x000000000103f37d goruntime.park_m + 157
frame #12: 0x000000000106933b goruntime.mcall + 91 frame #13: 0x00000000010557d9 goruntime.pthread_cond_wait + 57
frame #14: 0x0000000001032dcd goruntime.semasleep + 141 frame #15: 0x000000000100dca7 goruntime.notesleep + 231
frame #16: 0x000000000103c9a5 goruntime.stopm + 197 frame #17: 0x000000000103e15f goruntime.findrunnable + 2687
frame #18: 0x000000000103edd7 goruntime.schedule + 727 frame #19: 0x000000000103f37d goruntime.park_m + 157
frame #20: 0x000000000106933b goruntime.mcall + 91 frame #21: 0x0000000001032dcd goruntime.semasleep + 141
frame #22: 0x000000000100dca7 goruntime.notesleep + 231 frame #23: 0x000000000103c9a5 goruntime.stopm + 197
frame #24: 0x000000000103e15f goruntime.findrunnable + 2687 frame #25: 0x000000000103edd7 goruntime.schedule + 727
frame #26: 0x000000000103f37d goruntime.park_m + 157 frame #27: 0x000000000106933b goruntime.mcall + 91
frame #28: 0x000000000100dca7 goruntime.notesleep + 231 frame #29: 0x000000000103c9a5 goruntime.stopm + 197
frame #30: 0x000000000103e15f goruntime.findrunnable + 2687 frame #31: 0x000000000103edd7 goruntime.schedule + 727
frame #32: 0x000000000103f37d goruntime.park_m + 157 frame #33: 0x000000000106933b goruntime.mcall + 91
frame #34: 0x000000000103c9a5 goruntime.stopm + 197 frame #35: 0x000000000103e15f goruntime.findrunnable + 2687
frame #36: 0x000000000103edd7 goruntime.schedule + 727 frame #37: 0x000000000103f37d goruntime.park_m + 157
frame #38: 0x000000000106933b goruntime.mcall + 91 frame #39: 0x000000000103e15f goruntime.findrunnable + 2687
frame #40: 0x000000000103edd7 goruntime.schedule + 727 frame #41: 0x000000000103f37d goruntime.park_m + 157
frame #42: 0x000000000106933b goruntime.mcall + 91 frame #43: 0x000000000103edd7 goruntime.schedule + 727
frame #44: 0x000000000103f37d goruntime.park_m + 157 frame #45: 0x000000000106933b goruntime.mcall + 91
frame #46: 0x000000000103f37d goruntime.park_m + 157 frame #47: 0x000000000106933b goruntime.mcall + 91
frame #48: 0x000000000106933b goruntime.mcall + 91 frame #49: 0x000000000101edff goruntime.gcBgMarkWorker + 255
frame #50: 0x000000000106b121 goruntime.goexit + 1 frame #51: 0x000000000106b121 goruntime.goexit + 1
(lldb) ^D

Interesting.  Those backtraces are normal and just show a thread that has no goroutines to run.  The next time this happens can you get backtraces from the other threads?

Also, go test builds a test binary and runs it.  Is it the test binary that is hanging, or the cmd/go binary?  If the test binary, can you repeat it using go test -c and running the test binary directly?  Thanks.

I haven’t been able to reproduce since. I’ll keep trying.

This happened again. Some new information:

When this happens, it appears to be a systemwide bad state that affects all invocations of cmd/go, including different Go versions. (I tried 1.14.2 and tip.)  Given that the hang is at the end of executing the tests, this all suggests to me some sort of lock or contention writing to a shared resource, probably the build cache.

This does eventually resolve itself, if you wait long enough. Here's the end of a run of go test -v strings:

=== RUN   ExampleBuilder
--- PASS: ExampleBuilder (0.00s)
PASS
ok  	strings	1.917s
go test -v strings 10.67s user 48.31s system 37% cpu 2:38.10 total 83360 maxrss

The last line is from zsh, via REPORTTIME, with TIMEFMT set to '%J %U user %S system %P cpu %*E total %M maxrss'.
Observe that the test took ~2s to run, but according to the shell the process was alive well over 2 minutes.

I asked lldb to bt all a hung go test -c strings process. Results:

bt all
(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x00000000010557ac go`runtime.libcCall + 108
    frame #5: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #6: 0x00000000010335ed go`runtime.semasleep + 141
    frame #7: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #8: 0x000000000103d325 go`runtime.stopm + 197
    frame #9: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #10: 0x000000000103f717 go`runtime.schedule + 727
    frame #11: 0x000000000103fcbd go`runtime.park_m + 157
    frame #12: 0x000000000106a2bb go`runtime.mcall + 91
    frame #13: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #14: 0x00000000010335ed go`runtime.semasleep + 141
    frame #15: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #16: 0x000000000103d325 go`runtime.stopm + 197
    frame #17: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #18: 0x000000000103f717 go`runtime.schedule + 727
    frame #19: 0x000000000103fcbd go`runtime.park_m + 157
    frame #20: 0x000000000106a2bb go`runtime.mcall + 91
    frame #21: 0x00000000010335ed go`runtime.semasleep + 141
    frame #22: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #23: 0x000000000103d325 go`runtime.stopm + 197
    frame #24: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #25: 0x000000000103f717 go`runtime.schedule + 727
    frame #26: 0x000000000103fcbd go`runtime.park_m + 157
    frame #27: 0x000000000106a2bb go`runtime.mcall + 91
    frame #28: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #29: 0x000000000103d325 go`runtime.stopm + 197
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103d325 go`runtime.stopm + 197
    frame #35: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #36: 0x000000000103f717 go`runtime.schedule + 727
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #40: 0x000000000103f717 go`runtime.schedule + 727
    frame #41: 0x000000000103fcbd go`runtime.park_m + 157
    frame #42: 0x000000000106a2bb go`runtime.mcall + 91
    frame #43: 0x000000000103f717 go`runtime.schedule + 727
    frame #44: 0x000000000103fcbd go`runtime.park_m + 157
    frame #45: 0x000000000106a2bb go`runtime.mcall + 91
    frame #46: 0x000000000103fcbd go`runtime.park_m + 157
    frame #47: 0x000000000106a2bb go`runtime.mcall + 91
    frame #48: 0x000000000106a2bb go`runtime.mcall + 91
    frame #49: 0x000000000101f19f go`runtime.gcBgMarkWorker + 255
    frame #50: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #51: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #2
    frame #0: 0x00007fff71de4bba libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fff71d680fa libsystem_c.dylib`nanosleep + 196
    frame #2: 0x00007fff71d67ff4 libsystem_c.dylib`usleep + 53
    frame #3: 0x000000000106dbab go`runtime.usleep_trampoline + 11
    frame #4: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #5: 0x0000000001055cf1 go`runtime.usleep + 49
    frame #6: 0x000000000104426f go`runtime.sysmon + 143
    frame #7: 0x000000000103bec8 go`runtime.mstart1 + 200
    frame #8: 0x000000000103bde6 go`runtime.mstart + 102
    frame #9: 0x0000000001001eec go`crosscall_amd64 + 12
    frame #10: 0x0000000001001ae4 go`threadentry + 36
    frame #11: 0x00007fff71ea5e65 libsystem_pthread.dylib`_pthread_start + 148
    frame #12: 0x00007fff71ea183b libsystem_pthread.dylib`thread_start + 15
  thread #3
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000101f19f go`runtime.gcBgMarkWorker + 255
    frame #41: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #4
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000102454a go`runtime.scavengeSleep + 202
    frame #41: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #43: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #44: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #45: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #5
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000101f19f go`runtime.gcBgMarkWorker + 255
    frame #41: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #6
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x00000000010557ac go`runtime.libcCall + 108
    frame #5: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #6: 0x00000000010335ed go`runtime.semasleep + 141
    frame #7: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #8: 0x000000000103d23a go`runtime.templateThread + 250
    frame #9: 0x000000000103bec8 go`runtime.mstart1 + 200
    frame #10: 0x000000000103bde6 go`runtime.mstart + 102
    frame #11: 0x0000000001001eec go`crosscall_amd64 + 12
    frame #12: 0x0000000001001ae4 go`threadentry + 36
    frame #13: 0x00007fff71ea5e65 libsystem_pthread.dylib`_pthread_start + 148
    frame #14: 0x00007fff71ea183b libsystem_pthread.dylib`thread_start + 15
  thread #7
    frame #0: 0x00007fff71de6bce libsystem_kernel.dylib`kevent + 10
    frame #1: 0x000000000106dc5e go`runtime.kevent_trampoline + 30
    frame #2: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #3: 0x000000000106dc40 go`runtime.kqueue_trampoline + 32
    frame #4: 0x0000000001056199 go`runtime.kevent + 57
    frame #5: 0x000000000103316e go`runtime.netpoll + 174
    frame #6: 0x000000000103e7fd go`runtime.findrunnable + 1917
    frame #7: 0x000000000103f717 go`runtime.schedule + 727
    frame #8: 0x000000000103fcbd go`runtime.park_m + 157
    frame #9: 0x000000000106a2bb go`runtime.mcall + 91
    frame #10: 0x000000000103316e go`runtime.netpoll + 174
    frame #11: 0x000000000103e7fd go`runtime.findrunnable + 1917
    frame #12: 0x000000000103f717 go`runtime.schedule + 727
    frame #13: 0x000000000103fcbd go`runtime.park_m + 157
    frame #14: 0x000000000106a2bb go`runtime.mcall + 91
    frame #15: 0x000000000103e7fd go`runtime.findrunnable + 1917
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000103f717 go`runtime.schedule + 727
    frame #20: 0x000000000103fcbd go`runtime.park_m + 157
    frame #21: 0x000000000106a2bb go`runtime.mcall + 91
    frame #22: 0x000000000103fcbd go`runtime.park_m + 157
    frame #23: 0x000000000106a2bb go`runtime.mcall + 91
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #26: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #27: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #8
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000102454a go`runtime.scavengeSleep + 202
    frame #41: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #43: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #44: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #45: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #9
    frame #0: 0x00007fff71de3796 libsystem_kernel.dylib`stat$INODE64 + 10
    frame #1: 0x000000000106dedf go`runtime.syscall + 31
    frame #2: 0x000000000106bcd0 go`runtime.asmcgocall + 112
    frame #3: 0x000000000103bd80 go`runtime.startTheWorldWithSema + 576
    frame #4: 0x0000000001068cd1 go`syscall.syscall + 81
    frame #5: 0x00000000010b8a98 go`syscall.Stat + 184
    frame #6: 0x00000000010df41c go`os.statNolog + 92
    frame #7: 0x00000000010deeed go`os.Stat + 77
    frame #8: 0x000000000137625d go`cmd/go/internal/cache.(*Cache).trimSubdir + 413
    frame #9: 0x0000000001375e0b go`cmd/go/internal/cache.(*Cache).Trim + 747
    frame #10: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #11: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #12: 0x00000000015422cd go`main.main + 1421
    frame #13: 0x0000000001039363 go`runtime.main + 547
    frame #14: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #15: 0x00000000010b8a98 go`syscall.Stat + 184
    frame #16: 0x00000000010df41c go`os.statNolog + 92
    frame #17: 0x00000000010deeed go`os.Stat + 77
    frame #18: 0x000000000137625d go`cmd/go/internal/cache.(*Cache).trimSubdir + 413
    frame #19: 0x0000000001375e0b go`cmd/go/internal/cache.(*Cache).Trim + 747
    frame #20: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #21: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #22: 0x00000000015422cd go`main.main + 1421
    frame #23: 0x0000000001039363 go`runtime.main + 547
    frame #24: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #25: 0x00000000010df41c go`os.statNolog + 92
    frame #26: 0x00000000010deeed go`os.Stat + 77
    frame #27: 0x000000000137625d go`cmd/go/internal/cache.(*Cache).trimSubdir + 413
    frame #28: 0x0000000001375e0b go`cmd/go/internal/cache.(*Cache).Trim + 747
    frame #29: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #30: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #31: 0x00000000015422cd go`main.main + 1421
    frame #32: 0x0000000001039363 go`runtime.main + 547
    frame #33: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #34: 0x00000000010deeed go`os.Stat + 77
    frame #35: 0x000000000137625d go`cmd/go/internal/cache.(*Cache).trimSubdir + 413
    frame #36: 0x0000000001375e0b go`cmd/go/internal/cache.(*Cache).Trim + 747
    frame #37: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #38: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #39: 0x00000000015422cd go`main.main + 1421
    frame #40: 0x0000000001039363 go`runtime.main + 547
    frame #41: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #42: 0x000000000137625d go`cmd/go/internal/cache.(*Cache).trimSubdir + 413
    frame #43: 0x0000000001375e0b go`cmd/go/internal/cache.(*Cache).Trim + 747
    frame #44: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #45: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #46: 0x00000000015422cd go`main.main + 1421
    frame #47: 0x0000000001039363 go`runtime.main + 547
    frame #48: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #49: 0x0000000001375e0b go`cmd/go/internal/cache.(*Cache).Trim + 747
    frame #50: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #51: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #52: 0x00000000015422cd go`main.main + 1421
    frame #53: 0x0000000001039363 go`runtime.main + 547
    frame #54: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #55: 0x0000000001451ab4 go`cmd/go/internal/work.(*Builder).Do + 1012
    frame #56: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #57: 0x00000000015422cd go`main.main + 1421
    frame #58: 0x0000000001039363 go`runtime.main + 547
    frame #59: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #60: 0x0000000001526605 go`cmd/go/internal/test.runTest + 3781
    frame #61: 0x00000000015422cd go`main.main + 1421
    frame #62: 0x0000000001039363 go`runtime.main + 547
    frame #63: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #64: 0x00000000015422cd go`main.main + 1421
    frame #65: 0x0000000001039363 go`runtime.main + 547
    frame #66: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #67: 0x0000000001039363 go`runtime.main + 547
    frame #68: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #69: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #10
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000101f19f go`runtime.gcBgMarkWorker + 255
    frame #41: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #11
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000102454a go`runtime.scavengeSleep + 202
    frame #41: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #43: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #44: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #45: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #12
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000102454a go`runtime.scavengeSleep + 202
    frame #41: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #43: 0x0000000001024825 go`runtime.bgscavenge + 677
    frame #44: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #45: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #13
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x000000000102440c go`runtime.wakeScavenger + 76
    frame #5: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #6: 0x00000000010335ed go`runtime.semasleep + 141
    frame #7: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #8: 0x000000000103d325 go`runtime.stopm + 197
    frame #9: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #10: 0x000000000103f717 go`runtime.schedule + 727
    frame #11: 0x000000000103fcbd go`runtime.park_m + 157
    frame #12: 0x000000000106a2bb go`runtime.mcall + 91
    frame #13: 0x00000000010335ed go`runtime.semasleep + 141
    frame #14: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #15: 0x000000000103d325 go`runtime.stopm + 197
    frame #16: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #17: 0x000000000103f717 go`runtime.schedule + 727
    frame #18: 0x000000000103fcbd go`runtime.park_m + 157
    frame #19: 0x000000000106a2bb go`runtime.mcall + 91
    frame #20: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #21: 0x000000000103d325 go`runtime.stopm + 197
    frame #22: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #23: 0x000000000103f717 go`runtime.schedule + 727
    frame #24: 0x000000000103fcbd go`runtime.park_m + 157
    frame #25: 0x000000000106a2bb go`runtime.mcall + 91
    frame #26: 0x000000000103d325 go`runtime.stopm + 197
    frame #27: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #28: 0x000000000103f717 go`runtime.schedule + 727
    frame #29: 0x000000000103fcbd go`runtime.park_m + 157
    frame #30: 0x000000000106a2bb go`runtime.mcall + 91
    frame #31: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #32: 0x000000000103f717 go`runtime.schedule + 727
    frame #33: 0x000000000103fcbd go`runtime.park_m + 157
    frame #34: 0x000000000106a2bb go`runtime.mcall + 91
    frame #35: 0x000000000103f717 go`runtime.schedule + 727
    frame #36: 0x000000000103fcbd go`runtime.park_m + 157
    frame #37: 0x000000000106a2bb go`runtime.mcall + 91
    frame #38: 0x000000000103fcbd go`runtime.park_m + 157
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000106a2bb go`runtime.mcall + 91
  thread #14
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
  thread #15
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103be93 go`runtime.mstart1 + 147
    frame #11: 0x000000000103bde6 go`runtime.mstart + 102
    frame #12: 0x0000000001001eec go`crosscall_amd64 + 12
    frame #13: 0x0000000001001ae4 go`threadentry + 36
    frame #14: 0x00007fff71ea5e65 libsystem_pthread.dylib`_pthread_start + 148
    frame #15: 0x00007fff71ea183b libsystem_pthread.dylib`thread_start + 15
  thread #16
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103fcbd go`runtime.park_m + 157
    frame #11: 0x000000000106a2bb go`runtime.mcall + 91
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #16: 0x000000000103f717 go`runtime.schedule + 727
    frame #17: 0x000000000103fcbd go`runtime.park_m + 157
    frame #18: 0x000000000106a2bb go`runtime.mcall + 91
    frame #19: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #20: 0x000000000103d325 go`runtime.stopm + 197
    frame #21: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #22: 0x000000000103f717 go`runtime.schedule + 727
    frame #23: 0x000000000103fcbd go`runtime.park_m + 157
    frame #24: 0x000000000106a2bb go`runtime.mcall + 91
    frame #25: 0x000000000103d325 go`runtime.stopm + 197
    frame #26: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #27: 0x000000000103f717 go`runtime.schedule + 727
    frame #28: 0x000000000103fcbd go`runtime.park_m + 157
    frame #29: 0x000000000106a2bb go`runtime.mcall + 91
    frame #30: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #31: 0x000000000103f717 go`runtime.schedule + 727
    frame #32: 0x000000000103fcbd go`runtime.park_m + 157
    frame #33: 0x000000000106a2bb go`runtime.mcall + 91
    frame #34: 0x000000000103f717 go`runtime.schedule + 727
    frame #35: 0x000000000103fcbd go`runtime.park_m + 157
    frame #36: 0x000000000106a2bb go`runtime.mcall + 91
    frame #37: 0x000000000103fcbd go`runtime.park_m + 157
    frame #38: 0x000000000106a2bb go`runtime.mcall + 91
    frame #39: 0x000000000106a2bb go`runtime.mcall + 91
    frame #40: 0x000000000101f19f go`runtime.gcBgMarkWorker + 255
    frame #41: 0x000000000106c0a1 go`runtime.goexit + 1
    frame #42: 0x000000000106c0a1 go`runtime.goexit + 1
  thread #17
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x00000000010557ac go`runtime.libcCall + 108
    frame #5: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #6: 0x00000000010335ed go`runtime.semasleep + 141
    frame #7: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #8: 0x000000000103d325 go`runtime.stopm + 197
    frame #9: 0x000000000104129d go`runtime.exitsyscall0 + 285
    frame #10: 0x000000000106a2bb go`runtime.mcall + 91
    frame #11: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #12: 0x00000000010335ed go`runtime.semasleep + 141
    frame #13: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #14: 0x000000000103d325 go`runtime.stopm + 197
    frame #15: 0x000000000104129d go`runtime.exitsyscall0 + 285
    frame #16: 0x000000000106a2bb go`runtime.mcall + 91
    frame #17: 0x00000000010335ed go`runtime.semasleep + 141
    frame #18: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #19: 0x000000000103d325 go`runtime.stopm + 197
    frame #20: 0x000000000104129d go`runtime.exitsyscall0 + 285
    frame #21: 0x000000000106a2bb go`runtime.mcall + 91
    frame #22: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #23: 0x000000000103d325 go`runtime.stopm + 197
    frame #24: 0x000000000104129d go`runtime.exitsyscall0 + 285
    frame #25: 0x000000000106a2bb go`runtime.mcall + 91
    frame #26: 0x000000000103d325 go`runtime.stopm + 197
    frame #27: 0x000000000104129d go`runtime.exitsyscall0 + 285
    frame #28: 0x000000000106a2bb go`runtime.mcall + 91
    frame #29: 0x000000000104129d go`runtime.exitsyscall0 + 285
    frame #30: 0x000000000106a2bb go`runtime.mcall + 91
    frame #31: 0x000000000106a2bb go`runtime.mcall + 91
  thread #18
    frame #0: 0x00007fff71de4ce6 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff71ea6185 libsystem_pthread.dylib`_pthread_cond_wait + 701
    frame #2: 0x000000000106de30 go`runtime.pthread_cond_wait_trampoline + 16
    frame #3: 0x000000000106bd0d go`runtime.asmcgocall + 173
    frame #4: 0x0000000001056379 go`runtime.pthread_cond_wait + 57
    frame #5: 0x00000000010335ed go`runtime.semasleep + 141
    frame #6: 0x000000000100dd07 go`runtime.notesleep + 231
    frame #7: 0x000000000103d325 go`runtime.stopm + 197
    frame #8: 0x000000000103eaff go`runtime.findrunnable + 2687
    frame #9: 0x000000000103f717 go`runtime.schedule + 727
    frame #10: 0x000000000103be93 go`runtime.mstart1 + 147
    frame #11: 0x000000000103bde6 go`runtime.mstart + 102
    frame #12: 0x0000000001001eec go`crosscall_amd64 + 12
    frame #13: 0x0000000001001ae4 go`threadentry + 36
    frame #14: 0x00007fff71ea5e65 libsystem_pthread.dylib`_pthread_start + 148
    frame #15: 0x00007fff71ea183b libsystem_pthread.dylib`thread_start + 15
(lldb)

Something is weird about thread #9's backtrace.

Speculation: Could this just be cmd/go deleting a very large number of expired cache entries?
If so, maybe we need to bound the number of entries deleted during one auto-initiated run, and have cleanup happen incrementally.
cc @bcmills @jayconrod

Could this just be cmd/go deleting a very large number of expired cache entries?

Based on the stack and other comments, this seems likely.
If I remember correctly, the build cache expiration policy is purely time-based. There are some comments in src/cmd/go/internal/cache/cache.go. The go command will attempt to trim the cache at most once per day. It will remove files that haven't been accessed in 5 days.
I don't believe there are any limits on the number or total size of files in the cache. It may not make sense to limit the size of the cache, but we might want to trim files more aggressively when it's very large (#29561).
Trimming incrementally also seems like a good solution. We could limit the time spent trimming for any command to, say 500 ms. We could save where we left off so the next command could restart from that point.

We could limit the time spent trimming for any command to, say 500 ms.

I don't think we should limit the trimming time to any fixed duration, because that could lead to a state where the trimming can't keep pace with the rate of creation.
That said, I would expect deleting a file to almost always be faster than creating it. Perhaps we could limit the cleaning time to some multiple of the rest of the running time of the go command so far (with a lower bound to ensure that we can always do some cleaning).

Another option might be to kick off cleaning the cache at the beginning of the cmd/go run, and let it run concurrently with the rest of the command, except when running benchmarks.

I like that! But I worry it could be a bit racy — is it possible for part of the command to touch part of the cache and make it non-stale again?

It’s not that terrible to have to recalculate something that you just deleted—that would have happened anyway with slightly different timing of when you ran the commands.
I think the only problem is if you see something is in the cache, decide to use it, and then it gets cleaned up before you can use it. But if you can freshen it in the cache, and if the deletion goroutine always rechecks freshness before deletion, and if there are enough synchronization points, it should be ok. But that is a lot of ifs. :)

Yes, that's exactly the race I'm worried about. 🙂
I guess we could decide which portions of the cache to use, then freshen them, then kick off the cleaner while we do the remaining work. (But we intentionally don't rely on file-locking in the cache, and even if we did there is no atomic lock-check-and-delete operation, so there is in general no way to prevent the cleaner from racing with the consumer. So I don't think we can avoid the need to at least finish freshening the entries before we start the cleaner.)

Since this is all in one process, could we do our synchronization internally, in a thin intermediate layer?

Internally: yes. Thin: that's subjective. 😉

Fair enough. Happy to leave all these choices to you. :) I'd be happy enough with a simple 500ms time limit for automatically initialized cache cleanup.

@josharian, I noticed a similar issue tracking down #39183. I started with a test that ran lots of goroutines to try to provoke failures, and found that the test with N=10000 ran very quickly (~1s) but the go command hung for a long time afterward (~10s), on every run (not just when there were existing cache entries to invalidate).
I wonder if there is a bottleneck in producing the cache key itself, rather than merely cleaning the stale entries.

@josharian, are you on a Mac?
I am seeing this too and found that go clean -cache was significantly slower than rm -rf $(go env GOCACHE).
I haven't chased down what's different though.
When I kill -ABRT'ed the slow go clean -cache, it was in RemoveAll (as expected).

Yep, I'm on a mac.

This happened to me again and I found that even rm -rf $(go env GOCACHE) was taking a very long time. By very long time I mean it took 20 minutes to delete ~1,250,000 files.
On my Mac, fseventsd was writing down all the deleted file names in its own little databases, and then santa (https://github.com/google/santa) was writing down all the file accesses by fseventsd. If those weren't there I think rm would be faster. I tried telling Spotlight preferences that ~/Library/Caches was private and should not be indexed but it seems not to do anything re fseventsd.

Another option might be to kick off cleaning the cache at the beginning of the cmd/go run, and let it run concurrently with the rest of the command, except when running benchmarks.

One little comment to this approach.  As I understand it, currently the cache trimming is now done at the end? This means it a cache older than 5 days might be used once?
I think this actually helps a lot in the case of Continuous Integration systems, they might cache things for more than 5 days (CircleCI for example does 15). If the cache would be invalidated before, purely based on being old, that would mean the CI would not be able to use this cache and it might slow down things unnecessarily.
I'm not saying design decisions should be based on this fact, but just something I have come across when trying to optimise CI build/test times and it might be worth being aware of at least.

This sometimes (quite often, in fact) happens to me as well, with go run. The program won't terminate after Ctrl+C, no matter how many times I press it. kill from another terminal kills the hanging process.
It seems that it has something to do with go cache. See cmd/go/internal/cache.(*Cache).trimSubdir and cmd/go/internal/cache.(*Cache).Trim:
(gdb) bt

#0  runtime/internal/syscall.Syscall6 () at /usr/local/go/src/runtime/internal/syscall/asm_linux_amd64.s:36
#1  0x0000000000404173 in syscall.RawSyscall6 (num=0, a1=18446744073709551516, a2=4211086, a3=18446744073709551516,
    a4=824635707712, a5=0, a6=0, r1=<optimized out>, r2=<optimized out>, errno=<optimized out>)
    at /usr/local/go/src/runtime/internal/syscall/syscall_linux.go:38
#2  0x000000000047e01e in syscall.Syscall6 (trap=262, a1=18446744073709551516, a2=824635707712, a3=824635202936, a4=0, a5=0, a6=0,
    r1=<optimized out>, r2=<optimized out>, err=<optimized out>) at /usr/local/go/src/syscall/syscall_linux.go:91
#3  0x000000000047d3da in syscall.fstatat (fd=-100, path=..., stat=0xc000169d78, flags=0, err=...)
    at /usr/local/go/src/syscall/zsyscall_linux_amd64.go:1439
#4  0x00000000004e0298 in syscall.Stat (path=..., stat=0xffffffffffffff9c, err=...)
    at /usr/local/go/src/syscall/syscall_linux_amd64.go:59
#5  os.statNolog.func1 () at /usr/local/go/src/os/stat_unix.go:32
#6  os.ignoringEINTR (fn=<optimized out>) at /usr/local/go/src/os/file_posix.go:245
#7  os.statNolog (name=..., ~r0=..., ~r1=...) at /usr/local/go/src/os/stat_unix.go:31
#8  0x00000000004dfdd4 in os.Stat (name=..., ~r0=..., ~r1=...) at /usr/local/go/src/os/stat.go:13
#9  0x00000000007c7f85 in cmd/go/internal/cache.(*Cache).trimSubdir (c=<optimized out>, subdir=..., cutoff=...)
    at /usr/local/go/src/cmd/go/internal/cache/cache.go:366
#10 0x00000000007c7c08 in cmd/go/internal/cache.(*Cache).Trim (c=0xc000131200)
    at /usr/local/go/src/cmd/go/internal/cache/cache.go:334

@josharian Why would go run "helpfully" trim the cache beyond what's needed to start the program at all? The user didn't ask for it.
(I believe that the Go users who have their gocache directory on an SSD do not notice any delay, but my gocache resides on a slow spinning disk.)

I'll try the patch out and let know if it helps.


404 HTTP response when trying to dispense food

I have a Petkit Fresh Element Mini Pro and tried this plugin.
The fan accessory appears, but when I try to enable the internal switch service (which I guess is the "dispense food" action), the plugin throws a 401 error:
PetkitOpenAPI request: method = post, endpoint = http://api.petkt.com/latest, path = /feedermini/saveDailyFeed, params = null, body = {"amount":15,"day":"20230306","deviceId":"XXX","time":-1}, headers = {"X-Client":"ios(15.5;iPhone12,3)","Accept":"*/*","X-Timezone":"2.0","Accept-Language":"es-ES;q=1","Accept-Encoding":"gzip, deflate","X-Api-Version":"8.17.1","Content-Type":"application/x-www-form-urlencoded","User-Agent":"PETKIT/8.17.1 (iPhone; iOS 15.5; Scale/3.00)","X-TimezoneId":"Europe/Madrid","X-Locale":"es_ES","X-Session":"XXX"}
[SET][Fresh Element Mini] Characteristic Error: Error: Request failed with status code 404
    at createError (/volume2/homebridge/node_modules/homebridge-petkit-platform/node_modules/axios/lib/core/createError.js:16:15)
    at settle (/volume2/homebridge/node_modules/homebridge-petkit-platform/node_modules/axios/lib/core/settle.js:17:12)
    at IncomingMessage.handleStreamEnd (/volume2/homebridge/node_modules/homebridge-petkit-platform/node_modules/axios/lib/adapters/http.js:269:11)
    at IncomingMessage.emit (node:events:539:35)
    at endReadableNT (node:internal/streams/readable:1345:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  config: [Object],
  request: [ClientRequest],
  response: [Object],
  isAxiosError: true,
  toJSON: [Function: toJSON]
}

Any news on this? Thanks 🙏🏻

I am getting this same error message. Any help would be greatly appreciated.

@jubepue is the plugin still in development? :(


How can I get the ActionView Content

Hi All
I want to get ActionView Content ,How Can I do?

Could you please provide some more details on what you are trying to do? Can we see an example of your code?


Fix incorrect link in docs

Fixed an incorrect link in Docs pointing to "See more available Minifabric commands".

Looks like that your PR does not have your signature. Please use -s when you do submit. Thanks


Use noninteractive mode when installing packages in Docker build

Superseded by https://github.com/p4lang/p4runtime/pull/375


How do I use rpa.init() in PyScript or Pyodide?

When I use PyScript or Pyodide, platform.system() print is Emscripten.So when I run rpa.init() in browser,show error "unknown Emscripten operating system to setup TagUI".
In source codes,I can see it,is only support windows linux and macos.How should I solve this problem.
My English is not very good. If there is any problem with my expression, please forgive me,thanks

Hi @bielaiwuyang-j, can you share with me more on your use case of running Python code in the web browser?
Indeed, the package is designed to run directly on Python Windows, Linux, Mac, but not through a web browser.
There could be a workaround, you can try the following -

get location of the Python rpa package with

import rpa as r
print(r.__file__)

edit the file tagui.py under that folder
search and replace all references of platform.system() with Windows, Linux, Darwin(Darwin is code name for Mac) depending on what is the real OS that you are running the automation on
restart and try again

(you can also type in Chinese, I'm Chinese but primarily using English and type English keyboard, but I can read Chinese no problem)


wip: Worklist fixes

This pr addresses the issues indicated in #288
@norhh This is everything right?
Also fixes #321. this was caused by an assumption in svm.py to generate the cfg

@norhh That seems to be a different problem


Newsletter june

Description
First draft of a proposed newsletter.  This still needs refinement before we publish it.

@tnabtaf I opened a PR against your branch: https://github.com/tnabtaf/conda-dot-org/pull/2

@wolfv and @asmitbm : You people rock!  Thanks for the updates.


cluster: handle node error on unknown start container errors

Codecov Report

Merging #40 into master will increase coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #40      +/-   ##
==========================================
+ Coverage   83.58%   83.67%   +0.09%
==========================================
  Files           9        9
  Lines        1255     1262       +7
==========================================
+ Hits         1049     1056       +7
  Misses        139      139
  Partials       67       67

Impacted Files
Coverage Δ

cluster/container.go
87.91% <100%> (+0.36%)
:arrow_up:

Continue to review full report at Codecov.

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


shadow package incompatible

The \shabox command from the shadow package errors if the text spans more than one line. The tagging of the box should also probably be suppressed.
\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,title,table,firstaid},
  }
\documentclass{article}

\usepackage{shadow}

\title{shadow tagging test}

\begin{document}

\shabox{text}

\shabox{a long sentence a long sentence a long sentence a long sentence a long sentence a long sentence a long sentence}

\end{document}

errors with
! Package tagpdf Error: The number of automatic begin (3) and end (2)
(tagpdf)                text-unit para hooks differ!

It errors as the \vbox is not properly ended by a \par. And yes, the shadowbox should not be tagged/be artifacts.


Platform queries for OS dependent styles

Some kind of a special query to match the users OS / browser would be create to style e.g. iOS or Android specific component-parts.
e.g.
const styles = StyleSheet.create(Component, {
   box: {
     color: 'white',
     width: 200,
     '@platform ios': {
        backgroundColor: 'blue'
     },
     '@platform android': {
        backgroundColor: 'red'
     }
   }
})

This could be easily done using the browser information which the inline-style-prefixer provides.

This has been added and is supported by using inline-style-prefixer's data


(Key and Value) or just (Key) Template Arguments?

I was thinking that just the key is enough for the all the implemented tree data structures because the programmer that will use the library will be able to overload some operators and achieve the same result as if the value was separate from the key.
Do you think there is any point in keeping both key and value?

The value is interesting, because one key differs from the others, it would be nice to have more than one value equal in the tree, but different identities.

@ADSmarcossobral So you are in favor of having both key and value. Right?

Another thing I would like to mention is that all data structures here do not allow the insertion of a node with an already existing key. I guess I will have to document this too ...

@xorz57 Yes. I do!


hasura-auth-js breaking on Vercel

While deploying my NuxtJS application on Vercel, the hasura-auth-js is breaking for some reason. This wasn't happening until a month ago. And I didn't even change anything on my end. I'm also not getting this error locally. Everything is working fine locally.
I've tried changing multiple versions of @nhost/nhost-js. But none of them could solve this issue. Even tried falling back on v0.3.12. Even that didn't work.
Something is happening in @nhost/hasura-auth-js. Something that wasn't happening a month before.
Maybe @plmercereau can take a look at this.
ERROR in<EMAIL_ADDRESS>1:8801
  Module parse failed: Unexpected token (1:8801)
  You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
  > var A=Object.defineProperty;var O=Object.getOwnPropertyDescriptor;var U=Object.getOwnPropertyNames,p=Object.getOwnPropertySymbols;var y=Object.prototype.hasOwnProperty,I=Object.prototype.propertyIsEnumerable;var P=(i,e,n)=>e in i?A(i,e,{enumerable:!0,configurable:!0,writable:!0,value:n}):i[e]=n,d=(i,e)=>{for(var n in e||(e={}))y.call(e,n)&&P(i,n,e[n]);if(p)for(var n of p(e))I.call(e,n)&&P(i,n,e[n]);return i};var N=i=>A(i,"__esModule",{value:!0});var T=(i,e)=>{var n={};for(var t in i)y.call(i,t)&&e.indexOf(t)<0&&(n[t]=i[t]);if(i!=null&&p)for(var t of p(i))e.indexOf(t)<0&&I.call(i,t)&&(n[t]=i[t]);return n};var x=(i,e)=>{for(var n in e)A(i,n,{get:e[n],enumerable:!0})},k=(i,e,n,t)=>{if(e&&typeof e=="object"||typeof e=="function")for(let r of U(e))!y.call(i,r)&&(n||r!=="default")&&A(i,r,{get:()=>e[r],enumerable:!(t=O(e,r))||t.enumerable});return i};var D=(i=>(e,n)=>i&&i.get(e)||(n=k(N({}),e,1),i&&i.set(e,n),n))(typeof WeakMap!="undefined"?new WeakMap:0);var L={};x(L,{HasuraAuthClient:()=>C});var m=require("xstate"),o=require("@nhost/core");var E=require("@nhost/core"),g=()=>typeof window<"u",c=i=>!i||!i.accessToken.value||!i.refreshToken.value?null:{accessToken:i.accessToken.value,accessTokenExpiresIn:(i.accessToken.expiresAt.getTime()-Date.now())/1e3,refreshToken:i.refreshToken.value,user:i.user},l=(i,e)=>{e.forEach(n=>{typeof i[n]!="function"&&console.error(`clientStorage.${n} is not a function`)})},w=(i,e)=>{if(e){if(i==="react-native"||i==="custom")return l(e,["getItem"]),n=>{var t;return(t=e.getItem)==null?void 0:t.call(e,n)};if(i==="capacitor")return l(e,["get"]),n=>{var t;return(t=e.get)==null?void 0:t.call(e,{key:n})};if(i==="expo-secure-storage")return l(e,["getItemAsync"]),n=>{var t;return(t=e.getItemAsync)==null?void 0:t.call(e,n)}}return E.defaultClientStorageGetter},R=(i,e)=>{if(e){if(i==="react-native"||i==="custom")return l(e,["setItem","removeItem"]),(n,t)=>{var r,s;t?(r=e.setItem)==null||r.call(e,n,t):(s=e.removeItem)==null||s.call(e,n)};if(i==="capacitor")return l(e,["set","remove"]),(n,t)=>{var r,s;t?(r=e.set)==null||r.call(e,{key:n,value:t}):(s=e.remove)==null||s.call(e,{key:n})};if(i==="expo-secure-storage")return l(e,["setItemAsync","deleteItemAsync"]),async(n,t)=>{var r,s;t?await((r=e.setItemAsync)==null?void 0:r.call(e,n,t)):(s=e.deleteItemAsync)==null||s.call(e,n)}}return E.defaultClientStorageSetter};var S={message:"User is already signed in",status:100},b={message:"User is not authenticated",status:101},G={message:"User is not anonymous",status:101},M={message:"Email needs verification",status:102},C=class{constructor({url:e,autoRefreshToken:n=!0,autoLogin:t=!0,clientStorage:r,clientStorageType:s="web",clientStorageGetter:u,clientStorageSetter:a,refreshIntervalTime:f,start:h=!0,Client:_=o.AuthClient}){this._client=new _({backendUrl:e,autoRefreshToken:n,autoSignIn:t,start:h,clientStorageGetter:u||w(s,r),clientStorageSetter:a||R(s,r),refreshIntervalTime:f})}async signUp(e){let n=await this.waitUntilReady(),{email:t,password:r,options:s}=e;return this.isAuthenticated()?{session:null,error:S}:new Promise(u=>{n.send({type:"SIGNUP_EMAIL_PASSWORD",email:t,password:r,options:s}),n.onTransition(a=>{if(a.matches({authentication:{signedOut:"needsEmailVerification"}}))return u({session:null,error:null});if(a.matches({authentication:{signedOut:"failed"}}))return u({session:null,error:a.context.errors.registration||null});if(a.matches({authentication:"signedIn"}))return u({session:c(a.context),error:null})})})}async signIn(e){let n=await this.waitUntilReady();if(this.isAuthenticated())return{session:null,mfa:null,error:S};if("provider"in e){let{provider:t,options:r}=e,s=(0,o.encodeQueryParameters)(`${this._client.backendUrl}/signin/provider/${t}`,(0,o.rewriteRedirectTo)(this._client.clientUrl,r));return g()&&(window.location.href=s),{providerUrl:s,provider:t,session:null,mfa:null,error:null}}return"email"in e&&"password"in e?new Promise(t=>{n.send(d({type:"SIGNIN_PASSWORD"},e)),n.onTransition(r=>{r.matches({authentication:"signedIn"})?t({session:c(r.context),mfa:null,error:null}):r.matches({authentication:{si
message.txt
5 KB

Screenshot from Vercel deployment:

I think this problem is specific to [Nuxt Vercel<EMAIL_ADDRESS>that I'm using for building SSR on Vercel.
Weirdly it was working absolutely fine until a month ago. And now suddenly hasura-auth-js can no longer be compiled/built using this builder. I'm sure this is related to some changes made to hasura-auth-js in the last 2 months.

FYI: to reproduce this problem locally, do the following:

mkdir test && cd test
npx create-nuxt-app
Create a blank new nuxt app.
npm install @nhost/nhost-js
npx nuxt build --standalone --no-lock

And you should be able to see the error.

In file<EMAIL_ADDRESS>this is specifically where I am being shown an error, on line517 and 518.
getAccessToken() {
   var e;
   return ((e = this._client.interpreter) == null ? void 0 : e.state.context.accessToken.value) ? ? void 0
}

NOTE:

I'm only getting this error using --standalone flag. Not getting it while building without this flag.
I'm also not getting this error if I don't have the @nhost/nhost-js or @nhost/hasura-auth-js package in my application. Building using npx nuxt build --standalone --no-lock otherwise on a blank app, which doesn't use Nhost packages, builds absolutely fine

Please add this to your nuxt.config.js:
build: {
    transpile: [/@nhost\//],
}

That seems to have solved one problem. But now I have another one.
I have tried rm -rf node_modules package-lock.json && npm i --save. But it hasn't solved it.
Also tried both @nhost/nhost-js versions 1.0.11 and 1.1.0.
But locally it's working fine. Only breaking on vercel.

npm i graphql

Hey @mrinalwahal! Could you please take a look at the latest version? A new package has been published.

Yes, I can confirm the new version has fixed this problem.
Thanks a lot for your help guys. You really saved my day, @plmercereau and @szilarddoro! 🚀


Badges

Codecov Report

Merging #2 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master     #2   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines          52     52
  Branches       10     10
=====================================
  Hits           52     52

Continue to review full report at Codecov.

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


linalg.tsqr not working in python 2.7

I see that there were some changes in the inner structure of dask arrays since I coded the linalg module. One of them is the use of slice to create dask dicts. However, when I try to run the tests I get the error "TypeError: unhashable type" in lines 92 to 94 in linalg.
I believe that this is due to the slice class being non-hashable. Am I correct?

If you give me a failing example I'll be happy to track this down.  Things work for me in 2.7 (this is my normal development language).  I can't think of any changes that would affect dask.array.linalg off the top of my head.

I would not expect a hashability in those lines.
    dsk_q_st2 = dict(((name_q_st2,) + (i, 0),
                      (operator.getitem, (name_q_st2_aux, 0, 0), b))
                     for i, b in enumerate(block_slices))

Dicts only care about the hashability of keys which in this case is just (name_q_st2,), + (i, 0) which seems pretty harmless.

Sorry, my bad. Something weird I did when I rebased my fork. Thanks!
On Sat, Jun 6, 2015 at 6:35 PM, Matthew Rocklin<EMAIL_ADDRESS>wrote:

I would not expect a hashability in those lines.
dsk_q_st2 = dict(((name_q_st2,) + (i, 0),
                  (operator.getitem, (name_q_st2_aux, 0, 0), b))
                 for i, b in enumerate(block_slices))

Dicts only care about the hashability of keys which in this case is just (name_q_st2,),

(i, 0) which seems pretty harmless.

—
Reply to this email directly or view it on GitHub
https://github.com/ContinuumIO/dask/issues/279#issuecomment-109654817.


[DO NOT MERGE] Root cause the np max, min testing flakiness

Description
(Brief description on what this PR is about)
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

suspect the problem is in https://github.com/apache/incubator-mxnet/blob/df4125aa1d4ef013e68e6adf3738dabdb1b52865/src/operator/numpy/random/dist_common.h#L156

Hey, is this PR relevant to the recent fix?

yes, I can close it


Work with Editable div

how can i use with editable div? just work with textarea?

any news on this? Not working with any wysiwyg editor which replaces textarea with editable div

Any update on this for content editable div?

Any update?


When is it gonna be updated?

When is it gonna be updated?

I'm working on the next update, mostly on the SysWhisperU right now (reducing detections) which is very complicated.


error

i get this error when training the model, do you know what it is? definitely not my gpu memory cause i tried with the smallest model

It seems the dataloader failed to load imgs, check the data path/name/format is correct or not.


Scalability

We don't know if the Admin UI Picard was ever tested for scalability, so we should probably do that (or get someone with a huge system to do it for us).

Project issue from before launch that we won't get to, closing to keep issue tracker neat.


Automate OLM cleanup for running local operator w/ webhooks

When using make run-with-webhook, local versions of the operator and its webhooks are added to the cluster. If the operator was previously installed via OLM, then there might be lingering webhooks from that installation. We've previously been assuming that the user would manually remove them, but we should just get rid of them ourselves since those OLM webhooks need to be deleted anyhow for the local webhooks to function unimpeded.  We can also automatically scale down the operator's OLM deployment in such a scenario.

@abays: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
Test name 	Commit 	Details 	Required 	Rerun command
ci/prow/octavia-operator-build-deploy-kuttl 	a45a87e link 	true 	/test octavia-operator-build-deploy-kuttl
Full PR test history. Your PR dashboard.

error: build error: Failed to push image: trying to reuse blob sha256:4d5d1cbd7ece41ce278c26338e01e2b82e1861b820ca052da9f3e0b16815358f at destination: pinging container registry quay.rdoproject.org: Get "https://quay.rdoproject.org/v2/": dial tcp <IP_ADDRESS>:443: i/o timeout

/test octavia-operator-build-deploy-kuttl


Video Scheduler Errort

Asus laptop successfully flashed using a programmer. After enabling ReBar, laptop starts to crash with bsod  VIDEO SCHEDULER INTERNAL ERROR . Any ideas how to fix ?

Solved, i'm brainded, set PCI bus for all devices not for GPU

Solved, i'm brainded, set PCI bus for all devices not for GPU


Fixed #28798 -- Removed unused django.utils.dates.WEEKDAYS_REV, MONTHS_3_REV.

https://code.djangoproject.com/ticket/28798

Thanks @timgraham  :)


DEBUG logs are dominated by "No idle peers have any of the trie nodes we want"

What is wrong?
Currently, the debug logs are dominated by this logging statement during state sync.
https://github.com/ethereum/py-evm/blob/2f8f89a6abfec1757ab2090c98e4c1df03f2b3f1/p2p/state.py#L219-L221
How can it be fixed
We either need to move that to TRACE level, increase the sleep duration (probably bad for performance), or ideally, find a clean way to throttle that message so that it only shows up at most once every 1-2 seconts, or something else I haven't thought of.

Something like this leaky bucket algorithm in python:
https://stackoverflow.com/questions/45440900/throttling-async-functions-in-python-asyncio


getInventory().query(Hotbar.class)) returns wrong inventory row

getInventory().query(Hotbar.class)) returns bottom row of players inventory instead of hotbar

@Mumfrey

Should have been fixed a few days ago :/

@Mumfrey I just tried build 1025 ,can't reproduce this issue anymore.


Stacked inline form does not hide "Delete" button even if the admin.StackedInline child restricts inline deletions

templates/admin/edit_inline/stacked.html does not seem to respect permissions. Here I explicitly restricted deletions but the "Delete" button still appears (though doesn't delete anything):
class ParameterValuesInline(admin.StackedInline):
    model = ParameterValue
    verbose_name = _('Value')
    ordering = ("parameter",)
    extra = 0

    def has_delete_permission(self, request, obj=None):
        return False

In order to get rid of the button we can fix stacked.html like this (the condition is taken from the default django stacked.html):
{% if inline_admin_formset.formset.can_delete and inline_admin_formset.has_delete_permission and inline_admin_form.original %}

{% trans "Delete" %} delete_forever

{% endif %}

Thanks!
Fixed in v1.7.4

Awesome, much thanks! Should I close the issue then?

I think - yes


Add @oleg-nenashev to the List of SVN plugin developers

I am doing some reviews there to decrease the technical debt, and I can do releases sometimes till somebody adopts the plugin.
WDYT @stephenc @jglick ?

Origin branches make me a sad panda 😭

@stephenc I'd like to participate on Subversion Plugin but lately I don't have time.
@oleg-nenashev 👍


only use hint for disambiguation

Docs for https://github.com/PostgREST/postgrest/pull/2272

https://postgrest--533.org.readthedocs.build/en/533/api.html#embedding-disambiguation
Seeing that now we prefer the hint disambiguation, we go from this:
GET /orders?select=name,billing_address(name)

To this:
GET /orders?select=name,billing_address:addresses!billing_address(name)

Which makes me realize renaming the FK doesn't really make things clearer now, so I think that part should be omitted.
We can mention that the FK name can be used in composite foreign keys cases and just put the autogenerated name.

This tried to hide the "target disambiguation" feature - not good since it's still supported.
We should deprecate that form in a new release instead.


[BUG] Removing track should switch selection to nearest neighbor, not 0.

UX bug.
"This is very time consuming to have to scroll back down to the detection number we left off at"

Also, inserts should be sliced into the track list right after the current selected track if one exists, not allowed to appear anywhere in the current frame's time window.  This will require a bit more thought because we're only sorting by frame.  There's no ordering within frames.


Handle CubeList in line plotting operator

Fixes #918
Contribution checklist
Aim to have all relevant checks ticked off before merging. See the developer's guide for more detail.

[x] Documentation has been updated to reflect change.
[ ] New code has tests, and affected old tests have been updated.
[x] All tests and CI checks pass.
[x] Ensured the pull request title is descriptive.
[ ] Conda lock files have been updated if dependencies have changed.
[ ] Attributed any Generative AI, such as GitHub Copilot, used in this PR.
[x] Marked the PR as ready to review.

addresses issue https://github.com/MetOffice/CSET/issues/918

Oops, I've realised I've reviewed this PR wrong. While this is the correct transformation for most of the operators that need converting to handle a CubeList, this particular one is a bit special.
When we give the line plot operator multiple cubes, I suspect we are wanting multiple lines.


2D texture sampler clamp option

Hi!
I have a problem with texture visualization. I am not a pro in Vulkan API, I am trying to visualize the texture (picture) and clamp the image to the border. However, as much as I try to change the parameters in the sampler, I still get the repetitive pattern:

The code for the sampler:
        VkSamplerCreateInfo samplerInfo{};
	samplerInfo.sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO;
	samplerInfo.magFilter = VK_FILTER_LINEAR;
	samplerInfo.minFilter = VK_FILTER_LINEAR;
	samplerInfo.addressModeU = VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER;
	samplerInfo.addressModeV = VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER;
	samplerInfo.addressModeW = VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER;
	samplerInfo.anisotropyEnable = VK_FALSE;
	samplerInfo.maxAnisotropy = 1.0f;
	samplerInfo.borderColor = VK_BORDER_COLOR_INT_OPAQUE_BLACK;
	samplerInfo.unnormalizedCoordinates = VK_FALSE;
	samplerInfo.compareEnable = VK_FALSE;
	samplerInfo.compareOp = VK_COMPARE_OP_ALWAYS;
	samplerInfo.mipmapMode = VK_SAMPLER_MIPMAP_MODE_NEAREST;
	samplerInfo.mipLodBias = 0.0f;
	samplerInfo.minLod = 0.0f;
	samplerInfo.maxLod = 0.0f;

	if (vkCreateSampler(m_info.Device, &samplerInfo, nullptr, &m_textureSampler) != VK_SUCCESS)
	{
		throw std::runtime_error("failed to create texture sampler!");
	}

Even when VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER or VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_EDGE is set, the results are the same (see image above). Maybe anyone encountered something like this? Any help is appreciated!

Are you changing the right code? The code snippet you quote appears to be from base/VulkanTexture.cpp, but the sampler used by the texture sample is in examples/texture/texture.cpp here: https://github.com/SaschaWillems/Vulkan/blob/0dc33496df5c2e3a5b3c2ae150802dc660ddfd83/examples/texture/texture.cpp#L398

Yes indeed, I have written a structured function in my application. I am just not sure what am I doing wrong with a sampler definition since it is not clamping texture (although it is defined VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER). In general, it gives the same result as using VK_SAMPLER_ADDRESS_MODE_REPEAT. I am not sure which part might cause this kind of sampler behavior.

Use RenderDoc to verify the sampler settings to rule out that you're using the wrong sampler.
P.S. : I'm closing this, as it's not an issue related to my repo. If you want to discuss further, feel free to move to the discussion section of this repo.


Exposing fabricjs canvas object within ImageEditor class

Exposing the FabricJS canvas object and the loadFromJSON FabricJS function via the core imageEditor class
http://fabricjs.com/docs/fabric.Canvas.html#loadFromJSON
Exporting Canvas example:
import ImageEditor from '@toast-ui/react-image-editor';

var canvasData = imageEditor.getCanvas();
console.log(canvasData);

After storing the whole Canvas object inside a variable, it can then be saved to MongoDB. In theory, you can then fetch this object from MongoDB and it can be restored using the loadFromJSON FabricJS function which is exposed via the imageEditor class.
Example:
import ImageEditor from '@toast-ui/react-image-editor';

const canvasData = someFunction.getCanvasFromMongoDB()
imageEditor.loadCanvas(canvasData);

FYI this is completely experimental and has not been tested. It is only for example.

@lja1018 Sure you can continue with this, I made this draft as a theoretical proof of concept but I have have not actually tried it in action


Add option to choose docker registry mirror

Some corporate environments do not allow direct access to docker hub and use their own registry that mirrors docker hub.
Please add the ability to select a Docker Registry service connector as the source to pull the image tingle/dependabot-azure-devops

This is definitely a good idea. Could you put in a PR?

Yup.


WG: A device will sometimes fail to connect to the game

While the other devices have the option to enter their starting article, lagged-out devices just read "Waiting for other players..." while the game is ongoing.

This occurred on the old Samsung tablet from the equipment case.

Just had this occur again with an iPad. The device joined on the hub screen, but didn't appear to on the device screen. Trying to join the lobby returned a message that the name was already used.

Just referenced you in the issue this one references. Erika thinks its related, which seems to be the case.

Need ti verify fixed with new updates

Unable to reproduce


deploy-service scs fails

Hi,
Installed pcfdev-v1.2.0-darwin.tgz on MacBook Pro with 16GB ram (same error occurs on Linux Bionic Beaver with 16G ram, so Tried multiple OS-es). works as expecte, but when I deploy service scs, the deployment fails. Added the last part of the deployment log, since I have the feeling that the phrase "Service broker error: Could not find an available leader" has something to do with it. I have the same error when I try to bind the "spring music test app" to mysql service.
(Service broker error: Could not find an available leader from [https://<IP_ADDRESS>:8443]). Below the deploy-service scs log.
Organization 'p-spring-cloud-services' not found.
Space 'instances' not found.
Space 'p-spring-cloud-services' not found.
App spring-cloud-broker-venerable not found
App spring-cloud-broker not found
App spring-cloud-broker not found
App spring-cloud-broker-worker not found
Service instance spring-cloud-broker-db not found
Unexpected Response
Response code: 502
CC code: 0
CC error code:
Request ID: 358f67d4-112b-499f-7b5b-d5b9a7631289::082b9a30-0afa-47f2-93ea-36d3da80ca33
Description: {
"description": "Service broker error: Could not find an available leader from [https://<IP_ADDRESS>:8443]",
"error_code": "CF-ServiceBrokerBadResponse",
"code": 10001,
"http": {
"uri": "http://<IP_ADDRESS>:8080/v2/service_instances/828aa933-a3f4-48bd-b254-367ca165374a/service_bindings/4ce8d30a-ef09-433a-b51a-3c120b7b7f11",
"method": "PUT",
"status": 500

Could you please post you CF CLI version?
$ cf --version
...

Could you please post your CF CLI version?

$ cf --version

...
cf version
6.51.0+2acd15650.2020-04-07
�

--

You are receiving this because you authored the thread.

Reply to this email directly or view it on GitHub:

https://github.com/cloudfoundry-incubator/cfdev/issues/132#issuecomment-649539833

Hi,
cf version is:
cf version 6.51.0+2acd15650.2020-04-07

As was mentioned in https://github.com/pivotal-cf/pcfdev/issues/393#issuecomment-652761586:
This is caused by the expiration of internal certificates used in the Spring Cloud Services execution path.
# /var/vcap/sys/log/broker/broker.log
[on-demand-service-broker] [f347182b-3834-4f1d-9648-d92ebbe8fb51] 2020/06/30 22:47:58.061686 service adapter will delete binding with ID b3756eda-c00f-42c2-b9fa-dbb78fd06ddd for instance 0b252b61-0831-4cf3-a920-bd68dc012a20
[on-demand-service-broker] [f347182b-3834-4f1d-9648-d92ebbe8fb51] 2020/06/30 22:47:58.088705 external service adapter exited with 1 at /var/vcap/packages/odb-service-adapter/bin/service-adapter:
stdout:
    'Could not find an available leader from [https://<IP_ADDRESS>:8443]',
stderr: '
    [odb-sdk] handling delete-binding
    [dedicated-mysql-adapter] 2020/06/30 22:47:58 Using agent deleter
    [dedicated-mysql-adapter] 2020/06/30 22:47:58 Couldn't get read only information about URL https://<IP_ADDRESS>:8443, error: &errors.errorString{s:"GET https://<IP_ADDRESS>:8443/status failed: Get https://<IP_ADDRESS>:8443/status: x509: certificate has expired or is not yet valid"}
    [odb-sdk] Could not find an available leader from [https://<IP_ADDRESS>:8443]
    '

To rectify, I just released updates for the CF Dev product that will have newer certificates. This means that the problem is abated but, of course, not resolved forever.
New Release

v0.0.18 (plugin) - https://plugins.cloudfoundry.org/#cfdev
v1.3.0 (Service Assets) - https://network.pivotal.io/products/pcfdev/#/releases/685614

Thank you for raising this issue.

Hi @aemengo,
Thnx!
I can confirm that the install service scs works and I'm able to bind the spring-music app to the mysql service.
Thnx again for the support.


Add some logging to identify test failure

Codecov Report

Merging #8600 (938fcaf) into main (558b921) will decrease coverage by 0%.
The diff coverage is 100%.

:exclamation: Current head 938fcaf differs from pull request most recent head e5f5010. Consider uploading reports for the commit e5f5010 to get more accurate results

@@          Coverage Diff          @@
##            main   #8600   +/-   ##
=====================================
- Coverage     71%     71%   -1%
=====================================
  Files        381     381
  Lines      24471   24472    +1
  Branches    3758    3757    -1
=====================================
- Hits       17495   17469   -26
- Misses      5463    5484   +21
- Partials    1513    1519    +6

Impacted Files
Coverage Δ

...ent/common/process/environmentActivationService.ts
79% <100%> (+<1%)
:arrow_up:

...ience/variablesView/variableViewMessageListener.ts
77% <0%> (-23%)
:arrow_down:

...ent/common/application/webviewViews/webviewView.ts
67% <0%> (-11%)
:arrow_down:

.../client/datascience/debugLocationTrackerFactory.ts
92% <0%> (-4%)
:arrow_down:

...lient/datascience/jupyter/kernels/cellExecution.ts
73% <0%> (-4%)
:arrow_down:

...ence/editor-integration/cellHashProviderFactory.ts
97% <0%> (-3%)
:arrow_down:

src/client/datascience/raw-kernel/rawSocket.ts
82% <0%> (-2%)
:arrow_down:

src/client/datascience/webviews/webviewHost.ts
80% <0%> (-2%)
:arrow_down:

...t/datascience/notebook/vscodeNotebookController.ts
78% <0%> (-1%)
:arrow_down:

...ient/datascience/editor-integration/codewatcher.ts
70% <0%> (-1%)
:arrow_down:


cmd/vendor: ignore invalid XML after  tag

Addressing #642, port two changes from the upstream basis for the "vendor fetch" remote import path parser:

Go change 14482
cmd/go: use RawToken to parse remote package metadata
Go change 18051
cmd/go: ignore XML errors after Go  tags

The first allows "vendor fetch" to accept a server response that matches the "go help importpath" documentation literally, providing solely a "meta" start tag as the entire document. More broadly, it accepts XML documents with improperly nested or even missing elements.
The latter allows "vendor fetch" to accept responses that contain invalid XML encountered after having read at least one "meta" start tag successfully, here the invalidity being due to violations other than element nesting.

LGTM. and the verification failed on go 1.4.3 only

@davecheney, do you have any feedback on or concerns with this proposal?

Sorry I let this drop. I changed jobs a few months ago and have had zero
spare time since then.
On Fri, Sep 23, 2016 at 12:49 AM, Steven E. Harris<EMAIL_ADDRESS>
wrote:

@davecheney https://github.com/davecheney, do you have any feedback on
or concerns with this proposal?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/constabulary/gb/pull/643#issuecomment-248926067, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA5cQV5aromfxh3o83MpUBH9UkyEKks5qspVlgaJpZM4J8Aje
.

Thanks. I've fixed the integration test failure.