| 04:27 | <annevk> | Why is the WebAssembly shipping bar so low? Do you know rbyers? |
| 04:32 | <MikeSmith> | annevk: not sure but I think the state of things is that it’s already implemented across UAs at some relatively high level of interoperability |
| 04:33 | <MikeSmith> | they have common test suite and I think implementors have been working against that and I refining it |
| 04:34 | <MikeSmith> | so it seems like the implementations are pretty mature at this point |
| 04:34 | <MikeSmith> | that said I’m sure there are some interop issues there still and also spec issues which have not gotten as much outside scrutiny as they should have |
| 04:35 | <annevk> | I hope that is true for the JS API too |
| 04:36 | <MikeSmith> | well |
| 04:36 | <MikeSmith> | not sure it is |
| 04:36 | <annevk> | Bit skeptical though, since the design is sketch notes, working that out into an algorithm usually results in more choices to be made |
| 04:37 | <MikeSmith> | that I think they may not even have tests for |
| 04:37 | <MikeSmith> | the tests they do have are https://github.com/WebAssembly/spec/tree/master/test/core |
| 05:47 | <MikeSmith> | TabAtkins: did you hear back from plinss about the problem with the rel=serviceworker dfn? |
| 05:47 | <MikeSmith> | I see it’s still failing when I run bikeshed |
| 05:48 | <TabAtkins> | He's in Okinawa on vacation right now, but will check on it as soon as he can. |
| 05:53 | <MikeSmith> | ah OK |
| 05:53 | <MikeSmith> | (lucky him, diving I assume) |
| 05:54 | <MikeSmith> | thanks 🐠 |
| 06:04 | <MikeSmith> | seems like https://caniuse.com/ is loading a lot faster |
| 06:05 | <MikeSmith> | maybe he got some help on tweaking the backend |
| 06:27 | <MikeSmith> | https://www.ssllabs.com/ssltest/analyze.html?d=caniuse.com = 🄲 |
| 06:29 | <MikeSmith> | seems he needs to disable SSL3 and enable TLS1.2 |
| 06:30 | <MikeSmith> | anyway, it’s progress |
| 09:16 | <MikeSmith> | annevk: so yeah I see: |
| 09:17 | <MikeSmith> | > There is a possible compatibility risk, as while all major browsers have |
| 09:17 | <MikeSmith> | implemented WebAssembly, and have agreed in principle and form to the |
| 09:17 | <MikeSmith> | proposed API, none of have yet implemented it. |
| 09:17 | <MikeSmith> | There is a strong likelihood they will, given the feature is desirable for |
| 09:17 | <MikeSmith> | optimum performance when doing streaming compilation of WebAssembly. |
| 09:17 | <MikeSmith> | However, there is some risk the feature may change slightly as it is |
| 09:17 | <MikeSmith> | standardized more rigorously. |
| 09:17 | <MikeSmith> | ... |
| 09:17 | <MikeSmith> | so it does seem premature to ship, given that |
| 09:17 | <MikeSmith> | IMHO |
| 11:52 | <annevk> | JakeA: await (await fetch("data:,3")).json() seems to work |
| 11:53 | <annevk> | JakeA: having said that, it's a character longer than fetch("data:,3").then(r => r.json()) |
| 11:53 | <annevk> | JakeA: that's kinda a failure of the await syntax |
| 11:59 | <rbyers> | annevk: I haven't been following wasm in great detail but what Mike said matches my big picture understanding. There is a ton of collaboration and interop testing between the 4 engines. Can you point me at some specific concerns? |
| 12:00 | <rbyers> | MikeSmith: Which API are you taking about? The WebAssembly JS API is implemented and shipped in Chrome and Firefox. |
| 12:02 | <annevk> | rbyers: that may be true, but only fairly recently did it get some architectural review and such, let alone detailed review (which isn't really possible given they are API sketches and not formal definitions) |
| 12:03 | <JakeA> | annevk: yeah, but await (await fetch("data:,3")).json() reads badly to me. For docs, I tend to split it into two lines. const response = await fetch(url); const data = await response.json() |
| 12:03 | <JakeA> | annevk: but in my own code I'd probably just do: await fetch(url).then(r => r.json()) |
| 12:03 | <annevk> | JakeA: it's probably actually shorter btw, since you'd need a second .then to emulate the await await? |
| 12:04 | <annevk> | so no failure after all, just my failure |
| 12:05 | <JakeA> | I guess .then is still handy for one-liners, even if there's an await at the start |
| 12:05 | <annevk> | I dunno, nested await looks okayish to me |
| 12:22 | <JakeA> | Maybe I'm just not used to it |
| 12:25 | <rbyers> | annevk: Architectural review definitely could have gone better and earlier. For my part I screwed up in the intent to ship by not asking about this (eg. I should have at least asked about a TAG review). |
| 13:29 | <wanderview> | annevk: you're working on enabling a service worker opening a nested dedicated worker? |
| 13:30 | <annevk> | wanderview: I'm mostly working on shared memory integration |
| 13:31 | <wanderview> | ok |
| 13:31 | <annevk> | wanderview: as a side effect I had to refine worker ownership, which should help with that, and also nested shared workers |
| 13:32 | <wanderview> | annevk: ok, I thought of a quirk with nested workers in service workers... I'll just stick it in a github issue |
| 13:32 | <annevk> | wanderview: my last comment in that issue summarizes what still needs to be done |
| 14:25 | <annevk> | wanderview: for https://github.com/whatwg/html/issues/411#issuecomment-293272882 I filed an issue for 1, 3 we should maybe do separately, so that would leave 2? Not sure there's anything else |
| 14:27 | <wanderview> | annevk: based on my comment about stashing a worker reference on the about:blank global... I bet its just nto going to work as expected for about:blank replacement today |
| 14:30 | <wanderview> | I think we could write a test, but I guess we should define how we want it to work in that case |
| 16:09 | <annevk> | Best to first figure out what happens |
| 16:21 | <TabAtkins> | JakeA: Nah, nested await looks bad to me too - non-obvious precisely what the bounds are of each. Gotta spend some time thinking about what's going on before I can tell that it's right. |
| 21:43 | <MikeSmith> | Domenic: https://www.shellcheck.net/ is very good |
| 21:44 | <TabAtkins> | Does it just report "Error: you're still using a shell language. Switch to Python or something you noob."? |
| 21:44 | <MikeSmith> | haha |
| 21:44 | <MikeSmith> | would be fun if it did |
| 21:45 | <MikeSmith> | though less useful |
| 21:46 | <MikeSmith> | anyway had never used it before but been running on it on a few things now and been surprised at how much it finds |
| 21:46 | <MikeSmith> | it’s very clever |
| 21:46 | <MikeSmith> | and thorough |
| 21:47 | <MikeSmith> | now I just want to have it integrated into my vim |
| 21:47 | <MikeSmith> | oh and I find https://github.com/koalaman/shellcheck#user-content-in-your-editor *supported as an integrated linter in major editors* |
| 21:47 | <Domenic> | MikeSmith: oh cool, glad you're finding it useful. My experience was that it mostly complained about unquoted variables, and a few instances of `` vs. $(); I didn't see any "very clever" and "surprised how much it finds" personally :) |
| 21:48 | <Domenic> | I guess the move from cat to < was pretty clever |
| 21:48 | <MikeSmith> | yeah it depends on how complicated what you feed to it is |
| 21:50 | <MikeSmith> | but when I tried that find . -exec for the HTML checker with it, it really made me think more about the quoting differences and how I was referencing the filename |
| 21:51 | <MikeSmith> | specifically in that case, this check: |
| 21:51 | <MikeSmith> | https://github.com/koalaman/shellcheck/wiki/SC2156 |
| 21:51 | <MikeSmith> | doing find . -name '*.mp3' -exec sh -c 'i="{}"; sox "$i" "${i%.mp3}.wav"' \; |
| 21:51 | <MikeSmith> | vs |
| 21:51 | <MikeSmith> | find . -name '*.mp3' -exec sh -c 'i="$1"; sox "$i" "${i%.mp3}.wav"' _ {} \; |
| 21:53 | <MikeSmith> | the way the error messages link to those wiki pages with the details is pretty nice too |
| 22:23 | <TabAtkins> | tobie: Am I right that the regex for biblio keys is all alphanumerics, plus "-_+."? |
| 22:30 | <TabAtkins> | tobie: In that case, you can significantly simplify the regex to just `[\\w+.-]`. \w does all alphanumerics and underscore, there's no need to escape the period, and no need to escape the dash if you put it at the end. |
| 23:41 | <jyasskin> | For a field in an options dictionary, does https://w3ctag.github.io/design-principles/#casing-rules imply I should propose "public_key" instead of "publickey", "publicKey", or "public-key"? |
| 23:42 | <TabAtkins> | Nah, I think that falls in the "attribute" bucket, wanting camelCase. |
| 23:42 | <jyasskin> | TabAtkins: Ok, thanks. |
| 23:42 | <TabAtkins> | (I'm unclear why the JSON bucket recommends underscores.) |