runtime: sporadic but frequent "signal: illegal instruction" during all.bash on darwin/arm64 at CL 272258 PS 1

CL 272258 has made it easy to run all.bash, so I ran it a few times. It has passed at least once, but most of the some test will fail due to "signal: illegal instruction".
This is on a MacBook Air (M1, 2020), macOS 11.0.1 (20B29).
This may get resolved as part of finishing work on #42684, but reporting this in case these failures are helpful to see sooner, since I don't think of any existing macOS/ARM64 issues cover this failure mode specifically.
What version of Go are you using (go version)?

$ go version
go version devel +7716a2fbb7 Sun Nov 22 11:44:49 2020 -0500 darwin/arm64

What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/dmitri/Library/Caches/go-build"
GOENV="/Users/dmitri/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/dmitri/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/dmitri/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/dmitri/go116r2"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/dmitri/go116r2/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="devel +7716a2fbb7 Sun Nov 22 11:44:49 2020 -0500"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/go-build446541792=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Built Go at commit 7716a2fbb7 (CL 272258 PS 1) successfully, pointed GOROOT_BOOTSTRAP to it, then checked out the same commit elsewhere and ran all.bash repeatedly.
What did you expect to see?
$ ./all.bash
Building Go cmd/dist using /Users/dmitri/go116r2. (devel +7716a2fbb7 Sun Nov 22 11:44:49 2020 -0500 darwin/arm64)
Building Go toolchain1 using /Users/dmitri/go116r2.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/arm64.

[...]

What did you see instead?

Building Go toolchain2 using go_bootstrap and Go toolchain1.
go build internal/testlog: /Users/dmitri/go116r2/pkg/tool/darwin_arm64/compile: signal: illegal instruction
go tool dist: FAILED: /Users/dmitri/go116r2/pkg/tool/darwin_arm64/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 1

--- FAIL: TestCover (1.48s)
    cover_test.go:141: running [go -build -o /var/folders/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/go-testcover103682725/toolexec.exe testdata/toolexec.go]
    cover_test.go:130: running [go build -o /var/folders/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/go-testcover103682725/cover.exe]
    cover_test.go:173: failed to build testcover or toolexec program: signal: illegal instruction
--- FAIL: TestCoverHTML (1.48s)
    cover_test.go:390: failed to build testcover or toolexec program: signal: illegal instruction
--- FAIL: TestFuncWithDuplicateLines (1.48s)
    cover_test.go:537: failed to build testcover or toolexec program: signal: illegal instruction
--- FAIL: TestHtmlUnformatted (1.48s)
    cover_test.go:454: failed to build testcover or toolexec program: signal: illegal instruction
--- FAIL: TestDirectives (1.48s)
    cover_test.go:249: failed to build testcover or toolexec program: signal: illegal instruction
--- FAIL: TestCoverFunc (1.48s)
    cover_test.go:368: failed to build testcover or toolexec program: signal: illegal instruction
FAIL
FAIL	cmd/cover	1.728s

--- FAIL: TestDWARF (0.85s)
    --- FAIL: TestDWARF/testprog (1.75s)
        dwarf_test.go:99: symbols testprog.exe: exit status 255: /var/folders/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/go-link-TestDWARF652205567/testprog.exe [arm64, 0.054295 seconds]:
                null-uuid                            /private/var/folders/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/go-link-TestDWARF652205567/testprog.exe [AOUT, PIE, FaultedFromDisk]
                    0x0000000000000000 (0x100000000) __PAGEZERO SEGMENT
                    0x0000000100000000 ( 0xf0000) __TEXT SEGMENT
                        0x0000000100000000 (  0x1000) MACH_HEADER
                        0x0000000100001000 ( 0xc6c90) __TEXT __text
                            0x0000000100001000 (    0x70) go.buildid [FUNC, NameNList, MangledNameNList, Merged, NList]
                            0x0000000100001070 (    0x50) internal/cpu.Initialize [FUNC, NameNList, MangledNameNList, NList]
[...]
                            0x00000001002683a8 (     0x8) p [EXT, NameNList, MangledNameNList, NList]
                            0x00000001002683b0 (     0x4) threadExited [EXT, NameNList, MangledNameNList, NList]
                    0x000000010026c000 ( 0x402d2) __LINKEDIT SEGMENT
            symbols[31119]: [fatal]  child process status could not be determined; exit code unavailable.
FAIL
FAIL	cmd/link	20.081s

(Full log for TestDWARF/testprog failure.)
CC @cherrymui.

It's worth trying with GODEBUG=asyncpreemptoff=1 set /cc #42700

I think that issue is about running Go darwin/amd64 port under Rosetta 2. This is about running the darwin/arm64 port natively.
I can try it anyway to see what effect it has.

Interesting. Looks similar to #41702. If I'm not mistaken, all failed cases above involve starting processes. Maybe it is more likely to fail on ARM64 than AMD64? Maybe the workaround in #41702 is not effective enough?
@tmm1 this is not Rosetta 2, so #42700 is irrelevant.
That said, GODEBUG=asyncpreemptoff=1 is a workaround of #41702 as well.

I rarely see this on the DTK. I think I never see it since the workaround of #41702 is added. It is interesting that it more likely to fail on M1.
Does TestExec in syscall package pass reliably?

I've also seen this happen a few times. Interestingly the place I ran into it most often is when running the io benchmarks, particularly BenchmarkCopyNLarge-8.
~/go/src % ../bin/go test ./io -run=XXX -bench=. -count=10
goos: darwin
goarch: arm64
pkg: io
BenchmarkCopyNSmall-8   	 5467614	       425.9 ns/op
BenchmarkCopyNSmall-8   	 3287067	       428.3 ns/op
BenchmarkCopyNSmall-8   	 5085464	       740.8 ns/op
BenchmarkCopyNLarge-8   	signal: illegal instruction
FAIL	io	24.012s
FAIL

Does TestExec in syscall package pass reliably?

I believe it does:

$ go version
go version devel +7716a2fbb7 Sun Nov 22 11:44:49 2020 -0500 darwin/arm64
$ go test  -run=TestExec syscall
ok  	syscall	0.500s
$ go test -count=1 -run=TestExec syscall
ok  	syscall	0.227s
$ go test -count=10 -run=TestExec syscall
ok  	syscall	1.216s
$ go test -count=100 -run=TestExec syscall
ok  	syscall	7.949s
$ go test -count=1 -v -run=TestExec syscall
=== RUN   TestExec
--- PASS: TestExec (0.02s)
=== RUN   TestExecHelper
--- PASS: TestExecHelper (0.00s)
=== RUN   TestExecPtrace
--- PASS: TestExecPtrace (0.00s)
=== RUN   TestExecErrPermutedFds
--- PASS: TestExecErrPermutedFds (0.00s)
PASS
ok  	syscall	0.193s

I'm able to reproduce @rolandshoemaker's finding above with go test io -run='^$' -bench=BenchmarkCopy -count=10, 5 out of 5 times. It triggers within 5-30 seconds.

Trying out GODEBUG=asyncpreemptoff=1. So far, it made BenchmarkCopy work okay 2 out of 2 times, as well as all.bash has passed 2 out of 2 times with it set. I'll edit this comment if that changes.

Okay, I can reproduce the SIGILL with running the io benchmarks in a loop on the DTK, although with a much lower failure rate. I'll take it from there. (I'll be OOO this afternoon, though, so I probably won't get back to this very soon.)

Crash report for this error: https://gist.github.com/tonistiigi/23fbd4be8d1562ff935aa36b2dcdb299
With GODEBUG=asyncpreemptoff=1 ./io.test benchmark doesn't reproduce issue for me either.

@tonistiigi thanks for the crash report. I can reproduce the failure and get similar crash reports. I also managed to get a core dump, which is also quite similar.
In the crash report, it says it SIGILLs at __psynch_cvwait + 8, which doesn't make sense. It points to a valid instruction (b.lo $pc-4). In the core dump, the register and stack trace matches, and the memory it points to does have valid instructions. However, the core dump doesn't specify which thread crashes, so I checked them all, and found that two other threads, the PC of which are supposed to be in __semwait_signal and __pthread_kill, respectively, but actually in a page of zeros. This page is next to __psynch_cvwait and in the range of libsystem_kernel.dylib. That page should be mapped read-only, right? So it should not be possible for Go the overwrite that page.
It could be the core file being somehow truncated. Or, if it is actually right, somehow a page of system functions is replaced with a page of  0. I'll try to get more core files.
I haven't been able to get a crash while running under lldb (to eliminate the possibility of truncated core file).
Either way, it seems it crashed in some system function, with SIGILL. I don't see how that could be possible from the Go runtime.  In this case it doesn't. The only possibilities I can think of is that it crashes before the runtime is initialized, or it SIGILLs while handing signal (so it cannot handle another signal). From the crash report and the core dump, neither seems the case. Maybe the kernel directly kills it when it sees SIGILL in a system library?

Hmmm, running in the debugger I saw the runtime does a few MAP_FIXED mmaps at fairly low addresses. I'll look into why it does that.

The crash report from @tonistiigi https://github.com/golang/go/issues/42774#issuecomment-732432290 doesn’t look like a genuine SIGILL triggered by a hardware trap to me. It looks like the process itself called kill(getpid(), SIGILL).
https://gist.github.com/tonistiigi/23fbd4be8d1562ff935aa36b2dcdb299:
Exception Type:        EXC_CRASH (SIGILL)
Exception Codes:       0x0000000000000000, 0x0000000000000000

This is suspicious: a genuine illegal instruction in hardware will transform into EXC_BAD_INSTRUCTION, and codes[0] will appear as, in nearly every case, EXC_ARM_UNDEFINED. It will never be 0. Actually, it won’t be translated symbolically, it’ll show up numerically as 0x0000000000000001. Refer to 10.15.6 xnu-6153.141.1/osfmk/arm64/sleh.c handle_uncategorized, handle_wf_trap, handle_msr_trap, handle_user_trapped_instruction32, and handle_simd_trap. codes[1] would be the instruction, although seeing 0 here isn’t suspicious, as 0 is indeed an illegal instruction in arm64. In fact, asm(".long 0") is my preferred way to trigger this fault when I need to.
Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   io.test [65832]

Still more suspicious stuff here: for a genuine hardware trap, the Mach exception will be transformed to a signal by the in-kernel exc/mach_exc subsystem server, in 10.15.6 xnu-6153.141.1/bsd/uxkern/ux_exception.c handle_ux_exception. That would be blamed as the terminating process (although, as an in-kernel Mach server, it’s not a “process” in the strictest sense, but since it will have been operating on behalf of the faulting process, the PID will be the crashing process’ own PID). Here, you’d expect:
Terminating Process:   exc handler [65832]

Looks to me like this isn’t a hardware trap at all, but a software SIGILL. On the other hand, if you’re catching SIGILL and re-raising by calling, for example, kill(getpid(), SIGILL) rather than letting execution resume at the faulting instruction without your signal handler in place, the software SIGILL may ultimately have a hardware origin. In that case, though, information about the true origin of the SIGILL will unfortunately have been lost, making debugging a trickier proposition than it needs to be.
Is there anywhere a SIGILL might be generated in software by code?
@cherrymui https://github.com/golang/go/issues/42774#issuecomment-732545188:

However, the core dump doesn't specify which thread crashes, so I checked them all, and found that two other threads, the PC of which are supposed to be in __semwait_signal and __pthread_kill, respectively, but actually in a page of zeros.

If you see a thread in __pthread_kill, it just may be the source of the software SIGILL that’s taking things down.

I went through all my crash reports. While most of them are identical to the one I posted earlier (and with the same pc), I did find two that were quite different. https://gist.github.com/tonistiigi/9d0d40afe5248932cdac266c357d3135 . One of them has a stacktrace to pthread_kill.

No, I don't think the Go program send itself a SIGILL. The __pthread_kill is likely to send SIGURG.

Exception Type:        EXC_CRASH (SIGILL)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00000001e54c75d0 __pthread_kill + 8
1   libsystem_pthread.dylib       	0x00000001e5572c54 pthread_kill + 292
2   a.out                         	0x0000000100c3ff5c main + 36
3   libdyld.dylib                 	0x00000001e5356844 start + 4

Here is what I got for a process pthread_kill itself with SIGILL. The Exception Type and Exception Codes look like above, but it doesn't have Termination Signal, etc.

I reproduced this 0/10 times running all.bash and 0/15 times running go test io -run='^$' -bench=BenchmarkCopy -count=10 on my DTK running 11.0.1 20B29. My M1 isn’t here yet.
Are others seeing this only on a different OS version than I’m using? Or is the hardware the crucial difference?
OK, I only thought I reproduced 0/10 running all.bash, but when I checked ~/Library/Logs/DiagnosticReports, I saw a single crash from link, although I never saw anything like go tool link: signal: illegal instruction at all.
Process:               link [34564]
[…]
Code Type:             ARM-64 (Native)
[…]
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGILL)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   link [34564]

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib              0x000000018ff3f488 __psynch_cvwait + 8
1   libsystem_pthread.dylib             0x000000018ff75568 _pthread_cond_wait + 1192
2   link                                0x00000001043526d8 runtime.pthread_cond_wait_trampoline + 24
3   link                                0x00000001043515b8 runtime.asmcgocall + 200

I did some dtrace. It appears something sends a SIGILL signal. The kernel stack varies. Apparently, the kernel entry points can be a syscall (e.g. madvise), somewhere in user code (not syscall, e.g. runtime.scanobject), or no explicit entry point.
  4   2606 get_system_inshutdown:signal-send pid=606 tid=54569 io.test send signal 4

              kernel.release.t8027`0xfffffe00202d9038+0x244
              kernel.release.t8027`0xfffffe00202d9540+0x494
              kernel.release.t8027`0xfffffe001fde79f4+0xdc
              kernel.release.t8027`0xfffffe001fdabd9c+0xc
              0x1c4dee4d0 // _madvise

  6   2606 get_system_inshutdown:signal-send pid=590 tid=53893 io.test send signal 4

              kernel.release.t8027`0xfffffe00202d9038+0x244
              kernel.release.t8027`0xfffffe00202d9540+0x494
              kernel.release.t8027`0xfffffe001fde79f4+0xdc
              kernel.release.t8027`0xfffffe001fdabd9c+0xc
              kernel.release.t8027`0xfffffe001fef6714+0x564
              kernel.release.t8027`0xfffffe001fdab858+0x28
              0x1003337f0 // runtime.markrootSpans

  3   2606 get_system_inshutdown:signal-send pid=572 tid=53266 io.test send signal 4

              kernel.release.t8027`0xfffffe00202d9038+0x244
              kernel.release.t8027`0xfffffe00202d9540+0x494
              kernel.release.t8027`0xfffffe001fde79f4+0xdc
              kernel.release.t8027`0xfffffe001fdabd9c+0xc
              kernel.release.t8027`0xfffffe001fde7d24
              kernel.release.t8027`0xfffffe001fdb47c0+0x7c

The top 4 frames are essentially always the same, but lower frames vary.
The user stack also varies.
On contrast, for a program pthread_kill itself with SIGILL,
  2   2606 get_system_inshutdown:signal-send pid=394 tid=11884 a.out send signal 4

              kernel.release.t8027`0xfffffe001170d210+0x2e4
              kernel.release.t8027`0xfffffe0011236714+0x274
              kernel.release.t8027`0xfffffe00110eb858+0x28
              0x1d258f5d0 // __pthread_kill

It is a different code path, and the entry point is always __pthread_kill.
I also traced syscall __pthread_kill and I didn't see any SIGILL (all SIGURG).

That's definite progress! Can you symbolize those kernel frames or even try the debug kernel?

I don't know how to do that. Tried sym(address) and func(address) with dtrace and it still just prints the hex.

I tried to manually symbolize a kernel stack trace (by comparing the kernel memory with the symbol information of a kernel with a nearby version):
  6   2606 get_system_inshutdown:signal-send pid=670 tid=51032 io.test send signal 4 to 670 51030

              kernel.release.t8027`0xfffffe001765d038+0x244 // postsig_locked
              kernel.release.t8027`0xfffffe001765d540+0x494 // bsd_ast
              kernel.release.t8027`0xfffffe001716b9f4+0xdc  // ast_taken_user
              kernel.release.t8027`0xfffffe001712fd9c+0xc   // user_take_ast
              kernel.release.t8027`0xfffffe001716bd24       // ???
              kernel.release.t8027`0xfffffe00171387c0+0x7c  // _Call_continuation

The fifth frame is weird, as it is not a call instruction. Maybe a faked return address? I'll see if I can make sense of it...

This is another case:
  0   2606 get_system_inshutdown:signal-send pid=671 tid=51041 io.test send signal 4 to 671 51037

              kernel.release.t8027`0xfffffe001765d038+0x244 // postsig_locked
              kernel.release.t8027`0xfffffe001765d540+0x494 // bsd_ast
              kernel.release.t8027`0xfffffe001716b9f4+0xdc  // ast_taken_user
              kernel.release.t8027`0xfffffe001712fd9c+0xc   // _arm64_thread_exception_return (label user_take_ast)
              kernel.release.t8027`0xfffffe001727a714+0x564 // sleh_synchronous ???
              kernel.release.t8027`0xfffffe001712f858+0x28  // fleh_synchronous
              0x102387f84 // user code

Not quite sure about sleh_synchronous frame. It seems changed quite a bit from the in-memory kernel to the one with symbol information.
For comparison, this is the case that it pthread_kill SIGILL itself:
  2   2606 get_system_inshutdown:signal-send pid=1317 tid=176087 a.out send signal 4 to 0 176090

              kernel.release.t8027`0xfffffe0017751210+0x2e4 // unix_syscall
              kernel.release.t8027`0xfffffe001727a714+0x274 // sleh_synchronous ???
              kernel.release.t8027`0xfffffe001712f858+0x28  // fleh_synchronous
              0x1d66235d0 // __pthread_kill

@cherrymui https://github.com/golang/go/issues/42774#issuecomment-733852153, https://github.com/golang/go/issues/42774#issuecomment-733992157, https://github.com/golang/go/issues/42774#issuecomment-734014274:

kernel.release.t8027

What OS version are you using (sw_vers or uname -v)? I suspect that it’s quite out of date.
On 11.0.1 20B29, the kernel is named kernel.release.t8020 for the DTK (A12) and kernel.release.t8101 for production hardware (M1, note that T8101 is the same designation for M1 and A14).
kernel.release.t8020 is the kernel that the DTK since 11.0db4 20A5343i (2020-08-04). kernel.release.t8027 was also present in earlier betas, as late as 11.0db3 20a5323l (2020-07-22). T8027 indicates A12X/A12Z, A12Z being the part in the DTK, and is more specific than T8020, but it seems that the two kernels were merged into a single one with the more generic T8020 label as the beta period progressed.
The point I’m getting at is that the kernel on your DTK may be a beta that’s at least 4 months old, either the original 11.0db1 20A5299w that it shipped with, or a very early intermediate beta up to 11.0db3 20a5323l. This is going to be a very different animal than what’s in the factory image now shipping with M1-based machines (11.0 20A2411), the current released kernel for both DTK and M1 (11.0.1 20B29/20B50), and the current beta for both (11.1b1 20C5048k). This isn’t the a kernel that we should be testing against at this point.
The KDK for those old releases where there was a separate T8027 kernel never included a .dSYM for them either, so it won’t be the nicest possible debugging experience. (Incidentally, the newer post-M1 KDKs don’t include any T8101 kernels at all, so it is good that you’re able to do this on a DTK, where .dSYMs are available for contemporary release and beta kernels, and debug kernels are also an option.)

I have the original 20A5299w kernel. I tried to update the DTK earlier but somehow it failed, and I didn't try again. I understand this is not a good debugging experience. I'll try updating it again at some point.

I kept looking anyway, and as you may have found, the T8020 and T8027 kernels in those early releases were identical, so I was able to use the T8020 .dSYM from the 20A5299w KDK. Nothing much came of that, it basically confirmed your symbolization. But I was looking at what seemed to be the most promising stack you shared:
mark@sweet16 zsh% pbpaste
              kernel.release.t8027`0xfffffe001765d038+0x244 // postsig_locked
              kernel.release.t8027`0xfffffe001765d540+0x494 // bsd_ast
              kernel.release.t8027`0xfffffe001716b9f4+0xdc  // ast_taken_user
              kernel.release.t8027`0xfffffe001712fd9c+0xc   // _arm64_thread_exception_return (label user_take_ast)
              kernel.release.t8027`0xfffffe001727a714+0x564 // sleh_synchronous ???
              kernel.release.t8027`0xfffffe001712f858+0x28  // fleh_synchronous
              0x102387f84 // user code
mark@sweet16 zsh% pbpaste | sed -En -e 's/^.*kernel\.release\.t8027`([^ ]+).*$/print(hex(\1))/p' | python3 | atos -o kernel.release.t8020.dSYM/Contents/Resources/DWARF/kernel.release.t8020 -s 0xff68000
postsig_locked (in kernel.release.t8020) (kern_sig.c:3359)
bsd_ast (in kernel.release.t8020) (kern_sig.c:3573)
ast_taken_user (in kernel.release.t8020) (ast.c:219)
user_take_ast (in kernel.release.t8020) + 12
sleh_synchronous (in kernel.release.t8020) (sleh.c:594)
fleh_synchronous (in kernel.release.t8020) + 40

(0xff68000 computed as 0xfffffe001765d038 minus the address shown by nm kernel.release.t8020.dSYM/Contents/Resources/DWARF/kernel.release.t8020 | grep ' [Ss] _postsig_locked$'.)
Nothing too new or interesting there, and we can’t do much with the filenames and line numbers without a source drop. So I looked for other sources of SIGILL in xnu that aren’t strictly hardware traps, and I found one, right in 10.15.6 xnu-6153.141.1/bsd/dev/arm/unix_signal.c sendsig. Incidentally, that’s exactly where bsd/kern/kern_sig.c postsig_locked calls into.
At the bottom of sendsig, at the label bad, you’ll see a hard-coded SIGILL. bad is used when an error occurs while attempting to fulfill a request to send a signal to a user-space handler. Here, the errors can be in getting or setting thread state, or in copying data to user-space, so as to establish the user-space handler’s stack frame. This SIGILL is forced to SIG_DFL, which also agrees with your observation that the user-space handler never ran to show a backtrace.
(x86_64 need not feel left out, it has the same SIGILL behavior in bsd/dev/i386/unix_signal.c sendsig.)
Here’s a sample: t_impossible_sigaltstack. It sets up a sigaltstack to handle SIGABRT, but sets the protection on it to PROT_NONE, preventing the kernel from setting up the stack frame, before calling abort() to crash. You were expecting SIGABRT? In reality:
mark@arm-and-hammer zsh% clang++ -Wall -Werror t_impossible_sigaltstack.cc -o t_impossible_sigaltstack
mark@arm-and-hammer zsh% ./t_impossible_sigaltstack
zsh: illegal hardware instruction  ./t_impossible_sigaltstack
mark@arm-and-hammer zsh% cat less Library/Logs/DiagnosticReports/t_impossible_sigaltstack_*.crash
Process:               t_impossible_sigaltstack [72514]
[…]
Code Type:             ARM-64 (Native)
[…]
Exception Type:        EXC_CRASH (SIGILL)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   t_impossible_sigaltstack [72514]

Application Specific Information:
dyld2 mode
abort() called

(Another note: sigaltstack is broken for arm64 in the 10.15.6 xnu sources, but it’s working in 11.0. Doesn’t actually matter for this bug, though: the 10.15.6 xnu source shows everything you need to see how this SIGILL is generated.)
How to dig deeper from here? Well, the Mach exception type that was recorded (here, EXC_CRASH) will actually be the true exception type from the original hardware fault if there was one, and will be EXC_CRASH if it was a software fault. Since your reports don’t show EXC_BAD_INSTRUCTION, they’re not real illegal instructions at all, they’re just failures to invoke the user-space signal handler. In fact yours are showing EXC_CRASH, just like my example here.
Since golang is a heavy user of SIGURG internally, and since you mentioned that the __pthread_kill calls I originally suggested might be relevant were raising SIGURG, I think we have a very strong theory that the problem is a failure to invoke the user-space SIGURG signal handler. You don’t normally think of SIGURG as being a fatal signal, because its default disposition (at SIG_DFL) is to be discarded, but in fact when a user-space handler can’t be invoked, the default disposition of SIGILL will be the controlling behavior.
The remaining question concerns why the user-space signal handler couldn’t be invoked. It could be something like my example here, with an unusable signal stack. Conceivably, it could be stack exhaustion or some other memory problem, or it could be a problem with the user thread state or signal handler thread state. But I think that this new lead will be valuable in troubleshooting this further.

the T8020 and T8027 kernels in those early releases were identical

Interesting. The T8020 kernel I found isn't identical to the running T8027 kernel, just pretty close. There are small changes here and there, like off by one instruction. The relative PCs generally don't match. So I had to do some manual work.
signaltstack may be the right direction. We do use sigaltstack, and if I disable it it seems no longer SIGILLs. I'll look more on that direction.
Out of curiosity, I wonder why the kernel chooses SIGILL in this situation. (I hope it is not a typo of SIGKILL...)

For people who want to try, the CL above disables sigaltstack. It seems to fix this on my machine.

Interesting. The T8020 kernel I found isn't identical to the running T8027 kernel, just pretty close. There are small changes here and there, like off by one instruction. The relative PCs generally don't match. So I had to do some manual work.

If you have ADC access, log in to it by clicking Downloads on the ADC page here and then download Kernel_Debug_Kit_11.0_build_20A5299w.dmg. If you don’t have an ADC account, find me internally.

signaltstack may be the right direction. We do use sigaltstack, and if I disable it it seems no longer SIGILLs. I'll look more on that direction.

I suspect that the conditions to trigger the bug are merely more likely with a sigaltstack in effect, but doubt that they disappear entirely without sigaltstack. They may become so rare that testing won’t show them, though.
That said, sigaltstack working on arm64 in xnu at all is a brand-new thing.

Out of curiosity, I wonder why the kernel chooses SIGILL in this situation. (I hope it is not a typo of SIGKILL...)

It’s been there forever: 10.0.0 /xnu-123.5/bsd/dev/ppc/unix_signal.c sendsig. That’s from way before all of these SIGKILLs were fashionable. We’re way off in the fringe edges of xnu that don’t see much love or attention. I bet that it was sorta-intentionally chosen over 20 years ago and then simply forgotten.
Very interesting: https://github.com/golang/go/issues/41702 is another way to get the same SIGILL to trigger, although presumably that exact trigger has been worked around. Recent, too.
🦃

Apparently, it more likely to fail when the system is under load (e.g. running multiple instances of the test in parallel). So, one assumption is that it likely to fail when the signal stack is not faulted in when the signal happens. So I tried to mlock the signal stack, and it does seem to fix this.
CL https://golang.org/cl/273686 does the mlock. For people who want to try, let me know if that works on your machine. Thanks!

Oh, that’s a good find. I thought that this might have to do with faulting in the signal stack, but despite spending a half hour trying to reproduce the problem with purge, I had no luck.

If you have ADC access, log in to it by clicking Downloads on the ADC page here and then download Kernel_Debug_Kit_11.0_build_20A5299w.dmg.

I couldn't find 20A5299w kernel debug kit on that download page... So I downloaded 20A2411 and hoped for the best...

I tried CL 272258 (aka commit 7716a2fbb7abc24f1069b1fc4c4b10b2274eee8a) with and without the above sigaltstack revert CL 273627 rebased on top.
With revert, all.bash passed 3/3 times.
Without revert, all.bash passed 5/5 times.
When I filed this issue, all.bash was failing at 7716a2fbb7abc24f1069b1fc4c4b10b2274eee8a what felt like 80% of the time—I'm not sure what has changed since then to cause it to start to pass so often. (I checked and GODEBUG was unset.)

I’ve come up with a reduced C testcase that exhibits the bug fairly readily: t_fault_sigaltstack.cc. It should be possible to use this to prototype other possible workarounds, and for filing with Apple.
If it doesn’t crash with SIGILL shortly after starting it, start while true; do sudo purge; done (either before or while t_fault_sigaltstack is running) and it should crash.
Process:               t_fault_sigaltstack [80089]
[…]
Code Type:             ARM-64 (Native)
[…]
Crashed Thread:        1

Exception Type:        EXC_CRASH (SIGILL)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   t_fault_sigaltstack [80089]

Application Specific Information:
dyld2 mode

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib              0x000000018ff43cec __pthread_kill + 8
1   libsystem_pthread.dylib             0x000000018ff74c24 pthread_kill + 292
2   t_fault_sigaltstack                 0x0000000102b9dd60 main + 360
3   libdyld.dylib                       0x000000018ff90f54 start + 4

Thread 1 Crashed:
0   libsystem_kernel.dylib              0x000000018ff3f284 __semwait_signal + 8
1   libsystem_c.dylib                   0x000000018feb93a0 nanosleep + 216
2   t_fault_sigaltstack                 0x0000000102b9dfb4 (anonymous namespace)::ThreadMain(void*) + 420
3   libsystem_pthread.dylib             0x000000018ff7506c _pthread_start + 320
4   libsystem_pthread.dylib             0x000000018ff6fda0 thread_start + 8
[…]

Other times, it will show the thread calling pthread_kill as the crash thread.

The key to the t_fault_sigaltstack reproduction above is that I’ve allocated the signal stacks using mmap with file backing, as opposed to MAP_ANONYMOUS, malloc, vm_allocate, etc. That makes it much easier to see the problem with just purge. In theory, if there was enough pressure that the system was actually swapping, then this bug could occur regardless of the allocation method, and even without SA_ONSTACK, but it’s certainly easier to see with a file-backed mmap.
How is Go allocating the memory used for thread stacks and signal stacks?

When I posted my last comment, I hadn't seen the other comments that came in after https://github.com/golang/go/issues/42774#issuecomment-734572649.

dmitshur: I'm not sure what has changed since then to cause it to start to pass so often
cherrymui: it more likely to fail when the system is under load

Ah, adding system load (via a io.BenchmarkCopy benchmark running) in the background while running all.bash made the initial issue very reproducible once again. I tried both CL 273627 and CL 273686, this time using background load during all.bash, and got more conclusive results:
System load in the background was generated with:
$ go test io -run='^$' -bench=BenchmarkCopy -count=10  # (run repeatedly)

original (CL 272258):
• all.bash + background load = 5/5 fail
• io.BenchmarkCopy (on its own) = 5/5 fail

CL 272258 with CL 273627 (Revert "runtime: use sigaltstack on macOS/ARM64") on top:
• all.bash + background load = 3/3 ok, but also 2 inconclusive or unrelated fails¹
• io.BenchmarkCopy (on its own) = 6/6 ok

CL 272258 with CL 273686 (runtime: mlock signal stack on macOS/ARM64) on top:
• all.bash + background load = 3/3 ok
• io.BenchmarkCopy (on its own) = 5/5 ok

¹ (details about the two inconclusive failures)
--- FAIL: TestAllDependenciesVendored (4.88s)
    --- FAIL: TestAllDependenciesVendored/std (2.84s)
        moddeps_test.go:121: /Users/dmitri/gotip/bin/go list -mod=vendor -deps ./...: read |0: bad address
        moddeps_test.go:122: (Run 'go mod vendor' in /Users/dmitri/gotip/src to ensure that dependecies have been vendored.)
FAIL
FAIL	cmd/internal/moddeps	5.452s

[...]
ok  	reflect	0.489s
ok  	regexp	0.228s
ok  	regexp/syntax	0.795s
./all.bash: line 13: 66061 Illegal instruction: 4  bash run.bash --no-rebuild
./all.bash  125.95s user 14.23s system 132% cpu 1:45.80 total
ok  	runtime	60.007s
ok  	runtime/debug	0.234s
ok  	runtime/internal/atomic	0.228s
[...]
ALL TESTS PASSED

In summary, both CL 273627 and CL 273686 seem effective at resolving the original issue on my machine.

Thanks for the C++ reproducer!

How is Go allocating the memory used for thread stacks and signal stacks?

I think they are allocated from the Go heap (free page pool), and if that cannot be satisfied the heap will grow using mmap MAP_ANONYMOUS.
We always have SA_ONSTACK set. So mlock the signal stacks should suffice as a workaround.

I just revised t_fault_sigaltstack to be a bit more robust. I plan on using this to file the bug with Apple.
I also found that if there’s only one child thread, it gives a reliable SIGILL (with a file-backed mmap) on the very first SIGURG, even without all of the purge. So I made that the default mode of operation for the test program, but you can still select the number of threads (formerly 32) with -n.
mlock is a viable workaround, but I’m worried about unnecessarily wiring too much memory as it’s a constrained resource and in fact may be limited by RLIMIT_MEMLOCK (though it’s not limited by default on macOS). It should suffice to just mlock the highest page in the stack_t given to sigaltstack, because that’s the only page that the kernel needs to write the signal handler’s stack frame to.
(macOS’ SIGSTKSZ is 128kB, and even its MINSIGSTKSZ is 32kB, or two pages on arm64. No need to wire that much memory.)

I filed FB8922558 with Apple about these uncatchable spurious SIGILLs.

Is / was this a duplicate of #35851? (Can that issue be closed now?)

@bcmills probably not. #35851 is about iOS, where we don't use sigaltstack.
There is still the possibility that #35851 is due to that when the signal is delivered to the main stack and the main stack happens to be paged out, the kernel may still by buggy (at least I can't rule out this possibility), though much unlikely. Even if this is the case, the workaround for this issue won't help, as it is specific to sigaltstack.

@cherrymui sigaltstack ought to be working on iOS 14 (and all iOS versions on x86_64 aka the simulator). You can probably address #35851 at least on newer OS versions by enabling it subject to an OS version and architecture check.

@eliasnaur what versions of iOS do we support?
Last time I checked, our iOS builder machine doesn't support sigaltstack. The builder's kernel got updated recently, though. I could try again.
For iOS simulators we always use sigaltstack, as for macOS/AMD64.

As luck would have it, Corellium recently added iOS 14 images. I've upgraded all 3 builders to iOS 14.2.

@eliasnaur what versions of iOS do we support?

I don't think we have a policy for iOS versions. However, requiring iOS 14 for working Go programs is probably too little. Perhaps disable use signal preemption on iOS <= 13?

Preemption signal is not the only issue here. It can be any signals, like user generated signals. So I don't think disabling preemption is preferable.
We could use sigaltstack+mlock on iOS >=14. But before we do that, I think we would want to understand better if #35851 is the same cause or not.

Ok, thank you for being thorough; my concern was to not leave iOS out of the fix for this issue in 1.16.
How do we understand #35851 better? FWIW, I still have the iOS 13 images ready to run.

If there is someway we can reproduce the failure more easily (like running the io benchmarks in this issue), that would be helpful. Then we can play with the workaround and other ideas and see if it is effective.
It may also be helpful if you could get a crash report.
Do you know how likely the failure occurs? From the dashboard, it seems that it failed once in February, then not failed for several months, then failed 3 times in a row in October 29, then not failed since then.
2020-10-29T19:03:09-f2c0c2b/ios-arm64-corellium
2020-10-29T18:26:18-2e6f500/ios-arm64-corellium
2020-10-29T17:53:57-3a819e8/ios-arm64-corellium
2020-02-19T21:34:59-1e43298/darwin-arm64-corellium
2019-11-25T03:41:16-9940c77/darwin-arm64-corellium
2019-11-14T17:43:48-d3c2b1f/darwin-arm64-corellium
2019-11-07T19:18:49-69dcdbd/darwin-arm64-corellium

Another possibility could be #41702. The workaround (CL https://go-review.googlesource.com/c/go/+/262817 and https://go-review.googlesource.com/c/go/+/262438) only covers GOOS="darwin". Maybe we should extend them ios as well.


GcpSpannerAutoConfiguration should expose SpannerTemplate

Currently, it only autoconfigures a SpannerOperations bean. Instead, we can just autoconfigure the spannerTemplate bean.

Why this doesn't work for you https://github.com/spring-cloud/spring-cloud-gcp/blob/master/spring-cloud-gcp-autoconfigure/src/main/java/org/springframework/cloud/gcp/autoconfigure/spanner/GcpSpannerAutoConfiguration.java#L115-L122 ?

It works, but I have declare the field as SpannerOperations instead of SpannerTemplate.

That's correct. It's better to rely on the interface instead of its implementation.
May do you mean that @Bean must return SpannerTemplate instead of its interface ?

We came to this conclusion based on other Spring template autoconfigs:
e.g.:
JdbcTemplate
CassandraTemplate

@mp911de Hey Mark, I noticed you're an author on the Cassandra config file Balint linked above. Just wanted to ask why the choice  to use the Template vs the Operations being exposed as the bean.
Thanks!

There are two perspectives: Producer and consumer.

A consumer should inject the lowest-possible API (…Operations) to not require more than is really necessary.
Producer methods should declare the actual type they produce (sometimes there are requirements to expose a supertype/interface but that's more specific) to allow for the case you really want to get hold of the …Template object.

@artembilan Sorry, for my poor wording of the issue. :)


test: make scripts_tests pass

Scripts CI action is not triggered? What can we do about this?

Scripts CI action is not triggered? What can we do about this?

It's a good question! At the latest commit, I added a path trigger to .github/workflows/scripts.yml, and the scripts test was triggered. Let's wait for the running result.

To prevent godwoken changes making scripts tests fail in the future, I suggest we run or at least check (cargo check) scripts tests when relevant godwoken code changes.

To prevent godwoken changes making scripts tests fail in the future, I suggest we run or at least check (cargo check) scripts tests when relevant godwoken code changes.

How about modifying https://github.com/godwokenrises/godwoken/blob/develop/.github/workflows/rust.yml#L26
      - name: Cargo clippy check
        env:
          RUSTFLAGS: -D warnings
        run: cargo clippy --all-targets

to
      - name: Cargo clippy check
        env:
          RUSTFLAGS: -D warnings
        run: cargo clippy --tests --all-features --all-targets

      - name: Cargo clippy check
        env:
          RUSTFLAGS: -D warnings
        run: cargo clippy --tests --all-features --all-targets

Good idea.


Feature 001 partition creation

Change project distribution
Add WSI folder for both GDC and UCH-CPDAI data
Add wsi processing files for WSI data management

Ok


Hash values aren't populated for editing when used with fields_for

I created form with the following code inside:
      <%= f.fields_for :name_translations do |fo| %>
        <%= fo.label :ru %>
        <%= fo.text_field :ru %>
        <%= fo.label :en %>
        <%= fo.text_field :en %>
      <% end  %>

When I use this form for editing, fo.object is nil and values aren't populated in the fields

This is how to do this, since the translations are a hash and don't respond to the methods ru/en in your case:
= f.fields_for :name_translations, document.name_translations do |fo|
  = fo.text_field :ru, value: fo.object["ru"]
  = fo.text_field :en, value: fo.object["en"]


Fixed rendering issue of callout

Should be a minor change but need to check PDF output to verify that the fix works in both HTML and PDF.

Can one of the admins verify this patch?

Add to whitelist


pulse for a limited duration

Would it be possible to add a setting that stops the pulse animation after a number of seconds?
Something like:
var pulsingIcon = L.icon.pulse({iconSize:[20,20],color:'red', pulseDuration: 5});

Hi , if anyone is still interested you can edit this part in "L.Icon.Pulse.js" file.
Line 21 - animation-iteration-count defaults to infinite, you can change count to number of pulses you would like before.
` var after = [
            'box-shadow: 0 0 6px 2px '+this.options.color,

            'animation: pulsate ' + this.options.heartbeat + 's ease-out',
            'animation-iteration-count: 1',
            'animation-delay: '+ (this.options.heartbeat + .1) + 's',
        ];

`


Add ppc64le arch to build pipeline

This PR adds ppc64le to the build pipeline.
It's a requirement to build k3s in automated way.

Ping. News on this?

News on merging this PR?


Replace all instances of Log in to Sign In

This makes sense as there are no instances of log out on the site. Methods and URL also uses sign_in

We have renamed those on purpose because "sign in", "sign out" and "sign up" is confusing. The idea is to use three different words. However, we can't rename Devise internals, as it is backwards inompatible, so only the text mentions "log in" and "register" and similar.


Modify ImageDownloaderDelegate to accept URLReponse

Changed imageDownloader(_:didDownload:for:) to imageDownloader(_:didDownload:with:) accepting the returned URLResponse from the request.
This allows modifying the image data (like decrypting) based on the response the server sends (for example a specific header)

@FaizanDurrani
Thanks for this PR.
I believe it is a good direction and I'd like to have this in the new version. However, the implementation here breaks the public API and it requires a major upgrade. I am not sure if it worths a major version for just this commit. Can you try to keep the original protocol method (and mark it as deprecated), while adding a new delegate method? It would be nice that all the current behavior not changed.
Sure. If you do not have time for this, please feel free to let me know and I can also do it later when I can find more spare time.
Best regards.

Updated the PR to not break the existing implementations. that being said, there is a slight catch to this, intead of passing the originalUrl the url is taken from the URLResponse which is the final url after all the redirects, this may or may not be an issue.
A potential fix for it would be to also pass in the original URLRequest or the whole URLSessionDataTask instead of just the response so the method signature becomes:
imageDownloader(_: ImageDownloader, didDownload data: Data, for task: URLSessionDataTask) -> Data?

Yes. It would be nicer and should be no harm to pass all the task here. I will try to improve it, add documentation and tests after merging it.
Thanks!


Firebreak - Commenting on other things.

Don't merge me

closing the PR as it's served it's purpose. leaving the branch open for the time being as might revisit.


Series.hist() potential bug.

The following line of code prints the wrong distribution:
import matplotlib.pyplot as plt
import pandas as pd

# df is a pd.DataFrame object.  Define df here...

plt.figure();
(df['x1'] - df['x2']).hist(normed=True)
plt.show();

It should print the green distribution, but it prints the blue instead (which is not even a proper distribution).
I'm including the exact lists I used, x1 and x2, below.  These are ordered lists, so please insert them into your DataFrame accordingly.
(Pardon my presentation of the x-labels in the green figure.  Just shift them 1/2-bar length to the right.)
x1 = [4, 4, 6, 4, 4, 4, 4, 5, 5, 6, 4, 4, 5, 6, 4, 4, 4, 4, 5, 5, 6, 5, 3, 6, 6, 7, 7, 7, 4, 6, 4, 5, 4, 5, 4, 3, 7, 7, 7, 5, 4, 5, 4, 3, 5, 4, 4, 5, 6, 5, 4, 4, 4, 5, 6, 4, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 6, 7, 6, 7, 7, 7, 7, 6, 7, 7, 7, 5, 7, 7, 7, 7, 7, 5, 7, 5, 5, 7, 6, 7, 6, 4, 6, 7, 6, 7, 1, 6, 7, 2, 7, 4, 6, 7, 6, 6, 4, 6, 7, 7, 7, 5, 7, 6, 7, 4, 6, 7, 7, 6, 5, 7, 6, 6, 6, 6, 5, 5, 5, 5, 5, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 4, 7, 4, 5, 7, 6, 7, 4, 5, 7, 7, 7, 7, 7, 7, 7, 7, 4, 4, 5, 5, 7, 7, 7, 7, 6, 7]

x2 = [4, 4, 6, 3, 4, 4, 4, 5, 6, 6, 4, 4, 5, 6, 4, 4, 4, 4, 5, 5, 5, 5, 5, 6, 6, 7, 7, 7, 5, 7, 2, 4, 4, 4, 6, 7, 7, 7, 7, 4, 5, 4, 5, 3, 5, 4, 5, 5, 6, 5, 5, 5, 4, 5, 6, 4, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 4, 7, 7, 7, 7, 7, 7, 7, 5, 5, 7, 7, 7, 5, 5, 5, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 5, 6, 6, 5, 6, 7, 7, 7, 5, 7, 7, 6, 5, 5, 6, 6, 6, 5, 7, 5, 5, 5, 5, 4, 4, 3, 4, 7, 4, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 4, 4, 6, 5, 6, 4, 5, 7, 5, 7, 7, 7, 7, 7, 7, 5, 5, 7, 7, 7, 7, 7, 7, 7, 7]

Do you want a bar plot?
In [10]: (df.x1 - df.x2).value_counts(normalize=True).sort_index().plot.bar()

Histograms bins and aggregates according to n_bins. See the matplotlib docs

Going to close, let me know if a bar plot wasn't what you wanted.

The above code also unfortunately only prints the blue plot (a wrong solution), not the green one.

Can you be more specific about what is wrong with it?
This
In [10]: (df.x1 - df.x2).value_counts(normalize=True).sort_index().plot.bar()

gives me this, which I think is identical to your desired outcome.

Maybe list out the x and y coordinates that you expect for each bar.

Ah, thanks for showing me the plot!  After seeing your plot, I decided to upgrade some of my packages.  The hist() command still doesn't give me the right output, but the command that you gave me now does.  Thanks! (Unfortunately I forgot to record the previous version of pandas before upgrading.)


NDIS 6.0 RSS

Hi,
If I would like to get more information about RSS is this link (attached under "NDIS 6.0 Receive Side Scaling") https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddndis/index
correct? (well technically its correct but was it intended?) :)
Regards,
Robert

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

ID: 647b070a-ef93-b0b6-6e92-6c0bcdad4678
Version Independent ID: e1f927ce-e80a-7c77-7626-20b0b7bacf86
Content: Receive Side Scaling Support
Content Source: windows-driver-docs-pr/network/receive-scaling.md
Product: windows-hardware
GitHub Login: @tedhudek
Microsoft Alias: windowsdriverdev

Hi @robert1859 , that was not actually the intention. :) It looks like that old MSDN link got redirected incorrectly at some point when we did a content migration a few months ago, so I'll go ahead and correct all instances of it to point to the correct page: Receive Side Scaling.
Thanks for finding this! The changes should be live later today.


Call / when unable to Switch

When :Switch cannot replace under the cursor, call <C-A>/<C-X> instead.
The current implementation has several (unwanted?) side-effects:

Changes the default binding from gs to <C-A>
<C-A>/<C-X> is always called when :Switch doesn't match, even if g:switch_mapping is set to something other than <C-A>
with _cursor  false   42, :Switch would jump over false and change the number, which might be a bit surprising

What do you think? I could add an option to enable/disable calling ^a for any g:switch_mapping or try to pass the original mapping if :Switch failed, i.e. if g:switch_mapping == "gs", call the original gs mapping.

Changing the default mapping seems like too big of a change. Especially since it's overriding an existing built-in. Yes, it's true that it would default  to it if no switches are found under the cursor, but there might be an edge case, in which you want a real <c-a>, but there's a valid switch pattern as well.
I would prefer it if we just use the original mapping as a fallback, so, as you say, if g:switch_mapping is gs, and nothing matches, we fall back to the original gs. I would even consider making it a "boolean" option like g:switch_mapping_fallback or something, but even if you don't make it an option, I'll likely merge it anyway, and add an option if somebody complains (it shouldn't be a huge problem in practice, I think).

If you want a real <C-a> you can simply use :norm! <C-a>.
It's not really a problem for those rare corner cases.
As for other fallback plugins like vim-speeddating... you can call their respective :<Cmd anytime, right?)

I'm really sorry it took so long to respond to this. I seem to have forgotten to mark it for later work, and so I never really did work on it.
After thinking about the options, I feel like it's not something I want to change at this time. You can see some discussion on the topic in #42, but the short version is that I'd rather leave it to people to set up their own mappings if they need to -- your PR would work for the built-in <c-a> and <c-x> mappings, but wouldn't really work for falling back to other plugins. The example in #42 that we came up with was:
nnoremap <c-a> :if !switch#Switch()               | speeddating#increment() | endif<cr>
nnoremap <c-x> :if !switch#Switch({'reverse': 1}) | speeddating#decrement() | endif<cr>

In your case, in order to use the default mappings, this should work:
nnoremap <c-a> :if !switch#Switch()               | exe "normal! \<c-a>" | endif<cr>
nnoremap <c-x> :if !switch#Switch({'reverse': 1}) | exe "normal! \<c-x>" | endif<cr>

I realize it's more work, but it does give a lot more flexibility, and avoids some of the issues you point out yourself. If you want to talk about doing something different, though, feel free to either reopen this PR, or open a separate issue for discussing the API. Thank you for you work, regardless.


Governance Page Updates

[x] Note: this revision does not offer any way to veto a newly proposed position. I think that feature should be moved to the governance page. It is also not very important for now. (Moved from #84)

Latest mock-up (split into two for better readability):

done. PR #114

For the FPS holder section, I would change the following:

No button for "Connected Wallet"
Connected wallet should have a "open in etherscan" icon like the others
I think we should drop the "copy" icon, it creates too much visual noise and is not that useful
"Delegating to" should also have the "open in etherscan" icon

Delegating and revoking logic seems needs some attention. This is what happened after delegating:

This is what it looked like after I refreshed the page:

I think the logical place to put the "Revoke" button is not on the "connected wallet", but in the place where you clicked "delegate". So I would convert the "Delegate" button into a "Revoke" button for the address that the connected address is delegating to. But in order to find it, the "delegating to" address (if any) should always take the second spot in the list, regardless of how it is sorted. Also, it should have the special label "Delegate address" with the etherscan icon next to it.

So in the end, it should look a little like this (disregard wrong color and bad positioning of the icons):

Bei der minter section sollte es einen Weg geben, die Transaction auf Etherscan zu finden.  Es gibt ja nichts, das man tun kann, um diese wieder zu enablen.

The proposals section needs some rework. I would try to focus on the key variables here and place a link to the position so all the rest of the variables can be inspected. The link to the position would go to for example /monitoring/0x9057509C6DF28c50b3B4D142c44BAEEe23F22Fc7 .
How about the following:

Add a row "Address"  after "collateral" that shows the position address and that sends the user to "/monitoring/0x9057509C6DF28c50b3B4D142c44BAEEe23F22Fc7" when clicking on it.
Use the full name for the type.
Remove initial size, initial price, and initial LTV. If the price is wrong, it should be challenged on the monitoring page
In order to not have too many columns, it might make sense to group the information as follows:

Address + Owner, Collateral, Limit + Reserve, Interest + Maturity, Time Left + Auction duration, Action.

Furthermore, we should make sure to use consistent font sizes across all tables.

Under New Positions, we could probably lift up the "Action" text to fit into the same row as the other main headers, and change the font accordingly.

I think it might be best to implement these changes, and then we can take another look, since there are quite a few changes already.

Ready for review.
What i discovered in the voters table
The table data comes from hooks not a state, if you do a tx like "delegate" or "revoke", changes won't trigger a react re-render of components.
import { useFPSHolders } from "@hooks";
import { useVotingPowers } from "@hooks";
...
const fpsHolders = useFPSHolders();
const votingPowersHook = useVotingPowers(fpsHolders.holders);

React will not re-render if state changes, because its a hook and must stay "unconditional" under react components.
Basically, what i did the last months with the app is, to reduce or exclude hooks and rewrote them via a redux state coming from the api. Which gives each property of the state similar abilities like a "useState" side-effect. This is achievable by using the "useSelector" to reach a state from the redux store. React will re-render any changes from the state automatically.
What i could do

include the votingPower mapping in the api
fetch ponder indexing
prepare mapping and calculations at the api service layer
export "ready to use" state with an Endpoint from the api
include votingPower as a state in redux
exclude the use of hooks and rely on redux state

Not connected

Connected Wallet, no delegation

Connected Wallet, with delegation

I tend to leave the logic as it is. Mapping the voting power live in the backend is not trivial, as the voting power of every token holder is slightly changing with every block.

Even when the wallet is not connected, we sohuld show the original button labels like "Delegate" and not "Connect Wallet". But the behavior when clicking the button should still be a prompt to connect the wallet, if it is not yet connected.

It would be great if this area would be clickable too:

There should be some distance between the title and the text. Also, the text should be in a toned down color, like the second title in the table.


v4 static output file name without hash

It should be possible to just specify static output application name without hash,
output: 'dist/injectapp/my-static-app-name.js'

In some cases hash is not possible to pickup for embedding filename into injected script in election for example.
Option hash: false  not working in v4 as well.

Same issue here

How about this section You have a manifest file.

@kurdin I don't think manifest file can help in case of development. For production, hash help for sure but in development is just unnecessary overhead. Not sure how your HMR works in fusebox but it would be the best to have single output file with embedded HMR code that can detect source changes and do module reloading, same way as webpack-dev-server works, again adding hash in dev env in not needed in 90% of cases.

@kurdin there is no hash during development. I mean there is, but that's necessary. That preffix is a  hash of {homeDir + entryPoint} since user might pipe in several instances with different entry points -> then there is a problem

Besides, have you guys seen this? https://github.com/fuse-box/fuse-box/blob/master/docs/electron.md#launching

Besides, have you guys seen this
@nchanged yes I did and I was able to get bundle file name with something like bundle.context.output.lastPrimaryOutput.filename but still could not figure out to use it to replace static file path in my source file. I did not play with it much, I thought hash: false should fix my problem, still not sure why not to allow in some cases build output file without hash. I understand what you saying about hash but in some cases, for some bundles, it is useful to turn in off and use static file as output (why not).

Now with electron I need 3 bundles, main, renderer and inject script that I use to inject my app into webview, why not to allow for third bundle has static file name, I don't understand.

Could you guys describe a proposed solution to the problem you are facing . And maybe a more detailed picture of what's wrong

@nchanged solution is simple, as we describe it before, hash: false should work as expected in v4, if bundle settings for fusebox({}) has  hash: false and output: : 'dist/main/$name' then created bundle name in dist/main/ should has no dynamic hash, just static filename with $name of the bundle.

PR: https://github.com/fuse-box/fuse-box/pull/1642

This should be closed as of 4.0.0-next.138 or 4.0.0-next.139 (139 will likely include fixes related to output names).

Closed due to inactivity.


OPERA DB json contains empty property

The opera DB json now contains an empty property for each radar, that was not there before:
{
        "number": "1209",
        "country": "Austria",
        "countryid": "LOWM41",
        "oldcountryid": "OS41",
        "wmocode": "11038",
        "wigosid": "",
        "odimcode": "atrau",
        "location": "Wien/Schwechat",
        "status": "1",
        "latitude": "48.074",
        "longitude": "16.536",
        "heightofstation": "",
        "band": "C",
        "doppler": "Y",
        "polarization": "D",
        "maxrange": "224",
        "startyear": "1978",
        "heightantenna": "224",
        "diametrantenna": "",
        "beam": "0.88",
        "gain": "45.5",
        "frequency": "5.625",
        "stratus": "",
        "cirusnimbus": "",
        "wrwp": "",
        "": "" <----
    },

@BarVodSur can this be removed?

Dear Peter,
Excuse me for late respond. Yes, it’s possible to remove the last raw. We will to do it on next update.
BR,
Barbara

Barbara Vodarić Šurija, mag.phys & geophys.
Meteorological and Hydrological Service of Croatia (DHMZ)
Remote Sensing Department
Data Analysis and Remote Sensing Improvement Division
Ravnice 48, 10000 Zagreb, Croatia
mob: +385995356466
e-mail: @.*** @.***>
From: Peter Desmet @.>
Sent: Friday, September 9, 2022 9:20 PM
To: enram/aloftdata.eu @.>
Cc: Barbara Vodaric Surija @.>; Assign @.>
Subject: [enram/aloftdata.eu] OPERA DB json contains empty property (#9)
The opera DB json now contains an empty property for each radar, that was not there before:
{
"number": "1209",
"country": "Austria",
"countryid": "LOWM41",
"oldcountryid": "OS41",
"wmocode": "11038",
"wigosid": "",
"odimcode": "atrau",
"location": "Wien/Schwechat",
"status": "1",
"latitude": "48.074",
"longitude": "16.536",
"heightofstation": "",
"band": "C",
"doppler": "Y",
"polarization": "D",
"maxrange": "224",
"startyear": "1978",
"heightantenna": "224",
"diametrantenna": "",
"beam": "0.88",
"gain": "45.5",
"frequency": "5.625",
"stratus": "",
"cirusnimbus": "",
"wrwp": "",
"": "" <----
},
@BarVodSur https://github.com/BarVodSur  can this be removed?
—
Reply to this email directly, view it on GitHub https://github.com/enram/aloftdata.eu/issues/9 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AR7PG3333JYOJ2ROSTFBH23V5OEUXANCNFSM6AAAAAAQI6DNCQ .
You are receiving this because you were assigned.  https://github.com/notifications/beacon/AR7PG36J25SBNJGJK2VWOXDV5OEUXA5CNFSM6AAAAAAQI6DNCSWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFDDMP3I.gif Message ID: @.*** @.***> >

Yes! I will put a reminder.
BR,
Barbara
From: Peter Desmet @.>
Sent: Thursday, October 20, 2022 3:26 PM
To: enram/aloftdata.eu @.>
Cc: Barbara Vodaric Surija @.>; Mention @.>
Subject: Re: [enram/aloftdata.eu] OPERA DB json contains empty property (#9)
Great, can you let me know when it is done, so I can update and close this issue?
—
Reply to this email directly, view it on GitHub https://github.com/enram/aloftdata.eu/issues/9#issuecomment-1285537553 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AR7PG3Z3GFLO3PP7WASOC2LWEFCABANCNFSM6AAAAAAQI6DNCQ .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AR7PG32D4FOPJYYJ4H5KDB3WEFCABA5CNFSM6AAAAAAQI6DNCSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSMT67RC.gif Message ID: @.*** @.***> >

Dear Peter.
From last update last week empty row is removed.
BR,
Barbara
From: Peter Desmet @.>
Sent: Thursday, October 20, 2022 3:26 PM
To: enram/aloftdata.eu @.>
Cc: Barbara Vodaric Surija @.>; Mention @.>
Subject: Re: [enram/aloftdata.eu] OPERA DB json contains empty property (#9)
Great, can you let me know when it is done, so I can update and close this issue?
—
Reply to this email directly, view it on GitHub https://github.com/enram/aloftdata.eu/issues/9#issuecomment-1285537553 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AR7PG3Z3GFLO3PP7WASOC2LWEFCABANCNFSM6AAAAAAQI6DNCQ .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AR7PG32D4FOPJYYJ4H5KDB3WEFCABA5CNFSM6AAAAAAQI6DNCSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSMT67RC.gif Message ID: @.*** @.***> >


Pr/100

Fixes : #98 better configured!

Pull Request Test Coverage Report for Build 239

6 of 7 (85.71%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 63.456%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

tracer-sofa-boot-starter/src/main/java/com/alipay/sofa/tracer/boot/listener/SofaTracerConfigurationListener.java
6
7
85.71%

Totals

Change from base Build 237:
0.1%

Covered Lines:
2648

Relevant Lines:
4173

💛  - Coveralls


updated extrabuildphase (0.3.4)

Thank you for the contribution. It was merged directly as f157632b942e26a867b77d88d476130364a33d5d to keep commit history cleaner. Your contribution is still credited to you.

Thanks! :pray:


Add support for closing the connection automatically on disconnect

This setting is specifically useful for me (see below) and I understand if you don't want to merge it back but I figured I would send the PR incase you did (since it is just an extra setting). Also, I don't have translations for any of the other languages (nor a good way to acquire them).
Full story: I use connectbot to connect to a beagleboard that opens my garage and front door. I have separate users on the beagleboard that run appropriate commands (i.e. open garage) and then exit (dropping the connection). I keep widgets on my homescreen for these tasks/users and it's annoying that I have to click "Yes" to close the connect after clicking one of the widgets. This setting solves that.

I merged #23 last week, so I'll close this.


How to pause and resume the crawler?

When the IP is forbidden during the crawling, I didnt find how to resume to crawl after I change my ip

I will upgrade hawk to support pause and resume threads. thx

I have done that, enjoy


Fix the lowestCommonPath function, by stopping at first different sub-path

This fixes issue #772

Merged as https://github.com/dethcrypto/TypeChain/pull/858


docker compose up doesn't work on silicon macs?

Bug report

[ ] I confirm this is a bug with Supabase, not with my own application.
[ ] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
I am on a silicon mac (M2 Pro) and docker compose up just hangs as below. It works fine on intel macs however. Any ideas? And thanks for any help!
$ docker compose up
[+] Building 248.1s (13/17)                                                                                docker:desktop-linux
 => [db internal] load build definition from Dockerfile                                                                       0.0s
 => => transferring dockerfile: 1.02kB                                                                                0.0s
 => [db internal] load .dockerignore                                                                                0.0s
 => => transferring context: 162B                                                                                0.0s
 => [db internal] load metadata for docker.io/library/postgres:14                                                             1.6s
 => [db  1/13] FROM docker.io/library/postgres:14@sha256:b2f06ce12103bedbc0a49ae4ffff062d90824e0f45462de712f66952679f7670     3.5s
 => => resolve docker.io/library/postgres:14@sha256:b2f06ce12103bedbc0a49ae4ffff062d90824e0f45462de712f66952679f7670          0.0s
 => => sha256:e71d5c9dd884de4fc1ea74a91d970c0ad8e23c5cd783b26c4d3d206e61f37c8d 9.53kB / 9.53kB                                0.2s
 => => sha256:b2f06ce12103bedbc0a49ae4ffff062d90824e0f45462de712f66952679f7670 1.86kB / 1.86kB                                0.0s
 => => sha256:eb673d59ff2019c9059e196d384e84d7c39de6cc50c999d94dfc28de5a242ab9 10.42kB / 10.42kB                              0.0s
 => => sha256:38e7c1f051cc1287b84acd017ea088b822199cb70f658c51e27ec607e91f2e12 101.37MB / 101.37MB                            1.5s
 => => sha256:1d40741fbab766d525291f068923b7bab6658bd25918a8aa07e75aee9deab70f 3.04kB / 3.04kB                                0.0s
 => => sha256:4d0e2800e837e04d62cf1b3b34b06fe6bdb1b091e2d52ef48cb976b5211df4cc 129B / 129B                                    0.2s
 => => sha256:09a5999e7ba9e244249b9fd56301d240e04a0f9f1fd8b3c6c6c334d0ef0e7ef0 4.78kB / 4.78kB                                0.3s
 => => sha256:98904cb8f55dd3b2009ae89b4e7dfb92ace4cf8b3ac86a9b0fac2db00cfe7a17 199B / 199B                                    0.3s
 => => extracting sha256:38e7c1f051cc1287b84acd017ea088b822199cb70f658c51e27ec607e91f2e12                                     1.7s
 => => extracting sha256:e71d5c9dd884de4fc1ea74a91d970c0ad8e23c5cd783b26c4d3d206e61f37c8d                                     0.0s
 => => extracting sha256:4d0e2800e837e04d62cf1b3b34b06fe6bdb1b091e2d52ef48cb976b5211df4cc                                     0.0s
 => => extracting sha256:98904cb8f55dd3b2009ae89b4e7dfb92ace4cf8b3ac86a9b0fac2db00cfe7a17                                     0.0s
 => => extracting sha256:09a5999e7ba9e244249b9fd56301d240e04a0f9f1fd8b3c6c6c334d0ef0e7ef0                                     0.0s
 => [db internal] load build context                                                                                0.0s
 => => transferring context: 64.12kB                                                                                0.0s
 => [db  2/13] RUN apt-get update                                                                                1.7s
 => [db  3/13] RUN apt-get install -y --no-install-recommends ca-certificates   git   build-essential   libpq-dev   postgre  14.9s
 => [db  4/13] WORKDIR /home/supa                                                                                0.0s
 => [db  5/13] RUN chown postgres:postgres /home/supa                                                                         0.3s
 => [db  6/13] RUN   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --no-modify-path --profile min  13.0s
 => [db  7/13] RUN cargo install cargo-pgrx --version 0.10.1 --locked                                                        75.3s
 => [db  8/13] RUN cargo pgrx init --pg14 $(which pg_config)                                                                  1.1s
 => [db  9/13] COPY . .                                                                                0.0s
 => [db 10/13] RUN cargo pgrx install                                                                                136.7s
 => => #    Compiling bytecount v0.6.3
 => => #    Compiling base64 v0.13.1
 => => #    Compiling seq-macro v0.3.5
 => => #    Compiling seahash v4.1.0
 => => #    Compiling jsonschema v0.16.1
 => => #    Compiling pgrx v0.10.1
failed to receive status: rpc error: code = Unavailable desc = error reading from server: EOF

To Reproduce
Run docker compose up on a silicon mac.
Expected behavior
Runs Postgres with the pg_jsonschema extension installed.
Screenshots
If applicable, add screenshots to help explain your problem.
System information

OS: macOS

Additional context
Add any other context about the problem here.

Which docker version are you on? It works for me on the following version:
➜ docker -v
Docker version 24.0.5, build ced0996

Which docker version are you on? It works for me on the following version:

Oh, very good question. Thank you.
$ docker -v
Docker version 24.0.6, build ed223bc

I've also updated the issue.
Perhaps I need to try reinstalling docker. I'll report back.


Remove previously depreacted properties for 1.54

Fixes https://github.com/AnalyticalGraphicsInc/cesium/issues/7394
Removes deprecated ModelAnimation.speedup and ModelAnimationCollection.speedup.

Thanks for the pull request @ggetz!

:heavy_check_mark: Signed CLA found.
:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Looks good!  I'll merge as soon as CI passes

This is just failing because this branch isn't up to date with the fixes to the CWT tests.  Merging.  Thanks @ggetz!


[bugfix] Uppercase function 'undefind' for locale

Handled undefined casses and warning messages.

@Eliyas - not sure what you are trying to do. Can you add some tests?

@marwahaha I have added test case for bugfix #4507. can you please have a look around


faction icons changelings

adds icons to the changelings
all code pretty mutch copied from revs.
makes it so atlest aghost can see changlings
shud probably be changed so the lings can only know other lings if they have hivemind.

bro when i try to add antsg status icons nothing works literally how 😭
anyways sure but i'll change the icon into sth better because geneticist is a real job (real)

also gonna add a check if a ling has hivemind enabled

your PR did not just shitspam me with thousands of errors


Allow configuration of authenticators in DI

Motivation
Having the default authenticators live in the DI container isn't very
helpful if there isn't also a way to configure them.
Modifications
Add ConfigureAuthenticators method to IApiBuilder with an additional
overload which receives the IServiceProvider to allow configuration to
be acquired from the DI container.
Add a similar overload to ConfigureBaseAddress which accepts an
IServiceProvider for dynamic configuration.

/merge


Add react-native-permissions install instructions

Thanks for adding this to the docs, going to release this later today


POL-199 - GKE Plugin

Description
[Describe what this change achieves]
Issues Resolved
[List any existing issues this PR resolves]
Contribution Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable
[ ] New functionality has been documented in CHANGELOG.MD

          2 Errors

:no_entry_sign:
Please add a CHANGELOG.md file

:no_entry_sign:
File syntax check failed. google/gke/gke_test_cat.rb.

          1 Warning

:warning:
Should this include readme changes

  Generated by :no_entry_sign: Danger


OpenAI / Azure OpenAI missing optional user parameter

Hi, I think it's currently impossible to pass a user parameter - this is helpful for complying with abuse monitoring guidelines of both Azure OpenAI and OpenAI.
I would like to request this feature if not roadmapped.
Thanks!

You should be able to pass it in via model_kwargs


Fix tag name junit testdescription

Fixes #1097

The change to PactBrokerResult constructor has caused some test failures

Build is green now :)

Appveyor failures don't seem related to this story's changes. It is complaining about a missing nativa library.


Sync experimental changes from closed sources to dev branch

Currently sources for Google Cloud has changes related to avatar updating on startup. This changes needs to be synced with public version. ETA ~2-4 hours

Current dev branch has been updated to latest changes


GH Action to publish to crates.io automatically

Would be nice to automate the crates.io publish step on new releases, the same way it currently publishes py-bindings to PyPI.

Looks like https://github.com/marketplace/actions/publish-crates is the action to use from the Marketplace.


5.10.0 Roadmap

Is there any roadmap for 5.10.0?

Hi @kranidiotis,
You can find our product roadmap from here. From the mentioned near-term items, we are mainly working on the items mentioned in the identity administration section for 5.10.0 release.

Closing as answered.


Create data series from rows

It would be nice to create data series from rows.
Eg. When you group by country for example, the data in the query will be presented in the same row. It would be really useful to be able to create multiple data series from that output.

c83b24b4c7e170c0047572908cbaa10531efad5a introduces a new "Transform" tab in the job form allowing you to transpose the result set. A better description of the feature in the GUI will be following at a future point, but for now I hope it's intuitive enough.
Key field: field identifying rows after the transpose - typically the date field
Category field: values from this field are forming the new columns
Value field: self explanatory
Key | Category | Value
2016-09-01 | foo | 1
2016-09-01 | bar | 2
becomes
Key | foo | bar
2016-09-01 | 1 | 2


jsonschema version

Type: Enhancement
Version: icetea 2.0.1
Problem: requires jsonschema<3.0.0; Version 2.6.0 is from 2017
Request: update to use >=3.2.0
Pros: Easier environment setup by avoiding incompatibilities

This repository is no longer maintained and it is deprecated. As result, we are closing all issues/pull request.


Support validity period selection in years

Some CAs (DigiCert is one) only allow you to specify validity periods in integers (1, 2 or 3 years). There are no specific date selections allowed. Would be nice if there was a way in the GUI to quickly select one of these options. Implementation flexible.

Sorry for the lag time...
I believe the referenced commit should close this issue. Essentially I added a year drop down to the UI and then made the value of that dropdown visible via the issuer_options dict. Now individual plugins can have what they need to support number of years instead of specific beginning and end dates.
Feel free to comment on the PR.
An example of the field in question:


Define metadata templates for LCNAF embeddings

[ ] Define the handlebars and GraphQL templates to be used by VectorLink for LCNAF MADS/RDF data

For the authority-records WOQL, we should be sure to pull in the PersonalName data, and then grab the RWO (Person) data.
The paths should look like this:
/rdf:RDF/madsrdf:PersonalName/madsrdf:hasVariant/madsrdf:PersonalName/madsrdf:variantLabel [0..*]
/rdf:RDF/madsrdf:PersonalName/madsrdf:hasSource/madsrdf:Source/madsrdf:citationSource [0..*]
/rdf:RDF/madsrdf:PersonalName/madsrdf:hasSource/madsrdf:Source/madsrdf:citationNote [0..*]
/rdf:RDF/madsrdf:PersonalName/identifiesRWO/madsrdf:RWO ... [Person data here]

And then also add affiliation to the Person (RWO) data:
/rdf:RDF/madsrdf:PersonalName/identifiesRWO/madsrdf:RWO/madsrdf:hasAffiliation/madsrdf:Affiliation/madsrdf:organization/madsrdf:Organization/madsrdf:authoritativeLabel [0..*]

And also madsrdf:birthDate for the Person data.


Fix a bug with model indexes

Add serialization for a pair, fix a bug with model indexes

Please see 725e2ae for a proper fix

done, please verify and approve.

all that was discussed fixed


Scraper Attribute

Home Assistant release (hass --version):
0.43.2
Python release (python3 --version):
3.4.2
Component/platform:
Scraper
Description of problem:
Would like to add a sensor for an attribute of an element of the DOM.

The scrape sensor is limited to CSS selectors.
Please use the forum for feature requests. Thanks


GEOparse.logger.set_verbosity doesn't work

The docs mention there is a
GEOparse.logger.set_verbosity('ERROR')
however, this causes:
AttributeError: 'Logger' object has no attribute 'set_verbosity'
This can be side-stepped with:
import logging
GEOparse.logger.setLevel(logging.getLevelName("ERROR"))

Your right. The name is used twice :/.

 GEOparse.logger.set_verbosity doesn't work


Improve article 2302.09133

Exact location of issue
Algorithm 1
Problem details
The algorithm is printed on a single line whereas in the paper it is printed over several lines.
Expected behavior
Just as the paper, the printed algorithm should be printed over several lines.
Desktop (please complete the following information)

OS: Ubuntu
Browser: chrome

Smartphone (please complete the following information):

Device: Nexus
OS: Android 14
Browser: chrome (stock browser)

Thank you for the report, valuable catch!
We recently added a patch to protect linebreaks in algorithm environments, but it looks like this source has another variation that isn't yet supported by latexml.


Code scanning on GitHub

When I run a code scan on GitHub, I get a report that there is one vulnerability in Klecks.

Incomplete string escaping or encoding
High
Detected by CodeQL

Since it is a report of CodeQL, which is GitHub's standard code scanning function, if security scanning is enabled on the current repository, the repository owner will be able to see a detailed report.
I'm not sure if GitHub's security scan report is an issue that can be ignored or if it should be fixed.

That is a false positive by CodeQL. It relates to the text tool. In its text renderer it creates a string with the user input (to calculate its dimensions). This string is then assigned to textContent, which is safe. https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent#differences_from_innerhtml

Thank you for your verification.


platform.linux_distribution is removed in Python 3.8

use
distro.linux_distribution

Hey @Axel-Erfurt ,
Thanks for noticing and raising this up! I've fixed this issue in the ver. 1.2.3.


Headless mode fails to launch

puppeteer-extensionbridge was updated to die on non-headless mode so hackium needs to properly disable known-broken features when operating in headless mode.

fixed via 16241f210027cc066895665b32e6cde744835420


Fix typo

Hey!
The title says it all.
Thx for the awesome work!
cheers

This change is

Danke!


Add skip_hidden_files, reject_regexp

Motivation for changes:
Discussions in chat about frustrations in not being able to filter out hidden objects or files, extrapolated into two approaches: OS-specific methods for hiding files and regex for other files.
Detailed changes:
Added two new config settings: skip_hidden_files (boolean), reject_regexp (regex).
Config usage if relevant (new plugin or updated schema):
filesystem:
  path:
    - /storage/movies/
    - /storage/tv/
  recursive: yes  # No limit to depth, all sub dirs will be accessed
  retrieve:  # Only files and dirs will be retrieved
    - files
    - dirs
  regexp: '.*\.(avi|mkv|mp4|m4v|iso)$'
  reject_regexp: '.*\.(nfo|rar)$'
  skip_hidden_files: yes

I would highly prefer more shorter less double terminology keyword
hidden_files: no

@mannionpatrick Options need to be renamed.
reject_regexp -> skip_regexp
we avoid reject, accept words in all other context except action for entry (legacy issues exists)
skip_hidden_files may be ok after above change, but hidden_files: no is still preferred over that.
PR will be closed without further activity at some point.

Reopen if relevant


got ExternalReferenceException but there's no external reference in document

Hi,
I got error message 'Named reference xiv.a.area [1]Control!E62 not parsed

/Users/myname/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/excel_to_code-0.3.13/src/rewrite/caching_formula_parser.rb:93:in `external_reference': ExternalReferenceException

in my sheets "xiv.a" cell E62. it's just an empty cell. I've try to remove the related sheets. and remove all sheets and leave one sheet. still get the same error

This relates to a named reference. Take a look in the name manager in excel for a named reference called xiv.a.area and you should see it as linked to an external worksheet.You should be able to change it to point at the local worksheet there.

On 10 Mar 2015, at 06:22, Rifki Fauzi<EMAIL_ADDRESS>wrote:
Hi,
I got error message 'Named reference xiv.a.area [1]Control!E62 not parsed
/Users/myname/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/excel_to_code-0.3.13/src/rewrite/caching_formula_parser.rb:93:in `external_reference': ExternalReferenceException
in my sheets "xiv.a" cell E62. it's just an empty cell. I've try to remove the related sheets. and remove all sheets and leave one sheet. still get the same error
—
Reply to this email directly or view it on GitHub.

Issue hasn't been updated in a while. Closing.


After-login error persisting

Despite logging in, it requires a page refresh for the connect popup to work
https://github.com/user-attachments/assets/4df4ded2-69c4-4a28-82cf-36ce0532402d

fixed by https://github.com/penumbra-zone/web/pull/1938


Test posting Thrift to HTTP endpoint via Jaeger client

Test both jaeger and zipkin thrift in one function

Coverage remained the same at 100.0% when pulling 12f24fe8367d87edfb02eeff37afb22d6bae4ac4 on test-http-handler-via-client into 8c439ffa6e4b823e21c3a791e758c7299b4eb5cd on master.

Coverage remained the same at 100.0% when pulling 324a10f56121da1d74ca0c6ea55c588116f4120a on test-http-handler-via-client into 8c439ffa6e4b823e21c3a791e758c7299b4eb5cd on master.


Search results error

Foundation CMS MVC - Search results summaries contain configuration values that probably should be excluded from index and summary information. For example, "10-5" on all these pages...

merged to another issue


Build Transitions API (and what was formerly called soc)

The goal of this ticket is to build and populate a soc dataset within the jobhopper database and return the data as json so that it can be filtered based on region.
Find the data within the jobhopper database to build the table.
Build a process to populate the table/django migration (if/as needed).
GET http://localhost:/api/v1/transitions
This api will allow you to get the data that is needed for the underlying table in the user interface. It should have the fields that allow the data to be filtered based on soc codes and also allows the data to be filtered based on region as necessary.
The output should be valid json and have a status return code of 200.
See this resource:
https://jsonlint.com/

closing per merged code #139


Feature request: Add support for extra Labels on PODs

Use case:
AKS is a requirement for using Dev Spaces.
Alot of services developed for AKS are using other resources on Azure. The prefered way of securly accessing theese resources are by using Managed Identities.
To access Azure resources from from a POD (using Managed Identities), MS has developed "AAD Pod Identity".
To use AAD Pod Identity, the POD need to have a extra label with the name "aadpodidbinding" on it.
Today, adding a extra label to a POD requires you to hard code it into deployment.yaml
It would be great if you could add extra labels in the "values.yaml" file instead.

@Eneuman, thank you for the suggestion! We'll look into this and let you know what we find.

@Eneuman If you'd prefer a values.yaml-based strategy for customizing the labels on your Pod, you can make updates to your Helm chart to support this.  (Dev Spaces shouldn't get in the way.)
For example:
values.yaml
deployment:
  podLabels:
    aadpodidbinding: foo

deployment.yaml (truncated)
spec:
  template:
    metadata:
      labels:
        app: {{ template "$CHART_NAME$.name" . }}
        draft: {{ .Values.draft | default "draft-app" }}
        release: {{ .Release.Name }}
        {{- range $key, $value := .Values.deployment.podLabels }}
        {{ $key }}: {{ $value }}
        {{- end }}


Point user to cluster-specific endpoint in ssh-token error response

Currently if a user tries to ssh to a environment through the ssh-token service, it will fail with a generic error message.
It might be more discoverable if the error message was able to respond with the cluster-specific ssh endpoint.

authenticate the user via SSH key
check that the user is authorized to access the environment they requested
if 1 & 2 pass, respond with the cluster-specific ssh endpoint in the error message
otherwise respond with a generic error message

This way only authorised users will get the cluster-specific endpoint response, which disallows enumeration of environments and cluster-specific ssh endpoints.

Unfortunately this is not possible because the information mapping namespace name to Lagoon project and environment is only present in the labels of the namespace on the lagoon remote cluster.

Okay, so after discussion with the Lagoon team today we can do a lookup for environment based on the (non-unique) namespace name. It's not guaranteed to be correct, but will probably point the user in a useful direction.


Controllers Interrupted During Reconcile Create Duplicate Resources

Edited: Removed ec2 specification, Upon further investigation this would be true for all controllers
Describe the bug
During the reconcile of a VPC if the controller is interrupted before the reconcile completes, on restart the VPC is created a second time.
This is because the status on the VPC is empty and not updated to track the remote resource until after reconciliation is completed. This leads to orphaned duplicate resources
Steps to reproduce

Create a new VPC object

apiVersion: ec2.services.k8s.aws/v1alpha1
kind: VPC
metadata:
  name: example
spec:
  ...

As soon as the creation for the vpc is trigger on the remote, stop or restart the controller

alternatively place an interrupt inside the code between create and object update https://github.com/aws-controllers-k8s/ec2-controller/blob/main/pkg/resource/vpc/sdk.go#L266   resp, err = rm.sdkapi.CreateVpcWithContext(ctx, input)
   rm.metrics.RecordAPICall("CREATE", "CreateVpc", err)
   if err != nil {
       return nil, err
   }
   panic("interrupt to orphan")

Check the the status on the vpc, if the condition has triggered the status will still be empty with no reference to the remote
When the controller runs the reconcile again a new object with the same information will be created

This was found because of a panic on the controller causing a restart during the reconcile of the VPC causing the interrupt during creation
{"level":"info","ts":"2024-04-24T18:00:29.176Z","msg":"Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference","controller":"elasticipaddress",...}

Expected outcome
VPC status is tracked as pending before final status update on crd after creation is complete. The controller would attempt to then reconcile with remote before creating a new object
Environment
EKS version: eks.15
Kubernetes Version: 1.27
Service Targeted: EC2
EC2 ACK Controller Version: 1.2.6

A potential option:

Update status to pending before running create api call
Automatically add initial tag to AWS resource matching uid of crd object manifest as part of api create call
During reconciles, if the status of an object is pending attempt to reconcile from remote first before just reverting to creation of new item

Found during crashloop caused by https://github.com/aws-controllers-k8s/community/issues/2063

Thanks @a-hilaly for the quick triage and getting the discussion started during the community meeting today!
I've updated the title and added a note on the description that this would impact all controllers to reflect what I've found on further investigation. I'd love to see this get a resolution despite the initial cause being related to the crashloop. Let me know if you'd like me to take getting a proposal together for this


Requires 'android:enableOnBackInvokedCallbackto' be true

The documentation has no mention of the package requiring 'android:enableOnBackInvokedCallback' to be set to true. The project is required to target Android14 or above.

@RotenKiwi fork repo and update doc, i will review you PR and update it.


Add AESND Implentation.

chore: :recycle: Make GXTexObj to Texture a From impl instead of Into
feat(Audio): :sparkles: Add AESND implentation

LGTM, thanks!


Add link to Docker Hub Description action

Adds a link to this action: https://github.com/peter-evans/dockerhub-description

@peter-evans your changes have been merged, thanks for your contribution 👍


[Bug Report] Decimal separator format in el-input-number

Element UI version
2.2.0
OS/Browsers version
Chrome Version 64.0.3282.186
Vue version
2.5.13
Reproduction Link
https://jsfiddle.net/mmx38qxw/393/
Steps to reproduce
Introduce "2,23" with a comma instead of a dot.
What is Expected?
Format the number with decimals correctly either using separator "," or "." for internationalization purposes. Or add a new prop for stablishing the decimal separator character.
What is actually happening?
The new number is not valid and dissapears if the decimal separator is not ",".

https://github.com/ElemeFE/element/issues/8515

Thanks for your reply.

In my opinion, the thousands separator on a form float input is useless, it's only valid for readability purposes (due to database persistency behaviour).
The decimal separator could be passed as a prop and used after in the regexp for formatting.
If the decimal separator is switched, then a simple string replace should occur to the valid one, thus giving the user a visual hint of what is happening by the way, not needing any more visual aid.
My idea is to use the i18n key in order to pass the needed character, as I'm actually doing for the ElDatePicker component "format" prop.

I believe those changes will not take too long and will improve que i18n of the component.

@Leopoldthecoder

I'm inclined to adding a prop decimal-separator which defaults to '.'. i18n may not be a good place to put such a key, as in most cases the decimal separator is the same among different languages.

That would be awesome.

Any news on this one? I'm looking forward this feature.

There any news on this ? Thanks!

No advances in 5 months? This makes me sad :(

现在的 el-input-number 感觉可有可无，完全没有起到这个组件的作用楼上那个真的可以借鉴下

Any news on this feature, please? Cheers!

wish supporting for displaying custom units after Numbers!

Waiting for this

It can't be this hard to allow comma separated numbers right? It is the common decimal separator in alot of languages.

A comma as a thousands sign is a common scenario in the financial industry. It is recommended to add a component rather than modify the .

also waiting for this 😿

It would be a nice feature if we can set the decimal-separator prop.

I have modified the component to add dots (".") as a thousands separator and commas (",") as a decimal separator.
It's in https://gist.github.com/Saigesp/e662683ac6c79471de63d91bc2721a2f, in case it's useful for anyone

Could you use numbro.js to format the numbers? It is a good choice

@Leopoldthecoder Any update here? Is the decimal-separator prop coming any soon?
Cheers!

Hi guys ) Any updates here? Or maybe it is possible to do it with formatter and parser with el-input?


add SlimeVR-Rust firmware

SlimeVR-Rust/firmware is firmware targetting the esp32c3 (and some other chips too) that collects IMU data for SlimeVR, a program that tracks leg and body movements in Virtual Reality.
The project uses a large number of crates in the embedded ecosystem, including esp-hal, embassy, defmt, and more.
It took a lot of effort to get all of these pieces working together, and also working across multiple chips! So hopefully this project can serve as an example of a more complicated piece of firmware with many different parts of the ecosystem interacting.

updated description

Interesting! I was curious about what you've been working on :D. Perhaps, I'll get some trackers and try it out someday soon :).
Thanks for the PR!


[DATA] Error in plot

Which Dataset
Total Tests Performed (see attachment)

Error Description
For some reason, total test performed numbers now show up as 600,000 rather than ~63,000 IIRC.
Suggested fixes
Should be trivial

Fixed. Thanks @mattia-vaccari


LP4LAB1:EX1:TASK1 no results with KQL query

So,  my students next week are supposed to use the LA demo site: https://aka.ms/lademo for all KQL queries?
When I tried to do the lab,the MMA agent is running and WIn1 is connected
No results

Originally posted by @dpapkin in https://github.com/MicrosoftLearning/SC-200T00A-Microsoft-Security-Operations-Analyst/issues/284#issuecomment-2516176727

For LP4LAB1:EX1:TASK1 you need to perform the query in the LA Demo site as per the lab instructions. As you can see there are >30K results.

The LA Demo site is not connected to your lab workspace, so nothing on WIN1 would be there. Not an issue as described.


Bug: In multiplayer, "allow field creation" continuously gets added to and removed from the F1 menu

Seems to happen only when the seeder is folded. Maybe happens in singleplayer too

Only happens above 33 fps and only while the seeder is not fully unfolded


PHP8 Readiness

Bump the required PHP version to 8.0.
Remaining tasks:

[ ] Bump babenkoivan/elastic-scout-driver-plus when PHP 8 compatibility is released.
[ ] Migrate to FakerPHP/Faker.
[ ] Review composer.json requirements.

Build completes. Tests passed. Deployment successful. Closing.


Merge sig-virtualization to sig-cluster-management

As discussed in the sig meetings, sig-virtualization will merge under the sig-cluster-management

/approve
/lgtm