06:52
<annevk>
MikeSmith: if https://github.com/whatwg/html/pull/5882 looks okay to you we can merge that and then rebase the other PR and land that too
06:54
<MikeSmith>
annevk: OK
06:54
<MikeSmith>
annevk: and thanks yeah, I had been planning to deal with that one case after merging this one first then rebasing
06:54
<MikeSmith>
and thanks also for catching and fixing the ID cases; I should have considered that
06:58
<annevk>
JakeA: https://github.com/whatwg/dom/pull/887
06:59
<annevk>
MikeSmith: are you rebasing? I'm happy to do it
06:59
<MikeSmith>
annevk: I’m rebasing it now
06:59
<annevk>
I see :-)
07:04
<MikeSmith>
annevk: OK, https://github.com/whatwg/html/pull/5881 is all green, if you could go ahead and push the button
10:40
<annevk>
andreubotella: so decode blocking in parallel doesn't so bad to me, but I'll grant you that it's not an ideal setup
10:40
<annevk>
seem so*
10:53
<andreubotella>
annevk: right, since at that point the behavior of the different stages isn't observable from the main thread
10:55
<andreubotella>
but I don't think it hurts to make the hooks useful concurrently
11:15
<annevk>
andreubotella: I guess for that you need some kind of incremental hook that you push a couple of items at a time
11:16
<andreubotella>
yeah, that'd be best
11:16
<andreubotella>
but having decode optionally take an output I/O queue would do it for now
11:33
<annevk>
andreubotella: how would that work though? That queue would travel across parallel boundaries magically?
11:34
<annevk>
Might not be too bad
11:40
<andreubotella>
I was thinking something like: on the event loop, the first task from the networking task source creates the parser and the input byte stream, and passes the ibs to a new thread
11:40
<andreubotella>
that thread then creates the input stream, passes the is to a new thread that runs the tokenizer, and itself runs the decode algorithm
11:42
<andreubotella>
decode optionally takes an output I/O queue (otherwise it creates it), and pushes end-of-queue to it after it's done
11:43
<annevk>
So yeah, you pass a queue across threads; might be good enough
14:16
<jgraham>
It is somewhat unclear in the infra standard what happens if you get a value from a map with a key that's not in the map
14:18
<annevk>
jgraham: you have to "exists" check first
14:19
<jgraham>
That is also unclear (and pretty strange)
14:22
<jgraham>
It seems to be mentioned for using the index notation that the value existing is assumed to be a precondition
14:22
<jgraham>
But not for the actual accessor algorithm
14:23
<andreubotella>
The "out of bounds" language for that precondition seems copied from the definition for list, and could be reworded with reference to keys in the map's entries.
14:24
<annevk>
jgraham: third paragraph of (including note) of https://infra.spec.whatwg.org/#maps seems pretty clear?
14:24
<annevk>
Oh sigh, key not index
14:24
<jgraham>
That's what I mean by "it seems to be mentioned for index notation"
14:25
<jgraham>
It isn't obvious to me that anything there applies if I "call" 'get the value of an entry' directly
14:26
<annevk>
I don't think we support map[1] though so maybe that should just be reworded
14:26
<annevk>
s/The index cannot be out-of-bounds, except when used with exists./The key has to exist./?
14:27
<annevk>
Happy to PR that if that would help
14:28
<jgraham>
To get the value of an entry
14:29
<jgraham>
in an ordered map given a key, return the value of the entry whose key is the given key. It is a spec error to call this with a key that does not exist; when that is not statically known specs must first ensure that the map contains key.
14:30
<jgraham>
Or something
14:31
<annevk>
I prefer my clarification, but we should add an example as this is a common pattern
14:31
<jgraham>
Your clarification still give the impression it's talking about the indexing syntax.
14:32
<annevk>
Ah yeah, we should also add an assert to the get thing
14:51
<jgraham>
16:52
<annevk>
Domenic: it seems https://jsdom.github.io/whatwg-url/ broke down somehow
16:54
<Domenic>
annevk: https://github.com/jsdom/whatwg-url/issues/168
16:55
<annevk>
Oh yeah, it still works in Chrome, but no other browser
16:55
<annevk>
That makes it kinda useless though
16:56
<annevk>
Oh, it's IDL bindings code?
16:57
<annevk>
omg https://github.com/tc39/ecma262/issues/678
16:58
annevk
steps away from the computer
17:00
<Domenic>
annevk: it's my JS-implemented IDL bindings code. webidl2js (which underlies whatwg-url which underlies live-url-viewer) implements [AllowShared] in a way that depends on a SAB global existing at startup time.
17:01
<Domenic>
I don't think 678 is relevant to this particular issue, but it is indeed scary... I'm surprised you haven't seen it before.
17:01
<annevk>
I have
17:01
<annevk>
I keep forgetting about it and then it's there again
17:02
<Domenic>
Heh yes
17:02
<Domenic>
Maybe Shu wants to fix it. He's been good about that sort of thing.
17:03
<annevk>
Very true
17:12
<Domenic>
Pushed a fix for live URL viewer to master; it should deploy momentarily. Although I wasn't able to test Safari so if you have that, let me know.
17:12
<Domenic>
One day I will be allowed back into the office to get my testing Mac...
17:13
<annevk>
In Safari I get "ReferenceError: Can't find variable: SharedArrayBuffer"
17:13
<annevk>
Oh, momentarily
17:15
<Domenic>
Hmm Travis says it's deployed but it is not...
17:15
<Domenic>
OK, now it is... caching, maybe
17:17
<annevk>
It seems to work, though Safari seemingly ignores about:blank in base
17:17
<annevk>
But no more console errors
17:17
<annevk>
I would have expected new WebAssembly.Memory to throw
17:18
<annevk>
Ah, I guess it ignores the shared member entirely
17:26
<shu>
annevk: Domenic: i'll queue it up... still need to finish up the incumbents thing. i've been holding off prodding the MDN article progress given the layoffs