2021-09-10 [22:26:27.0032] it looks like in node v16.9, which has a newer v8, `'cause' in Error.prototype` returns `true`, but https://tc39.es/proposal-error-cause/ dictates that should return `false` (it's only an own property, not on the prototype). cc shu filed https://bugs.chromium.org/p/v8/issues/detail?id=12210 - oops, looks like https://bugs.chromium.org/p/v8/issues/detail?id=12006 already exists [22:27:08.0441] * it looks like in node v16.9, which has a newer v8, `'cause' in Error.prototype` returns `true`, but https://tc39.es/proposal-error-cause/ dictates that should return `false`. cc shu [22:28:50.0289] * it looks like in node v16.9, which has a newer v8, `'cause' in Error.prototype` returns `true`, but https://tc39.es/proposal-error-cause/ dictates that should return `false` (it's only an own property, not on the prototype). cc shu [22:30:16.0927] * it looks like in node v16.9, which has a newer v8, `'cause' in Error.prototype` returns `true`, but https://tc39.es/proposal-error-cause/ dictates that should return `false` (it's only an own property, not on the prototype). cc shu filed https://bugs.chromium.org/p/v8/issues/detail?id=12210 [22:38:39.0568] * it looks like in node v16.9, which has a newer v8, `'cause' in Error.prototype` returns `true`, but https://tc39.es/proposal-error-cause/ dictates that should return `false` (it's only an own property, not on the prototype). cc shu filed https://bugs.chromium.org/p/v8/issues/detail?id=12210 - oops, looks like https://bugs.chromium.org/p/v8/issues/detail?id=12006 already exists [07:26:26.0259] answered in the issue 2021-09-23 [23:53:24.0738] I guess it's really not that bad [23:53:25.0419] https://bugs.webkit.org/show_bug.cgi?id=230668 [10:36:40.0051] ...and landed, fwiw [11:31:58.0559] V8 fix landed as well https://chromium-review.googlesource.com/c/v8/v8/+/3176506 [11:44:44.0228] > <@shuyuguo:matrix.org> V8 fix landed as well https://chromium-review.googlesource.com/c/v8/v8/+/3176506 oh yay I'm glad the solution is similar 2021-09-24 [07:16:43.0962] lol engine262 has this same bug [07:43:15.0062] perhaps it is the spec that should change to simply allow this to be a runtime error! [07:46:12.0400] halt and catch fire 2021-09-28 [18:00:56.0216] does anyone have a clever trick for hashing ropes? I was looking for an easy-to-compute associative non-commutative operation on int32 for combining hash values (so you can efficiently derive the hash of the rope from the hash of its parts) but didn't have that much luck. things I found: - c(x, y) = x + y when x even, x - y when x odd [which suffers from being commutative 1/4 of the time, when both are even, and also has a lot of collisions between things of the form "x" and "xyy"] - the examples in this page, all of which are pretty complex: https://alexknvl.com/posts/monoidal-hashing.html [18:01:20.0363] I was expecting there to be a known answer to this but I couldn't find one; I'm hoping there's something clever engines are doing here [08:48:18.0998] i'm not sure we even hash ropes [08:48:49.0955] what is the use case where you need to hash a rope but not flatten it? [08:49:05.0284] "hash a rope" has got to be slang for something with drugs [08:59:16.0581] in my case, I'm using it as a key in a hash table [09:16:02.0380] i'd recommend just flattening in that case too 2021-09-30 [08:09:32.0671] instead of combining the hashes of each part, you could run the normal hashing algo over the substrings as if they were flat, but without actually flattening it