Siad has exited unexpectedly (on Ubuntu Linux)

After more than 20 hours running for the first time, Sia GUI had synchronized only 42% and then threw the following error (log follows):
Loading...
(0/6) Loading siad...
(1/6) Loading gateway...
(2/6) Loading consensus...
(3/6) Loading transaction pool...
(4/6) Loading wallet...
(5/6) Loading host...
(6/6) Loading renter...
Finished loading in 0.310817624 seconds
Wallet: scanned to height 1638...
Done!
2017/05/24 23:31:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
...
2017/05/25 08:56:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/25 08:56:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
goroutine 1380556 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc424d02c80)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc424d02e78, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc42033a8a0, 0xc424d02e78, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc4215547f0, 0xc4202ca788, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:196 +0x236
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5
goroutine 1380555 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc426386d68)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc426386ec0, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc42033a8a0, 0xc426386ec0, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func1(0xc4215547f0, 0xc4202ca788)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:167 +0x227
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:184 +0x15d
Severe error: ERROR: unable to create write-ahead-log: open /home/rstephe/.config/Sia-UI/sia/host/contractmanager/contractmanager.wal_temp: too many open files
Severe error: Unable to open temporary settings file for writing: open /home/rstephe/.config/Sia-UI/sia/host/contractmanager/contractmanager.json_temp: too many open files
goroutine 1380556 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc424d02c80)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc424d02e58, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc42033a8a0, 0xc424d02e58, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc4215547f0, 0xc4202ca788, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:201 +0x357
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5
Severe error: Unable to properly initialize WAL file, crashing to prevent corruption: unable to write WAL metadata: invalid argument
goroutine 1380556 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc424d02aa0)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc424d02c18, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc42033a8a0, 0xc424d02c18, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).appendChange(0xc4202ca788, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlog.go:151 +0x46e
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc4215547f0, 0xc4202ca788, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:208 +0x423
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5
Severe error: Unable to write state change to WAL: invalid argument
2017/05/25 08:56:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/25 08:56:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
panic: unable to append a change to the WAL, crashing to prevent corruption
goroutine 1380556 [running]:
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).appendChange(0xc4202ca788, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlog.go:152 +0x4b8
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc4215547f0, 0xc4202ca788, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:208 +0x423
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5

Siad is opening too many files/keeping open too many file handles. I'm only subscribed to Sia's repo and don't know much about the process, but if it restarts at the place it left off, you should be able to finish it with a restart.

Make sure you are using Sia 1.2.2, which fixes this issue.

Thx for the comments.  I should have added the versions:
Sia-UI 1.6.4
Sia      1.2.2

Where does the version say 1.6.4? What does the version say in the About plugin?

Looks like the fix for this bug we pushed to before the release inadvertently didn't make it into v1.2.2; we've updated the releases, you should be able to download v1.2.2 again and this bug will be gone.

Thanks, Jonathan, I'm downlooading 1.22 and will try it again.

Rob

Thanks, Jonathan, I'm downlooading 1.22 and will try it again.

Rob

The new version of version 1.22 definitely works better, but the 'too many open files' error persists.  See log below:
Loading...
(0/6) Loading siad...
(1/6) Loading gateway...
(2/6) Loading consensus...
(3/6) Loading transaction pool...
(4/6) Loading wallet...
(5/6) Loading host...
(6/6) Loading renter...
Finished loading in 1.938366067 seconds
2017/05/28 07:57:43 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/05/28 07:57:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 160ms
2017/05/28 07:57:47 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 320ms
2017/05/28 07:57:47 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 640ms
2017/05/28 07:57:48 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:49 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:50 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:51 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:53 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:54 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:56 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:57 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:58 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:57:59 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:00 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:01 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:02 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:03 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:04 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:05 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:06 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:07 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:08 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:09 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:10 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:11 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:12 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:13 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:14 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 07:58:15 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:49 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:49 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:50 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:50 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 160ms
2017/05/28 13:23:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 320ms
2017/05/28 13:23:53 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 640ms
2017/05/28 13:23:53 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:54 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:56 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:57 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:58 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:23:59 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:00 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:01 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:02 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:03 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:04 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:05 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:06 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:07 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:08 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:09 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:10 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:11 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:12 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:13 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:14 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:15 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:16 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:18 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:19 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:20 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:21 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:22 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:23 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:24 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:27 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:28 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:29 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:30 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:31 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:32 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:33 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:35 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:36 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:37 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:38 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:39 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:40 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:41 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:42 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:43 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:44 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:45 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:47 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:48 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:49 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:50 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:51 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:53 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:54 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:56 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:57 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:58 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:24:59 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:25:00 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:25:01 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:25:02 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 13:25:03 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:31 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:33 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 160ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/05/28 15:21:34 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/05/28 15:21:35 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 160ms
2017/05/28 15:21:35 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 320ms
2017/05/28 15:21:35 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 640ms
2017/05/28 15:21:36 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:37 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:38 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:39 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:40 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:41 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:42 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:43 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:44 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:45 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:46 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:47 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:48 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:49 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:50 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:51 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:52 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:53 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:54 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:55 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:56 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:57 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:58 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:21:59 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:00 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:01 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:02 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:03 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:04 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:05 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:06 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:07 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:08 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:09 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:10 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:11 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:12 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:13 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:14 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:15 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:16 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/05/28 15:22:17 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
goroutine 1872404 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc425d5fc80)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc425d5fe78, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc4201fe940, 0xc425d5fe78, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc422a43af0, 0xc4200a8308, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:196 +0x236
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5
Severe error: ERROR: unable to create write-ahead-log: open /home/rstephe/.config/Sia-UI/sia/host/contractmanager/contractmanager.wal_temp: too many open files
goroutine 1872403 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc420afed68)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc420afeec0, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc4201fe940, 0xc420afeec0, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func1(0xc422a43af0, 0xc4200a8308)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:167 +0x227
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:184 +0x15d
Severe error: Unable to open temporary settings file for writing: open /home/rstephe/.config/Sia-UI/sia/host/contractmanager/contractmanager.json_temp: too many open files
goroutine 1872404 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc425d5fc80)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc425d5fe58, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc4201fe940, 0xc425d5fe58, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc422a43af0, 0xc4200a8308, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:201 +0x357
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5
Severe error: Unable to properly initialize WAL file, crashing to prevent corruption: unable to write WAL metadata: invalid argument
goroutine 1872404 [running]:
runtime/debug.Stack(0x445617, 0x0, 0xc425d5faa0)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Severe(0xc425d5fc18, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:32 +0x92
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc4201fe940, 0xc425d5fc18, 0x2, 0x2)
/home/jrh/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe0
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).appendChange(0xc4200a8308, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlog.go:151 +0x46e
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc422a43af0, 0xc4200a8308, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:208 +0x423
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5
Severe error: Unable to write state change to WAL: invalid argument
panic: unable to append a change to the WAL, crashing to prevent corruption
goroutine 1872404 [running]:
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).appendChange(0xc4200a8308, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlog.go:152 +0x4b8
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit.func2(0xc422a43af0, 0xc4200a8308, 0x0, 0x0, 0x0, 0xebc2b0, 0x0, 0x0)
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:208 +0x423
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit
/home/jrh/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:209 +0x1e5

BTW, @johnathanhowell, the GUI version is shown as 1.22 when I go to About in the GUI itself, but is listed as 1.6.4 in the version file in the Sia-UI directory

It took nearly 2 weeks and uncountable restarts of Sia-UI to completely synchronize.  This seems to be very slow for a fairly recent blockchain (when was its genesis block?
In any case, that did not stop the "too many open files" errors:

Siad has exited unexpectedly. Please submit a bug report including the error log here.
Block height  108102
Entire error log follows (it did not contain a traceback):
Loading...
(0/6) Loading siad...
(1/6) Loading gateway...
(2/6) Loading consensus...
(3/6) Loading transaction pool...
(4/6) Loading wallet...
(5/6) Loading host...
(6/6) Loading renter...
Finished loading in<PHONE_NUMBER>26 seconds
2017/06/06 17:14:22 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:25 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 5ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 10ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 20ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 40ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 80ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 160ms
2017/06/06 17:14:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 320ms
2017/06/06 17:14:27 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 640ms
2017/06/06 17:14:27 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s
... <600 similar lines deleted>
2017/06/06 17:24:26 http: Accept error: accept tcp <IP_ADDRESS>:9980: accept4: too many open files; retrying in 1s

what are your system specs like? Currently, Sia is heavily IO-bound and will perform far better on systems with SSDs

@johnathanhowell I installed  the Sia files in my home directory, so it is running on a 1 TB 5400 RPM SATA III Hybrid Hard Drive with 8 GB SSD.  If I installed it as root it could run on a SSD if you thank that would make a big difference.

duplicate of #1840


feat: Extract and store batch_condition during dataset submission

#1459

Reviewers
Functional:
@metakuni
@brianraymor
Readability:
@danieljhegeman
Changes

added migration script to add batch_condition column to dataset table in portal db, as ARRAY(String) data type
extract batch_condition during dataset ingestion, and push to dataset table alongside other uns metadata

QA steps (optional)

tested migration following documented steps, tests passed
updated local db test data to include batch_condition numpy array, and verified it was captured correctly in local db dataset table on init

Notes for Reviewer

Scanning our codebase, it looks like the validation logic for batch_condition (i.e. ensuring all entries are obs cell metadata fields, enforcing correct data type) is already handled in cellxgene schema validation, so I did not include that logic here. Please let me know if that is incorrect

Scanning our codebase, it looks like the validation logic for batch_condition (i.e. ensuring all entries are obs cell metadata fields, enforcing correct data type) is already handled in cellxgene schema validation, so I did not include that logic here. Please let me know if that is incorrect

All schema metadata is validated per the specification prior to ingestion in the portal. Any gaps would be addressed in cellxgene-schema CLI.
On another note, I'm curious to see if any submitters are setting this field.


Landing Page Update

I'm not going to treat this as a draft in case we want to get something else up right away, but there is additional work to be done here. In particular, linking to both AWS and GCP images. We have a link for the AWS marketplace: https://aws.amazon.com/marketplace/pp/prodview-xprkx44kyqgp6 but I can't find anything equivalent form google. This was the closest I found it doesn't seem especially helpful as a user facing document: https://console.cloud.google.com/compute/instanceTemplates/list?project=e4s-pro
This page should go into more detail on the support for AWS and GCP respectively but I want to check up on feature parity before I do that.

@wspear this looks good. Should we merge or is there more you want to add first?


SVG->PDF conversion fails when there is more than one image

What version of mystjs are you using?
0.1.17
How did you install myst?
npm
What operating system are you using?
Linux
Which area is this feature request for?
Command Line Interface, Export: LaTeX or PDF
Describe the Bug
When compiling a document with SVG images, myst build --tex will attempt to convert them to PDF with Inkscape. However, if there is more than one image, the call fails with
Converting 6 SVG images to PDF using inkscape
ConcreteInkscapeApplication<Gtk::Application>::on_open:
Can't use '--export-filename' with multiple input files (output file would be overwritten for each input file).
Please use '--export-type' instead and rename manually.

Expected Behavior
Presumably this line is actually making a single batch call, rather than looping over file names and calling Inkscape separately on each ?
To Reproduce
Inkscape version:

Inkscape 1.2.2 (b0a8486541, 2022-12-01)

How strange, thank you for the bug report -- could you confirm that a single image does actually works? (e.g. commenting out all but one figure and trying a build?)
I don't believe that the code batches the images with inkscape, and instead loops over calls in Javascript, but that message certainly suggests that it does. If a single image does not work, it could be the version of inkscape installed.
Maybe @fwkoch you have other ideas?

Curious: This happens when I build the sources for the paper I am currently porting to MySTJS, but it doesn't happen when I build an empty document with just the figures.
So there must be an interaction with another part of the build process.
The paper doesn't build yet, so it's a bit hard to debug directly on that – I will finish that first, then I'll see if I can pare it down to a MWE for this issue.

To answer the question: Yes, this also occurs when there is only one figure.
Converting 1 SVG image to PDF using inkscape
ConcreteInkscapeApplication<Gtk::Application>::on_open:
Can't use '--export-filename' with multiple input files (output file would be overwritten for each input file).
Please use '--export-type' instead and rename manually.

So the issue title is incorrect. Rather, it seems to occur when the figures are inside another environment, in this case images in the {tab-set} or {margin} directives are causing the issue.
I also have an SVG image in a {sidebar} directives which does not trigger the error.
(From this you may surmise that I am porting a document that was originally written for Jupyter Book)
I think it could be that the first two environments are not actually supported by mystjs, so that may be related ?
(On a tangential note, a list of incompatibilities between Jupyter Book and mystjs would be useful. I will try to keep track of those I notice.)
For the record though, it is actually difficult to trim down to a minimal example. Even just copying to a different folder, or working on a different machine (with an earlier Inkscape version) can make the error go away.
So given the challenge of reproducing this, and that it might be limited to using unsupported directives, I would propose to close the issue. If I can make a small breaking example I will reopen it.

Hi @alcrene, we are attempting to keep a list of the incompatibilities here: #189 if you notice things that are not on that list, please raise them!! We will get to them as fast as we can! 🚀


Suggested changes

Here's what I managed to implement today. It's not everything mentioned in my comment, but the major things are there, I think.
I tried to make the commits atomic. They aren't perfect, but it should be easier to review them individually than all at once.
In particular, I overhauled the rtc module. Take a look and see what you think. I was able to remove the Output1k and Output32k type parameters entirely from OscUlp32k and Xosc32k.

I'm adding my question from Matrix here.
Here's another broad question for both of you.
In the spi and uart modules, we tried to maintain a particular pattern when dealing with the Config and Spi/Uart structs. For a given setting, the Config struct has three methods:
.get_setting(&self)
.set_setting(&mut self, ...)
.setting(self, ...) -> Self
The versions taking self by value are the primary API, because they can be chained together and finalized with a call to .enable(). However, we included the .get_ and .set_ versions to allow the following pattern.
The Spi and Uart structs implement AsRef, so you can always get read access to those properties. This approach means we don't have to repeat those methods on both Config and Spi. Furthermore, the Spi and Uart structs have a .reconfigure(&mut self, F) method that takes a closure F: FnOnce(&mut Config). The .reconfigure function temporarily disables the peripheral, runs the closure, and re-enables it. Again, we're able to provide access to the methods on Config without repeating them on the Spi/Uart structs.
Note that some settings do break this pattern. In particular, any setting that changes a type parameter must take self by value, so it can't have a .set_ version or be used with .reconfigure.
I was wondering if we might want to establish a similar convention for the clock module, although I think it would have to be slightly different. Obviously functions taking self by value will still be the primary API. But we could also selectively implement .set_ versions as well. Then, we could implement Deref and DerefMut for Enabled<T, N>. Any functions with a .set_ method would be available, but any methods with a self-by-value-only API would not.
Do you think that would work? It would save us repeated definitions of functions on Enabled<T, N>.
Maybe there's a problem with that approach I'm not seeing?

Also, let me reference the main PR, for posterity. #450

I'm adding my question from Matrix here.
Here's another broad question for both of you.
In the spi and uart modules, we tried to maintain a particular pattern when dealing with the Config and Spi/Uart structs. For a given setting, the Config struct has three methods:

.get_setting(&self)
.set_setting(&mut self, ...)
.setting(self, ...) -> Self

The versions taking self by value are the primary API, because they can be chained together and finalized with a call to .enable(). However, we included the .get_ and .set_ versions to allow the following pattern.
The Spi and Uart structs implement AsRef<Config>, so you can always get read access to those properties. This approach means we don't have to repeat those methods on both Config and Spi. Furthermore, the Spi and Uart structs have a .reconfigure<F>(&mut self, F) method that takes a closure F: FnOnce(&mut Config). The .reconfigure function temporarily disables the peripheral, runs the closure, and re-enables it. Again, we're able to provide access to the methods on Config without repeating them on the Spi/Uart structs.
Note that some settings do break this pattern. In particular, any setting that changes a type parameter must take self by value, so it can't have a .set_ version or be used with .reconfigure.
I was wondering if we might want to establish a similar convention for the clock module, although I think it would have to be slightly different. Obviously functions taking self by value will still be the primary API. But we could also selectively implement .set_ versions as well. Then, we could implement Deref and DerefMut for Enabled<T, N>. Any functions with a .set_ method would be available, but any methods with a self-by-value-only API would not.
Do you think that would work? It would save us repeated definitions of functions on Enabled<T, N>.

Also copied from Matrix
First thought that pops up in my head is that clock abstractions, once Enabled, do not really have that many settings (as it would break their soundness) to benefit from Derefing into underlying type. Unless I missed your point, sorry

Yeah, you're probably right. It just feels to me like Enabled should implement Deref in some form, since it's such a thin wrapper. But then again, you could also argue that the entire purpose of Enabled is as a wrapper that removes access to the underlying functions.

Yeah, you're probably right. It just feels to me like Enabled should implement Deref in some form, since it's such a thin wrapper. But then again, you could also argue that the entire purpose of Enabled is as a wrapper that removes access to the underlying functions.

Implementing Deref on Enabled is probably harmless as, well, it won't allow mutating the underlying clock through immutable reference. DerefMut is definitely not acceptable. My point was that you don't really have that much to deref through it after all, as most of the existing API focuses on mutating the clock state.

Accidentally pushed to the wrong branch. Sorry. Trying to undo it now

Can you "unmerge" this? Is that possible? I already forced your branch back to its original position.

Ok, since we can't seem to recover, I'm going to re-merge this and create a new PR with commits since then. Does that work?


[rv_dm] Intg error on d_data is ignored by rv_dm

The tlul_adapter_host does not internally check intg error on d_data - it instead forwards it to an output port. It does check the intg error on other d_rsp fields.
In rv_dm, this port is unconnected, which means an intg error on d_data is completely ignored.
An easy fix would be to add a parameter to tlul_adapter_host which will be set to 0 by default. This parameter will enable intg error check on d_data and OR the error signal directly into err_o output. In rv_dm, this parameter will then be set to 1.

Fixed in https://github.com/lowRISC/opentitan/pull/13955/commits/bda512b9af50327a7c4b5a4a08b9752c1231d6bf.


StackOverflow in GenericHollowIterable

When I tried using Iterable returned from objects method in GenericHollowSet I got SOError. Returned GenericHollowIterable in next() operation calls its own method, not passed iterator's one. I was using Generic Object API.

Thanks very much for the report.  This fix is now released in v2.3.1.


Fix sw-datepicker uses timezones for date values

1. Why is this change necessary?
When picking a date using the sw-datepicker component, you might result in a stored date one day in the past (depending on your timezone).
2. What does this change do, exactly?
It ensures that the sw-datepicker does not pay attention to the user's timezone if only a date (without time) is selected.
3. Describe each step to reproduce the issue or behaviour.

set your admin user to the timezone "Europe/Berlin"
open an order
create an invoice
set the invoice date to a date of your choice
save the invoice

The invoice date will now be one day before your selected date.
4. Please link to the relevant issues (if any).

https://issues.shopware.com/issues/NEXT-21597
https://issues.shopware.com/issues/NEXT-19136

5. Checklist

[X] I have rebased my changes to remove merge conflicts
[X] I have written tests and verified that they fail without my change
[X] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

Hello @silviokennecke, thanks for your contribution!
However, we decided to not merge this PR as is, because there's a lot more to timezones than just setting a specific offset and we need to outline a proper spec about how these should work across the different platform components.

Hi @bschulzebaek, that's understandable. Are there any specific plans on fixing the stated issue in the near future? As I see it it's quite problematic if I create an invoice using the Shopware administration and the invoice is dated one day in the past (probably even before the order was placed). Of course this should be fixed properly, but I currently see no issues, this would cause if being merged. If it will probably take a longer timeframe to be addressed again, this would provide at least a fix for the time being.

We currently override the sw-datepicker component to fix this issue:
const { Component } = Shopware;

Component.override('sw-datepicker', {
    computed: {
        timezoneFormattedValue: {
            get() {
                if (!this.value) {
                    return null;
                }

                if (this.dateType !== 'date') {
                    return this.$super('timezoneFormattedValue.get');
                }

                // Get the iso string for the date
                return new Date(this.value).toISOString();
            },
            set(newValue) {
                if (newValue === null) {
                    this.$emit('input', null);
                    return;
                }

                if (this.dateType !== 'date') {
                    this.$super('timezoneFormattedValue.set', newValue);
                    return;
                }

                // emit the date formatted as YYYY-mm-dd.
                this.$emit('input', newValue.substring(0, 10));
            },
        },
    },
});

Should be fixed in Shopware core though

this has still not been fixed for over a year and we regularly receive complaints from our plugin customers. this also affects many other places in the shopware core. please fix this problem now in shopware 6.5.


Functionality

[x] Rename track to order
[x] Create order
[x] Find nearest vehicle
[x] Calc price
[x] Add test time moving
[ ] Calc all routes by get endpoint

Rename track to order
Create order

#16 Add test time moving


Query returns null Metadata

When I Query scored vectors by a new, previously unseen vector, it returns a ScroredVector[] but all of the Metadata fields are null.

Thanks a bunch for creating this .NET wrapper though! Life saver for me here :)

My bad, found my mistake :)


Adjusted whois.registry.net.za to co-whois.registry.net.za ...

... for co.za lookups

I see that both servers whois.registry.net.za and co-whois.registry.net.za work for the co.za zone. Could you instead of replacing whois.registry.net.za just add co-whois.registry.net.za as further whois server.
Also when adding a server manually, please set the source to XML. Otherwise it would get lost during next automatic generation. I'll add a contribution note, so that this will be clear.
Thank you.

Thanks for the feedback.
The major issue is that whois.registry.net.za does not respond to port 43 requests.
I'll adjust the source and resubmit

On 27 Jul 2016, at 08:55, Markus Malkusch<EMAIL_ADDRESS>wrote:
I see that both servers whois.registry.net.za and co-whois.registry.net.za work for the co.za zone. Could you instead of replacing whois.registry.net.za just add co-whois.registry.net.za as further whois server.
Also when adding a server manually, please set the source to XML. Otherwise it would get lost during next automatic generation. I'll add a contribution note, so that this will be clear.
Thank you.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The major issue is that whois.registry.net.za does not respond to port 43 requests.

It does for me:
$ echo "google.co.za" | nc whois.registry.net.za 43
Domain Name:
    google.co.za…

So I'll keep the old one. Thank you for your addition. Would you mind squash the commits to one, then I would accept the PR.


Ferrum::Network::Exchange doesn't support #url

I have a test helper function that calls
page.driver.network_traffic.select { |request| request.url =~ /foo/ }
This code used to work but is broken with Cuprite 0.8 and the advent of Ferrum::Network::Exchange.   Is this an intentional change of the API?
Thank you for your help!

Hey Noach, sorry for inconvenience but this is an intended change, it was done in order to combine all 3 entities (request, response, error) into one object to simplify work with it. As it's still pre 1.0 there can be backwards incompatible API changes. You can rewrite it as page.driver.network_traffic.select { |e| e.request.url =~ /foo/ }

Feel free to give feedback about API


'13' as invalid search string

Mist does fail to download a valid installer if only the main OS version is give. I'm not sure if this is intentional or not. However, it used to work and it currently breaks other tools (like erase-install) which expect this to work.
Version
% mist --version
1.11 (Latest: 1.11)

Command
sudo mist download installer 13 application --application-name "Install %NAME%.app" --output-directory /Applications --no-ansi

Expected
mist does download the latest version of macOS 13. (13.3.1 in this case)
Actual
mist does fail with No macOS Installer found with '13', exiting
% sudo mist download installer 13 application --application-name "Install %NAME%.app" --output-directory /Applications --no-ansi
Password:
┌──────────────────┐
│ INPUT VALIDATION │
└──────────────────┘
  ├─ User is 'root'...
  ├─ Download search string will be '13'...
  ├─ Include betas in search results will be 'false'...
  ├─ Only include compatible installers will be 'false'...
  ├─ Cache downloads will be 'false'...
  ├─ Output directory will be '/Applications'...
  ├─ Temporary directory will be '/private/tmp/com.ninxsoft.mist'...
  ├─ Force flag has not been set, existing files will not be overwritten...
  ├─ Application name will be 'Install %NAME%.app'...
┌────────┐
│ SEARCH │
└────────┘
  ├─ Searching for macOS download '13'...
  └─ No macOS Installer found with '13', exiting...

@aschwanb Nice catch - looks like this bug was introduced when we attempted to filter on exact matches only: #122
Investigating a way forward that strike a happy balance between exact / fuzzy matching, stay tuned 👍

In the interim, can you move forward with the following?
sudo mist download installer ventura application --application-name "Install %NAME%.app" --output-directory /Applications --no-ansi

I don't think that macOS 13 is ever a specific version - it's 13.0. So the logic could probably see if there's any dot in the search string and if so, treat it as an exact search, whereas if not, go for the latest available.

In the interim, can you move forward with the following?
sudo mist download installer ventura application --application-name "Install %NAME%.app" --output-directory /Applications --no-ansi

For the record: This works as intended:
Found [032-66588] macOS Ventura 13.3.1 (22E261) [2023-04-17]

@aschwanb + @grahampugh looks like the fix was more trivial than expected: #132

mist download firmware "Ventura" will download the latest (eg. macOS Ventura 13.4 22F66)
mist download firmware "13" will download the latest (eg. macOS Ventura 13.4 22F66)
mist download firmware "13.3.1" will download a specific version (eg. macOS Ventura 13.3.1 22E261)
mist download firmware "13.0" will download a specific version (eg. macOS Ventura 13.0 22A380)


Login/ Signup UI fix

The Websites Sign Up and Login UI Should be improved
also for phones, the menu should automatcally close when user enters the fields
I can make a better interface for login/signup

in this photo you can the gap which is not needed
I can improve the login/signup page effectively

Hey @wpsadi, you can fix the ui! Join us on Discord for any help with setting up locally.


Typo in WFC tutorial

Thank you for your well-written tutorial!

Typo in the waveform collapse tutorial: pub fn patterns_to_constaints should be pub fn patterns_to_constraints.

Just my curious, but why do you refer to it as "waveform collapse", not "wave function collapse"?

Also, this code in the function (patterns_to_constaints)

                    let opposite;
                    match direction {
                        0 => opposite = 1, // Our North, Their South
                        1 => opposite = 0, // Our South, Their North
                        2 => opposite = 3, // Our West, Their East
                        _ => opposite = 2 // Our East, Their West
                    }

may be written as
                    let opposite = match direction {
                        0 => 1, // Our North, Their South
                        1 => 0, // Our South, Their North
                        2 => 3, // Our West, Their East
                        _ => 2, // Our East, Their West
                    };

You're right, it really should be "wave function collapse" rather than "waveform collapse". I saw it as the former once and the name stuck, unfortunately I've repeated the error EVERYWHERE so it may take some time to fix!


Add samples for node.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.00%. Comparing base (7637723) to head (9fb87fd).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #366   +/-   ##
=======================================
  Coverage   92.00%   92.00%
=======================================
  Files          53       53
  Lines        3792     3792
  Branches      352      352
=======================================
  Hits         3489     3489
  Misses        302      302
  Partials        1        1

Flag
Coverage Δ

unittests
92.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Active activity verification

There is a way to verify if already have an active activity?
EZLoadingActivity: You still have an active activity, please stop that before creating a new one

When you say show, it returns false

Ok, but I want avoid the warning in console.

You might write a function that checks the instance, if its nil return false

@Morbix did you find a way to do this?

I didn't try @lfarah


StorageDevice.FromId(id) gives 'Access Denied Exception' in a OOP DeviceWatcher task in WinUI - Desktop

Describe the bug
I am porting a UWP/DesktopBridge app to WinUI - Desktop. The app registers a DeviceWatcher task to detect inserts and ejects of USB storage devices.
In the UWP app the task is an in-process task; in the WinUI app it is (must be) a OOP task.
The task runs well but there is a Access denied exception when the task is informed about a USB device being inserted and then calls StorageDevice.FromId(id). The call is there in order to get a StorageFolder and from there to extract the Volume Label and Drive Letter of the MSC device.
The app is SyncFolder, which is a folder sync/copy tool for users, and the Volume Label and Drive Letter information is needed in order to find out whether the app must inform the user that a possible candidate storage device is being inserted for a given sync/backup task. This would be necessary when the user is using a set of rotating backup disks. Volume Label (and to a lesser extend Drive Letter) would then be the common name for all disks in the set.
The exception happens in the call to Windows.Devices.Portable.StorageDevice.FromId(). The code is actually quite simple:
async Task<List<StorageDeviceExt.StorageDeviceInfo>> GetAvailableMSCStorageDevicesAsync()
        {
            var devices = new List<StorageDeviceExt.StorageDeviceInfo>();
            var portableStorageDevices = await Windows.Devices.Enumeration.DeviceInformation.FindAllAsync(Windows.Devices.Enumeration.DeviceClass.PortableStorageDevice);
            ConditionalFileLogger.Log($"PortableStorageDevicesMonitor - GetAvailableStorageDevicesAsync: found {portableStorageDevices.Count} portable devices");
            foreach (var d in portableStorageDevices)
            {
                int step = 0;
                try
                {
                    step = 1;
                    var props = d.Properties;
                    ConditionalFileLogger.Log($"PortableStorageDevicesMonitor - GetAvailableStorageDevicesAsync: get storage folder of {d.Name}, {d.Id}");
                    step = 2;
                    var storageFolder = Windows.Devices.Portable.StorageDevice.FromId(d.Id);
                    if (storageFolder != null &&
                        !String.IsNullOrEmpty(storageFolder.Path))
                    {
                        step = 3;
                        ConditionalFileLogger.Log($"PortableStorageDevicesMonitor - RefreshPortableStorageDevicesAsync: add {{d.Name}} ({storageFolder.Path}) to list");
                        string driveLetter;
                        string volumeLabel = StorageDeviceExt.GetVolumeLabelAndDriveLetter(storageFolder.DisplayName, out driveLetter);
                        devices.Add(new StorageDeviceExt.StorageDeviceInfo()
                        {
                            DeviceId = d.Id,
                            DriveType = System.IO.DriveType.Removable,
                            VolumeLabel = volumeLabel,
                            DriveLetter = driveLetter
                        });
                    }
                }
                catch (Exception e)
                {
                    ConditionalFileLogger.Log($"StorageDeviceHelper - RefreshPortableStorageDevicesAsync exception 1, step {step} for {d.Name}: {e.Message}");
                    Analytics.TrackEvent("PortableStorageDevicesMonitor-Exception", new Dictionary<string, string>
                    {
                        { "Exception", $"GetAvailableStorageDevicesAsync: {e.Message}" }
                    });
                }
            }
            ConditionalFileLogger.Log($"PortableStorageDevicesMonitor - GetAvailableStorageDevicesAsync: found {devices.Count} portable MSC storage devices");
            return devices;
        }

ConditionalFileLogger is my own implementation of a log service that outputs log events to a file.
Analytics.TrackEvent(..) is a call to ms appcenter to register the exception in appcenter.
The exception is: Access denied. (0x80070005 (E_ACCESSDENIED)) and is generated for every USB device for which the FromId() call is made.
The same call to the above GetAvailableMSCStorageDevicesAsync() method runs fine when invoked from within the WinUI app itself (i.e. not from the OOP WinRT process).
So, it seems that the app itself is granted all the rights to get a StorageFolder for a portable device but not the OOP DeviceWatcher task.
Is this intended behavior?
That would be strange/wrong because the same code in the UWP in-process DeviceWatcher runs without issues.
Steps to reproduce the bug
Create a OOP DeviceWatcher task in a WinUI 3 Desktop app (packaged, using wap project).
Register the task.
Call Windows.Devices.Portable.StorageDevice.FromId()
Expected behavior
No response
Screenshots
No response
NuGet package version
1.0.0
Packaging type
Packaged (MSIX)
Windows version
Windows 11 version 21H2 (22000)
IDE
Visual Studio 2022
Additional context
No response

Ok, so you're basically doing what https://github.com/microsoft/Windows-universal-samples/tree/main/Samples/DeviceEnumerationAndPairing/cs does, but in a WinUI3 app instead of a UWP?

@jonwis Yes, except that in my implementation I am also creating a list of all mounted USB devices with their ID, Volume Label and Drive Letter.
In the mean time I also found out that the issue is not related to the task being a DeviceWatcher. I called the above method in a Timer background task and, as I expected, the Access Denied exception occurs also there.
It looks like the problem is related to the fact that the call is done in a OOP background task which in WinUI3-Desktop must be build using a Windows Runtime Component.
I am aware that there are restrictions with a normal WinRT component but I don't understand why such restrictions must still exist when the component is integrated in a WinUI3-Desktop app/package.

Ok, thanks. @aeloros we should probably talk more about that "bounce a bg task invocation back to the main app process" - maybe what's happening here is the BG tasks are getting launched as AppContainers, which don't have access?

Yeah, in the InProc case the task is run in the same process as the UI.  It therefore gets the same sort of access as a foreground application.  In the OOP case, the task runs inside BackgroundTaskHost.exe which is never foreground.  I'm not sure if the 'foreground' nature is what is blocking here, but clearly the UI app has a different set of policies applied.
My guess is if you changed the UWP scenario to be OOP as well, it would fail.  I actually think this is expected and probably by design, but since we have new scenarios to support it could be improved for sure. :)

@aeloros I appreciate the quick answer.
I assume that in this case there are only a couple of options available to solve this:

Allow also in-process background tasks in a WinUI3-Desktop app. That is currently not possible.
Allow OOP background tasks to have the same set of policies as the 'main' app.
Launch the 'main' app (or another full trust process) from within the OOP task, but without a visible window, and hand-over anything to the main app what cannot be done within the OOP task.

I am afraid that I will have to use option 3: that is not a price winner in software design if the only thing to do is to send a toast notification.

Maybe look into using protocol launch for your design of #4.  There is a lot of room for improvement on our end here. :|


Lazy eval Rows and use Rows instead of Datum slices.

Signed-off-by: qupeng<EMAIL_ADDRESS>What have you changed? (mandatory)
Lazy eval Rows for any cases.
What are the type of the changes? (mandatory)
Improvement.
How has this PR been tested? (mandatory)
Work in progress. Not all tests are fixed now.
Does this PR affect documentation (docs/docs-cn) update? (mandatory)
No.
Does this PR affect tidb-ansible update? (mandatory)
No.

@hicqu There are many conflicts. :(
Please resolve them and request a review from me. :)


Removed capacity_credit node attribute and related dataset attributes

Part of https://github.com/quintel/etsource/issues/896.

:+1:


Using birdseye in interactive session

I want to be able to decorate functions in an interactive session.
When I try to evaluate such function, it will throw the exception:
FileNotFoundError: [Errno 2] No such file or directory: '<ipython-input-7-01fc7a9cd10c>'

Initially I thought: go for an easy/hacky fix whenever the filename starts with "<", then replace it with something like "interactive-session".
But I see you depend on it for the source code from filename. You could try inspect.getsource(obj) instead.

Done! Upgrade and give it a go.

It works! Great job :)


To Implement a badge preview on the top of the screen

Motive : Implement a badge preview on the top of the screen
Changes: [

Created a Custom Layout (PreviewBadge.kt) for getting the complete visual of an Actual LED
Added seperate data classes(Cell.kt, CheckList.kt) for better management
Changes to MessageActivity to incorporate Support for Badge
Vector Drawable's for LED
Added Function in Presenter(MessagePresenter.kt) to take care of the hex conversions
Changes to Message Activity XML
]

Screenshots for the change:

👍

@iamareebjamal Please Take a look, If any changes need to be done inform me :)

#84 is open for this issue

@iamareebajmal what so you suggest me to do? I did talk with Ark, he told me to go ahead and request the PR

@iamareebjamal what do you suggest me to do then? I had a talk with Ark, He was good about me requesting a PR.

@iamareebjamal do you want me to work on a different feature till then?

Yes

@iamareebjamal Sir, I have completed the bitmap Display Feature also. But unfortunately it wont work until this base is pushed.

@iamareebjamal So as a new feature, I shall get the saving, import and export on the new branch working by tomm evening :)

I have closed my PR #84 . Please proceed with this one  :)

@adityastic mention the issue (like  #14 ) against which you've opened this PR in your motive and also Squash your commits to make it cleaner . Happy Coding :)

@adityastic mention the issue (like #14 ) against which you've opened this PR in your motive and also Squash your commits to make it cleaner . Happy Coding :)

Alright Sir, On it.

Squashed and Merged

I am removing this PR and issuing another PR with Squashed Commits


Handle json response better

Fixes for https://github.com/openshift-eng/art-bot/pull/67

PR for API server: https://github.com/openshift-eng/art-dashboard-server/pull/48

/lgtm


Release v0.13.0

Release summary
Version number: v0.13.0
Release details
Autonomy:

Replaces open-aea-web3 with web3py<7,>=6.0.0
Bumps protobuf<5.0.0,>=4.21.6
Fixes protobuf incompatibility issue when importing hardware wallet plugin
Refactors autonomy and agent images to

Include install and build scripts in the base image
Remove unwanted layers
Remove unwanted data files

Packages:

Generates protocols using the latest compatible protobuf compiler
Compiles the tendermint connection protocol buffers using the latest compatible protobuf compiler

Chores:

Bumps protobuf compiler to 24.3

Checklist
Put an x in the boxes that apply.

[ ] I have read the CONTRIBUTING doc
[ ] I am making a pull request against the main branch (left side), from develop
[ ] I've updated the dependencies versions to the latest, wherever is possible.
[ ] Lint and unit tests pass locally (please run tests also manually, not only with tox)
[ ] I built the documentation and updated it with the latest changes
[ ] I've added an item in HISTORY.md for this release
[ ] I bumped the version number in the __init__.py file.
[ ] I published the latest version on TestPyPI and checked that the following command work:
pip install project-name==<version-number> --index-url https://test.pypi.org/simple --force --no-cache-dir --no-deps
[ ] After merging the PR, I'll publish the build also on PyPI. Then, I'll make sure the following
command will work:
pip install project-name-template==<version_number> --force --no-cache-dir --no-deps
[ ] After merging the PR, I'll tag the repo with v${VERSION_NUMVER} (e.g. v0.1.2)

Please include the --reuse-multisig flag in the corresponding documentation.


Drop spdlog

The flockfile issue was not related to spdlog and was solved by switching back to the pipe(2) approach.


Add support for the approle authentication backend

The approle authentication seems like the best solution for in a puppetized env: https://www.vaultproject.io/docs/auth/approle.html.
I prefer to store the secret_id on the host in a file and not in hiera, since this would be the same as storing the token directly.

Is there a particular reason you prefer a file containing a secret id to an environment variable? So far the config has been either hiera.yml or environment variable driven.

I just didn't think about using an env variable. When/here would this be set?
My originally reason for storing it in a secret file was to prevent it stored in a central place (i.e hiera).

Setting the environment variable is out of scope, e.g. you can set VAULT_TOKEN as per the vault convention. Similarly you should be able to set the VAULT_APPROLE_{ID,SECRET} or whatever env vars.
I'm just very conscious of the number of configuration options growing out of control. So when you introduce a new option as well as another option to control that option I'm a bit hesitant.

I understand, what I meant was not where to set the env variable in this module, but when using puppetmaster which will call hiera, where do you then have to configure the env var.

One way, when using puppetmaster-passenger with Apache2, is to use /etc/apache2/envvars and put something like:
if [ -s /some/path/vault_token ]; then
  export VAULT_TOKEN=`cat /some/path/vault_token`
fi

in that file.
And have some mechanism/procedure in place to create/update the /some/path/vault_token file with the proper permissions and ownership.

Thanks @abooitt, that was the example I was looking for :smiley:
@jsok do you believe it's a good idea to create just one configuration option to enable approle auth en then use the VAULT_APPROLE_{ID,SECRET} env and don't use reading from file? Then I'll adapt this PR to it.

I moved to puppet 5 and I'm now using https://github.com/petems/hiera-vault. This PR isn't needed anymore for me.


Multiple panels problem on a single page

So I'm building a single page that has multiple panels, one after another as the user scrolls down. Inside the panels there are content such as list, dropdown menus and buttons.
The issue is, on my 5th panel down the page, the panel loses its margin on both left and right and stretches across the full width of the browser. This is the case as I keep adding more panels from 5th onwards but have absolutely no problem from panels 1 to 4.
I thought it might be an error with the content inside the panels but I've copied the exact code from the first panel and placed it as the 5th and the problem is there, so I don't believe it is related to my code.
If I just create multiple panels on the page with no content inside the panels, there is no issue. The issue seems to effect when there are multiple panels on one page with content inside the panels.

We cannot help unless you post a JS Bin that demonstrates the problem.
Also, on which browser(s) and OS(es) does the problem occur?

Closing until we hear more.


Does @loadable works with React Hooks?

It's just that simple question really, does @loadable/components works with React Hooks? Is there any example available in the repo that uses hooks?
Thanks!

Q: Could you use hooks inside loadable components?
A: Sure you can
Q: Is there any hook API to load "something" using hooks?
A: No there isn't any.
Q: What is your use case @marcialca?
A: ...

Thanks for the answer @theKashey! That's great news, is there any example on the code base for hooks?
My use case is basically that I need to wrap @loadable/components inside an Express-like app (it uses Kraken.js ) and I keep getting errors when trying to use hooks, it's the same type of error of this issue: https://github.com/smooth-code/loadable-components/issues/327
but I already verified for async/defer stuff, double script tags, etc and I'm not using any other library besides react and loadable, so I wanted to know if there was something that I was missing

This problem could be caused by only two reasons:

two bundles with two reacts
two reacts in one bundle

Which is one problem, just made more severe by code splitting. Try to use Webpack alias to pin single version of React.

Thanks for the answer, I think in our case, We might be having two reacts in two bundles, since the "renderer" code for React on the Kraken (server) side is being bundled and then loaded by React itself, and could be creating the first issue you mention. Anyway is good to know that there's no limitation from loadable and that the causes are limited.
I'll keep digging on our codebase. For the mean time, I think we are good to close the issue.
Thanks again for the answers.


Comparative benchmarks for hGetSome(at) and their replacement functions

A first step towards #50. These micro-benchmarks should allow us to determine whether we can replace the HasFS get-primitives by the HasBufFS primitives, without losing functionality or performance.

One thing I am unsure about is whether we can replace the HasFS put-primitives by the HasBufFS primitives easily. Some background first :
Defining hGetSome in terms of hGetBufSome requires conversion from a MutableByteArray to a ByteString, which is possible using unsafeByteArrayToByteString or copyByteArrayToByteString. The former function is a little bit hacky, but it ensures we don't copy bytes from the MutableByteArray to the ByteString, which is what the latter function would do.
Defining hPutSome in terms of hPutBufSome requires conversion from a ByteString to a MutableByteArray. This will not always be possible without copying, because a ByteString is a ForeignPtr under the hood which is a Ptr with (optionally) a reference to its underlying MutableByteArray. If the reference isn't there, then we can do nothing but copy the bytes to a fresh MutableByteArray.
The question is: do we want to keep both the "old" and the "new" primitives, if we can't ensure that the new primitives are as performant as the old ones?


False positive on 5.4.2 Ensure the GKE Metadata Server is Enabled

Hi Team,
We're seeing false-positives reported for "5.4.2 Ensure the GKE Metadata Server is Enabled" control. More specifically, we have a project with one and only cluster, on which Workload Metadata is enabled. When I query this cluster using
gcloud beta container clusters describe <cluster> --region <region> --project <project> --format json \
  | jq '.nodePools[].config.workloadMetadataConfig'

it returns
{
  "mode": "GKE_METADATA",
  "nodeMetadata": "GKE_METADATA_SERVER"
}
{
  "mode": "GKE_METADATA",
  "nodeMetadata": "GKE_METADATA_SERVER"
}
{
  "mode": "GKE_METADATA",
  "nodeMetadata": "GKE_METADATA_SERVER"
}

for the 3 node pools that we have on it.
However, when running the latest Git version of GKE CIS for this project, it reports
Cluster <region>/<cluster>, Node Pool: batch config.workload_meta_config.mode is expected to be in "GCE_METADATA" and "GKE_METADATA"

for each of these pools.
Thanks

Any update on this one?


Support prepared statements

There does not seem to be a way to prepare a statement/query other than globally via connection string. It would be nice to be able to do this explicitly for particular queries.
Correct me if I'm wrong, but it appears to me that the implementation could be as simple as adding
member __.Prepare () = cmd.Prepare ()

around here: https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/50b4f01bdfeb58bfd759d16f102ca3bd78bb4ab7/src/Runtime/ISqlCommand.fs#L107

No, that doesn't work, because here the connection is only opened inside the execute methods. How about __.(Async)ExecutePrepared parameters then?

Thanks for the contribution!
Do you think this is a good idea to implement prepared statements by introducting 2 additional methods for ISqlCommand?
Npgsql library supports automatic command preparation by checking frequency of usage for particular command. If certain treshhold is reached, - further commands will be prepared. This was a workaround for consumers of Npgsql, who use it via EF/Dapper etc, and are not able to call Prepare explicitly.
I think, it would be better to implement it using static bool parameter 'Prepare' in NpgsqlConnectionProvider and NpgsqlCommandProvider.
This will allow to support global configuration as well as optional opt in/out for particular commands.

I'm aware of that as I've stated in the very first sentence above :))). Explicit preparation is handy if you need more fine-grained control and the officials docs actually recommend using it over the automatic method.
As far as going with the Prepare=true route, that's certainly an option too.

Totally agree on the utility of making it explicit.  I like the global and local override combo with the static parameters.  I imagine you mostly want it off and then on for specific cases but might be applications where people are happy to have slower startup and all sql prepared (E.g. long running server)
Von meinem iPhone gesendet

Am 07.04.2019 um 04:52 schrieb kerams<EMAIL_ADDRESS>I'm aware of that as I've stated in the very first sentence above :))). Explicit preparation is handy if you need more fine-grained control and the officials docs actually recommend using it over the automatic method.
As far as going with the Prepare=true route, that's certainly an option too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@kerams, do you want to implement a version with DbCommand/DbConnection parametrization, or should I do that? :)

Sure, I can change the existing PR

One little problem I see is the fact that in NpgsqlConnectionProvider the parameter will have to be an Option<bool> in order to be able to do overrides on the CreateCommand level.

I think what you are looking for is:

NpgsqlConnectionProvider

NpgsqlCommandProvider should be extended in ~ same way

SqlCommand overrides should take prepare as parameter supplied from NpgsqlConnectionProvider/NpgsqlCommandProvider expression

Please correct me, if I'm wrong.

Changes above is rough proof of concept, - implementation will definitely require more changes than code above, - but I hope you got the idea :)

I've got all that. My point is the fact that Prepare needs to be of type Option<bool> on CreateCommand because with just bool I don't know if the user is overriding with false or if it's the default value.

Now I see that it actually does not work either, because None is not a literal.

Doesit matter whether Prepare is false by default or overridden to false on DbCommand level?
Maybe we can get away with setting default value of Prepare for CreateCommand to one supplied from addCreateCommandMethod?

Sure it does. If Prepare = true in NpgsqlConnection and you don't know if the false in CreateCommand is the default or user-provided value, you can't decide whether to prepare the statement or not.

Why would CreateCommand take false as default? It can take whatever was a default from DbConnection config. Sorry, it looks like I do miss the point :(

Aaaaaaaaaa! That will work beautifully. My bad :)
By the way, shouldn't the parameter be last? It could be a breaking change otherwise.

We are using named parameters upon DbCommand/DbConnection setup within solution:
type Db = NpgsqlConnection<Connection="FooDb",ConfigType=ConfigType.UserStore,Config="d1e8157c",XCtor=true>
In this case, order shouldn't matter. I'm not sure whether it is possible to parametrize NpgsqlConnection/NpgsqlCommand without specifying names, but if yes - sure, it makes more sense to have it a last parameter.

Merged.


Tests are failing using "old" template configuration...

When updating the repository in a new computer, tests fail this way:
===> Testing: Documentable:ver<1.2.4>:auth<github:perl6>:api<1>
    # Failed test 'Includes Raku'
    # at t/400-header-footer.t line 53
    # expected a match with: /Raku/
    #                   got: "
\n\n
\n
\n      This is a work in progress to document Perl 6, and known to be\n      incomplete.\n
\n      Please report any issuesEDITURL\n      Your contribution is appreciated.\n
\n
\n      This documentation is provided under the terms of the\n      Artistic License 2.0.\n      The Camelia image is copyright © 2009 by Larry Wall.\n      \n      \n\n
\n\n\n\n\n"
    # You failed 1 test of 4
# Failed test 'URL substitution in footer'
# at t/400-header-footer.t line 47
# You failed 1 test of 6
===> Testing [FAIL]: Documentable:ver<1.2.4>:auth<github:perl6>:api<1>
Aborting due to test failure: Documentable:ver<1.2.4>:auth<github:perl6>:api<1> (use --force-test to override)

That is no longer in the repository, however. git grep returns:
resources/template/footer.html:
This is a work in progress to document Raku (formerly known as Perl 6),

So we need to clean the cache before running the tests, or at least that part of it.

There was an "old" and undetected template directory in the repository; this was not under git control, so it was failing.


Pdf chake file

https://github.com/alexyaang/TestSolution/commit/1e59c35b4623e41986053ee61ee1bcb8a73bb10d

Closing as not actionable.


Build: Remove sonar.yml workflow

This PR removes the sonar.yml workflow to switch to automatic analysis. Once this is merged, we can enable automatic analysis. From that point forward, all new PRs and the latest 5 PRs will be analyzed automatically.

Thanks @xC0dex
Is there a PR to remove the template-sonar.yml in WorkFlows

@mikes-gh I'll create a PR soon!


This is a Terrible Example

You don't tell people how the dynamic objects or made or anything about the PowerApps Power automate trigger control. It took me hours to figure it out where eventually after editing it in flow that I realized what I could do with it and am still learning no thanks to you nor from a lack of looking at attempting to learn. When showing this example you should tell people that you cannot manipulate the Power Apps control's user inputs and that this is an item you can update and replace. Also for me, when I follow these instructions, I go into a permanent wait state, 3 minutes of which I recorded. The work around was to create this flow, give it a name, then edit it in the Flow editor, not the editor launched from Power Apps and delete the PowerApps control and replace with my own. This type of instructions is meant for grade school kids, & has 0 application in the real world.

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

ID: 2c6ca5a1-19a8-d7dc-7f40-7ac8abfe8ca3
Version Independent ID: e8f7d75a-b9ff-1301-1bab-838f2bfd402b
Content: Create a canvas app that can trigger a Power Automate flow (contains video) - Power Apps
Content Source: powerapps-docs/maker/canvas-apps/how-to/trigger-flow.md
Service: powerapps
Sub-service: canvas-maker
GitHub Login: @joel-lindstrom
Microsoft Alias: emcoope

Thanks for your comment, @crtjr64. This issue has been assigned to the doc author for review.


feat: Add tokio support to anchor_client RequestBuilder

Picking up on https://github.com/coral-xyz/anchor/pull/3006 since we need this for Arcium.
Adds request_threadsafe which creates a threadsafe request for usage in tokio. Fully backwards compatible.
Idk if https://github.com/coral-xyz/anchor/pull/3053 breaks this, so would be good to get this PR merged before that one. Lmk what you think @acheroncrypto

True, although even in this case the fix is relatively easy. It's just a matter of implementing it for RequestBuilder<'a, C, Box<dyn Signer + 'a>> instead of RequestBuilder<'a, C>>.

All SemVer violations can potentially result in build errors for downstream projects, no matter how easy the fix is e.g. https://github.com/coral-xyz/anchor/issues/3044. It's better to be safe in this case, and consider this a breaking change.

Suffering on this, but I cannot use the latest anchor due to Solana version constraints. Not sure what are my options 🥴


[Feature] Checkout branch as configurable flag

Hello @vbehar
Currently octopilot is checking out from the master/main branch and creating a new branch. We have a support for providing a different branch as base for PR. I would like to also have a similar support while checking out. I use the same repository for multiple applications so if I want to use octopilot for the application which is in some other branch I was not able to do that. I couldn't find any solution for this. If there is no existing solution, consider this as a feature request. Thanks 😊

Hi,
you can configure the branch to checkout while cloning using the branch parameter on a repo, such as
$ octopilot --repo "my-github-org/my-repo(branch=whatever)" ...

see https://dailymotion-oss.github.io/octopilot/v1.0.10/index.html#static for more details.
Does this answer your question?

I missed the branch option in the repo flag, this will be enough. Thanks @vbehar 🤩

ok perfect, I'll close this issue then, and feel free to open a new one if you need anything!


After adding the reposity and refreshing the add-on store I cannot find the wireguard client

After adding the reposity and refreshing the add-on store I cannot find the wireguard client

Hi @damarges please you have to add this URL https://github.com/bigmoby/hassio-repository-addon into custom repository URL's section.

thats what I did. no addon showing up I could install :/

well now after done it for the ike 5th or 6th time and refreshing and so on. now it shows up :)

Probably a browser cache issue.


Remove Top layout

Top layout makes some css harder to maintain

Additionally, no one seems to be using it. Instead, we should condense the options into Simplified and Classic

[x] Merge mtd-head-left code into their respective classes, overwriting the top navigation code underneath
[x] Rename the settings
[x] Reprogram the Welcome screen to accommodate the changes

Tasks completed


Update the rvc-operational-state code to match the 1.3 changes

In version 1.3 of the spec, the RVC operational state cluster's start and stop commands have been deprecated. These need to be removed from the rvc op state delegate's implementation in the all-clusters-app.
Due to the removal of these commands, there needs no be a way of changing the operational state to all states to allow the tests to execute on the all-clusters app.
As prat of this fix, ensure and fix any broken RVC op state tests.

The content of this issue are replicated in issue #31761 which is addressed in PR #31764. Note that the all-clusters-app will not support all the test steps and the appropriate PICS have been set in the ci-pics-values.


Post Videos

I have been trying to post videos using FacePy, but according with the Grap Api documentation the video must be encoding as form data.
I am trying to make a function to encode the file, but I am non an expert.
There are any tip to make it work?
Thanks!

I just need to specify the path 7me/videos/: Fixed!

@Azrrael-exe Hi there, if you're looking for a simpler alternative for uploading videos via Facebook's Graph Video API, I just uploaded this script here:
https://github.com/mdublin/Facebook-Video-Uploader


Runtime Error on Android client in JacksonBranch

Whenever I login to the Android client, there is a crash. @FrankHYB  has pointed out that the crash originates from the DataSend.java class. I did some investigation into the problem and it appears that when the client attempts to receive the weights from the Firebase db, the data the java code expects is different from the actual data stored in Firebase.

This is what the weights tree looks like in my Firebase db. If you expand the first child, thousands of weight values appear. If you expand the second branch, a 1 and a -1 appear.

Yubin also discovered that if you run crowdML-server-android.js from the master branch, you get the above tree as a result. If you run crowdML-server.js instead, you get a very different tree.

I asked Yani about this, she said these two servers use different algorithms. crowdML-server.js should be Neural network, i think Jackson’s android uses softmax.
Yubin
On Oct 19, 2016, at 11:47 AM, Tyler Zeller <notifications<EMAIL_ADDRESS>wrote:
Yubin also discovered that if you run crowdML-server-android.js from the master branch, you get the above tree as a result. If you run crowdML-server.js instead, you get a very different tree.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/jihunhamm/Crowd-ML/issues/7#issuecomment-254854250, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKKXlP3BcgCowgk5BK7mNJcF6nviibJXks5q1juJgaJpZM4KbIsT.

crowdML-server.js works for normal versions of both iOS and Android, and crowdML-server-android.js only works for test version of Android(It may work for normal version if Jackson made further modification, but this version is made because he used test lab to test the app). Both versions can run all algorithms, not just NN or Softmax. You can change the option of algorithms in Constants.js. I used NN to test the app with running multiple devices. This is because of my setting, and doesn't mean the server can only run NN or Softmax. I know Jason used Softmax to test for sure, but I don't know if he got time to test with NN. You guys can try different algorithms. Maybe try logReg or hingeLoss first, because they can run binary-class data. Then the lengths of gradients&weights are shorter. Let me know if you have any question about it.


Don't clear some fields on insert, and allow enter to edit/insert

A user may want to bulk enter data. In that case, a few of the fields will likely remain the same(Such as the date). I'd like for fields of my choosing to remain populated with the previous data, even when it's inserted.
I'd like to be able to press enter to either insert or confirm an edit. I'd also love for the escape button to cancel the edit. I've seen some examples posted around but they seem outdated now and don't work.
Finally, I'd like for tab behaviour to be slightly different. I'd like for it to loop around the currently selected row(Rather than the entire page) and, if possible, ignore the control buttons entirely.
Could you give me a few pointers on how to do what I want?

Clearing insertrow data after insert is the behavior of the control field (https://github.com/tabalinas/jsgrid/blob/master/src/fields/jsgrid.field.control.js#L183). You can redefine it on the control field of your grid.
Better keyboard support is reported in this issue https://github.com/tabalinas/jsgrid/issues/773
There you can find a suggestion on how to implement it now.


Move forward, save and delete form buttons to the top right

Since the buttons are currently at the bottom, we must scroll all the way down

I propose we move them at the top to make them more accessible

Should we have them at both location? Or have them "floating" so that we always see them?

Oh! floating is a good idea. I'll add them to the header and make that floating so that it's always at the top when scrolling