Limit the number of events that can exist

Description
Introduce a mechanism for configuring and enforcing an upper bound on the number of events that can exist at a given time.
Requirements
A solution will:

maintain a "soft" upper bound on the number of events; i.e. the system can temporarily exceed the limit for short periods.
surface a configuration point on Acorn

Motivation
Today, clients can record an unlimited number of events, which can consume an unlimited amount of resources.
Notes

We could extend Quota to bound Events
The simplest approach involves a controller that repeatedly deletes the oldest known event until the number of events is less than or equal to the upper bound.
Another approach is to think of the bounded event set as a fixed-length circular queue; we write events in the order they were received until we fill up the queue, then circle back to the beginning and overwrite the older entries to record new events
Another approach is to reject write requests once the upper bound is hit and leave it to some other process to free up space
Consider capping events on a per-Project or per-Account basis so that clusters can scale with usage. A constant number of events per-cluster probably won't scale well since one bad tenant can hog all the space by triggering more events than others.

In a discussion today with @ibuildthecloud we came to the conclusion that rate-limiting event creation would be a better solution than imposing a hard cap on the number of events.

Tested with acorn versionv0.8.0-rc4+b6a95e8a on local clusters.
Created 1500 events ( this was done directly using kubectl)
After 5 minutes , acorn events from all projects reported only 1000 latest events.
Deployed few apps.
This result in more events getting created and count getting to > 1000 .
In the next 5 minutes, event count gets back to 1000 . Older events get deleted to keep the count to 1000. Events relating to deployed app continue to be present.


wrong API endpoint for getOrderDetails method

When we call getOrderDetails method, it looks like the endpoint called is https://vendors.paddle.com/api/1.0/order, but it should be https://checkout.paddle.com/api/1.0/order instead.
With the first one, the method always returns a 404 error.

Fixed in v1.1.0, thanks for sharing!

@dimitribocquet
how to access this method "getOrderDetails "  ? I am looking for a way to find out subscription details like next payments, status directly from paddle

@alzaabi98
Paddle::checkout()->getOrderDetails();
You can see some examples in the readme.


Finding old request rooms

As user I like to find an old request channeI, that I joined in the past, by the integrated Rocket.Chat channel search.

This issue was moved to assistify/Rocket.Chat#13


Split getters and setters into big and little endian. Change PureScript

type for Uint32 operations to Int53.

Looks good, but I would keep the big-endian names without suffix to avoid bumping the major version.

On a second though, the UInt32 fetcher was quite silly with an Int return type, so maybe we should bump.

I've written this package. It provides exactly the UInt32 type, maybe it could be used instead of Int53. It's poorly documented though - I'm not good at English. But I'll try adopting some more of docstrings from purescript-int-53 later.

Sounds good, I guess it's more appropriate here than the -int53 package.

The changes to use Data.UInt are in the zaquest-int53_and_endianness, waiting for the -quickcheck/-transformers fix to merge to master.

Should be merged now, thanks!


about for minify

Hello, I'm happy with grunt-ts, and have a question with js minify settings. Anyway to minify js file after compile from ts to js.
the flow:
.ts > .js > .min.js

Use grunt-contrib-watch and specify the targets, they are executed in sequence.
Docs : https://github.com/gruntjs/grunt-contrib-watch#tasks :rose:


[6.4.x] GUVNOR-2417: Repository view doesn't show contents of the project after switching from another project.

Jenkins please retest this

+1 to merge.

6.4.x: 64459a57a6577c01530ef9fc394f3b831ab118a2


UI: More accurate lane routing arcs

The lane routing lines at junctions don't follow the actual path the vehicles take, they just use a very basic arc between source lane and destination lane.
Would it be possible to use the same approach that the vehicle AIs use in order to create more accurate lines to depict the lane routing? They'd still be an arc, but the properties of the arc would be more accurate based on the actual trajectory the vehicles take.
While this in itself is a minor and somewhat superfluous enhancement, it would be very useful for several other enhancements which I'll post as separate tickets.

Current state of develoment...

Perfect

Perfect

Still not the best path and I have no idea how to catch this type of connection yet (diverge - merge)

Again problem with diverging lanes (pink)

In addition, sometimes path connecting straight lanes is not calculated correctly

Bonus

omfg that is huge improvement!
I note also on the last image the u-turn at the bottom is upside down.
For catching the connection types, I think there's already something in TMPE that does that - specifically the code that works out default lane connections I think - see bottom section of this wiki page in old docs: https://tmpe.viathinksoft.com/wiki/index.php?title=Junction_%26_transition_routing

I note also on the last image the u-turn at the bottom is upside down.

I know that was bonus of the bonus 😉
I am sure you've noticed too that there are no straight lane connections because they are bugged now 😄
Moreover I have to work on performance because last image have been eating few fps per added connection 😕  (currently every connection is calculated on the fly while rendering - no caching)
I think the best would be create textures/ meshes from connection (on the fly) and cache somewhere to greatly increase performance - similar as path visualizer is doing it and intersections of connection curves would be easier to detect, I think.
Additionally I think I will need textures for those triangles and squares, but I will try to generate them using code first.

How are textures done for the arrows that flow along bus route lines done? Remember we'll need to be able to colourise them (eg. yellow for arrows on the source segment) and fill them (for lanes that have at least one incoming connection), etc.
As for path visualiser, I assume that it's already dealing with everything we'd need for the lane connector visualisation? Like, when I route a bus through a junction, the route line is already showing accurately where the bus will go (as far as I can tell). We'd just need thinner line.

Not sure if it's any use, but there's various node/segment/lane flags that could be inspected, many of which are described here: https://cslmodding.info/asset/network/#flags

Finally managed to create most accurate lane connections ever! 🤣 🤣

That's freaking awesome!

Nice work, this got me thinking. Perhaps this is a nice idea:
When you start to work on manually connecting lanes, perhaps it would be nice that per default all the lanes are drawn, so you will only have to remove the ones you don't like. Because in my experience i usually want to keep 80% of the default lane connections...

Tagging #985, #282, #932


bolt: Performance degradation while loading Freebase dump

Description
I'm trying to load full Freebase dump into cayley, but load performance is degrading, and it looks like the load process will never finish.
At first I've run a series of experiments to determine the fastest way to load the data. Here are the results (cells contain minutes needed to load the number of quads from the column header). As we can see Bolt + pq + nosync + 2.5M had the best performance (not sure though that nosync contributed at all)
| 5M | 10M | 15M | 20M | 25M
-- | -- | -- | -- | -- | --
Bolt + nq + 10k | 2 | 7 | 16 | 20 | 29
Bolt + nq + 50k | 2 | 5 | 13 | 15 | 23
Bolt + nq + 100k | 2 | 5 | 12 | 14 | 20
Bolt + nq + 200k | 2 | 5 | 10 | 12 | 17
Bolt + nq + 500k | 2 | 5 | 8 | 10 | 13
Bolt + nq + 500k | 2 | 5 | 8 | 9 | 12
Bolt + nq + 1.25M | 2 | 5 | 7 | 9 | 12
Bolt + nq + 2.5M | 2 | 5 | 7 | 9 | 12
Bolt + nq + 5M | 3 | 5 | 8 | 9 | 12
Bolt + nq + 1M + nosync | 2 | 5 | 7 | 9 | 12
Bolt + nq + 2.5M + nosync | 2 | 5 | 7 | 9 | 11
Bolt + pq.gz + 1.25M | 2 | 4 | 7 | 8 | 10
Bolt + pq + nosync + 1.25M | 2 | 4 | 6 | 7 | 10
Bolt + pq + nosync + 2.5M | 2 | 4 | 6 | 7 | 9
Leveldb + nq + buffer 20 + 10k | 4 | 12 | 26 |   |
Leveldb + pq.gz + buffer 20M + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + nq + buffer 20M + 5M | 2 | 18 |   |   |
Leveldb + pq.gz + buffer 200M + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + pq.gz + buffer 1G + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + pq.gz + buffer 1G + 500k | 1 | 5 | 11 | 13 | 19
Leveldb + pq.gz + buffer 4G + 500k | 1 | 5 | 11 | 13 | 19
Leveldb + pq.gz + buffer 4G + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + pq.gz + buffer 4G + cache 200M + 1.25M | 1 | 8 | 16 | 18 | 28

Steps to reproduce the issue:

cayley load -c bolt.yml --verbose=3 -i freebase.pq
bolt.yml:

store:
  backend: bolt
  address: bolt
load:
  batch: 2500000

Received results:
At first, everything was ok, but then load started to slow down. The graph can demonstrate it better:

Then I've decided to make smaller batches and add nosync:

cayley load -c bolt.yml --verbose=3 -i freebase.pq
bolt.yml:

store:
  backend: bolt
  address: bolt
  options:
    nosync: true
load:
  batch: 500000

Things became a bit better, but not for long:

htop says the process consumes more and more memory (58gb after 2 days)
Expected results:
Freebase loaded in less than infinity
Output of cayley version or commit hash:
Cayley version: 0.7.5
Git commit hash: cf576babb7db

Environment details:
CPU: 8 x Intel(R) Xeon(R) CPU @ 2.30GHz
Memory: 29Gb
OS: Ubuntu 16.04.6 LTS
Disk: SSD
Backend database: (database and version)
Bolt, not sure about version - cayley handled that for me
So the question is - am I doing it wrong or is there some bug?

Yes, this can be considered a performance-related bug in the import implementation.
Can you please try 79d7d62393142cfd7035e942cc705f6947e7bcbb? It should improve import performance considerably.
But we may need other changes as well to make it faster for those large dumps specifically. For example, a two-stage import process may be faster because we can pre-compute nodes table during the first pass and then resolve quads during the second pass, so the nodes table is mostly in read-only mode during the second pass.

I tried to load data using the latest master (I believe the commit you've referenced is already in there), and probably things became a bit better, but the pattern seems to be the same:

Also, the docker was killed with 137 code (OOM) in 1.5h (98M quads was processed)

On another try received this:
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x150ab5f, 0x16)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc68c000000, 0x3c000000, 0x22e1738)
	/usr/local/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0x22c0640, 0x3c000000, 0x7f16c9bdaf80, 0x7f16a3013bc0)
	/usr/local/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0x22c0640, 0x1d6b2, 0x0)
	/usr/local/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0x22c0640, 0x1d6b2, 0x22e1748, 0x2030b500000000)
	/usr/local/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0x22c0640, 0x1d6b2, 0xffffffffffff0100, 0x7f16a3013c78)
	/usr/local/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0x22c0640, 0x1d6b2, 0x7f16a3010100, 0x418415)
	/usr/local/go/src/runtime/mheap.go:758 +0x8a
runtime.largeAlloc(0x3ad64000, 0x450001, 0x7f1732460000)
	/usr/local/go/src/runtime/malloc.go:1019 +0x97
runtime.mallocgc.func1()
	/usr/local/go/src/runtime/malloc.go:914 +0x46
runtime.systemstack(0xc067a6fe00)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1229

goroutine 1 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc004d1efd0 sp=0xc004d1efc8 pc=0x459700
runtime.mallocgc(0x3ad64000, 0x141dca0, 0x1, 0xffffffffffffffff)
	/usr/local/go/src/runtime/malloc.go:913 +0x896 fp=0xc004d1f070 sp=0xc004d1efd0 pc=0x40e2e6
runtime.growslice(0x141dca0, 0xc5d8d58000, 0xbc4700, 0xbc4700, 0xbc4701, 0x0, 0xc000170000, 0xc004d1f178)
	/usr/local/go/src/runtime/slice.go:204 +0x145 fp=0xc004d1f0d8 sp=0xc004d1f070 pc=0x444445
github.com/boltdb/bolt.(*node).put(0xc0002483f0, 0xc2ad76f168, 0x8, 0x8, 0xc2ad76f168, 0x8, 0x8, 0xc462a3f120, 0x1b, 0x1b, ...)
	/go/pkg/mod/github.com/boltdb/bolt@v1.3.1/node.go:131 +0x3dd fp=0xc004d1f188 sp=0xc004d1f0d8 pc=0x908bed
github.com/boltdb/bolt.(*Bucket).Put(0xc3cddf2a00, 0xc2ad76f160, 0x8, 0x8, 0xc462a3f120, 0x1b, 0x1b, 0x30, 0x12e4ae0)
	/go/pkg/mod/github.com/boltdb/bolt@v1.3.1/bucket.go:309 +0x26d fp=0xc004d1f238 sp=0xc004d1f188 pc=0x8ff9ad
github.com/hidal-go/hidalgo/kv/bolt.(*Tx).Put(0xc03e41b620, 0xc2d68d9950, 0x2, 0x2, 0xc462a3f120, 0x1b, 0x1b, 0x1, 0x10f14ea)
	/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/bolt/bolt.go:161 +0x13f fp=0xc004d1f2a0 sp=0xc004d1f238 pc=0x9125ff
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).addToLog(0xc000281900, 0x174aa20, 0xc03e41b620, 0xc004d1f428, 0x2, 0x2)
	/cayley/graph/kv/indexing.go:886 +0x245 fp=0xc004d1f358 sp=0xc004d1f2a0 pc=0xad8075
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).indexLink(0xc000281900, 0x174aa20, 0xc03e41b620, 0xc004d1f428, 0x0, 0x0)
	/cayley/graph/kv/indexing.go:636 +0x1a1 fp=0xc004d1f3d8 sp=0xc004d1f358 pc=0xad5701
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).indexLinks(0xc000281900, 0x1744b20, 0xc0000b2028, 0x174aa20, 0xc03e41b620, 0xc4ec708000, 0x7a114, 0x7a120, 0x0, 0x0)
	/cayley/graph/kv/indexing.go:614 +0x113 fp=0xc004d1f4e8 sp=0xc004d1f3d8 pc=0xad5483
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).applyAddDeltas(0xc000281900, 0x174aa20, 0xc03e41b620, 0x0, 0x0, 0x0, 0xc13b3d0ea0, 0x22d0001, 0x173a2a0, 0xc32781cbe0, ...)
	/cayley/graph/kv/indexing.go:484 +0x6e4 fp=0xc004d1f8e8 sp=0xc004d1f4e8 pc=0xad38f4
github.com/cayleygraph/cayley/graph/kv.(*quadWriter).WriteQuads(0xc004d30060, 0xc004d5a000, 0x7a120, 0x7a120, 0xc0000c00a0, 0xc004d5a000, 0x7a120)
	/cayley/graph/kv/indexing.go:388 +0xa1 fp=0xc004d1f960 sp=0xc004d1f8e8 pc=0xad2dc1
github.com/cayleygraph/cayley/internal.(*batchLogger).WriteQuads(0xc0000c00c0, 0xc004d5a000, 0x7a120, 0x7a120, 0x7a120, 0x0, 0x0)
	/cayley/internal/load.go:146 +0x59 fp=0xc004d1f9c8 sp=0xc004d1f960 pc=0x75fe09
github.com/cayleygraph/cayley/quad.CopyBatch(0x1731b40, 0xc0000c00c0, 0x7f172d9f8ae0, 0xc0000c00a0, 0x7a120, 0xc0000c00a0, 0x0, 0x0)
	/cayley/quad/rw.go:145 +0x1dc fp=0xc004d1fa70 sp=0xc004d1f9c8 pc=0x746d1c
github.com/cayleygraph/cayley/internal.DecompressAndLoad(0x173bfa0, 0xc004d30060, 0x7a120, 0x7ffdb3958f78, 0x14, 0x0, 0x0, 0x0, 0x0)
	/cayley/internal/load.go:133 +0x17c fp=0xc004d1fae8 sp=0xc004d1fa70 pc=0x75fc7c
github.com/cayleygraph/cayley/internal.Load(0x173bfa0, 0xc004d30060, 0x7a120, 0x7ffdb3958f78, 0x14, 0x0, 0x0, 0x14fc8ff, 0xa)
	/cayley/internal/load.go:21 +0x71 fp=0xc004d1fb40 sp=0xc004d1fae8 pc=0x75ec31
github.com/cayleygraph/cayley/cmd/cayley/command.openForQueries(0xc00027cc80, 0x0, 0x0, 0x0)
	/cayley/cmd/cayley/command/database.go:259 +0x2bb fp=0xc004d1fc48 sp=0xc004d1fb40 pc=0x8d2ceb
github.com/cayleygraph/cayley/cmd/cayley/command.NewHttpCmd.func1(0xc00027cc80, 0xc000100fd0, 0x0, 0xb, 0x0, 0x0)
	/cayley/cmd/cayley/command/http.go:24 +0x9f fp=0xc004d1fce8 sp=0xc004d1fc48 pc=0x8d860f
github.com/spf13/cobra.(*Command).execute(0xc00027cc80, 0xc000100f20, 0xb, 0xb, 0xc00027cc80, 0xc000100f20)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:826 +0x473 fp=0xc004d1fdd8 sp=0xc004d1fce8 pc=0x5c0fa3
github.com/spf13/cobra.(*Command).ExecuteC(0x2124ae0, 0x2124d60, 0xc00023db80, 0xc000191f88)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914 +0x2f8 fp=0xc004d1ff20 sp=0xc004d1fdd8 pc=0x5c1998
github.com/spf13/cobra.(*Command).Execute(0x2124ae0, 0xc00027ca00, 0xc00027cc80)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864 +0x2b fp=0xc004d1ff50 sp=0xc004d1ff20 pc=0x5c167b
main.main()
	/cayley/cmd/cayley/cayley.go:187 +0x31 fp=0xc004d1ff98 sp=0xc004d1ff50 pc=0x10c8061
runtime.main()
	/usr/local/go/src/runtime/proc.go:201 +0x207 fp=0xc004d1ffe0 sp=0xc004d1ff98 pc=0x42f197
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc004d1ffe8 sp=0xc004d1ffe0 pc=0x45b7e1

goroutine 19 [syscall, 191 minutes]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 20 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x22b7240)
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:410 +0x203

@eawer Thanks a lot for providing the stack trace and new test results! I can confirm that the new code path is used.
Can you please try setting --batch to lower values? The new code path should behave differently with the same parameters, so the table in the first post may show a different optimal batch size. Setting batch too high will lead to OOM with certainty, since the whole transaction of that size will be buffered to memory by BoltDB.
In general, BoltDB does not perform well with random writes which happen frequently during import of a dataset of this size. You may also try switching to Badger instead for this import. You may need to set the --batch to even lower values because the way transactions work in Badger, but the write performance should be much better. Note, however, that Badger backend is not fully tested yet.

Badger failed with such error:
I0821 08:20:19.862643       1 cayley.go:63] Cayley version: v0.7.x-dev (300dcf1f8503)
I0821 08:20:19.862868       1 cayley.go:76] using config file: etc/cayley.json
I0821 08:20:19.862959       1 database.go:193] using backend "badger" (/data/badger)
2019/08/21 08:20:19 Replaying from value pointer: {Fid:0 Len:0 Offset:0}
2019/08/21 08:20:19 Iterating file id: 0
2019/08/21 08:20:19 Iteration took: 23.881µs
2019/08/21 08:20:20 Replaying from value pointer: {Fid:0 Len:42 Offset:225}
2019/08/21 08:20:20 Iterating file id: 0
2019/08/21 08:20:20 Iteration took: 17.805µs
I0821 08:20:20.536147       1 load.go:149] Wrote 5000 quads.
I0821 08:20:20.604970       1 load.go:149] Wrote 10000 quads.
I0821 08:20:20.680754       1 load.go:149] Wrote 15000 quads.
I0821 08:20:20.752241       1 load.go:149] Wrote 20000 quads.
I0821 08:20:20.809708       1 load.go:149] Wrote 25000 quads.
I0821 08:20:20.838822       1 load.go:149] Wrote 25000 quads.
Error: db: failed to load data: Txn is too big to fit into one request
...
E0821 08:20:21.287193       1 cayley.go:188] db: failed to load data: Txn is too big to fit into one request

After replacing badger 1.5.5 with 1.6.0 docker build fails with
# github.com/hidal-go/hidalgo/kv/flat/badger
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:46:5: opt.Dir undefined (type func(string) badger.Options has no field or method Dir)
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:47:17: cannot use opt (type func(string) badger.Options) as type badger.Options in argument to Open
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:77:21: too many arguments in call to tx.tx.Commit
	have (nil)
	want ()
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:149:9: assignment mismatch: 2 variables but 1 values
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:149:30: not enough arguments in call to it.it.Item().Value
	have ()
	want (func([]byte) error)

Regarding smaller batches - I put it on test and will paste the results here right after I have them.

db: failed to load data: Txn is too big to fit into one request

This is expected, and this is exactly the reason why I suggested lowering --batch even more for Badger. It may be way below the default of 10K.
Regarding 1.6, we can update Hidalgo later to support it.

Reducing batch size to 10k for bolt did not help a lot, process ended with no trace, but because of OOM with something like this https://github.com/cayleygraph/cayley/issues/815#issuecomment-523063489 in the journal

Badger started to work as expected only on 1k batch size, but after all crashed like this:
I0821 13:46:05.629259       1 load.go:149] Wrote 91399000 quads.
fatal error: runtime: out of memory
runtime stack:
runtime.throw(0x150ab5f, 0x16)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc6e4000000, 0x8000000, 0x22e1738)
	/usr/local/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0x22c0640, 0x8000000, 0x0, 0x7fb6928a7b98)
	/usr/local/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0x22c0640, 0x20fa, 0x0)
	/usr/local/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0x22c0640, 0x20fa, 0x22e1748, 0x0)
	/usr/local/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0x22c0640, 0x20fa, 0x101, 0x1871dd8)
	/usr/local/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0x22c0640, 0x20fa, 0x7fb692010101, 0x43694f)
	/usr/local/go/src/runtime/mheap.go:758 +0x8a
runtime.largeAlloc(0x41f3ce6, 0xc000040101, 0xc03cec4180)
	/usr/local/go/src/runtime/malloc.go:1019 +0x97
runtime.mallocgc.func1()
	/usr/local/go/src/runtime/malloc.go:914 +0x46
runtime.systemstack(0xc000000f00)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1229

goroutine 131304 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc102bc8c90 sp=0xc102bc8c88 pc=0x459700
runtime.mallocgc(0x41f3ce6, 0x12f6c20, 0xc094429801, 0xa8)
	/usr/local/go/src/runtime/malloc.go:913 +0x896 fp=0xc102bc8d30 sp=0xc102bc8c90 pc=0x40e2e6
runtime.makeslice(0x12f6c20, 0x41f3ce6, 0x41f3ce6, 0x7fb6952da000, 0x0, 0xc102bc8dd8)
	/usr/local/go/src/runtime/slice.go:70 +0x77 fp=0xc102bc8d60 sp=0xc102bc8d30 pc=0x444277
github.com/dgraph-io/badger/table.(*Table).loadToRAM(0xc01fb1ee00, 0x41f3ce6, 0x7a6)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/table/table.go:351 +0x4a fp=0xc102bc8de8 sp=0xc102bc8d60 pc=0x9757fa
github.com/dgraph-io/badger/table.OpenTable(0xc012a122a8, 0x1, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/table/table.go:139 +0x374 fp=0xc102bc8eb0 sp=0xc102bc8de8 pc=0x9743e4
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a6, 0xc0001320e0, 0xc3f4f19080, 0xc114e604e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:461 +0x22f fp=0xc102bc8fc0 sp=0xc102bc8eb0 pc=0x99e9cf
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc102bc8fc8 sp=0xc102bc8fc0 pc=0x45b7e1
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 1 [running]:
	goroutine running on other thread; stack unavailable

goroutine 19 [syscall, 79 minutes]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 20 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x22b7240)
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:410 +0x203

goroutine 21 [chan receive, 79 minutes]:
github.com/dgraph-io/badger/y.(*WaterMark).process(0xc000274c98)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:125 +0x15b
created by github.com/dgraph-io/badger/y.(*WaterMark).Init
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:54 +0xc1

goroutine 214 [chan receive]:
github.com/dgraph-io/badger/y.(*WaterMark).process(0xc000274b18)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:125 +0x15b
created by github.com/dgraph-io/badger/y.(*WaterMark).Init
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:54 +0xc1

goroutine 128689 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x77c, 0xc0001320e0, 0xc2b7dcc000, 0xc251d95da0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128945 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x788, 0xc0001320e0, 0xc2b7dcc000, 0xc0784fd9e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 215 [select]:
github.com/dgraph-io/badger.(*DB).updateSize(0xc000170000, 0xc005632540)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:928 +0x125
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:267 +0x7d7

goroutine 28 [select]:
github.com/dgraph-io/badger.(*levelsController).runWorker(0xc0001320e0, 0xc00024c040)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:248 +0x151
created by github.com/dgraph-io/badger.(*levelsController).startCompact
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:233 +0x82

goroutine 27 [chan receive]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables(0xc0001320e0, 0x2, 0x174ad20, 0xc000182d00, 0xc00564b680, 0xc00564b6e0, 0xc08c20de68, 0x1, 0x1, 0xc08c20de70, ...)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:472 +0x1103
github.com/dgraph-io/badger.(*levelsController).runCompactDef(0xc0001320e0, 0x2, 0x174ad20, 0xc000182d00, 0xc00564b680, 0xc00564b6e0, 0xc08c20de68, 0x1, 0x1, 0xc08c20de70, ...)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:638 +0xd3
github.com/dgraph-io/badger.(*levelsController).doCompact(0xc0001320e0, 0x2, 0x3ff00cadb9666666, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:705 +0x498
github.com/dgraph-io/badger.(*levelsController).runWorker(0xc0001320e0, 0xc00024c040)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:254 +0x1c9
created by github.com/dgraph-io/badger.(*levelsController).startCompact
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:233 +0x82

goroutine 29 [running]:
	goroutine running on other thread; stack unavailable
created by github.com/dgraph-io/badger.(*levelsController).startCompact
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:233 +0x82

goroutine 33 [chan receive, 79 minutes]:
github.com/dgraph-io/badger.(*valueLog).waitOnGC(0xc000170148, 0xc00024c4a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/value.go:1186 +0x61
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:328 +0xcde

goroutine 30 [chan receive, 1 minutes]:
github.com/dgraph-io/badger.(*DB).flushMemtable(0xc000170000, 0xc00024c140, 0x0, 0x0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:806 +0xd3
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:280 +0xf3e

goroutine 32 [select]:
github.com/dgraph-io/badger.(*DB).doWrites(0xc000170000, 0xc00024c480)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:670 +0x404
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:325 +0xc81

goroutine 130260 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x798, 0xc0001320e0, 0xc2b7dcc000, 0xc296d15020)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130056 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x78a, 0xc0001320e0, 0xc2b7dcc000, 0xc01c1aaf60)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131302 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a3, 0xc0001320e0, 0xc2b7dcc000, 0xc113d06060)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130249 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x790, 0xc0001320e0, 0xc2b7dcc000, 0xc020507aa0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 127571 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x775, 0xc0001320e0, 0xc2b7dcc000, 0xc296d14120)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131303 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a5, 0xc0001320e0, 0xc2b7dcc000, 0xc094429800)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130251 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x79c, 0xc0001320e0, 0xc2b7dcc000, 0xc02c45c5a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128293 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x771, 0xc0001320e0, 0xc2b7dcc000, 0xc296d156e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130338 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x78d, 0xc0001320e0, 0xc2b7dcc000, 0xc05b4bc060)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 129072 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x77e, 0xc0001320e0, 0xc2b7dcc000, 0xc114e61740)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131176 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a0, 0xc0001320e0, 0xc2b7dcc000, 0xc1b16205a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128151 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x773, 0xc0001320e0, 0xc2b7dcc000, 0xc118c22fc0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128624 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x780, 0xc0001320e0, 0xc2b7dcc000, 0xc010d74000)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131055 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x79a, 0xc0001320e0, 0xc2b7dcc000, 0xc118c22000)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131057 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x79e, 0xc0001320e0, 0xc2b7dcc000, 0xc010585320)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130259 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x792, 0xc0001320e0, 0xc2b7dcc000, 0xc113d076e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128222 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x76f, 0xc0001320e0, 0xc2b7dcc000, 0xc0c16bc2a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128495 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x77a, 0xc0001320e0, 0xc2b7dcc000, 0xc113d07440)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131238 [running]:
	goroutine running on other thread; stack unavailable
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 129196 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x785, 0xc0001320e0, 0xc2b7dcc000, 0xc06f42d0e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130596 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x795, 0xc0001320e0, 0xc2b7dcc000, 0xc251d95080)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128941 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x783, 0xc0001320e0, 0xc2b7dcc000, 0xc00cd0f8c0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128493 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x777, 0xc0001320e0, 0xc2b7dcc000, 0xc1b1621b60)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

Thanks a lot for testing it @eawer. This definitely looks like a memory issue in the new code path. I will investigate it.

After a few short tests, I think the OOM is related to how the quad indexing works in all KV backends. The dataset of this size leads to an extremely large index entries for supernodes. Modifying this kind of index entry requires loading it into the memory.
A quick workaround may be to take a physical size of the transaction into account when auto-committing during batch import. However, this will only delay an issue.
The mid-term fix is to allow disabling those list indexes and switch to a single value indexes. This may lead to a larger DB size, but will solve the issue completely. Query performance may also suffer to some degree.
The long-term solution is to allow both kinds of indexes. This will complicate the design, however, and must be tested carefully in comparison with the previous proposed solution.

@eawer I made a few changes to indexing in https://github.com/cayleygraph/cayley/pull/816. It should help with the OOM issue, but at the same time it will increase the size of the index on disk, so write performance may suffer. But it's hard to make any statements because the new indexing strategy should also improve quad lookup performance, which may remove the need for multiple reads during the import process.
I will continue looking into it and will run a few tests locally as well. But the help with the testing is highly appreciated.

Cayley version: v0.7.x-dev (88cbd1564ad0)
badger died after 20min and 14M quads (batch size 1k) with Error: db: failed to load data: Txn is too big to fit into one request
Bolt failed after 13.5h and 207M quads with error:
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x1534adf, 0x16)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc6c4000000, 0x4000000, 0x23407b8)
	/usr/local/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0x231f6c0, 0x4000000, 0x231f8c8, 0x7fcff738c4d8)
	/usr/local/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0x231f6c0, 0x30, 0x0)
	/usr/local/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0x231f6c0, 0x30, 0x23407c8, 0x9800)
	/usr/local/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0x231f6c0, 0x30, 0x101, 0x7fcfeaf6ffff)
	/usr/local/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0x231f6c0, 0x30, 0x7fcfea000101, 0x7fd0284c9130)
	/usr/local/go/src/runtime/mheap.go:758 +0x8a
runtime.largeAlloc(0x60000, 0x450100, 0x7fd0284c9130)
	/usr/local/go/src/runtime/malloc.go:1019 +0x97
runtime.mallocgc.func1()
	/usr/local/go/src/runtime/malloc.go:914 +0x46
runtime.systemstack(0xc000001380)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1229

goroutine 1 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc0000c91f8 sp=0xc0000c91f0 pc=0x459700
runtime.mallocgc(0x60000, 0x0, 0x3c000, 0xc6c3f74000)
	/usr/local/go/src/runtime/malloc.go:913 +0x896 fp=0xc0000c9298 sp=0xc0000c91f8 pc=0x40e2e6
runtime.growslice(0x1318ee0, 0xc6c3f74000, 0x9800, 0x9800, 0x9801, 0xc6c3f74000, 0x7800, 0x9800)
	/usr/local/go/src/runtime/slice.go:197 +0x219 fp=0xc0000c9300 sp=0xc0000c9298 pc=0x444519
github.com/cayleygraph/cayley/graph/kv.decodeIndex(0x7fcb35042040, 0x43f1f8, 0x43f1f8, 0xc1b8a96f30, 0x2, 0x2, 0xc1b8a96e70, 0x2)
	/cayley/graph/kv/indexing.go:753 +0x131 fp=0xc0000c9378 sp=0xc0000c9300 pc=0xaece71
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).getBucketIndexes(0xc000273900, 0x176f900, 0xc000038048, 0x1777160, 0xc3c1e8e008, 0xc1b8a96c30, 0x2, 0x2, 0x410029, 0x132a520, ...)
	/cayley/graph/kv/indexing.go:720 +0x176 fp=0xc0000c9418 sp=0xc0000c9378 pc=0xaecab6
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).hasPrimitive(0xc000273900, 0x176f900, 0xc000038048, 0x1777160, 0xc3c1e8e008, 0xc0000c9880, 0x968c42f20953f800, 0x837bace2, 0x0, 0x0)
	/cayley/graph/kv/indexing.go:860 +0x216 fp=0xc0000c94e8 sp=0xc0000c9418 pc=0xaedd36
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).applyAddDeltas(0xc000273900, 0x1777160, 0xc3c1e8e008, 0x0, 0x0, 0x0, 0xc1c0dc01e0, 0x2330001, 0x1765240, 0xc4aa122a80, ...)
	/cayley/graph/kv/indexing.go:507 +0x94c fp=0xc0000c98e8 sp=0xc0000c94e8 pc=0xaea8ac
github.com/cayleygraph/cayley/graph/kv.(*quadWriter).WriteQuads(0xc0002753e0, 0xc004d26000, 0x186a0, 0x186a0, 0xc00000c0c0, 0xc004d26000, 0x186a0)
	/cayley/graph/kv/indexing.go:439 +0xa1 fp=0xc0000c9960 sp=0xc0000c98e8 pc=0xae9b11
github.com/cayleygraph/cayley/internal.(*batchLogger).WriteQuads(0xc00000c0e0, 0xc004d26000, 0x186a0, 0x186a0, 0x186a0, 0x0, 0x0)
	/cayley/internal/load.go:146 +0x59 fp=0xc0000c99c8 sp=0xc0000c9960 pc=0x75fe09
github.com/cayleygraph/cayley/quad.CopyBatch(0x175caa0, 0xc00000c0e0, 0x7fd080409068, 0xc00000c0c0, 0x186a0, 0xc00000c0c0, 0x0, 0x0)
	/cayley/quad/rw.go:145 +0x1dc fp=0xc0000c9a70 sp=0xc0000c99c8 pc=0x746d1c
github.com/cayleygraph/cayley/internal.DecompressAndLoad(0x1766f40, 0xc0002753e0, 0x186a0, 0x7ffff4cc0f78, 0x14, 0x0, 0x0, 0x0, 0x0)
	/cayley/internal/load.go:133 +0x17c fp=0xc0000c9ae8 sp=0xc0000c9a70 pc=0x75fc7c
github.com/cayleygraph/cayley/internal.Load(0x1766f40, 0xc0002753e0, 0x186a0, 0x7ffff4cc0f78, 0x14, 0x0, 0x0, 0x15266d9, 0xa)
	/cayley/internal/load.go:21 +0x71 fp=0xc0000c9b40 sp=0xc0000c9ae8 pc=0x75ec31
github.com/cayleygraph/cayley/cmd/cayley/command.openForQueries(0xc000270c80, 0x0, 0x0, 0x0)
	/cayley/cmd/cayley/command/database.go:259 +0x2bb fp=0xc0000c9c48 sp=0xc0000c9b40 pc=0x8e908b
github.com/cayleygraph/cayley/cmd/cayley/command.NewHttpCmd.func1(0xc000270c80, 0xc0000eefd0, 0x0, 0xb, 0x0, 0x0)
	/cayley/cmd/cayley/command/http.go:24 +0x9f fp=0xc0000c9ce8 sp=0xc0000c9c48 pc=0x8ee9af
github.com/spf13/cobra.(*Command).execute(0xc000270c80, 0xc0000eef20, 0xb, 0xb, 0xc000270c80, 0xc0000eef20)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:826 +0x473 fp=0xc0000c9dd8 sp=0xc0000c9ce8 pc=0x5c0fa3
github.com/spf13/cobra.(*Command).ExecuteC(0x2183b40, 0x2183dc0, 0xc000231b80, 0xc000187f88)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914 +0x2f8 fp=0xc0000c9f20 sp=0xc0000c9dd8 pc=0x5c1998
github.com/spf13/cobra.(*Command).Execute(0x2183b40, 0xc000270a00, 0xc000270c80)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864 +0x2b fp=0xc0000c9f50 sp=0xc0000c9f20 pc=0x5c167b
main.main()
	/cayley/cmd/cayley/cayley.go:187 +0x31 fp=0xc0000c9f98 sp=0xc0000c9f50 pc=0x10e9381
runtime.main()
	/usr/local/go/src/runtime/proc.go:201 +0x207 fp=0xc0000c9fe0 sp=0xc0000c9f98 pc=0x42f197
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000c9fe8 sp=0xc0000c9fe0 pc=0x45b7e1

goroutine 5 [syscall, 834 minutes]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 6 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x23162c0)
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:410 +0x203

Thanks for taking the time to test the new version!

badger died after 20min and 14M quads (batch size 1k) with Error: db: failed to load data: Txn is too big to fit into one request

I think we may give up for now on Badger. I'll need to change the way how we import data into it to avoid those large transaction.

Bolt failed after 13.5h and 207M quads

We are getting somewhere. But it seems like the SP index may also build up over time. I wonder what in the Freebase schema may cause it? I guess we will find out after a successful import :)
In any case, I will get back to you after making a few more changes.
First, I want to add instrumentation, so me can get more insights from the import process. I will add a "time per batch" metric, so we can get the same graph as you've built from Prometheus/Grafana directly. Also, I'm particularly interested in seeing the sizes of those index entries on each index. Also, things like lookup durations may be useful to speed up the import further.
And second, I will add an option to set custom indexes for KV, so we can try "SPO" index instead of "SP". Since the import was able to proceed further than before, I think the "O" index was indeed the case for previous OOM.

@eawer The patch with metrics and improved write performance was pushed upstream. It now optimizes the first batch write (e.g. cayley load) to minimize reads from the disk.
However, as I mentioned before, this improves performance only to some extent. I'm now working on a two-stage import tool that should improve write speed significantly. It will first use Badger to build a node index, and then export it to the target backend (e.g. Bolt).
From the first prototype, metrics show that the import process speed is constant and doesn't degrade over time, thanks to Badger's write optimizations. Building nodes index for the whole dataset takes < 10h. I will post precise test results later.

Just happened upon this issue. Have you guys considered using WriteBatch for Badger? It can deal with txn sizes and automatically commit them as needed.

@manishrjain Thanks for a suggestion, we will definitely consider that API :)
The problem is not with Badger specifically, as I mentioned. It's a problem with Cayley's legacy write API which tries to be suitable both for batch uploads and regular transactions. The new importer can take advantage of a WriteBatch in Badger directly and it work really well so far!

For info on my system

the orginial data "30kmovie-SampleData.nq" is 26,8 Mo
-When imported  indexes.bolt is 154Mo

5 X the size of the original data seems a little big.

@hubyhuby Note that Bolt pre-allocates some space, so not all of it is actually used by the database.

Just a follow up, but does now work to import freebase on Cayley?


After upgrade, lost the default database on connection settings

After migrated to 6.1.5 lost the default database definition for all connections...
https://i.postimg.cc/FRDJ53DL/screenshot-547.png

Can't reproduce. What database types do you use?

For postgres the config was preserved, for mysql/mariadb lost

I'm quite sure that this bug was fixed in 6.1.4. Maybe you noticed that only after 6.1.5 upgrade?
In order to restore lost settings just delete DBeaverData folder and perform migration again.


Add -DUSE_BTF=ON cmake configuration parameter on CI

DOPS-292
Description of the Change
add -DUSE_BTF=ON for cmake configuration on CI
Benefits
It always false,  true if  build type "Before merge to trunk"
Possible Drawbacks

Usage Examples or Tests [optional]

Alternate Designs [optional]

Currently  build fails due to error :
CMake Error at /usr/local/Cellar/cmake/3.11.4/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):

  Could NOT find PythonInterp: Found unsuitable version "1.4", but required
  is at least "3.5" (found /Users/jenkins/.pyenv/shims/python3.5)

But looks like it work fine on mac-mcst-1,
@bakhtin, can you please add pysha3 to rest of mac

@bakhtin mac-mcst-1 and mac-mcst-2 works fine, but problem with mac-mcst-3

mac-mcst-3 now works


Exit HYP mode on Raspberry Pi

I've tried using TamaGo on Raspberry Pi 2 (v1.1)
The Pi firmware initializes in HYP mode by default.  Being in HYP mode breaks set_exc_stack, so this change borrows the technique from the Linux kernel to use ERET to exit from HYP mode early in boot.
The code conditionally exits HYP mode, so should be safe on systems that do not initialize in HYP mode.

Thanks, I've changed to use Go asm where possible.
I believe the breakage in set_exc_stack is because until HYP mode is exited, attempts to set processor mode using msr CPSR_c, 0xXXXXX fail to actually change the processor mode.  Reading CPSR after the instruction msr CPSR_c, 0xdf later in the function, for example, shows that the mode is still 0x1a.
When set_exc_stack tries to change between the different modes to initialize the stack pointers, I guess it's actually stomping on the current stack pointer since the mode change fails to occur?
The HYP mode oddity on the Pi's is fairly well known, see:
https://www.raspberrypi.org/forums/viewtopic.php?t=187227
https://stackoverflow.com/questions/45107469/change-arm-mode-to-system-mode-cpsr-on-armv8-a
https://stackoverflow.com/questions/40105507/spsr-is-changing-modes-but-not-able-to-change-the-cpsr-mode-in-armv7

Merged, thanks!


Add Word Scramble Game

Add Word Scramble Game where the user will be given an hint and the answer will be present in scrambled manner ! There will be a timer within which if the user answers it correctly , then the user wins or else looses ! Please assign me under JWOC 2024.

@SohanRC Go for it!


Add noTemplateCurlyInString lint rule

Add no template curly in string for #94

Thought on auto-fixing this to a template string?

Autofix for this would be difficult since you need to parse a substring. We would need to support offset positions in js-parser so that syntax errors would align, and figure out some UX if the interpolation is actually invalid.

Thank you!


Don't crash when starting resolution if activity is null

I'm getting a few of those crashes in production. Not sure how to repro and why activity is null in this case but this seems better than crashing.

My app has encountered this same exact problems, and this seems like a great solution. I hope it gets merged !


tty hosed in bash

# After running the uutils/coreutils cargo test under bash/linux.
 stty --all

speed 38400 baud; rows 30; columns 175; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = <undef>; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

# After  'reset' or 'stty sane'
stty --all
speed 38400 baud; rows 30; columns 175; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

The lnext is undefined after cargo test. Both icanon and echo add dashes in front. macOS has similar behavior setting the icanon and echo dashes.  Which test is doing this?

The culprit was test_tail::test_follow_with_pid. Muted in https://github.com/uutils/coreutils/pull/1724 .

Closing this ticket as I guess it was fixed in https://github.com/uutils/coreutils/pull/1724


Update in the max number of segments for IB

Update in the max number of segments for IB

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@chrfox PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

Rob as FYI

Thank you!
Anwar Ali | PM @ TEAMS | LinkedInhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fanwarali&data=04|01|Ali.Anwar%40microsoft.com|61a24ee754db4b1493e408d6b4dc7b41|72f988bf86f141af91ab2d7cd011db47|1|0|636895256392090042|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|-1&sdata=KpQ4z1jxZOc8s8IWXAYS3oVAbqKpT94E%2BzEB%2FLypv2c%3D&reserved=0
IP, Security and Compliance Team
From: Manuela Scanu @.>
Sent: Wednesday, March 17, 2021 5:37 PM
To: MicrosoftDocs/OfficeDocs-SkypeForBusiness @.>
Cc: Anwar Ali @.>; Author @.>
Subject: Re: [MicrosoftDocs/OfficeDocs-SkypeForBusiness] Update in the max number of segments for IB (#6866)
@chrfoxhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchrfox&data=04|01|Anwar.Ali%40microsoft.com|87c6dee2243a4834d57308d8e9a5fe08|72f988bf86f141af91ab2d7cd011db47|1|0|637516246455628497|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=kXT80P9mWz86xh0L%2BlvHILxmsPQb5aqZAwUq%2FGQLyAg%3D&reserved=0 PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2FOfficeDocs-SkypeForBusiness%2Fpull%2F6866%23issuecomment-801530799&data=04|01|Anwar.Ali%40microsoft.com|87c6dee2243a4834d57308d8e9a5fe08|72f988bf86f141af91ab2d7cd011db47|1|0|637516246455628497|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=qZrCVz7%2BJPZ8uXpJsH7soxFtEKj%2F8zCfoB4vyNxoUUc%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACEEVX6TIYCESGJ25LIFNKTTEFDMDANCNFSM4ZHVEVYA&data=04|01|Anwar.Ali%40microsoft.com|87c6dee2243a4834d57308d8e9a5fe08|72f988bf86f141af91ab2d7cd011db47|1|0|637516246455638441|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=lcOfW%2FmpNaYJ02XkwQLG7IsERiepKPm%2F2rmDwMO9%2BoE%3D&reserved=0.

@anwara-ms - Instead of managing the conflict in here, I'm going to close this PR and make the change on private repo and publish. I'll also reach out to you today about how we should manage updates moving forward. Thanks!


React Key Error in fields/plugins/BlocksFieldPlugin/BlockSelectorBig.tsx in @tinacms/toolkit

Description
There is a React key error on line 168 in this component
Steps to reproduce
Run the editor in contextual editing mode, open console
Expected result
It shouldn't be there
Actual result
It is there (I tried to open a PR, but I kept getting a 403, even after following the guide in CONTRIBUTING)

Hey @skyfriends, thanks for reporting. What's the actual behavior that you're seeing from this issue?
Just a performance impact from the re-render? Or are you seeing an actual error?

Just the performance impact.  Apologies on the delayed response.


Enable-WriteCore-feature-for-cosmosdbforpostgresql

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.CosmosDBForPostgreSql


feat(bridge-ui): allow ERC20 and Ether to be transferred in one message/transaction.

Describe the feature request
The bridge contracts support such a feature, it will be cool that users can do this to reduce cost. A similar feature may also be possible for NFTs.
This feature is a low priority.
Describe alternatives you've considered
No response
Additional context
No response

You mean users can bridge multiple token/NFT in one transaction?
In this case, we can add a simple + button next to the token that we wish to transfer, and when the user clicks on it, another row is added.
These are the swap samples that can be changed for the bridge.
Single

Multi

Not really. You can bridge some Ether alone with another ERC20 or NFT. But you cannot bridge more than one ERC20 or NFT in one transaction. Ether is special.

I review the code of EtherVault and ERC20Vault, it seems that the contracts don't support such a feature yet -- EtherVault and ERC20Vault needs to merge into one Vault to achieve my goal of bridge multiple assets via one tx. Lets demote this feature.

Is it possible to bridge multi-tokens by swapping them into a stablecoin, then bridging them, and swapping back into the multi-tokens on destination chain?

The default bridge from Taiko shall be as simple as possible not to compete with third party bridges who may offer such features.

I'm closing this issue for now, please feel free to reopen if you hope to continue the conversation.


Cline Extension Fails to Activate in Remote SSH Environment on VSCodium (and probably also on VSCode)

Which API Provider are you using?
OpenRouter
Which Model are you using?
Claude 3.5 Sonnet
What happened?
The Cline extension fails to activate when used in a remote SSH environment, while working correctly in the local VSCodium installation.
Steps to reproduce

Connect to remote environment using Open Remote SSH Extension (in VSCode this is Microsoft Remote - SSH)
Click on the Cline extension icon in the sidebar
Extension shows loading icon but fails to activate

Relevant API REQUEST output
No response
Additional context
Observed Behavior:

Extension fails to activate
Error logged in "Extension Host (Remote)":

[error] ReferenceError: ReadableStream is not defined
    at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:502:14488

Cline is missing in the remote OUTPUT section dropdown, indicating that the issue appears before it the extension is registered. All other extension are activated.

For Comparison, this is the local OUTPUT section for Cline:

Additional error in "Remote Tunnel Service" (that shows also on the local instance where Cline works - so this is probably unrelated and could indicate strict sshd_config):
[error] Missing 'tunnelApplicationConfig' or 'tunnelApplicationName' in product.json. Remote tunneling is not available.

Expected Behavior:

Cline extension should activate and function in remote environment as it does locally
Extension should appear in Output section selection
No ReadableStream-related errors

Additional Notes:

The extension activates successfully in local environment
Other extensions are working in the remote environment

This is the full error log from the "Extension Host (Remote)" Secion in OUTPUT
[info] ExtensionService#_doActivateExtension saoudrizwan.claude-dev, startup: false, activationEvent: 'onView:claude-dev.SidebarProvider'
[error] Activating extension saoudrizwan.claude-dev failed due to an error:
[error] ReferenceError: ReadableStream is not defined
at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:502:14488
at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:1:357
at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:502:27736
at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:1:357
at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:503:6108
at /home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:1:357
at Object.<anonymous> (/home/[user]/.vscodium-server/extensions/saoudrizwan.claude-dev-2.1.6-universal/dist/extension.js:920:180062)
at Module._compile (node:internal/modules/cjs/loader:1198:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10)
at Module.load (node:internal/modules/cjs/loader:1076:32)
at Function.Module._load (node:internal/modules/cjs/loader:911:12)
at Function.e._load (file:///home/[user]/.vscodium-server/bin/[id]/out/vs/workbench/api/node/extensionHostProcess.js:174:12010)
at Function.t._load (file:///home/[user]/.vscodium-server/bin/[id]/out/vs/workbench/api/node/extensionHostProcess.js:166:28448)
at Function.i._load (file:///home/[user]/.vscodium-server/bin/[id]/out/vs/workbench/api/node/extensionHostProcess.js:158:5023)
at Module.require (node:internal/modules/cjs/loader:1100:19)
at require (node:internal/modules/cjs/helpers:119:18)
at VB._loadCommonJSModule (file:///home/[user]/.vscodium-server/bin/[id]
/out/vs/workbench/api/node/extensionHostProcess.js:166:30081)
at async Promise.all (index 0)

Related issues:
#430
#807
#587

Thank you for sharing all the details, cline runs into issues in remote–I'll have to dig into the vs code docs and figure out what's going on but if anyone has any pointers here I'd appreciate them.

I not yet dug deep into this. A vague guess is, that the extension may require a newer version of Node.js that includes ReadableStream as part of the Web Streams API. Maybe a polyfill for ReadableStream in environments where it's not natively available could resolve the issue? Like i mentioned, its just a guess. VSCodium server environment may not have web APIs fully configured that would normally be available in a browser context.

@spechtx @saoudrizwan is there a workaround to install newer node.js?

opened my vscode developer tools in romote env and I saw some proxy error in the console. guess maybe cline in remote env want to use the local env proxy settings.
after created a new config file for remote project and set http.proxy to null.  everythings works for me .

Just in case it helps: Cline is working perfectly for me using Vscode locally but connected to a Github Codespace. (which is essentially a Ubuntu linux virtual machine via SSH)

Cline works fine for me when i use ssh to replit - using VS Code


Security: use latest version of alpine 3.x

This fixes 3 critical and 5 high severity issues in expat that's part of alpine 3.

Sorry, this got lost in my mailbox. Merging now.


Oxidize NLocal & family

Summary
Part of #13046: create the n_local function and port the internals to Rust. This will include other parts of the NLocal family, such as TwoLocal, EfficientSU2, RealAmplitudes etc. EvolvedOperatorAnsatz is potentially a bit more involved and might be done in a follow-up.
Details and comments
The new code is particularly fast when dealing with gates we already have in Rust and that don't need any special re-parameterization. In this case:

the new code is ~22x faster for 100 qubits, full entanglement and 10 reps
num qubits: 10, speedup: 9.075
main: 0.005 +- 0.004
this: 0.001 +- 0.000

num qubits: 50, speedup: 18.138
main: 0.063 +- 0.014
this: 0.003 +- 0.003

num qubits: 100, speedup: 22.011
main: 0.251 +- 0.034
this: 0.011 +- 0.007

num qubits: 200, speedup: 26.829
main: 0.957 +- 0.034
this: 0.036 +- 0.010

But if custom gates or special parameterizations are used (e.g. RXGate(x + 3 * y)) we need to go back to Python space to correctly handle the parameter logic. This slows down the code and in this case:

the new code is ~3.5x faster for 100 qubits, linear entanglement (full took too long) and 10 reps
num qubits: 10, speedup: 4.594
main: 0.027 +- 0.006
this: 0.006 +- 0.000

num qubits: 50, speedup: 3.947
main: 0.162 +- 0.006
this: 0.041 +- 0.011

num qubits: 100, speedup: 3.666
main: 0.366 +- 0.031
this: 0.100 +- 0.019

To do

[x] Improve docstrings
[x] Make the entanglement handling rust-side a bit better to understand instead of a 4-times nested vec
[ ] Use n_local in NLocal (i.e. fast path for Python code) This might not be possible since NLocal works with QuantumCircuits as blocks, but n_local needs gates. Functionally it'd be the same but the circuits are nested differently, which is not backward compatible. We could add a fast-path in case the inputs are not circuits but gates.
[x] Add the family members, like efficient_su2 etc.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

338 of 427 (79.16%)  changed or added relevant lines in 5 files are covered.
10 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.04%) to 88.612%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/library/n_local/n_local.py
42
86
48.84%

crates/accelerate/src/circuit_library/n_local.rs
291
336
86.61%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
4
91.98%

crates/qasm2/src/parse.rs
6
97.15%

Totals

Change from base Build<PHONE_NUMBER>5:
-0.04%

Covered Lines:
73453

Relevant Lines:
82893

💛  - Coveralls

069f45c added tests for the flagged lines in Coveralls (for the new functions, not for the existing classes), so I think we should have the 100% on that 🙂


docs(examples): Added Auth.js 5 example app

This example shows how to use an Arcjet rate limit with a user ID from Auth.js authentication with Next.js. It's a copy of the Next.js demo, but with Arcjet added.

I realized this and the other example weren't added to CI

@blaine-arcjet builds are now working.


added events to new directory

Moved events to a new directory, renamed the event 'ICS20Transfer' to 'ICS20TokenTransfer' as it was colliding with the 'ICS20Transfer.sol' contract. ran unit tests as well.

Hey @gjermundgaraba should I lint the code and update the PR? Also, I don't know golang so didn't test the e2e directory.
P.S: I just remembered that the ICS20Transfer.json should be updated with the new event name.

Hey @gjermundgaraba, in the latest commit I've ran linter and updated the ABI for ICS20Transfer.json. Wasn't able to test the e2e directory code as I'm not comfortable with golang.

Hey @DrParadox05. Gjermund is on holidays now until end of next week, but I will review the PR and help you to (hopefully) get it merged.

The e2e tests run locally fine for me, so I think the failures are due to the fact that they are running from a fork and doesn't have access to the secrets. We will have to figure out a way to fix that, but for now I don't think we need to block the PR on that.

Hey @sangier I agree. What should I do then? because I was told to move them in a different directory. We can close the issue and PR in that case.

Thanks for the feedback @sangier. We could wait for @srdtrk or @gjermundgaraba feedback as well, but if keeping them where they are right now is the general best practices, then I am happy to follow that and close the issue and the PR.

I mean, I see a value in dividing events and to specify them in specific folder when the project is really complex and, specifically, when you have events that can be generated by multiple distinct contracts (that have distinct interfaces). In that case you would use this approach to avoid code duplications, extending the contract interface with the eventInterface. In our concrete case, I don't see too much value in doing it.

Then let's close the PR and the issue. Thank you for the time you spent on the work, @DrParadox05. Sorry that we will not merge it for now.


Fixed template lookup logic in ObjectNotesView, ObjectDynamicGroupsVi…

…ew and ObjectChangeLogView.

Closes: #2509
What's Changed

TODO

[ ] Explanation of Change(s)
[ ] Attached Screenshots, Payload Example
[ ] Unit, Integration Tests
[ ] Documentation Updates (when adding/changing features)
[ ] Example Plugin Updates (when adding/changing features)
[ ] Outline Remaining Work, Constraints from Design

@HanlinMiao Just to confirm, is the issue that plugins are trying to use the new template naming convention even though it was most heavily used in NautobotUIViewSet?

Yeah, the new plugins are trying to follow the new naming conventions but we have to incoporate both template lookup logic so as not to break some of the existing plugins.

👍 I know we added backwards compatibility templates our side to address this fact but good to know.


Adding instanceName: 'SQLEXPRESS'

Adding instanceName: 'SQLEXPRESS' letting users of SQLEXPRESS connect their databases

Thanks for the contribution @ArturoAguileraV ! There is a bit more to do in order to wire this property all the way through the application. For example, you'll need to add it to the actual SQL connection here: https://github.com/plotly/plotly-database-connector/blob/master/backend/persistent/datastores/Sql.js#L41-L43.
Let us know if you need any help navigating the codebase, happy to help.

Closing due to inactivity. Feel free to reopen if you'd like to take another stab at this!


Update license year in README.md

Integration failed due to Github time out. Passed in Gitlab
Static test failures:

Min Phantom Version


ENH: Visualizers should not return anything

Visualizers should only return None (Python implicit return value when not otherwise specified). This adds a quick check when calling the visualizer function, and if a value other than None is returned it raises a ValueError exception.
Questions:

Thoughts on the verbiage for the exception?

Thanks!

@thermokarst done reviewing!

Lucky number 7. Thanks!

@jairideout: squashed and ready to roll.

Looks good, thanks @thermokarst!


Add project short description to StaffBot requests

Coverage increased (+0.003%) to 91.501% when pulling f5204656e01aa718d4bb394d92c65ef4515f4b9a on project-shortdescription into cd40b555b5632a496e6bd88fb7378da8c103a99b on master.

one question, otherwise lgtm

Perfect!  Removed short after offline discussion.

Coverage increased (+0.003%) to 91.501% when pulling 300c887e7ec516432471c8133ed30dce84c6eaf2 on project-shortdescription into cd40b555b5632a496e6bd88fb7378da8c103a99b on master.


iScroll events onScroll not work

  <ReactIScroll iScroll={iScroll} options={{mouseWheel: true}} onScroll={function(){console.log(1)}} >
    <div>
      ...
    </div>
  </ReactIScroll>

the onScroll callback function not work,

Hi, do you have iscroll probe version? It is only one with onacroll support

you need to define the probe type you want to use in the options. Had same issue and only that worked for me.
so in your example:
 <ReactIScroll iScroll={iScroll} options={{mouseWheel: true, probeType: 1}} onScroll={function(){console.log(1)}} >     <div>       ...     </div>   </ReactIScroll>
@schovi
would be nice if there is an possibilty to tell iscroll to use at least type 1 if there is the probe version passed in react component?!

@Inoir It didn't work!

@Inoir updated README with this info https://github.com/schovi/react-iscroll/blob/master/README.md#faqs
Will think if I can do the checking.


cherry-pick(build): update go version to 1.14.7 (#476)

move build files to separate directory
update go version to 1.14.7 due to vulnerability in earlier versions (CVE-2020-16845)

cherry-pick #476
Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>

Codecov Report

Merging #483 into v0.8.x will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           v0.8.x     #483   +/-   ##
=======================================
  Coverage   40.53%   40.53%
=======================================
  Files          71       71
  Lines        3488     3488
=======================================
  Hits         1414     1414
  Misses       1966     1966
  Partials      108      108

Continue to review full report at Codecov.

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


PBR materials: Add ambient occlusion color to debug mode

See https://forum.babylonjs.com/t/debug-occlusion-channel-in-orm-texture-pbrmaterial/49245

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/14937/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14937/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14937/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/14937/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/14937/merge
https://gui.babylonjs.com/?snapshot=refs/pull/14937/merge
https://nme.babylonjs.com/?snapshot=refs/pull/14937/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/14937/merge#BCU1XR#0

WebGL2 visualization test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14937/merge/testResults/webgl2playwright/index.html

Visualization tests for WebGPU (Experimental)
Important - these might fail sporadically. This is an optional test.
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14937/merge/testResults/webgpuplaywright/index.html


Instead of SEARCH/REPLACE, just output the new file

Issue
Just an idea and I could be missing something, but is there a reason why smaller files wouldn't just have only the updated new file content requested in the output instead of doing a SEARCH/REPLACE which spends a lot more tokens?
If the necessary changes require changing a large of a file, you can just request a full rewrite to be the output instead.
I've mostly been working this way when using 3.5 Sonnet outside of Aider and it seems to work pretty well.
Version and model info
No response

Thanks for trying aider and filing this issue.
You could try using --edit-format whole for this.

Thanks for trying aider and filing this issue.
You could try using --edit-format whole for this.

I should've read the docs better!
What do you think about having the option to let Sonnet choose which format to use depending on how much needs to be changed?

I have another idea. What if there was an option for the model to provide its response in a human-readable format, describing the necessary code changes instead of using the diff format? Then, a more cost-effective model, such as Sonnet Haiku, could generate the diff from this description. Alternatively, we could fine-tune a model specifically for this purpose. What do you think?

I'm going to close this issue for now, but feel free to add a comment here and I will re-open or file a new issue any time.


glide.yaml: set missing version pins in glide.yaml

Running make vendor on a clean checkout produces a diff. With dependencies pinned in glide.yaml, there should only be a diff when a dependency is explicitly updated.

Add missing version pins to glide.yaml
glide.yaml lists github.com/golang/mock as a testImport. However, glide is treating it as a regular dependency since it is used in source pkg/k8sutil/mocks/node_interface_mock.go. List it as a dependency so that it can be pinned
Set the k8s.io/kubernetes version explicitly, based on glide.lock

No changes to vendor contents, but now running make vendor produces no diff.

@dghubble those comments should have been in the commit comment instead of, or in addition to, the github comment for git log posterity.
Since the mocks package is only important from _test files, glide really should be fine with it, but if it's not then oh well.


[AutoDiff upstream] Add SIL transpose function type calculation.

Add SILFunctionType::getAutoDiffTransposeFunctionType.
It computes the transpose SILFucntionType for an original SILFunctionType, given:

Linearity parameter indices
Transpose function generic signature (optional)
Other auxiliary parameters

Add doc comments explaining typing rules, preconditions, and other details.
Add isTranspose flag to autodiff::getConstrainedDerivativeGenericSignature.
Partially resolves TF-1125.
Unblocks TF-1141: upstream differentiability_witness_function instruction.
Tests coming with TF-1141.

I'll cherry-pick these changes to tensorflow branch soon to verify there aren't breakages.

@swift-ci Please smoke test


castsByParent with reverse parameter fails on popular channels

What is the bug?
When using certain channels as parent for castsByParent, the data lookup errors only when reverse=1.
ie.
  const resp = await fetch(
    `${API_URL}/v1/castsByParent?pageSize=1&reverse=1&url=https://warpcast.com/~/channel/${channel}`,
    {
      method: "GET",
    }
  );

Will succeed on some channels like bikes and fail on ones like degen.
Error returned is here:
{
  code: 2,
  details: 'db.internal_error/could not get message with key: [ ... ]',
  metadata: { errcode: [ null ] }
}

https://github.com/farcasterxyz/hub-monorepo/blob/26ced763673da456f74c041ce7084e2813c83720/apps/hubble/src/addon/src/store/message.rs#L312
How can it be reproduced? (optional)
Try calling castsbyparent (api or at the rpc level) with url equal to the degen channel for instance, and set reverse to 1.
Additional context (optional)
Perhaps related to channel size?
Ty for taking a look 🙇 🟣

👀

Hello, you're not providing the required parameters for the castsbyparent endpoint, parent it could be castid object includes fid of the channel I think & hash of cast, or provide parenturl string instead castid
refer to this: https://docs.farcaster.xyz/reference/hubble/grpcapi/casts & this: https://github.com/farcasterxyz/hub-monorepo/blob/main/packages/hub-nodejs/docs/Client.md#getcastsbyparent & this: https://docs.farcaster.xyz/developers/guides/querying/fetch-channel-casts
not works with degen because there are no replies to https://degen.tips
I tested it & it works:

If you would like to get casts by channel you should use pinata.cloud api refer to this: https://docs.pinata.cloud/farcaster/farcaster-api/endpoint/casts & add channel, reverse parameters
I tested it & it works

I'm waiting you to pay the bounty: 0xAa6659efc2165d8ff121C616d9F1039EC1781f12 thanks

@BenraouaneSoufiane
The error is that the lookup fails with reverse order only on certain channels. For example, the following code works:
  const channelName = "bikes";
  const parentUrl = `https://warpcast.com/~/channel/${channelName}`;

  const result = await client.getCastsByParent({
    parentUrl,
    pageSize: 2,
    reverse: true,
  });

...but when changing the channel to something like degen it fails with the error codes above. This should be supported with the hubble hub alone, not requiring external indices like Pinata's. It may be due to size, or perhaps something else, seemingly erroring at the db call when the client is making the query.

Gooday, thank you for your fast reply, as per my check the degen channel does not have the parentUrl you provided, the right parentUrl for degen is: chain://eip155:7777777/erc721:0x5d6a07d07354f8793d1ca06280c4adf04767ad7e , so it works using only the hubble hub alone, you need to enter the right parentUrl of the channel, to get it use warpcast api & then pass it to the request query
import { getSSLHubRpcClient, hexStringToBytes } from '@farcaster/hub-nodejs';
const hubRpcEndpoint = 'nemes.farcaster.xyz:2283';
const client = getSSLHubRpcClient(hubRpcEndpoint);
let parentUrl='';
client.$.waitForReady(Date.now() + 5000, async (e) => {
    if (e) {
        console.error(`Failed to connect to ${hubRpcEndpoint}:`, e);
       process.exit(1);
    } else {
        console.log(`Connected to ${hubRpcEndpoint}`);
        // Get parentUrl for specific channel
        fetch('https://api.warpcast.com/v1/channel?channelId=degen', {method: 'GET'})
        .then(response => response.json())
        .then(async(response) => {
          parentUrl = response.result.channel.url;
          console.log(parentUrl);
          // Get casts
          const castsResult = await client.getCastsByParent({ parentUrl: parentUrl });

          castsResult.map((casts) => console.log(casts.messages));
          client.close();
       })
       .catch(err => console.error(err));
   }
});

I'm waiting you to pay: 0xAa6659efc2165d8ff121C616d9F1039EC1781f12
Best regards

@BenraouaneSoufiane brilliant, I wasn't using the correct parentUrl, and didn't see that in the warpcast API. It is interesting that using the channel URL as parentUrl does work for some queries, which is why I ended up lost.
Docs for anyone else looking: https://docs.farcaster.xyz/reference/warpcast/api
Bounty sent: https://basescan.org/tx/0x20b443d955eb1963583be4b6c86643719f1c90729eec44de9890f8117b19236b

Thanks @nicovalencia , awesome challenge!


Create dataset loader for TALPCo

NusaCatalogue: https://indonlp.github.io/nusa-catalogue/card.html?talpco

Dataset
talpco

Description
The TUFS Asian Language Parallel Corpus (TALPCo) is an open parallel corpus consisting of Japanese sentences and their translations into Korean, Burmese (Myanmar; the official language of the Republic of the Union of Myanmar), Malay (the national language of Malaysia, Singapore and Brunei), Indonesian, Thai, Vietnamese and English

License
CC-BY 4.0

#self-assign


Announcement rework

Reworked the backend announcement classes and changed how they're stored to make it less complex
Switched to use snake_case to conform with python standards
Reworked the UI to function with the new backend changes
Added a Dockerfile

Add a .gitignore to ignore __pycache__


[Bug]: PythonDataframeWordCount broken for Beam 2.42.0 release with default expansion service

What happened?
I'm getting following error when trying to run PythonDataframeWordCount according to instructions here.
    return transform.to_runner_api(
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/transforms/ptransform.py", line 745, in to_runner_api
    urn, typed_param = self.to_runner_api_parameter(context, **extra_kwargs)  # type: ignore[call-arg]
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/transforms/core.py", line 1674, in to_runner_api_parameter
    do_fn=self._do_fn_info().to_runner_api(context),
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/transforms/core.py", line 1621, in _do_fn_info
    return DoFnInfo.create(self.fn, self.args, self.kwargs)
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/transforms/core.py", line 1770, in create
    return PickledDoFnInfo(cls._pickled_do_fn_info(fn, args, kwargs))
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/transforms/core.py", line 1784, in _pickled_do_fn_info
    return pickler.dumps((fn, args, kwargs, None, None))
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/internal/pickler.py", line 44, in dumps
    return desired_pickle_lib.dumps(
  File "/Users/chamikara/code/beam_checkout_2/beam/sdks/python/apache_beam/internal/cloudpickle_pickler.py", line 64, in dumps
    pickler.dump(o)
  File "/Users/chamikara/code/beam_checkout_2/venv/beam_venv_3/lib/python3.8/site-packages/cloudpickle/cloudpickle_fast.py", line 632, in dump
    return Pickler.dump(self, obj)
TypeError: cannot pickle 'google.protobuf.pyext._message.MessageDescriptor' object

This seems to be due to the "--pickle_library=cloudpickle" option which was added here: https://github.com/apache/beam/pull/23111
https://github.com/apache/beam/issues/22714 might be related.
Issue Priority
Priority: 1
Issue Component
Component: cross-language

FYI, I was getting the similar error while implementing wrapper in Go SDK. After skipping the flag, it passes successfully.

Cherry-pick: https://github.com/apache/beam/pull/23798


[Bug Report] Directive can't get value of element when value is setted with Axios (Promise)

Element UI version
2.8.2
OS/Browsers version
Linux Mint / Chrome 74
Vue version
2.6.10
Reproduction Link
https://jsfiddle.net/Denuro/4wxv80fg/11/
Steps to reproduce
No steps are necessary, error occurs on create, and the problem is outputted to console.
First input (el-input) v-model variable is beeing setted in axios request, and has the problem.
Second input (el-input) v-model variable is beeing setted outside of axios request, during create, and there's no problem.
Third input (html input) v-model variable is beeing seeted in axios request, and there's no problem.
What is Expected?
When axios request sets the el-input v-model variable, the directive should be able to get the data in the value attribute of the el-input element, just like the input element.
What is actually happening?
When axios request set the v-model variable, the el-input value element is empty on creation.

first,recommand that you can use directie options to  create a  directive. because the lifecycle of directive,you can see CustomDirective,especially update and componentUpdated. in your reproduction,use componentUpdated.after that wrapper all business functions to Vue.nextTick. You will get correct value.
example:
Vue.directive('test',{
  componentUpdated(el.binding,vnode,oldVnode){
    Vue.nextTick(()=>{
         // your code
    })
  }
})

I was using the Function Shorthand method of creating a directive just for testing purpose, as it's faster, and to test if the same problem occurs with update (witch it doesn't).
That beeing said, using the Vue.nextTick function to get the value of the input worked!
I did not know about that helper beforehand, so, thank you @qingdengyue, that solved it!


Comment not including the correct environment URL

A recent site resulted in the following GitHub comment being created:

It appears the "Environment Url" $name property from the EnvironmentUrlBuilder is being passed in ratehr than the actual url? I haven't had time to dig into the code yet but will submit a PR if I can identify the problem.

This is interesting. The environment url's value comes from the (Forge site name)[https://forge.laravel.com/api-documentation#get-site] which is expected to be a domain name.
By any chance, does it still happening for you? As it works correctly for me already.

Today I noticed an inconsistency with the database URL name on the PR comment. Currently, it's set as "DatabaseBuilder Url" instead of "Database Url," which is incorrect.

Fixed the DatabaseBuilder Url name.
I'm closing this issue since the Environment Url looks right. Feel free to comment or open a new issue if it's still wrong.

Hi, yes I’ve never had this happen again, very odd. The only issue I’ve noticed is the URL seems to use http:// even when SSL has been enabled, but I haven’t checked that recently so may open a separate issue.


sync from upstream

Advantage 360 Pro PR template
What's changed:
Why has this change been implemented:
What (if any) actions must a user take after this change:

Sorry, I made a mistake on the target branch.


Recorder Console - GetAddrFailed

Hey all.  Using the following command:
python recorder_console.py --dev_portal_address <IP_ADDRESS> --dev_portal_username dandandan --dev_portal_password dandandan --workspace_path output
Returns error
urllib.error.URLError: <urlopen error [Errno 11001] getaddrinfo failed>
Other listed usage does not specify using the dev portal address (as per the documentation here) suggests using the below commands:
python StreamRecorderConverter/recorder_console.py --workspace_path <output_folder>  --dev_portal_username <user> --dev_portal_password <password>
However, this returns an issue - target machine actively refused the request.  Any insights here?

Resolved this myself:
In recorder_console.py I hardcoded the URL to the device portal URL (In my case, "https://<IP_ADDRESS>".  I then ran the second usage scenario (path, output, username, password) - and it worked well!

You mean the self.url right? and then "https://ip".format(address)
Now the error changes to
urllib.error.URLError: <urlopen error [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond>
parser.add_argument("--dev_portal_address", default="<IP_ADDRESS>:10080",
                    help="The IP address for the HoloLens Device Portal")

    self.url = "https://<IP_ADDRESS>" #.format(address) # "http://{}".format(address)

That (inserting the IP) solved it partially. Thereafter I got an SSL Certification error.
But if you just connect it (HL2) via usb-c, it works like a charm. I no this is a workaround, but I could not fix the certification error and happy it's working. For HL2 and recorder_console, this should suffice.


Separate exception for absent return values

When parsing method responses, if a return value is absent, instead of returning TypeError, a more specific exception should be returned.

Related #76