text:
Zeus crash makes typing in console invisible

I am running zeus 0.13.3 on OSX 10.8.5, iTerm1.0.0.20130624. Every single time zeus crashes, I am no longer able to see what I'm typing in the shell. I recover from the problem by using reset. Any suggestions as to what might be causing this? Here's one stacktrace, after which the problem appears:
↳ zeus start
Starting Zeus server
exit status 1hed] [running] [connecting] [waiting]
[ready] [crashed] [running] [connecting] [waiting]
boot
└── default_bundle
    ├── development_environment
    │   └── prerake
    └── test_environment
        └── test_helper

Available Commands: [waiting] [crashed] [ready]
zeus destroy (alias: d)
zeus server (alias: s)
zeus rake
zeus generate (alias: g)
zeus console (alias: c)
zeus runner (alias: r)
zeus dbconsole
zeus test (alias: rspec, testrb)
slavenode.go:202: EOF
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x73d27]

goroutine 13 [running]:
github.com/burke/zeus/go/unixsocket.(*Usock).WriteMessage(0x0, 0xf8400f96a0, 0x3a5300000010, 0xf84005d420, 0xe, ...)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/unixsocket/unixsocket.go:81 +0xba
github.com/burke/zeus/go/processtree.(*SlaveNode).bootSlave(0xf8400870d0, 0xf8400871a0, 0x0, 0x5200000001)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:274 +0x10e
github.com/burke/zeus/go/processtree.(*SlaveNode).doCrashedOrReadyState(0xf8400870d0, 0xf800000001, 0x10dadc, 0x4300000001)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:247 +0x142
github.com/burke/zeus/go/processtree.(*SlaveNode).Run(0xf8400870d0, 0xf84005d800, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:142 +0x184
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:52 +0x215

goroutine 1 [select]:
github.com/burke/zeus/go/zeusmaster.doRun(0x0, 0x229c)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/zeusmaster/zeusmaster.go:47 +0x377
github.com/burke/zeus/go/zeusmaster.Run()
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/zeusmaster/zeusmaster.go:22 +0x1c
main.main()
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/cmd/zeus/zeus.go:40 +0x29c

goroutine 2 [syscall]:
created by runtime.main
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/proc.c:221

goroutine 3 [syscall]:
os/signal.loop()
        /usr/local/Cellar/go/1.0.3/src/pkg/os/signal/signal_unix.go:20 +0x1c
created by os/signal.init·1
        /usr/local/Cellar/go/1.0.3/src/pkg/os/signal/signal_unix.go:26 +0x2f

goroutine 4 [select]:
github.com/burke/zeus/go/filemonitor.start(0xf840097000, 0xf84008a3c0, 0xf84008a410, 0x0, 0x0, ...)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/filemonitor/filemonitor.go:51 +0x148
created by github.com/burke/zeus/go/filemonitor.Start
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/filemonitor/filemonitor.go:21 +0x7e

goroutine 5 [select]:
github.com/burke/zeus/go/processtree._func_001(0xf84005e240, 0xf84005e250, 0xf84005e248, 0x0, 0x0, ...)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:56 +0x314
created by github.com/burke/zeus/go/processtree.StartSlaveMonitor
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:65 +0xb6

goroutine 6 [select]:
github.com/burke/zeus/go/clienthandler._func_001(0xf84005e268, 0xf84005e260, 0xf84005e258, 0x0, 0x0, ...)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/clienthandler/clienthandler.go:47 +0x23c
created by github.com/burke/zeus/go/clienthandler.Start
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/clienthandler/clienthandler.go:56 +0xb6

goroutine 7 [runnable]:
syscall.Syscall()
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/asm_darwin_amd64.s:34 +0x61
syscall.Write(0x1, 0xf840081240, 0x4000000022, 0xf800000000, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/zsyscall_darwin_amd64.go:1279 +0x78
os.(*File).write(0xf84005e008, 0xf840081240, 0x4000000022, 0xf800000000, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/file_unix.go:188 +0x69
os.(*File).Write(0xf84005e008, 0xf840081240, 0x4000000022, 0x0, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/file.go:139 +0x83
fmt.Fprintf(0xf840043a80, 0xf84005e008, 0xf84012cc00, 0xf800000022, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/fmt/print.go:214 +0xa4
fmt.Printf(0xf84012cc00, 0x22, 0x0, 0x0, 0x1135f4, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/fmt/print.go:222 +0x97
github.com/burke/zeus/go/statuschart.(*StatusChart).draw(0xf840096c00, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/statuschart/statuschart.go:131 +0x220
github.com/burke/zeus/go/statuschart._func_001(0xf84005e270, 0xf84005e280, 0xf84005e278, 0x0, 0x0, ...)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/statuschart/statuschart.go:76 +0x49f
created by github.com/burke/zeus/go/statuschart.Start
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/statuschart/statuschart.go:83 +0xb6

goroutine 8 [finalizer wait]:
created by runtime.gc
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/mgc0.c:882

goroutine 9 [syscall]:
created by addtimer
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/ztime_amd64.c:72

goroutine 10 [syscall]:
syscall.Syscall6()
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/asm_darwin_amd64.s:38 +0x5
syscall.kevent(0x11, 0x0, 0x0, 0xf84006ad88, 0xa, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/zsyscall_darwin_amd64.go:199 +0x88
syscall.Kevent(0xf800000011, 0x0, 0x0, 0xf84006ad88, 0xa0000000a, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/syscall_bsd.go:546 +0xa4
net.(*pollster).WaitFD(0xf84006ad80, 0xf840044d80, 0x0, 0x0, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/fd_darwin.go:96 +0x185
net.(*pollServer).Run(0xf840044d80, 0x0)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/fd.go:236 +0xe4
created by net.newPollServer
        /usr/local/Cellar/go/1.0.3/src/pkg/net/newpollserver.go:35 +0x382

goroutine 11 [chan receive]:
net.(*pollServer).WaitRead(0xf840044d80, 0xf840064120, 0xf8400ea6c0, 0x23, 0x1, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/fd.go:268 +0x73
net.(*netFD).ReadMsg(0xf840064120, 0xf84011d000, 0x40000000400, 0xf840045ba0, 0x2000000020, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/fd.go:486 +0x2d5
net.(*UnixConn).ReadMsgUnix(0xf84005e488, 0xf84011d000, 0x40000000400, 0xf840045ba0, 0x2000000020, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/unixsock_posix.go:274 +0x144
github.com/burke/zeus/go/unixsocket.(*Usock).readFromSocket(0xf8400ec000, 0x0, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/unixsocket/unixsocket.go:186 +0xf4
github.com/burke/zeus/go/unixsocket.(*Usock).ReadFD(0xf8400ec000, 0xf800000000, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/unixsocket/unixsocket.go:109 +0xaa
github.com/burke/zeus/go/processtree._func_002(0xf84005e318, 0xf84005e490, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:43 +0x28
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:49 +0x1a7

goroutine 12 [semacquire]:
sync.runtime_Semacquire(0xf84005e148, 0xf84005e148)
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/zsema_amd64.c:146 +0x25
sync.(*Cond).Wait(0xf840081440, 0x1)
        /usr/local/Cellar/go/1.0.3/src/pkg/sync/cond.go:67 +0xaa
github.com/burke/zeus/go/processtree.(*SlaveNode).WaitUntilReadyOrCrashed(0xf840087410, 0x51629)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:75 +0x133
github.com/burke/zeus/go/processtree.(*SlaveNode).doWaitingState(0xf8400874e0, 0xf800000001, 0x10e22c, 0x5700000001)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:163 +0x51
github.com/burke/zeus/go/processtree.(*SlaveNode).Run(0xf8400874e0, 0xf84005d800, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:136 +0x2f2
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:52 +0x215

goroutine 14 [semacquire]:
sync.runtime_Semacquire(0xf84005e5d8, 0xf84005e5d8)
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/zsema_amd64.c:146 +0x25
sync.(*Cond).Wait(0xf840081300, 0x1)
        /usr/local/Cellar/go/1.0.3/src/pkg/sync/cond.go:67 +0xaa
github.com/burke/zeus/go/processtree.(*SlaveNode).WaitUntilReadyOrCrashed(0xf8400871a0, 0x51629)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:75 +0x133
github.com/burke/zeus/go/processtree.(*SlaveNode).doWaitingState(0xf840087270, 0xf800000001, 0x10e22c, 0x5700000001)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:163 +0x51
github.com/burke/zeus/go/processtree.(*SlaveNode).Run(0xf840087270, 0xf84005d800, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:136 +0x2f2
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:52 +0x215

goroutine 15 [semacquire]:
sync.runtime_Semacquire(0xf84005e4a8, 0xf84005e4a8)
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/zsema_amd64.c:146 +0x25
sync.(*Cond).Wait(0xf840081340, 0x1)
        /usr/local/Cellar/go/1.0.3/src/pkg/sync/cond.go:67 +0xaa
github.com/burke/zeus/go/processtree.(*SlaveNode).WaitUntilReadyOrCrashed(0xf840087270, 0x51629)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:75 +0x133
github.com/burke/zeus/go/processtree.(*SlaveNode).doWaitingState(0xf840087340, 0xf800000001, 0x10e22c, 0x5700000001)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:163 +0x51
github.com/burke/zeus/go/processtree.(*SlaveNode).Run(0xf840087340, 0xf84005d800, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:136 +0x2f2
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:52 +0x215

goroutine 16 [semacquire]:
sync.runtime_Semacquire(0xf84005e5d8, 0x1915f)
        /usr/local/Cellar/go/1.0.3/src/pkg/runtime/zsema_amd64.c:146 +0x25
sync.(*Cond).Wait(0xf840081300, 0x1)
        /usr/local/Cellar/go/1.0.3/src/pkg/sync/cond.go:67 +0xaa
github.com/burke/zeus/go/processtree.(*SlaveNode).WaitUntilReadyOrCrashed(0xf8400871a0, 0x51629)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:75 +0x133
github.com/burke/zeus/go/processtree.(*SlaveNode).doWaitingState(0xf840087410, 0xf800000001, 0x10e22c, 0x5700000001)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:163 +0x51
github.com/burke/zeus/go/processtree.(*SlaveNode).Run(0xf840087410, 0xf84005d800, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:136 +0x2f2
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:52 +0x215

goroutine 17 [chan receive]:
github.com/burke/zeus/go/processtree.(*SlaveNode).doUnbootedState(0xf8400871a0, 0xf84005d800, 0x0, 0x5500000000, 0x0, ...)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:184 +0x3d4
github.com/burke/zeus/go/processtree.(*SlaveNode).Run(0xf8400871a0, 0xf84005d800, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavenode.go:138 +0x294
created by github.com/burke/zeus/go/processtree._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/processtree/slavemonitor.go:52 +0x215

goroutine 19 [syscall]:
syscall.Syscall()
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/asm_darwin_amd64.s:14 +0x5
syscall.Read(0x230000000b, 0xf840103000, 0x80000000800, 0x100000001, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/zsyscall_darwin_amd64.go:905 +0x78
os.(*File).read(0xf84005e3e0, 0xf840103000, 0x80000000800, 0x80000000800, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/file_unix.go:174 +0x58
os.(*File).Read(0xf84005e3e0, 0xf840103000, 0x80000000800, 0xf840103000, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/file.go:95 +0x83
github.com/burke/zeus/go/filemonitor._func_001(0xf84005e288, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/filemonitor/filemonitor.go:92 +0x87
created by github.com/burke/zeus/go/filemonitor.startWrapper
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/filemonitor/filemonitor.go:103 +0x22f

goroutine 20 [syscall]:
syscall.Syscall6()
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/asm_darwin_amd64.s:38 +0x5
syscall.wait4(0x7925, 0xf84005e4e8, 0x0, 0xf840064240, 0x1, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/zsyscall_darwin_amd64.go:32 +0x81
syscall.Wait4(0x7925, 0x226de34, 0x0, 0xf840064240, 0x0, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/syscall/syscall_bsd.go:136 +0x6a
os.(*Process).wait(0xf840045d60, 0x0, 0x0, 0x0, 0x9e551, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/exec_unix.go:22 +0xe1
os.(*Process).Wait(0xf840045d60, 0x0, 0x0, 0x0)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/doc.go:43 +0x25
os/exec.(*Cmd).Wait(0xf840069000, 0x0, 0x0, 0x0)
        /usr/local/Cellar/go/1.0.3/src/pkg/os/exec/exec.go:308 +0x1b7
github.com/burke/zeus/go/filemonitor._func_002(0xf84005e290, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/filemonitor/filemonitor.go:106 +0x29
created by github.com/burke/zeus/go/filemonitor.startWrapper
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/filemonitor/filemonitor.go:111 +0x246

goroutine 22 [chan receive]:
net.(*pollServer).WaitRead(0xf840044d80, 0xf84011a000, 0xf8400ea6c0, 0x23, 0x1, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/fd.go:268 +0x73
net.(*netFD).accept(0xf84011a000, 0x641a5, 0x0, 0xf840043480, 0xf84005e040, ...)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/fd.go:622 +0x20d
net.(*UnixListener).AcceptUnix(0xf8400455c0, 0x0, 0x0, 0x0)
        /usr/local/Cellar/go/1.0.3/src/pkg/net/unixsock_posix.go:350 +0x4d
github.com/burke/zeus/go/clienthandler._func_002(0xf84005e3f8, 0xf84005e038, 0x0, 0x0)
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/clienthandler/clienthandler.go:37 +0x28
created by github.com/burke/zeus/go/clienthandler._func_001
        /Users/turadg/Code/Go/src/github.com/burke/zeus/go/clienthandler/clienthandler.go:44 +0x15a
Bilbo:dimitar user_service (master)

The issue is very old now, probably not relevant.

repo: burke/zeus


text:
Master CI build error

Transpile... https://travis-ci.org/bustlelabs/shep/builds/204605328

will fix

On Feb 23, 2017, at 6:55 AM, Steve Faulkner notifications@github.com wrote:
Transpile... https://travis-ci.org/bustlelabs/shep/builds/204605328
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I just restarted and it passed

source: gharchive/issue

authors: southpolesteve zfoster

repo: bustlelabs/shep

license: MIT

license_type: permissive

license_source: github-api


text:
Single post, interesting people block should not appear

The block "Interesting people" on right sidebar should not appear on single post when logged:

Also there should be a bottom margin on sidebar right blocks

Yes, was going to report this. Thanks for fixing it. Also noticed: on Recommended Posts, there's no context menu (i.e. I can't right-click), nor Cmd + Click to open in a new tab. I don't always want to navigate away from the page I'm on right away.
I can file into another issue if you'd like.

@ryanbaer yeah probably should put it in another issue

Couldn't assign you, so here you go: https://github.com/busyorg/busy/issues/917

@ryanbaer thanks!

Fixed in #916

authors: bonustrack jm90m ryanbaer

repo: busyorg/busy

license: mit

license_source: bigquery


text:
Option to completely deactivate hitAreaMargins

The whole hitAreaMargins is quite tricky and compote heavy as you state yourself in: https://github.com/bvaughn/react-resizable-panels/blob/638d0f6d3a9d1aeabae8333396ed725ecbeff513/packages/react-resizable-panels/src/PanelResizeHandleRegistry.ts#L169-L174
I propose we have an option to completely disable the behavior, getting back the old straight-forward behaviour.
My problems with hitAreaMargins:

clicking panning in the margin area triggers movement of the panel but also of a element behind it (a map that gets panned). This feels bad, because a user would expect either to pan the panel or the map but not both
setting hitAreaMargins={{ coarse: 0, fine: 0}} still uses the tricky calculations you do in your code which is totally unnecessary and can lead to bugs. Reporting the bugs is one thing, but being able to disableable it would help a lot.
I have some weird behaviour in combination with collapsible, which I can not reproduce in codesandbox but I suspect it has to do with the way hitAreaMargins works.

What you're describing sounds like it's pretty specific to your website. If you can provide a Code Sandbox example, I'll take a look and see if I can recommend something to help. (Or if there is a bug in this library, that's also good to uncover.)
Generally speaking, I don't want to support two separate mechanisms for resize handling based on hitAreaMargins though, so this is not a change I'm interested in making.

This problem was related to https://github.com/bvaughn/react-resizable-panels/issues/342, so I am fine for the moment.
I still think we should have the option to disable the "TRICKY" functionality from hitAreaMargins 😃

If you'd like to remove that feature, I suggest just forking this library. The license is very permissive so as to allow that.

One of my problems ("clicking panning in the margin area triggers movement of the panel but also of a element behind it") should have actually been solved by https://github.com/bvaughn/react-resizable-panels/pull/338, correct?
I still have it and will try to create a sandbox. Maybe this is related to how google maps api is also kind of greedy for panning events.

For reference, here a screen recording:
https://github.com/bvaughn/react-resizable-panels/assets/45362676/5f6d9679-3c67-49ae-8f15-1b14e5e461cd

If you'd like to remove that feature, I suggest just forking this library. The license is very permissive so as to allow that.

Would you allow a PR?

No. This is not a change I'm interested in making.

It's possible Google maps is also listening at the root of the window and intercepting the events before this library is. I don't know.

authors: Fabioni bvaughn

repo: bvaughn/react-resizable-panels


text:
🛑 SMR Vinay Cascade A Block is down

In 6872cf7, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 20349 ms

Resolved: SMR Vinay Cascade A Block is back up in f963a8a.

repo: bvenkysubbu/tymlymonitor


text:
🛑 Sowparnika Swastika 2 is down

In f3dbd6b, Sowparnika Swastika 2 (https://cloud.tymly.in/status/1099) was down:

HTTP code: 521
Response time: 232 ms

Resolved: Sowparnika Swastika 2 is back up in 7d49a2d.


text:
🛑 SMR Vinay Cascade A Block is down

In eb9bb52, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 20228 ms

Resolved: SMR Vinay Cascade A Block is back up in b922c73.


text:
🛑 Desai Grandeur 1 is down

In 6b325f7, Desai Grandeur 1 (https://cloud.tymly.in/status/1133) was down:

HTTP code: 521
Response time: 20248 ms

Resolved: Desai Grandeur 1 is back up in 147c985.


text:
🛑 Sowparnika Swastika 1 is down

In 0500573, Sowparnika Swastika 1 (https://cloud.tymly.in/status/1101) was down:

HTTP code: 521
Response time: 239 ms

Resolved: Sowparnika Swastika 1 is back up in 0dadfe0.


text:
🛑 SMR Vinay Cascade A Block is down

In 0ba23dc, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 229 ms

Resolved: SMR Vinay Cascade A Block is back up in bf11fdc.


text:
🛑 SBB Touchstone D Block is down

In c3bd218, SBB Touchstone D Block (https://cloud.tymly.in/status/1085) was down:

HTTP code: 521
Response time: 230 ms

Resolved: SBB Touchstone D Block is back up in 9305ee5.


text:
🛑 PSR Aster 1 is down

In 3292e42, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 20219 ms

Resolved: PSR Aster 1 is back up in 40a9d12.


text:
🛑 Dasta Concerto Clubhouse Gym is down

In 797d729, Dasta Concerto Clubhouse Gym (https://cloud.tymly.in/status/1189) was down:

HTTP code: 521
Response time: 20228 ms

Resolved: Dasta Concerto Clubhouse Gym is back up in e2c96c8.


text:
🛑 SBB Touchstone C Block is down

In 1e7a523, SBB Touchstone C Block (https://cloud.tymly.in/status/1184) was down:

HTTP code: 521
Response time: 20236 ms

Resolved: SBB Touchstone C Block is back up in 795ac00.


text:
🛑 Desai Grandeur 2 is down

In f0a1978, Desai Grandeur 2 (https://cloud.tymly.in/status/1134) was down:

HTTP code: 521
Response time: 20256 ms

Resolved: Desai Grandeur 2 is back up in 4b2777c.


text:
🛑 White Breeze 1 is down

In 571c4f2, White Breeze 1 (https://cloud.tymly.in/status/1096) was down:

HTTP code: 521
Response time: 258 ms

Resolved: White Breeze 1 is back up in a43b21a.


text:
🛑 SMD Altezz Block B is down

In 750376f, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 20247 ms

Resolved: SMD Altezz Block B is back up in a8ff7b2.


text:
🛑 SMD Altezz Block B is down

In 9b5452d, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 20213 ms

Resolved: SMD Altezz Block B is back up in 52f43e5.


text:
🛑 Trifecta Esplanade C Block is down

In 7a89f71, Trifecta Esplanade C Block (https://cloud.tymly.in/status/1155) was down:

HTTP code: 521
Response time: 225 ms

Resolved: Trifecta Esplanade C Block is back up in a5db01c.


text:
🛑 SMD Altezz Block C is down

In 471d131, SMD Altezz Block C (https://cloud.tymly.in/status/1177) was down:

HTTP code: 521
Response time: 20234 ms

Resolved: SMD Altezz Block C is back up in 33bfb75.


text:
🛑 DSR Sunrise Towers is down

In adead4f, DSR Sunrise Towers (https://cloud.tymly.in/status/1025) was down:

HTTP code: 521
Response time: 20238 ms

Resolved: DSR Sunrise Towers is back up in 83a818c.


text:
🛑 Nitesh Flushing Meadows Block B is down

In bbc3483, Nitesh Flushing Meadows Block B (https://cloud.tymly.in/status/1047) was down:

HTTP code: 521
Response time: 20247 ms

Resolved: Nitesh Flushing Meadows Block B is back up in 0bbe81f.


text:
🛑 SMD Altezz Block B is down

In c2ecdd8, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 224 ms

Resolved: SMD Altezz Block B is back up in 9e28f8d.


text:
🛑 SBB Touchstone C Block is down

In 093271d, SBB Touchstone C Block (https://cloud.tymly.in/status/1184) was down:

HTTP code: 521
Response time: 20249 ms

Resolved: SBB Touchstone C Block is back up in 7c04d8a.


text:
🛑 White Breeze 2 is down

In 5e2d513, White Breeze 2 (https://cloud.tymly.in/status/1097) was down:

HTTP code: 521
Response time: 241 ms

Resolved: White Breeze 2 is back up in 977731e.


text:
🛑 Madhuban Brindavan B Block is down

In 9cfdd1c, Madhuban Brindavan B Block (https://cloud.tymly.in/status/1136) was down:

HTTP code: 521
Response time: 242 ms

Resolved: Madhuban Brindavan B Block is back up in fa32f0e after 875 days, 18 hours, 44 minutes.


text:
🛑 Sowparnika Ananda is down

In 0cf3bc2, Sowparnika Ananda (https://cloud.tymly.in/status/1036) was down:

HTTP code: 521
Response time: 20232 ms

Resolved: Sowparnika Ananda is back up in 48ebd7d after 26 minutes.


text:
🛑 SMR Vinay Cascade A Block is down

In b04e0fe, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 20235 ms

Resolved: SMR Vinay Cascade A Block is back up in 4c230e4.


text:
Add EU smart plug mini MSS315 (Matter)

{"uuid":"xxxxxxxxxxxxxxxxxxxxx","onlineStatus":1,"devName":"Reiskocher","devIconId":"device024","bindTime":1681137596,"deviceType":"mss315","subType":"eu","channels":[{}],"region":"eu","fmwareVersion":"9.3.26","hdwareVersion":"9.0.0","userDevIcon":"","iconType":1,"domain":"mqtt-eu-3.meross.com","reservedDomain":"mqtt-eu-3.meross.com","cluster":3,"hardwareCapabilities":[],"firmware":"9.3.26","hbDeviceId":"xxxxxxxxxxxxxxxxxxxxx","model":"MSS315"

Hi @DeutscheMark
Please install the beta version of the plugin
https://github.com/bwp91/homebridge-meross/wiki/Beta-Version

Hi @bwp91
Thanks for the fast response and the beta version with support for the MSS315.
All the plugs I use are now found by the plugin (hybrid with simple confit) and I can see their current status in Home and turn them on/off. I also have some offline plugs that are ignored as intended.
Thank you. 😊


text:
Buttons "Create", "Edit" and "Delete" for template tags are absent for user

Buttons "Create", "Edit" and "Delete" tags aren't available for role "User" in Images tab.
Steps:

Log in and go to Images;
Go to Tags tab of any Template or ISO

Actual result: Buttons for manage of tags aren't available for a role "User"
Expected result: Buttons for manage of tags are available for a role "User"
Connected feature: image_tag_create, image_tag_edit, image_tag_delete
Screenshot:

Test on:
tamazlykar/1012-template-tags-action-buttons
Regression:
image_tag_create, image_tag_edit, image_tag_delete

Tested on tamazlykar/1012-template-tags-action-buttons

authors: rennervo tamazlykar

repo: bwsw/cloudstack-ui


text:
Use with Tails

Unfortunately Tails has not the recent Electrum version and since I cannot use pip I cannot either install from source.
The only option is to use AppImage, but AFAIK this plugin cannot work with it. There is any workaround to this?
(I cannot use the old Electrum, because my watch-only wallet has been created with a recent electrum version and is not compatible)

I'm afraid that I'm not aware of a workaround for using the AppImage. It's not just that bwt can't work with it, it cannot be used with external electrum plugins at all.
But I'll investigate some more and report back, I might have an idea that could work...

I'm afraid that I'm not aware of a workaround for using the AppImage. It's not just that bwt can't work with it, it cannot be used with external electrum plugins at all.
But I'll investigate some more and report back, I might have an idea that could work...

Okay, so its actually pretty simple!
# Extract AppImage (to a subdirectory named 'squashfs-root')
$ ./electrum-x.y.z-x86_64.AppImage --appimage-extract

# Copy the bwt plugin directory
$ cp -r /path/to/bwt squashfs-root/usr/lib/python3.7/site-packages/electrum/plugins

# Start Electrum, setup bwt, then run again without --offline
./squashfs-root/AppRun --offline

(The --offline thing is unrelated to the AppImage, just a general recommendation to avoid acceidntly connecting to public servers.)

Okay, so its actually pretty simple!
# Extract AppImage (to a subdirectory named 'squashfs-root')
$ ./electrum-x.y.z-x86_64.AppImage --appimage-extract

# Copy the bwt plugin directory
$ cp -r /path/to/bwt squashfs-root/usr/lib/python3.7/site-packages/electrum/plugins

# Start Electrum, setup bwt, then run again without --offline
./squashfs-root/AppRun --offline

(The --offline thing is unrelated to the AppImage, just a general recommendation to avoid acceidntly connecting to public servers.)

I added some instructions and a small helper script to ease the setup.
Thanks for getting me to look into this again!

I added some instructions and a small helper script to ease the setup.
Thanks for getting me to look into this again!

Reopening until you confirm this works for you.

Reopening until you confirm this works for you.

It worked on various environments that I tried this on, closing.

authors: shesek tiero

repo: bwt-dev/bwt-electrum-plugin


text:
Hitbox being offset and way too large

I tried to make a boss that has a custom hitbox using this mod but the hitbox is really large and offset. I used the sample code from the repo's readme but whenever I returned a list with more than one element the hitbox became like the one in the image. I've tried to use extremely small numbers for the hitbox size but it didn't work. I've also customized and completely removed the setDimensions() method for the entity but it also didn't work
The entity type I'm using is a PathAwareEntity

Hi, can I see the code for your custom collider?

repo: byteManiak/mecha


text:
Add Divya as recognized contributor

I am nominating or self-nominating a Recognized Contributor.
Name: Divya Mohan
GitHub Username: @divya-mohan0209
Projects/SIGs:

SIG-Documentation
JCO

Nomination
Divya has made several contributions to documentation for component docs and JCO.
Optional: Endorsements

Bailey Hayes (@ricochet)

[ ] I have read and understood the qualifications for a Recognized Contributor

Thank you @ricochet :heart:

source: gharchive/pull-request

repo: bytecodealliance/governance


text:
aot/jit native stack bound check improvement

summary:
Move the native stack overflow check from the caller to the callee because the former doesn't work for call_indirect and imported functions.
Make the stack usage estimation more accurate.
Instead of making a guess from the number of wasm locals in the function, use the LLVM's idea of the stack size of each MachineFunction. The former is inaccurate because a) it doesn't reflect optimization passes and b) wasm locals are not the only reason to use stack.
To use the post-compilation stack usage information without requiring 2-pass compilation or machine-code imm rewrites, introduce a global array to store stack consumption of each functions.
for JIT, use a custom IRCompiler with an extra pass to fill the array.
for AOT, use clang -fstack-usage equivalent instead because we support external llc.
Re-implement function call stack usage estimation to reflect the real calling conventions better.
(aot_estimate_stack_usage_for_function_call)
Re-implement stack estimation logic (--enable-memory-profiling) based on the new machinery.
discussions:
https://github.com/bytecodealliance/wasm-micro-runtime/issues/2105
todo/known issues/open questions:

implement 32-bit case
fill the stack_sizes array for jit (use something similar to https://github.com/bytecodealliance/wasm-micro-runtime/pull/2216)
fix jit tier up (or confirm it isn't broken) reading the code, i couldn't find anything broken.
ensure appropriate jit partitioning (ensure to compile the function body before executing the corresponding wrapper)
account caller-side stack consumption (cf https://github.com/bytecodealliance/wasm-micro-runtime/issues/2105#issuecomment-1543533575)

what to do for native function calls? do nothing special, at least within this PR

fix external llc. pass -fstack-usage to the external command?
re-implement enable_stack_estimation based on the new machinary
what to do for RtlAddFunctionTable?

it seems broken regardless of this PR. but this PR might break it further.
i'm not even sure how i can test it. is it for AddVectoredExceptionHandler?
see also: https://github.com/bytecodealliance/wasm-micro-runtime/issues/2242
references:

https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtladdfunctiontable
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format?redirectedfrom=MSDN#the-pdata-section

test

this test module consumes about 8MB of stack (wamr aot with llvm 14, amd64) https://github.com/yamt/toywasm/blob/1cc6d551b0fcd10cc8c8b3516c48ba08015e6ad6/wat/many_stack.wat.jinja#L37-L38 worked as expected
investigate assertion failure seen with js.wasm
investigate app heap corruptions seen with aot https://github.com/bytecodealliance/wasm-micro-runtime/issues/2275
non x86 archs

benchmark. noinline can have severe implications for certain type of modules. however, as wasm is usually a compiler target, hopefully fundamental inlining has already been done before aot/jit compilation. https://github.com/bytecodealliance/wasm-micro-runtime/pull/2244#issuecomment-1588769538
remove/disable debug code
do something for func_ctx->debug_func. just disable for the wrapper func?
add missing error checks
reduce code dup. probably make aot_create_func_context use create_basic_func_context.
fix errors caused by empty function
look at x86_32 failure on the ci

Segv https://github.com/bytecodealliance/wasm-micro-runtime/pull/2260
*Nan related issue: an i32.reinterpret_f32 test in conversions.wast was failing. it's x87 flds/fstp which doesn't preserve sNaN. the problem is not specific to this PR. it seems working on main branch just by luck. (it would fail if you disable optimizations.) i don't think there's a simple way to fix it w/o changing the aot ABI. https://github.com/bytecodealliance/wasm-micro-runtime/pull/2269

a quick benchmark with coremark

# wamr versions
# base: 7ec77598dd5c62eafdbe03eca883bc42781f097e
# new: be166e8a4fdeef4b941a979d62ab81e62cdf4ddf (https://github.com/bytecodealliance/wasm-micro-runtime/pull/2244)

# wamrc options
# bc0: --bounds-checks=0
# bc1: --bounds-checks=1
# bc1-emp: --bounds-checks=1 --enable-memory-profiling

script: https://gist.github.com/yamt/78de859809694a893b7c7732a1025722

@yamt Do we need to add extra option if we want to enable the new stack overflow check? Or we just use it as normal, e.g. wamrc --target=i386 -o test.aot test.wasm?

the same usage as before.

@yamt Do we need to add extra option if we want to enable the new stack overflow check? Or we just use it as normal, e.g. wamrc --target=i386 -o test.aot test.wasm?

the same usage as before.

Got it, thanks. I just had a quick review, it looks good but it is a little complex, I need to read more carefully about the aot_llvm.c and aot_emit_function.c, and do some tests.

while this works for x86. it doesn't seem working well for xtensa. let me investigate a bit.

while this works for x86. it doesn't seem working well for xtensa. let me investigate a bit.

there are at least two problems:

with its windowed abi, tail call elimination is difficult. the xtensa version of llvm doesn't implement it.
it allocates the area of function call arguments as a part of caller's stack frame. unlike x86, it seems that it's already included the stack size reported by MFI->getStackSize().

while this works for x86. it doesn't seem working well for xtensa. let me investigate a bit.

there are at least two problems:

with its windowed abi, tail call elimination is difficult. the xtensa version of llvm doesn't implement it.
it allocates the area of function call arguments as a part of caller's stack frame. unlike x86, it seems that it's already included by the stack size reported by MFI->getStackSize().

Thanks, do you mean changing size += 16; to size = align_uint(size, 16) doesn't work for xtensa, or this PR has issue for xtensa?

while this works for x86. it doesn't seem working well for xtensa. let me investigate a bit.

there are at least two problems:

with its windowed abi, tail call elimination is difficult. the xtensa version of llvm doesn't implement it.
it allocates the area of function call arguments as a part of caller's stack frame. unlike x86, it seems that it's already included by the stack size reported by MFI->getStackSize().

Thanks, do you mean changing size += 16; to size = align_uint(size, 16) doesn't work for xtensa, or this PR has issue for xtensa?

this PR.
the approach with a wrapper function somehow assumes efficient tail call.

while this works for x86. it doesn't seem working well for xtensa. let me investigate a bit.

there are at least two problems:
* with its windowed abi, tail call elimination is difficult. the xtensa version of llvm doesn't implement it.

as a tail call in general seems impossible in xtensa windowed abi, i suspect there is no simple solution.
also, riscv seems to prevent tail call optimization in some cases. (when a function have too many parameters to pass via registers?)
a possible workaround is to tweak our aot abi to make >N parameters via a pointer like the following.
that way the stack consumption of the wrapper functions will not be too large even w/o tail call optimization. i feel it's a bit too intrusive though.
struct func1_stack_params {
     arg3
     arg4
};

func1(exec_env, arg1, arg2, struct func1_stack_params *)

caller()
{
    struct func1_stack_params params;
    func1(exec_env, arg1, arg2, &params);
}

* it allocates the area of function call arguments as a part of caller's stack frame. unlike x86, it seems that it's already included by the stack size reported by MFI->getStackSize().

this is just a matter of adding some target dependent code. (eg if (xtensa))

It is good to me if it is only for xtensa 32-bit. For xtensa 64-bit linux/macos, we can also use stack hw boundary check, right?

i fixed xtensa case. it's still inefficient, but not broken.
while i haven't tested on a real hardware yet, the wamrc output looks reasonable.

i fixed xtensa case. it's still inefficient, but not broken. while i haven't tested on a real hardware yet, the wamrc output looks reasonable.

lightly tested on esp32-devkitc. it worked as expected so far.

i fixed xtensa case. it's still inefficient, but not broken. while i haven't tested on a real hardware yet, the wamrc output looks reasonable.

lightly tested on esp32-devkitc. it worked as expected so far.

OK, it seems there is no comment from other developers, let's merge this PR?

i fixed xtensa case. it's still inefficient, but not broken. while i haven't tested on a real hardware yet, the wamrc output looks reasonable.

lightly tested on esp32-devkitc. it worked as expected so far.

OK, it seems there is no comment from other developers, let's merge this PR?

i have no problem with it

authors: wenyongh yamt

repo: bytecodealliance/wasm-micro-runtime


text:
GlobalValueSet was moved to IRPartitionLayer recently, but we have a …

…local definition anyway

This resolves a compilation error against recent revisions of LLVM

GlobalValueSet was moved to IRPartitionLayer recently

In which llvm release? WAMR is somewhat sensitive to the version of LLVM. Currently WAMR depends on LLVM 15.x

It was moved about a month ago in https://github.com/llvm/llvm-project/commit/04af63b267c391a4b0a0fb61060f724f8b5bc2be. Internally at Google we build WAMR against LLVM at approximately HEAD.
In the above change, GlobalValueSet is now using GlobalValueSet = std::set<const GlobalValue *>; inside IRPartitionLayer.
I think my change is safe, to my non-expert eyes the definition of GlobalValueSet is the same before and after this change.


text:
What should the default behavior of wasmtime serve be with scheme/authority?

My changes in https://github.com/bytecodealliance/wasmtime/pull/8861 introduced a change in the default behavior of wasmtime serve. Notably this program:
use wasi::http::types::*;

struct T;

wasi::http::proxy::export!(T);

impl wasi::exports::wasi::http::incoming_handler::Guest for T {
    fn handle(request: IncomingRequest, outparam: ResponseOutparam) {
        println!("request.method = {:?}", request.method());
        println!("request.scheme = {:?}", request.scheme());
        println!("request.authority = {:?}", request.authority());

        let resp = OutgoingResponse::new(Fields::new());
        ResponseOutparam::set(outparam, Ok(resp));
    }
}

(compiled component)
When run with wasmtime serve and hit with curl http://localhost:8080 it prints:
Serving HTTP on http://0.0.0.0:8080/
stdout [0] :: request.method = Method::Get
stdout [0] :: request.scheme = Some(Scheme::Http)
stdout [0] :: request.authority = Some("localhost:8080")

On main, however, it prints
Serving HTTP on http://0.0.0.0:8080/
stdout [0] :: request.method = Method::Get
stdout [0] :: request.scheme = None
stdout [0] :: request.authority = None

This regression is due to these changes because I didn't understand what they were doing.
Now why wasn't this caught by the test suite? I tried writing a test for this and it passed, but apparently it's due to our usage of
hyper::Request::builder().uri("http://localhost/") in the test suite. That creates an HTTP requests that looks like:
GET http://localhost/ HTTP/1.1
...

where using curl on the command line generates:
GET / HTTP/1.1
...

That leads me to this issue. What should scheme and authority report in these two cases for wasmtime serve by default? The previous behavior means that GET / could not be distinguished from GET http://localhost/ which naively seems like what scheme and authority are trying to map to.
Is the previous behavior of wasmtime serve buggy? Is the current behavior buggy? Should the spec be clarified?
cc @elliottt @pchickey

I'll note that the difference can be seen with:
$ curl -v --request-target http://localhost/ http://localhost:8080

vs
$ curl -v http://localhost:8080

in terms of how the headers are set. The former is basically what our test suite does while the latter is what the curl command line does by default.

The former (full URL in request) is incorrect; that form is only applicable to CONNECT methods.

The former (full URL in request) is incorrect; that form is only applicable to CONNECT methods.
Edit: looks like I might be wrong about it being incorrect per se; it might just be very uncommon.

That makes sense, and means we should probably update our tests, but I guess I'm also curious still what the behavior here should be. For example why do scheme and authority return an Option at the WIT level? Are they intended to map to this or is it expected that they're effectively always Some?

scheme is derived from out of band info: whether the request came in over TLS or not

my take is that we should have wasi:http either always provide an authority, or provide the host header. Otherwise there's no standard way for content to learn about the authority it's called under. I know that @lukewagner concluded that we must never provide the host header. If that stands, I conversely think that we must continue providing the authority for incoming requests.
In effect, that means that for incoming requests what content sees is always the absoluteURI form, which the RFC seems to indicate is the way forward, too:

To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.

Don't pay too much attention to the 1.1 spec for future direction. HTTP/2 makes authority even more special by splitting it into a "pseudo-header".

Great question.  First of all, from asking some HTTP folks, I believe it is the case that we could tighten the spec wording to say that for methods other than CONNECT and OPTIONS, there must always be an authority (i.e., the return value is some).  Apparently, CONNECT and OPTIONS have an unfortunate * option that simply has no authority.
Next, my understanding from RFC 9110 is that the authority either comes from the :authority pseudo-header in H/2/3 or the Host header in H/1, and if both are present, they are not allowed to disagree (and this is Web-compatible).  Thus, I think what WASI HTTP should say is that:

Host is in the definitely-forbidden headers list
The request.authority field is derived in a transport-dependent manner (and required to be present for non-CONNECT/OPTIONS)

This allows the host implementation to do the transport-appropriate thing for requests coming in or out over the wire.

Ok so for the use case of wasmtime serve specifically:

[method]incoming-request.scheme is always some(http) because we don't implement https yet
[method]incoming-request.authority uses the incoming URI's host if it's there (probably only for CONNECT and OPTIONS). Otherwise it uses Host, otherwise it returns .... None? "127.0.0.1"? The value of --addr?

This all indicates to me that new_incoming_request should take both a scheme and an authority argument rather than inferring these from the Request as well?
(sorry I'm really looking for guidance/second opinions here, I don't know why things were originally constructed the way they are or if they're just how things got shaken out)

otherwise it returns .... None?

Do we want/need to support HTTP/1.0? afaik host is mandatory for 1.1

Ah ok I didn't realize that was a 1.0 thing. Sounds like it should search for Host as a header in the host-side hyper::Request for the authority if it's not present in the URI. I try to make a PR with these changes tomorrow.

The impression that I got talking to an HTTP server maintainer is that it's web-compatible to require the Host field (rejecting if it's absent in HTTP 1.0 or 1.1) and that allowing an empty authority in cases other than CONNECT/OPTIONS can transitively lead to security issues (random googling found this e.g.).  Similarly, RFC 9110 (which also intends to be Web-compatible) says that there MUST be a Host header (when there is no :authority pseudo-header) without making an exception for HTTP 1.0.  Thus, I'd suggest making it an error in wasmtime serve if there is no Host in HTTP 1.0, at least to start with, and see if anyone complains.

authors: alexcrichton lann lukewagner tschneidereit

repo: bytecodealliance/wasmtime


text:
为什么不用透明的webm格式呢？

透明的webm格式大小占用非常小，为什么不采用这种方案呢？

急急急!!! 大佬,我们现在公司就需要用webm透明通道的视频播放,背景透明,,这个你有方案吗???

repo: bytedance/AlphaPlayer


text:
fix: BufReader should not panic when used after cancellation

If a BufReader::fill_buf() call is cancelled when the internal buffer is held by .read(), re-allocate the buffer when used in the future.

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

Closing this - simply re-allocating the buffer is incorrect because cancellation is asynchronous and this can result in lost data.
The error message could be improved though...

authors: CLAassistant losfair

repo: bytedance/monoio


text:
Undefined symbols for architecture x86_64

Hello.When I use sonic which version is 1.9.2,I get an error 'Undefined symbols for architecture x86_64'.I test this problem in linux and mac.My go version is 1.17.11.I don't know how to solve this problem

Please describe your question in more details.

Maybe you mean decoder.SyntaxError, it works now on v1.10.0-rc

authors: AsterDY chenzhuoyu zacharytse

repo: bytedance/sonic


text:
Update to ActorDB 0.10.25.

Updated ActorDB to 0.10.25 and dumb-init to 1.20

Reviewed and tested, merging.
Thanks @VisualFox!

authors: VisualFox ianmjones

repo: bytepixie/actordb-for-docker


text:
🛑 byzocker.de is down

In 1e5a18e, byzocker.de (https://byzocker.de) was down:

HTTP code: 502
Response time: 653 ms

Resolved: byzocker.de is back up in 1c17927.


text:
SeaExplorer delayed mode time series data loss

In testing the new code for this pull request, I found an issue with processing the delayed mode SeaExplorer time series data for missions for which certain sensors (oxygen in this case) are severely oversampled. These missions end up with delayed mode data files that contain fewer actual (non-nan) data points than the realtime files. In other words, we are losing data during the processing.
Currently, the dropna function is used to remove the oversampled oxygen data when converting the raw data. The dropna function is working correctly, however note that the resulting data has many nan values in it, for both the CTD and optics. These nan values will often not co-occur.
I think the problem in the processing is caused by using the GPCTD_TEMPERATURE as the default time base in seaexplorer.py. This variable contains nan values that are not all co-located with the nan values in the oxygen and optical variables. It's desirable to use the CTD as the time base, but we may need to do some interpolation to avoid losing data when the other variables are mapped onto this base.

We have had similar issues with our delayed mode datasets in the past. To get around it, we use NAV_LATITUDE as the timebase in all of our datasets, as this has a non-nan value for every line. Here's an example yml for one of our gliders with a GPCTD. https://github.com/voto-ocean-knowledge/deployment-yaml/blob/master/mission_yaml/SEA70_M15.yml
Would this solution work for you?
This also raises the broader point that perhaps we should have a test with delayed mode data, as currently all tests are run with nrt data

We use NAV_LATITUDE as timebase in conjunction with keep_variables that account for each of the sensors. In this way, all data pass the dropna function, but rows with no data from any of the sensors are dropped by the 'keep_variables' in ncvar block.

I'm not sure if this is related, but I had previously noticed that the timestamps recorded for sensors that are known to be outputting at 1Hz (according to the sensor) are never exactly 1Hz, likely due to the time that they arrive at the payload computer -- in other words, timing information from the sensor is not recorded by the PLD but it assigns it's own. The result is that two different sensors sampling at the same rate (e.g. a CTD and an optical O2 sensor) end up with times that are different by microseconds from one sample to the next, and even though we expect them to be "simultaneous", in terms of the recorded time stamps, they aren't.

For our data, we have the situation where indeed "Nav" is written every heartbeat; certainly though there is no new data in Nav.  Some heartbeats have no data at all, some have CTD data (all variables), some have Optical, some have O2.  Sometimes these line up, and currently we only save when the other sensors line up with the CTD sensors.
I think what needs to happen is that for each instrument we need a timeseries, and then we need to align it with the timebase.   For our SeaExplorers, that time base is most naturally the CTD.  The other samples may be offset from that a it, but the CTD is sampling at 2 Hz, and I don't think we care about the other sensors slight phase errors at less than 2 Hz.
I haven't explored how to do this with polars, but in xarray you would just do an interp operation before filling it into the parent.  So in pseudocode:
time, ctd_temp = decode('ctd_temp', drop_na=True)
ds['time'] = ('time', time)
ds['temperature'] = ctd_temp
# etc other ctd variables
time_O2, O2_sat = decode('O2_sat', drop_na=True)
ds['O2'] = np.interp(time, time_O2, O2_sat)
...
# etc other O2 variables

I don't think this step would slow things down very much, and I think linear interpolation should be pretty OK from a data point of view.
A second option would be just to save the three instruments as separate polars arrays as raw output and then merge as a second step.  That would allow double checking the raw data.  However, I think the raw SeaExplorer data is simple enough that it's pretty usable as-is for any debugging.

I'll ping about this.  Is there a consensus about how to proceed?

I think what needs to happen is that for each instrument we need a timeseries, and then we need to align it with the timebase. For our SeaExplorers, that time base is most naturally the CTD. The other samples may be offset from that a it, but the CTD is sampling at 2 Hz, and I don't think we care about the other sensors slight phase errors at less than 2 Hz.

I agree with this approach, with the clarification (not really important for the decision or discussion) that I'm 99% sure the GP-CTD samples internally at a max of 1Hz. That's not true for a legato, which can be programmed to sample much faster (up to 16Hz), though the SeaExplorer PLD can only be configured to sample at 1Hz or "as fast as possible" (which IIRC is something like 20Hz)

@callumrollo any objections to this?  I can take a crack at doing it the next few days.
@hvdosser, do we have a link to some data where this is problematic?

The delayed L0-timeseries (dfo-bb046-20200908_delayed.nc) for this mission is a nice example of the problem.

Is there a time, or ideally a set of raw files where this problem occurred?  I couldn't replicate, though I couldn't get it to work at all with the setup in that directory.

Sorry for the delay on this, just got back from vacation. The idea of aligning timebases sounds good to me. Should we linearly interpolate, or do a nearest neighbour? I'm always a little cautious about interpolating data. Especially as it would lead to some strange results with integer data like raw counts for chlorophyll etc. If we want to do it at the raw to raw nc step I can look at implementing it in polars tomorrow

OK, I ran the whole data set, and can see the problem now.
@callumrollo if you wanted to do this, happy to let you.  I'm less nervous about linear interpolation - nearest neighbour leads to phase errors;  However, if there is a difference for other data types, maybe we need an entry in the yml metadata that says which interpolation is used?

The tests are currently failing on the main branch. Looks like this way caused by something in #129. That PR was only for slocum data, so I'll work from the last commit where all the tests cleared for this PR. I've downloaded the dataset that @hvdosser indicated and will use that as a test case for timestamp alignment

@callumrollo I think the tests should be OK on main now (I hope)
I think we need to do some work on the test infrastructure.  In particular, we should force rewriting of the files we compare with.  Right now the way the processing works is it does incremental.

Thanks for working to get the tests  passing again @jklymak. I'll start on resolving this Issue now.
I agree on forced reprocessing in the tests. would using the incremental=False flag suffice for this?

@hvdosser I think the keep_vars functionality present in pyglider already could solve this problem to first order. Is it something you're using?
I've put a demo together of the difference between using CTD as a timebase and using NAV_LATITUDE as a timebase then cutting down to the rows where at least one of the sensors has a sample. It's not perfect, but has been working pretty well for us so far.
https://github.com/callumrollo/keep_vars_experiment/blob/main/timebase_keep_experiment.ipynb
Sorry, it's a bit of a rushed Friday afternoon job!

OK, I forgot about this, and I'm not sure it's documented.  What does this do exactly?

I haven't had a chance to look in detail yet, but the first thing I'd check is whether this works for a delayed-mode dataset. We didn't see much of an issue with the realtime data.

looking at it quickly it seems to keep the data if any of the listed sensors are present in a line.
I guess this is a philosophical thing - do we want all the raw data in a time series, which means any given sensor is riddled with NaN, or do we want time series where the sensors are time-aligned to one sensor's time base.
I guess I'll argue for the latter.  If someone needs the time series with raw O2, for instance, they can rerun the processing with just that variable, and that variable as the timebase.  Or they can load the raw parquet files.   I think by the time we make the first time series netcdf, it should be time-aligned, and not full of NaN's.
This seems particularly apropos for the O2 and the optics on the SeaExplorer, which so far as I can tell are often ludicrously oversampled?
But happy to discuss further.

II agree we need a way to reduce the size of the final timeseries while keeping as much science data as possible.
I've been white-boarding this morning to represent the way pyglider currently does this for seaexplorer data, and what potential improvements could look like. Here's some ASCII art:
Key
Time: PLD_REALTIMECLOCK
nav: NAV_LATITUDE
ctd: LEGATO_TEMPERATURE or GPCTD_TEMPERATURE
oxy: e.g. AROD_FT_DO
nitrate: e.g. NITRATE_CONCENTRATION or other rarely sampling sensor
X: original data
-: no data
I: interpolated data
N: nearest neighbor data
Input pld1 file

Time
nav
ctd
oxy
nitrate

0
X
X
-
X

1
X
-
X
-

2
X
-
X
-

3
X
X
-
-

4
X
-
X
-

5
X
-
X
-

6
X
X
-
-

7
X
-
-
X

8
X
-
X
-

9
X
-
X
-

10
X
X
-
-

Current output options
timebase: ctd

Time
nav
ctd
oxy
nitrate

0
X
X
-
X

3
X
X
-
-

6
X
X
-
-

10
X
X
-
-

This illustrates @hvdosser's problem where oxygen is on a slightly offset timestamp to ctd so it is all dropped
timebase: nav, keep_vars: [ctd, oxy]

Time
nav
ctd
oxy
nitrate

0
X
X
-
X

1
X
-
X
-

2
X
-
X
-

3
X
X
-
-

4
X
-
X
-

5
X
-
X
-

6
X
X
-
-

8
X
-
X
-

9
X
-
X
-

10
X
X
-
-

With keep_vars, as @jklymak identified, any line with a non-nan value for one of the sensors in keep_vars is kept. Resultant files are big, particularly if one of the keep_vars has a high sampling rate.
This is the method we currently implement at VOTO, as the scientists we supply data to don't want any interpolation of data. Some of our delayed mode datasets are almost 10 GB though! Not ideal.
Potential improvements
timebase:ctd linear interpolation

Time
nav
ctd
oxy
nitrate

0
X
X
I
X

3
X
X
I
I

6
X
X
I
I

10
X
X
I
I

This solves the problem nicely for oversampling sensors like oxygen. However, this would be a severe distortion of e.g. a methane sensor that records a sample every 10 minutes and now has an apparent sample every second
timebase:ctd nearst neighbour

Time
nav
ctd
oxy
nitrate

0
X
X
N
X

3
X
X
N
-

6
X
X
N
-

10
X
X
N
N

This avoids over-interpolation of slow sampling sensors, but the downsampling of more fast sampling sensors may be less preferable. May also be more complex to implement.
Whatever we decide to do going forward, I recommend that it is either controllable from the yaml, like the keep_vars solution, or operates on the l0 timeseries as an extra step, so that an end user can get the final l0 timeseries without any interpolation if they want.
We should also explain these various options in the documentation. Perhaps using diagrams like the ones in this comment.

Folks who don't want any interpolation or alignment of sensors have two options (that I agree should be documented)

I would argue that the raw merged parquet file is what the folks who don't want any interpolation are after.  That, to my knowledge, doesn't drop any data or do any processing?

They can make a oxy.yaml that aligns everything to oxygen instead of the ctd, and then they have the best of both worlds - pure oxygen data, and interpolated quantities of everything else.

For interpolation options, totally fine with both linear and nearest.  I'd never use nearest, but...
The original reason for using the CTD for our data sets was that indeed oxygen had much more data, but it was all repeated and was really being sampled at 1 Hz or 2 Hz or something, and seemed a silly error of Alseamars to be sampling it at 48 Hz or whatever they were doing.  Of course if someone has a real data set that needs sampling at higher frequency than the CTD, they should be using that as the timebase.

This sounds like a good way to implement the interpolation. I've started working on a PR.

authors: callumrollo hvdosser jklymak richardsc

repo: c-proof/pyglider


text:
sciter.js using console.log cannot exceed 11 lines

Using usciter debugging, console.log cannot exceed 11 lines, otherwise it cannot be displayed

Fixed already.

authors: c-smile zyxk

repo: c-smile/sciter-js-sdk


text:
JSON Agent

This PR implements a fully-fledged JSON Agent deployment with HTTP and MQTT transports as #185 requested. Specifically, the following got implemented.

Manifests to run JSON Agent in a K8s cluster. The agent comes with an internal endpoint for provisioning and two external endpoints to get JSON device data in, one over HTTP, the other over MQTT---see #181 for our current MQTT setup.
Routing. We expose the HTTP endpoint at <kitt4sme-base-url>/jsonagent/ so devices can POST JSON data at <kitt4sme-base-url>/jsonagent/iot/json?k=<api-key>&i=<device-id>. To send JSON data over MQTT, devices use the MQTT WebSocket implemented in #181 and the topic: json/<api-key>/<device-id>/attrs.
Security. Istio handles TLS termination for the HTTP endpoint and delegates security decisions to the existing FIWARE OPA policy. Security over MQTT works as explained in #181.
In-memory configuration. The service pre-loads device mappings and other config in memory to speed up JSON to FIWARE data translation---see config.js.
Persistence. No Mongo DB backend. Data sits in memory (it isn't much actually) but it's loaded from K8s configmaps, so that's the persistence backend. (If the pod restarts, config map data gets loaded again in memory; all service pods share the same config map data.)
IaC management. The manifests of all agent-related resources are tied to an Argo CD app in the mesh infra project so we can easily manage deployments through a GUI too.
Simplified config model. All the agent config sits in our repo, including devices and mappings. Argo CD automatically deploys this data to the configmaps the service uses as a persistence backend---see point above. No need to fiddle with awkward service calls to figure out what devices have been defined, what their mappings are, or to add new devices. It's all defined in config.js  in our repo. Look at that file to figure out the lay of the land at a glance. Edit it to add or modify device defs, mappings etc. Argo CD takes care of propagating your changes to the cluster.

Demo
Here's a sum up of how to demo most of what this PR implemented.
First off, build your own KITT4SME cluster in a Multipass VM as explained in the bootstrap procedure. Wait a bit until all services are ready. The commands below use the 192.168.64.20 IP address to reach the Multipass VM; replace 192.168.64.20 in each command with your VM's IP.
IaC
Log into Argo CD. There's a json-agent app among the platform infra services. Check out all the resources deployed and have a look at the logs. Open the config map, you should be able to see the exact same content as in the config.js included in this PR.
Provisioning
Provision a service with two devices, one sending data over MQTT and the other over HTTP. Notice it's best to do that in config.js, but we'll do that manually here to speed things up. So as a rule, there would be no need to expose JSON Agent's provisioning API. Since we're bending the rules here, port-forward the agent's provisioning port.
$ kubectl port-forward svc/jsonagent 4041:4041

On to the provisioning business. Create a service with an API key of gr33t, entity type of Greeting and HTTP endpoint of /iot/d.
$ curl -iX POST 'http://localhost:4041/iot/services' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /' \
  -d '{
 "services": [
   {
     "apikey":      "gr33t",
     "entity_type": "Greeting",
     "resource":    "/iot/json"
   }
 ]
}'

Create two devices to send a greeting message. The message is in the JSON format: { "w": data }, where data is a greeting string the device sends. The corresponding NGSI entity has type Greeting and a words attribute holding the actual greeting. The first device has an ID of greeter001 and sends its data over MQTT, whereas the second has ID greeter002 and sends data over HTTP.
$ curl -iX POST \
  'http://localhost:4041/iot/devices' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /' \
  -d '{
 "devices": [
   {
     "device_id":   "greeter001",
     "entity_name": "urn:ngsi-ld:Greeting:001",
     "entity_type": "Greeting",
     "protocol":    "PDI-IoTA-JSON",
     "transport":   "MQTT",
     "attributes": [
       { "object_id": "w", "name": "words", "type": "Text" }
     ]
   }
 ]
}
'

$ curl -iX POST \
  'http://localhost:4041/iot/devices' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /' \
  -d '{
 "devices": [
   {
     "device_id":   "greeter002",
     "entity_name": "urn:ngsi-ld:Greeting:002",
     "entity_type": "Greeting",
     "protocol":    "PDI-IoTA-JSON",
     "transport":   "HTTP",
     "attributes": [
       { "object_id": "w", "name": "words", "type": "Text" }
     ]
   }
 ]
}
'

With this setup, greeter001 is expected to send its UL payload to the MQTT topic

json/gr33t/greeter001/attrs

whereas greeter002 is supposed to POST its JSON payload to the URL

http://192.168.64.20/jsonagent/iot/d?k=gr33t&i=greeter002

since our Istio config routes /jsonagent/<rest> to /<rest> on port 7896 of the jsonagent service.
Finally, check you can retrieve the service and devices you've just created.
$ curl 'http://localhost:4041/iot/services' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /'

{"count":1,"services":[{"apikey":"gr33t","resource":"/iot/json","service":"greeting","subservice":"/","_id":1,"creationDate":1668087518563,"entity_type":"Greeting"}]}

$ curl 'http://localhost:4041/iot/devices' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /'

{"count":2,"devices":[{"device_id":"greeter001","service":"greeting","service_path":"/","entity_name":"urn:ngsi-ld:Greeting:001","entity_type":"Greeting","transport":"MQTT","attributes":[{"object_id":"w","name":"words","type":"Text"}],"commands":[],"static_attributes":[],"protocol":"PDI-IoTA-JSON","explicitAttrs":false},{"device_id":"greeter002","service":"greeting","service_path":"/","entity_name":"urn:ngsi-ld:Greeting:002","entity_type":"Greeting","polling":true,"transport":"HTTP","attributes":[{"object_id":"w","name":"words","type":"Text"}],"commands":[],"static_attributes":[],"protocol":"PDI-IoTA-JSON","explicitAttrs":false}]}

Sending device data over MQTT
We're going to use an external WebSocket client to simulate device data coming in over MQTT.
Browse to http://www.emqx.io/online-mqtt-client. Hit the "New Connection" button and enter the following data: name=kitt4sme, client-id=tasty, host=ws://192.168.64.20, path=/mqtt/, port=80, username=iot. You also need to enter the "iot" user's password, which I can't type here obviously. Hit connect, then send the following JSON message to the json/gr33t/greeter001/attrs topic: { "w": "howzit!" }.
Check the "howzit!" greeting trekked all the way to Orion. It should be stored in the "Greeting" entity having an ID of urn:ngsi-ld:Greeting:001.
$ curl \
  'http://192.168.64.20/orion/v2/entities/urn:ngsi-ld:Greeting:001/attrs/words/value' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /'

"howzit!"

Sending device data over HTTP
Let's also send a greeting from greeter002. This device sends its data over HTTP
$ curl -iX POST \
  'http://192.168.64.20/jsonagent/iot/json?k=gr33t&i=greeter002' \
  -H 'Content-Type: application/json' \
  -d '{ "w": "ahoy, matey!" }'

HTTP/1.1 403 Forbidden
date: Thu, 10 Nov 2022 14:00:52 GMT
server: istio-envoy
content-length: 0

What?! Yep, that's right. Our FIWARE OPA policy checks you've got a valid JWT token, since we didn't have one, we got shown the door. How rude. Well, it's too much of a mission to get a token, so let's zap the security policy
$ kubectl -n istio-system delete authorizationpolicy/fiware-opa

and try again
$ curl -iX POST \
  'http://192.168.64.20/jsonagent/iot/json?k=gr33t&i=greeter002' \
  -H 'Content-Type: application/json' \
  -d '{ "w": "ahoy, matey!" }'

This time the POST goes through and Orion gets our friendly greeting
$ curl \
  'http://192.168.64.20/orion/v2/entities/urn:ngsi-ld:Greeting:002/attrs/words/value' \
  -H 'fiware-service: greeting' \
  -H 'fiware-servicepath: /'

"ahoy, matey!"

As expected, the greeting got stored in the "Greeting" entity having an ID of urn:ngsi-ld:Greeting:002.
Cool bananas!


text:
🛑 www.ozpsav.sk is down

In 6dea76f, www.ozpsav.sk (https://www.ozpsav.sk/sk/Odborovy-zvaz.alej) was down:

HTTP code: 403
Response time: 1184 ms

Resolved: www.ozpsav.sk is back up in 51ed266.


text:
🛑 cms5.alejtech.eu is down

In 8cddacf, cms5.alejtech.eu (http://cms5.alejtech.eu/UserSystem/login/login.alej) was down:

HTTP code: 403
Response time: 479 ms

Resolved: cms5.alejtech.eu is back up in 6640b71.


text:
🛑 www.leopoldov.sk is down

In 2e3051d, www.leopoldov.sk (https://www.leopoldov.sk/) was down:

HTTP code: 403
Response time: 932 ms

Resolved: www.leopoldov.sk is back up in 5fa2d4a.


text:
Hide private symbols (issue #33).

Hi, this is a PR for patch in https://github.com/cacalabs/libcaca/issues/33

Thanks for the PR.

authors: samhocevar yugr

repo: cacalabs/libcaca

license: WTFPL


text:
🛑 CBTB Coffee House Shop is down

In 5fc484c, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 865 ms

Resolved: CBTB Coffee House Shop is back up in a175878 after 13 minutes.

repo: cachetech/service-status


text:
🛑 CBTB Coffee House Shop is down

In e3c7417, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1383 ms

Resolved: CBTB Coffee House Shop is back up in 0489b98 after 16 minutes.


text:
🛑 CBTB Coffee House Shop is down

In 8317883, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1220 ms

Resolved: CBTB Coffee House Shop is back up in 59c1bd6 after 12 minutes.


text:
[WIP] Notifications

DO NOT MERGE THIS YET. IT'S TOTALLY UNREADY!

@Crash-- You've misused migrations here. That belongs in a seeder.

@GrahamCampbell OK but I absolutely need these data in the DB. Without, we'll have a problem, this is why I put it into a migration because migrations are mandatory and seeds are optional, right?

@Crash-- you can still put the data into tables, but you need to look doing that in a seeder, not the migration.

@jbrooksuk Yes, but in the Cachet's documentation we can read " then you may want to seed the database with some example data." and from Laravel's "with test data using seed classes". But in my case, these datas are needed at the beginning.
I can ofc change this behavior, but I'll add more lines of code :(

@GrahamCampbell Can you close this PR? I'll open a new one with several fixes and improvements.

@Crash-- adding more lines of code isn't a problem if it's in the right place. If you're relying on default values to be inserted before the service can run, then you need to add error handling to only look for the service if the service is indeed setup.

This needs rebasing and needs all language filled synced again.

Travis is failing because of a package not being able to download:
- Installing symfony/process (v2.5.8)
    Cloning 62c77d834c6cbf9cafa294a864aeba3a6c985af3
    Failed to download symfony/process from source: Failed to clone git@github.com:symfony/Process.git via git, https, ssh protocols, aborting.

Hmm. I see nothing on github/travis status pages about this.

Also I saw "Could not authenticate github.com"

Do we have to add an API key or something (I've never had to).

No, not at all.

Travis has just f***ed up somewhere.

Bizarre. They need to run Cachet and let us know about this kind of shenanigans!

Maybe we should tweet to them to let them know this is happening?

Bizarre. They need to run Cachet and let us know about this kind of shenanigans!

lol

Will do from the Cachet account.

Done :)

Needs rebasing.

Rebased but not squashed yet. @GrahamCampbell please tell me that I didn't !@#$ it up this time?

@GrahamCampbell are you ok continuing work on this one? If not, what's left?

@GrahamCampbell Maybe this will help https://github.com/dinkbit/notifyme

@joecohens how do you want to do this? Close this PR and implement fresh with notifyme, or modify this one?

I think more than half of this branch is reusable. I'll take it form here :)

@cachethq/owners Closing this for now, I'm starting fresh.

:+1:

authors: Crash-- GrahamCampbell jbrooksuk joecohens

repo: cachethq/Cachet


text:
pruebafinal

kisto

confirmar

repo: cacoronel/github-slideshow


text:
Rationale of :443 in ":443, example.com"

The doc says

In the Caddyfile the addresses must start with :443 for the forward_proxy to work for proxy requests of all origins.

Could you help further clarify? I thought example.com alone should have both 80 and 443 covered. The magic :443, example.com looks a self contradiction to me.

It's not a contradiction. (But this is a good question.) A site block name in the Caddyfile serves three purposes (somewhat regrettably):

To tell the web server what port to listen on
To tell the web server what domain name(s) to manage certs for
To tell the web server how to route HTTP requests

In most cases, these are correlate and align identically as long as we assume the default port(s) of 80/443: you can tell the server you have example.com and it will listen on 443, get a cert for example.com, and serve HTTP requests with a Host header of example.com accordingly.
But when you're running a forward proxy, the Host header can contain basically anything, so you need to listen on :443 to not black-hole those HTTP requests (no. 3). But without a domain name it can't get a cert (no. 2), so you need to tell which certificate to serve in the TLS handshake. Hence, both :443, example.com.

authors: Lingxi-Li mholt

repo: caddyserver/forwardproxy


text:
Deploy vraptor-site

Taking a look at vraptor-site commit, if I'm not worng vraptor-site isn't deployed since October with "articles and presentations" page.
The download page still with 4.1.1 vraptor's version.
Since we had some improvements on documentation, what about deploy it ?

Done! (actually, I forgot that it's done manually!) Thanks

authors: Turini renanigt


text:
Explicitly pass CXX to NCCL Makefile

Necessary if CXX isn't set when cmake is called. The CXX variable will then be
empty which prevents make from using its own default.

cc Mr @slayton58 by the way - in case NV finds errors in other nccl clients.

@Yangqing Thanks! Good catch @pietern!

authors: Yangqing pietern slayton58


text:
Fix broken Publish-GitHub-Release Task

Both both the 0.12.0 and 0.13.0 release of Cake, we were met with an error similar to this:
https://ci.appveyor.com/project/cakebuild/cake/build/0.12.0.build.2049#L506
When trying to Publish the GitHub Release.  Initially, I thought this was an error with GitReleaseManager, but I have just ran the following test:

And as you can see here, the asset got added correctly:
https://github.com/gep13/FakeRepository/releases/tag/untagged-694b79655a063bd1e6f7
So, if we get this https://github.com/cake-build/cake/issues/923 working, we can try to figure out what is going on.  Looks like there is an issue in one of the parameters that are being passed in, but I can't replicate it on my test repository.

@gep13 Should be possible now when we can set the verbosity of the logger from the script.

In an update to this, it also failed for the 0.14.0 release:
https://ci.appveyor.com/project/cakebuild/cake/build/0.14.0.build.2320#L575
This time, with the aid of the additional logging, I have come to the conclusion that the problem is the password that is being passed into the command line.  I think it must contain a " or similar, that is breaking the input to GitReleaseManager.  Going to change this password for the next release, and assume that everything is going to work :smile:   Will re-open if required.

Tested this locally using an newly generated personal access token, and it seems to work :+1:

repo: cake-build/cake


text:
GH1625 Escape comma and semicolon in msbuild property values

Replace comma and semicolon in msbuild properties values by hex equivalent to fix issue #1625

@Julien-Mialon,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla2.dotnetfoundation.org.
It will cover your contributions to all .NET Foundation-managed open source projects.
Thanks,
.NET Foundation Pull Request Bot

@Julien-Mialon, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, .NET Foundation Pull Request Bot

@Julien-Mialon your changes have been merged, thanks for your contribution 👍

authors: Julien-Mialon devlead dnfclas


text:
🛑 xmr-node.cakewallet.com:18081 is down

In 111cb0f, xmr-node.cakewallet.com:18081 (xmr-node.cakewallet.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: xmr-node.cakewallet.com:18081 is back up in e95f794 after 52 minutes.

repo: cake-tech/upptime-cakewallet


text:
🛑 XMR USA Servers is down

In 0f8a7a1, XMR USA Servers ($XMR_USA) was down:

HTTP code: 0
Response time: 0 ms

Resolved: XMR USA Servers is back up in f92bfe0 after 277 days, 9 hours, 57 minutes.


text:
🛑 XMR USA Servers is down

In cbceb8e, XMR USA Servers ($XMR_USA) was down:

HTTP code: 0
Response time: 0 ms

Resolved: XMR USA Servers is back up in e78f1ae after 32 minutes.


text:
🛑 xmr-node.cakewallet.com:18081 is down

In c4a2349, xmr-node.cakewallet.com:18081 (xmr-node.cakewallet.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: xmr-node.cakewallet.com:18081 is back up in 9c6b061 after 6 minutes.


text:
🛑 node.moneroworld.com:18089 is down

In a25f6e6, node.moneroworld.com:18089 (node.moneroworld.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: node.moneroworld.com:18089 is back up in 4ad0e99.

repo: cake-tech/upptime-monerocom


text:
"Phinx\Console\Command\Init" cannot have an empty name (symfony/console >= 4.3.4)

PHP Fatal error:  Uncaught Symfony\Component\Console\Exception\LogicException: The command defined in "Phinx\Console\Command\Init" cannot have an empty name. in /var/www/localhost/htdocs/vendor/symfony/console/Command/Command.php:453
Stack trace:
#0 /var/www/localhost/htdocs/vendor/robmorgan/phinx/src/Phinx/Console/Command/Init.php(47): Symfony\Component\Console\Command\Command->getName()
#1 /var/www/localhost/htdocs/vendor/symfony/console/Command/Command.php(77): Phinx\Console\Command\Init->configure()
#2 /var/www/localhost/htdocs/vendor/robmorgan/phinx/src/Phinx/Console/PhinxApplication.php(60): Symfony\Component\Console\Command\Command->__construct()
#3 /var/www/localhost/htdocs/vendor/nartex/nx-phinx/bin/nx-phinx(12): Phinx\Console\PhinxApplication->__construct()
#4 {main}
  thrown in /var/www/localhost/htdocs/vendor/symfony/console/Command/Command.php on line 453

With composer json:
{
    "require": {
        "robmorgan/phinx": "~0.10"
    },
}

composer info | grep console
symfony/console                     v4.3.4              Symfony Console C...

When symfony/console is downgraded to v4.3.3:
{
    "require": {
        "robmorgan/phinx": "~0.10",
        "symfony/console": "=4.3.3"
    },
}

It works. I guess  symfony/console  v4.3.4 introduces a breaking change with phinx.

We released a fix today.

see: https://github.com/cakephp/phinx/pull/1596

authors: dereuromark tarnagas

repo: cakephp/phinx


text:
Cache names of created tables for exists check

Fixes #1569 where because running under dry-run meant that the table was never actually created subsequent checks for existence of the table would fail, and an extra invalid CREATE TABLE statement would end up getting inserted into the dry-run log.
I'm not 100% satisfied with how this looks, but unsure of how might improve things and reduce the amount of copy/paste of things. It'll also still fail in the case where someone would directly call execute() with a create/drop/rename query.

I think we can't fix all cases, but this sure looks already like an improvement for most standard cases :+1:

Yeah, unless you put in a full SQL parser, the real complex cases around direct execute will never be fully captured. This will also not capture case of doing say an insert and save, then select over the table, and then use that to create additional queries. That case (assuming using internal functions) could be captured by just caching the various inserts/updates, but that's probably a bridge to burn if people actually report it. Can also probably just put a note in the docs about dry-run not being able to fully generate all SQL for complex cases (e.g. using execute, or the above example) due to it not being hooked up to a real DB.

Thanks, this makes sense to me

Can also probably just put a note in the docs about dry-run not being able to fully generate all SQL for complex cases (e.g. using execute, or the above example) due to it not being hooked up to a real DB.

Good idea.

authors: MasterOdin dereuromark lorenzo raph1mm


text:
JWT Token Verification using RS256

I was having some problems getting token verification working if the token was signed using RS256 instead of HS256.
In RS256 you need to pass in the public key in PEM format.   My issues was that the PEM format is strict both in terms of encoding (base64) AND  line breaking.

Download your pem file it should like this

-----BEGIN CERTIFICATE-----
MIIC+DC...
...j+NjK0Bjo=
-----END CERTIFICATE-----

Your PEM file needs to have a line break after BEGIN CERTIFICATE---- and then a line break every 64 characters.   A quick way to do this on *nix/mac is this fold filename.pem > filename-wrapped.pem
Since its pretty hard to pass things with line breaks you should set an environment variable from it like this. (this folds it automatically, if its already wrapped it will do nothing export GRAPHQL_SECRET="$(cat filename.pem | fold -64)"`
Then start up your graphql server passing --secret=${GRAPHQL_SECRET}

You still need to figure out how to pass audience until this issue closes

@angelosarto Nice auto-close to give documentation for others who may struggle in future 👍

It’s really awesome to know RS256 works without any other modifications! Does signing work fine?

Thanks @natejenkins; I've modified the issue description with your fixes 👍

I was having some problems getting token verification working if the token was signed using RS256 instead of HS256.
In RS256 you need to pass in the public key in PEM format. My issues was that the PEM format is strict both in terms of encoding (base64) AND line breaking.

Download your pem file it should like this

-----BEGIN CERTIFICATE-----
MIIC+DC...
...j+NjK0Bjo=
-----END CERTIFICATE-----

Your PEM file needs to have a line break after BEGIN CERTIFICATE---- and then a line break every 64 characters.   A quick way to do this on *nix/mac is this fold filename.pem > filename-wrapped.pem
Since its pretty hard to pass things with line breaks you should set an environment variable from it like this. (this folds it automatically, if its already wrapped it will do nothing
export GRAPHQL_SECRET="$(cat filename.pem | fold -64)"
Then start up your graphql server passing --jwt-secret="${GRAPHQL_SECRET}"

You still need to figure out how to pass audience until this issue closes

Could you please explain how RS256 works in this case?
I'm using PostGraphile 4.6.0, has option set as:
createServer(     postgraphile(env.DATABASE_URL, "public", {       jwtSecret: "./publickey.pem",       jwtVerifyAlgorithms: ["RS256"],       jwtPgTypeIdentifier: "public.jwt_token",       graphiql: true,       enhanceGraphiql: true,       graphqlRoute: env.POSTGRAPHILE_ROUTE + "/graphql",       graphiqlRoute: env.POSTGRAPHILE_ROUTE + "/graphiql",     })   ).listen(port, () => {     console.log("Listening at port:" + port);   });
But when I sending the Authorization header in Postman with RS256 encrypted JWT token, always get 'errors: invalid algorithm'.
In fact, the JWT token I get back from this PostGraphile server is always HS256 encrypted.
Appears that RS256 doesn't take effect.
Could you show your working example of PostGraphile JWT verification with RS256?

It is treating the literal string you have passed it as the secret, as the secret. Same as it would if you passed it “MY_SECRET_HERE”. You need to read the file and send through the file contents.

authors: angelosarto benjie calebmer yleigh

repo: calebmer/postgraphql


text:
Did something break with netlify?

Hello,
This isn't an issue with your repo per say. I had a working website for the past many months (forked your code.. and modified it considerably for my own purposes).
But today, it looks really wierd on all my browsers:
http://rsangole.netlify.com
Did netlify break? Why has this happened suddenly?
Rahul

The https://bootswatch.com/solar/bootstrap.css gives a 404 error.

Thanks @Tafkas. They have a version 3 and version 4 now, which broke the link.

authors: Tafkas rsangole

repo: calintat/minimal


text:
[Table Pagination] export LabelDisplayedRowArgs interface and improve label props types

Export LabelDisplayedRowsArgs from TablePagination.d.ts.
Change labelDisplayedRows return type to JSX.Element | string so it is aligned with the implementation.
Change labelRowsPerPage  return type to JSX.Element | string.

Hi @oliviertassinari , do you have any idea on how to address the differences in Argos test ? I have no clue and the regression test run successful on my environment.

@t49tran thanks

repo: callemall/material-ui


text:
🛑 TAIF is down

In e537560, TAIF (https://taif.ru) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TAIF is back up in 2010ccf.

repo: callmeurpapa/uptime


text:
Feat: change press enter action

enterを押した時の挙動を以下の仕様に変更しました。
デフォルトのinsertBreak

行の先頭でenterを押した場合、行の上にデフォルトのElementを挿入する。
行の途中の場合、後ろのテキストを下に改行し、デフォルトのElementにする。
行の最後の場合、行の下にデフォルトのElementを挿入する。
テキストが空の場合、その行をデフォルトのElementで上書きする。

toggle/body

Elementを下にコピーする。

list , order , todo , toggle , callout

Elementを下にコピーする。
textが空の場合、Elementを削除して次の行の末尾に移動する。

ツールバー

enterを押してもツールバーを消さない。

動作テスト↓
https://www.notion.so/cyberagent-group/bento-8021ff081c644ed2b44e63b028390477

https://github.com/cam-inc/bento/pull/92/files#diff-1d9cd182bbb8fc009625fd0116ea08750087fd2d7cf35a701c5179de3361ec17R25-R28
endPathは型がPathなので、別途でoffsetを指定する必要があります。

https://github.com/cam-inc/bento/pull/92/files#diff-1d9cd182bbb8fc009625fd0116ea08750087fd2d7cf35a701c5179de3361ec17R25-R28

endPathは型がPathなので、別途でoffsetを指定する必要があります。
このコメントは該当のコードの部分にほしい～

repo: cam-inc/bento


text:
Damn!

This could be a powerful classroom tool for reading fluency - in fact, I found it on an educational website - but I would be very hesitant to use it in my third grade classroom when the word "damn" pops up every time they finish reading. Is there a way to get that changed?
Cathi Palmer

I agree, this should be changed.

@notolaf, this project is no longer maintained (thanks to legal threats from Spritz), so I don't think this will be changed.
If you're looking for something to use in class, jetzt works very well, although it's less polished.
Good luck.

authors: IBPX notolaf

repo: cameron/squirt


text:
プレミアムユーザーじゃないときにモーダルが表示される条件

プレミアムユーザーじゃないときにモーダルが表示される条件を変更する。
現在リロードすると何度も表示されるので、プレミアムが必要な操作のときだけにする

v3では、セッション作成時にだけ表示すれば良さそう

repo: camphor-/relaym-client


text:
New release

The Puppet Development Kit includes pinned gems and that includes facterdb 0.6.0. That is unfortunately a bit behind the times and leads to things like RHEL 6 and 7 not including the networking facts hash. It would be nice to see a newer version they could include in the next PDK release.

@rnelson0 I'm working on closing out some open issues and updating factsets to get ready for a release :)

repo: camptocamp/facterdb


text:
empty plain object cause "unsupported BodyInit type" error

fetch(url,{
    body : {},
    method : 'POST'
})

this code may cause  "unsupported BodyInit type" error because of  below code from  fetch-ie8 source
this._initBody = function(body, options) {
      this._bodyInit = body
      if (typeof body === 'string') {
        this._bodyText = body
      } else if (support.blob && Blob.prototype.isPrototypeOf(body)) {
        this._bodyBlob = body
        this._options = options
      } else if (support.formData && FormData.prototype.isPrototypeOf(body)) {
        this._bodyFormData = body
      } else if (!body) {
        this._bodyText = ''
      } else if (support.arrayBuffer && ArrayBuffer.prototype.isPrototypeOf(body)) {
        // Only support ArrayBuffers for POST method.
        // Receiving ArrayBuffers happens via Blobs, instead.
      } else {
        throw new Error('unsupported BodyInit type')
      }
    }

Fetch body does not support object. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Body

抱歉，我没有表述清楚我的意思，空对象是不被支持的，但你的库则会直接报错， 而不是被忽略
在 win10  chrome 58.0.3029.81 和 firefox 53 上
fetch('./',{method : 'POST',body:{}})

上述代码仍然会产生请求，只不过 body 部分被忽略了，fetch 请求仍然会正常进行。

authors: camsong mingzepeng


text:
Shortcuts override the search input in template selection modal

Describe the bug
If you open the template selector popup window the search input field has the focus, and if you press the button "p", everything works as expected. But if you press any button which is a shortcut, for example "n", or "a", it does not search but execute the command bound to that shortcut. The biggest problem is the backspace. Press p, and then backspace. It will remove the Task element, but won't close the Template selector popup window. If you select the template after this, it will throw an error saying : Cannot read properties of undefined (reading 'children')

Steps to reproduce

Open editor
Create a new Task
Click on template selection button
Press "p" to start filtering the templates
Press backspace to delete the letter "p"
It will remove the Task

OR

Open editor
Create a new Task
Click on template selection button
Press "n" to start filtering the templates
It won't filter the templates as expected but it will open the Create element context menu

Expected behavior
When the search input field has the focus, we should disable shortcuts.
Environment

OS:  Windows 11
Camunda Modeler Version: 5.9.0-nightly.20230227
Execution Platform: Camunda Platform
Installed plug-ins: none

Additional context
Related to SUPPORT-21053

I can reproduce the issue in 5.21.0 but cannot reproduce the backspace-related error anymore.

Closed via https://github.com/camunda/camunda-modeler/issues/4195.

authors: barmac markfarkas-camunda nikku

repo: camunda/camunda-modeler