| 06:31 | <annevk> | Domenic: it's ready; planning on writing tests later |
| 06:57 | <annevk> | hsivonen: if you could review the window.event tests I think we're all good to go |
| 06:58 | <annevk> | hsivonen: only https://github.com/web-platform-tests/wpt/pull/10329 really |
| 06:58 | <annevk> | I guess I can also try foolip again |
| 07:22 | <foolip> | annevk: need review on something? |
| 07:25 | <annevk> | foolip: yeah, the above URL |
| 07:29 | <foolip> | annevk: I'll take a look |
| 07:31 | <annevk> | \o/ |
| 07:37 | <foolip> | annevk: most of the tests fail in Chrome and Safari, did you look into that? |
| 07:37 | <foolip> | I haven't tested Edge |
| 07:37 | <annevk> | foolip: I filed bugs on that |
| 07:37 | <annevk> | foolip: they follow a suggestion that we should base the global on the global of the listener's callback |
| 07:38 | <foolip> | annevk: ah, as opposed to the event target? |
| 07:38 | <annevk> | foolip: made by Shiino Yuki from Chrome |
| 07:39 | <annevk> | foolip: yeah, and even that wasn't consistent I think, it's a little unclear to me still what the existing mechanism is |
| 07:40 | <foolip> | annevk: the first two test names include "{ [native code] }", do you think that's worth fixing? |
| 07:41 | <annevk> | foolip: if you want to do some light background reading: https://github.com/whatwg/dom/issues/334 |
| 07:41 | <annevk> | foolip: I could fix that, sure |
| 07:41 | <foolip> | annevk: fixing now |
| 07:42 | <JakeA> | annevk: Would we ever allow developers to get at the undecoded bytes of a response? I imagine it'd require an additional CORS opt-in at least |
| 07:43 | <annevk> | JakeA: we could, I don't think we'd need another opt-in per se, but I maybe I haven't thought about it enough |
| 07:44 | <annevk> | JakeA: we actually wanted to go that way initially, but it turned out it was buried deep into the networking stack and nobody liked it, so it didn't seem good as a default |
| 07:44 | <foolip> | annevk: what |
| 07:45 | <foolip> | annevk: what's "listener intentionally not wrapped in t.step_func" about? |
| 07:45 | <foolip> | annevk: is it to cause a harness error? |
| 07:45 | <foolip> | annevk: or because that would change the global of the listener? |
| 07:45 | <foolip> | I guess that's it |
| 07:45 | <foolip> | gotta run |
| 07:46 | <JakeA> | annevk: I was wondering about compression formats with some kind of dictionary that might leak additional info, but I guess that'd be a separate request. Ta. Just trying to get my head around Chrome's complaints about the Accept-Encoding stuff. |
| 07:46 | <annevk> | foolip: that's it |
| 07:47 | <annevk> | JakeA: I think some H/2 stuff might be across requests, but maybe that's just for headers? |
| 07:47 | <annevk> | JakeA: dunno how brotli works either |
| 07:48 | <JakeA> | annevk: If it becomes a big problem, we could add an optional arg to https://fetch.spec.whatwg.org/#concept-request-add-range-header which can specify the encoding, which would default to identity. |
| 07:48 | <JakeA> | me neither |
| 07:48 | <annevk> | JakeA: I was thinking that could be another solution here, but it doesn't help when someone sets Range manually |
| 07:49 | <annevk> | JakeA: there are a ton of issues around Accept-Encoding though that I recently surfaced a bit in issues, mmenke(sp?) helped with that |
| 07:49 | <JakeA> | annevk: we always want identity in that case, so we'd still need the line we already have, unless something set Accept-Encoding first |
| 07:50 | <annevk> | JakeA: yeah, but the way we set things up nothing can set that first |
| 07:51 | <annevk> | JakeA: I guess their concern is that their layering is different from ours, but I'm not sure how to reconcile properly |
| 07:52 | <JakeA> | annevk: I'll see what they come back with. It seems like they're softening a bit from the initial "this doesn't make sense" reaction |
| 07:53 | <annevk> | k |
| 07:56 | <MikeSmith> | botie, inform tantek http://microformats.org/wiki/existing-rel-values is not responding |
| 07:56 | <botie> | will do |
| 14:46 | <MikeSmith> | annevk: Domenic about the syntax highlighter: After doing some initial testing with TabAtkins tool hooked into wattsi and html-build: |
| 14:47 | <MikeSmith> | the good news is that increases the output file size by only 3.5% |
| 14:48 | <MikeSmith> | the single-page output size increases by 300MB, to 8.8MB from 8.5MB |
| 14:49 | <MikeSmith> | the somewhat less good news is that makes the build go from 16 seconds (without the highlighter) up to about 4.5 minutes |
| 14:51 | <MikeSmith> | but that’s not too surprising given that we have 1121 examples in the spec, and because of the way it needs to be handled in wattsi, each example gets processed 3 times: 1) single-page full spec, 2) multipage full spec, 3) developer version |
| 14:52 | <TabAtkins> | Holy shit tho |
| 14:52 | <annevk> | Hmm |
| 14:52 | <MikeSmith> | TabAtkins: well I think that works out to only 80ms per example |
| 14:53 | <TabAtkins> | MikeSmith: You think you could do a pass and pull all the to-be-highlighted text out so I can play with it? |
| 14:53 | <MikeSmith> | to pipe the example to the highlighter, have the highlighter process it, write it back to the output |
| 14:53 | <annevk> | Also one singlepage snapshot |
| 14:53 | <TabAtkins> | 80ms is a long time. 😤 |
| 14:53 | <TabAtkins> | But I'm wondering how much is it vs highlighting |
| 14:54 | <MikeSmith> | annevk: right now I have it not highlighting the snapshot output |
| 14:54 | <TabAtkins> | * is IO |
| 14:54 | <MikeSmith> | annevk: on the assumption we don’t want to make the snapshot especially user-friendly anyway |
| 14:54 | <annevk> | 4.5min would be annoying with Travis too, currently failure is reported quite quick |
| 14:55 | <annevk> | MikeSmith: fair |
| 14:55 | <MikeSmith> | or rather maybe, we don’t want people using the snapshot for anything |
| 14:55 | <Domenic> | Yeah we knew it would take a while. But I think it's ok since we'll only run it on CI. |
| 14:55 | <Domenic> | I think the snapshot should be user friendly, but not the review draft |
| 14:55 | <Domenic> | Snapshot is for people being like "this is what I implemented last Thursday" |
| 14:55 | <annevk> | How long does Bikeshed take? |
| 14:56 | <MikeSmith> | TabAtkins: yeah I can get you the source for all the examples |
| 14:56 | <annevk> | If we don’t care about build times… |
| 14:56 | <annevk> | (I care a bit) |
| 14:56 | <MikeSmith> | TabAtkins: oh, you want the JSONized source of the examples? or the original HTML? |
| 14:56 | <TabAtkins> | On my laptop, the Bikeshedded version of HTML took about 3min. On my desktop it was a minute and change iirc. |
| 14:57 | <TabAtkins> | MikeSmith: the json, what you'd give to highlighter. |
| 14:57 | <annevk> | Sounds like we’d be better of switching to Bikeshed… |
| 14:58 | <annevk> | We could potentially do that by making wattsi output a bs source file |
| 14:59 | <MikeSmith> | TabAtkins: OK, I have https://gist.githubusercontent.com/sideshowbarker/8284404/raw/cff69f158ea995a17a73af3e9eff29823617caa8/html-spec-all-pre-elements.json but I generated that before I added code for emitting {} for the no-attributes case. So I will regenerate it |
| 14:59 | <annevk> | For the conversion |
| 15:00 | <MikeSmith> | Domenic: ah OK (about the snapshot). I can flip it on and see how much time it adds |
| 15:00 | <TabAtkins> | MikeSmith: I presume you tell which language to highlight it with by looking at the class? |
| 15:00 | <MikeSmith> | oh |
| 15:01 | <MikeSmith> | I have not implemented that yet |
| 15:01 | <MikeSmith> | I think right now I just have it assuming it’s all HTML |
| 15:01 | <MikeSmith> | but yeah I will need to have it check the class value |
| 15:01 | <TabAtkins> | Ahahaha, ok. That won't give right results. 😀 |
| 15:01 | <MikeSmith> | yeah I know |
| 15:02 | <TabAtkins> | But yeah I'm guessing most of the cost here is in IO, shelling out for each individual example. |
| 15:03 | <TabAtkins> | But I think wattsi is intentionally single-pass? |
| 15:06 | <MikeSmith> | TabAtkins: single-pass? |
| 15:07 | <TabAtkins> | As in it runs thru the source document only one time, rather than repeatedly searching over it (like Bikeshed does). |
| 15:08 | <MikeSmith> | it runs through it once for each “variant” we output |
| 15:08 | <MikeSmith> | but we output 4 variants |
| 15:08 | <MikeSmith> | 1) single-page full spec, 2) multipage full spec, 3) developer version, 4) snapshot |
| 15:08 | <TabAtkins> | Yeah, but that's fine. Single-pass is just the only way I could imagine getting 16s for each. |
| 15:09 | <TabAtkins> | (I really need to buckle down and see about converting wattsi's HTML parser/serializer to Python; those are still the *dominant* time-sinks in large Bikeshed specs.) |
| 15:09 | <TabAtkins> | (I think in the Bikeshed-HTML spec they're each 40% of the runtime?) |
| 15:09 | <annevk> | MikeSmith: I think it only parses once, serializes a lot though |
| 15:10 | <MikeSmith> | annevk: ah right yeah for sure |
| 15:10 | <MikeSmith> | if we are talking about HTML parsing, yes, it does it only once |
| 15:10 | <MikeSmith> | and blazingly blazingly fast |
| 15:11 | <TabAtkins> | Parsing and just general *handling*. Like, Bikeshed obvi only does a single HTML parse, but then it runs over the DOM many many times. |
| 15:11 | <TabAtkins> | One of my 2018 goals is to replace almost all of my selectors with a properly-maintained data structure sorting elements by significant classes. |
| 15:18 | <Domenic> | annevk: I prefer the <10 second times of the current build to 1.5 minute times... |
| 15:21 | <Domenic> | (OK, it's up to 23 seconds now, including linting and pre-processing.) |
| 15:21 | <Domenic> | Notably it parses once and then does the three output passes |
| 15:21 | <MikeSmith> | TabAtkins: https://gist.githubusercontent.com/sideshowbarker/8284404/raw/8efdf8fe9713839b839955c9a099ff90e2e559a1/examples.json |
| 15:23 | <Domenic> | My understanding is that a large part of Wattsi's speed comes from being very intentional about memory use with strings, which is hard to do in a high-level language (i.e. not C/C++/Rust, or apparently, Pascal). |
| 15:23 | <Domenic> | s/memory usage/allocation and copying/ |
| 15:23 | <TabAtkins> | Ah, that would make sense. |
| 15:26 | <MikeSmith> | I think it’s actually pretty hard to do even in Pascal |
| 15:27 | <MikeSmith> | Hixie did it by inventing some stuff optimized for it |
| 15:31 | <annevk> | Domenic: oh, we’d only enable syntax highlighting on master or some such? That’s getting rather fragmented |
| 15:32 | <MikeSmith> | why would we need it other than on master? |
| 15:32 | <MikeSmith> | I mean the goal is just for end users to have it in the published spec, right? |
| 15:32 | <Domenic> | annevk: Well, I certainly wouldn't run it when building locally. Whether we make it on by default (so you have to pass a flag to build.sh to get fast build times) or off by default (so that CI has to pass a flag to get syntax highlighting) is up to us, but I lean toward off by default. |
| 15:33 | <MikeSmith> | ah |
| 15:33 | <MikeSmith> | good point |
| 15:33 | <MikeSmith> | we can add a build flag to disable it |
| 15:34 | <MikeSmith> | for local builds |
| 15:34 | <Domenic> | Or add one to enable it, for CI builds? |
| 15:34 | <MikeSmith> | yeah |
| 15:35 | <MikeSmith> | so yeah however we enable/disable it, it runs only for CI builds, so the time cost would only be for CI runs |
| 15:36 | <MikeSmith> | that makes it a lot less icky I guess |
| 15:36 | <MikeSmith> | as long as it doesn’t cause CI to time out |
| 15:37 | <MikeSmith> | I can make it emit log output the whole time at least |
| 15:38 | <MikeSmith> | I mean, say, just keeping a counter (of examples) and emitting that after incrementing it each time |
| 15:38 | <Domenic> | Yeah I think CI timeout is like 15 minutes so we should be OK |
| 15:38 | <MikeSmith> | cool |
| 15:39 | <Domenic> | Incremental logs sounds good, yeah, it's annoying staring at CI and wondering if it's stuck |
| 15:39 | <MikeSmith> | true yeah |
| 15:39 | <MikeSmith> | at this poitn without emitting something, it just feels like it’s hung |
| 15:39 | <MikeSmith> | so yeah will add that regardless |
| 15:40 | <MikeSmith> | anyway it’s late here so I’ll need to finish the wattsi patch for this later (maybe not til over the weekend) |
| 15:45 | <Domenic> | Sounds good! Excited to have these. |
| 16:26 | <botie> | tantek, at 2018-06-07 07:56 UTC, MikeSmith said: http://microformats.org/wiki/existing-rel-values is not responding |
| 16:49 | <tantek> | botie, inform MikeSmith WFM now, please try reloading microformats.org/wiki/existing-rel-values to confirm and thanks for the heads-up. |
| 16:49 | <botie> | will do |
| 16:51 | <TabAtkins> | If the CI-errors being quick is something you really care about, the no-highlight version is *so fast* that you could just... do it twice, once without highlighting and once with. |
| 17:02 | <annevk> | Not a bad idea |
| 17:47 | <annevk> | Ugh, some of the people who want header support in WebSocket are really not helping their cause |
| 19:34 | <zcorpan> | jgraham: you're right that the survey should be more coordinated, sorry about that. Can we coordinate now and make tweaks if necessary? |
| 19:35 | <zcorpan> | foolip annevk ^ |
| 19:47 | <zcorpan> | Also what distribution method do you think we should use |
| 19:48 | <zcorpan> | Should we have a question for which employer? |
| 20:03 | <annevk> | zcorpan: I don’t think any of this matters much personally due to window.js and any.js |
| 20:04 | <annevk> | zcorpan: I’d be okay trying to get rid of the single test format entirely |
| 20:06 | <foolip> | FWIW, I've always stayed away from it because I never really knew until reading the source how it worked, and when I saw it first thought the tests must be broken |
| 20:06 | <foolip> | Which makes me a bad judge of what people who like it would want, of course |
| 20:18 | <jgraham> | zcorpan: I think we should withdraw the survey and send out a new one in a week or so. I know that's annoying but since we can only do this kind of thing once per year I think we have to be sure we're getting the input we need each time |
| 20:30 | <zcorpan> | Ok |
| 20:38 | <zcorpan> | Turned off responses and removed the tweet. Maybe MikeSmith can still reject my email as it's in moderation |
| 20:39 | <jgraham> | zcorpan: Thanks. I'll spend some time tomorrow on this |
| 20:43 | <zcorpan> | Thank you |
| 23:22 | <MikeSmith> | hai, successfully rejected that e-mail message |
| 23:22 | <botie> | MikeSmith, at 2018-06-07 16:49 UTC, tantek said: WFM now, please try reloading microformats.org/wiki/existing-rel-values to confirm and thanks for the heads-up. |