| 02:51 | <MikeSmith> | https://twitter.com/maxogden/status/592883522932756481 |
| 05:29 | <hayato> | annevk: Sure. I think we can get benefits from these terms. >>> for parent/child across boundaries I suggest we introduce "composed parent/child", "deep parent/child", |
| 09:30 | <MikeSmith> | http://www.webkit.org/status.html seems to have magically appeared in the last day or so |
| 09:30 | <MikeSmith> | or maybe I just missed the news |
| 09:30 | MikeSmith | checks webkit-dev |
| 11:19 | <hsivonen_> | the ambigous ampersand stuff would be easier to review if Hixie had written the spec as a genuine state machine instead of having the character reference part of the spec unconsume input |
| 11:20 | <hsivonen> | need to mentally page in stuff |
| 12:01 | <MikeSmith> | hsivonen: unfortunately it's also been so long since I first wrote that patch that I need to go back and retrace what I was thinking myself and compare it to the spec |
| 13:33 | <wanderview> | Domenic: it appears streams API is on http://www.webkit.org/status.html |
| 13:37 | <Domenic> | wanderview: indeed :D |
| 13:38 | <wanderview> | Domenic: I guess if they don't have fetch or serviceworkers, then it must just be a js-only thing to start |
| 13:39 | <Domenic> | wanderview: yeah, that's what the code looks like; new ReadableStream() is the focus. |
| 13:39 | <Domenic> | wanderview: I am implementing that this week actually... in Munich working with the V8 team to make self-hosting in Blink better. |
| 13:39 | <wanderview> | Domenic: cool! |
| 13:40 | <wanderview> | webkit having removed SharedWorker seems to not bode well for ServiceWorkers there |
| 13:40 | <Domenic> | Yeah... their reasoning especially... |
| 13:40 | <Domenic> | Still I can't imagine they're going to be OK missing out on the service worker revolution. |
| 13:41 | <Domenic> | Array.prototype.includes is also nice haha, got my feature |
| 13:42 | <wanderview> | implementing Force Click... wonder how that plays with pointer events, etc |
| 13:43 | <Domenic> | heh yeah... that's one of those apple "spring new prefixed features on everyone!" fun times |
| 13:46 | <wanderview> | Domenic: btw, I hope to do some kind of system test for async read vs sync read this week... I will probably just build on top of released chrome fetch body stream... I'll make a pure js transform stream that does some parsing... it will then expose either does the Promise-for-every-read or a ready-promise-with-sync-read... then measure differences |
| 13:46 | <wanderview> | I don't feel I have time to prototype something in the gecko platform in time |
| 13:47 | <Domenic> | wanderview: awesome, will be good to have. We're looking into optimizing our promise impl so that this is a non-issue... the overhead is hurting lots of APIs that want to use promises, e.g. some CSS custom layout stuff. |
| 13:48 | <wanderview> | Domenic: do those other APIs encourage relatively tight async loops? that seems somewhat unique to Streams as far as I know |
| 13:48 | <Domenic> | wanderview: yeah, they deal with many promises per frame |
| 13:49 | <wanderview> | ah, its a Promise thing for animations or something? not familiar with that API |
| 13:49 | <Domenic> | yeah it's new, Houdini stuff if you're familiar with that term |
| 13:49 | <wanderview> | oh, the display worker or whatever? |
| 13:49 | <Domenic> | The idea is to allow customization of layout by JS code, but they want to make all access to layout properties async |
| 13:49 | <wanderview> | Domenic: I updated this last week with new data, btw: https://docs.google.com/spreadsheets/d/1rl6mbD2z1x1bgJLD6y9KJLYWjppB7BujfiWvUMjYTVs/edit?usp=sharing |
| 13:49 | <wanderview> | after we removed the setTimeout from benchmark.js |
| 13:59 | <Domenic> | Still weirded out by Bluebird's poor performance |
| 13:59 | <Domenic> | Should be using MutationObserver |
| 14:00 | <wanderview> | Domenic: what do you mean by poor performance there? bluebird is better than Chrome and Firefox native promises |
| 14:00 | <wanderview> | are you looking at the "new data" tab? |
| 14:00 | <Domenic> | Nope! |
| 14:01 | <Domenic> | the degradation is still surprising to me though |
| 14:01 | <Domenic> | microtask hits should in theory be one-time |
| 14:01 | <Domenic> | then you get into a fast loop |
| 14:02 | <wanderview> | Domenic: I think I'm convinced its more GC costs now |
| 14:02 | <wanderview> | but I haven't profiled |
| 14:02 | <Domenic> | yeah maybe, although my recent experiments made it seem like chrome wasn't GCing at all while the loop was ongoing |
| 14:03 | <wanderview> | the slowdown could be at the end of the loop, but would still reduce overall ops/sec measurements |
| 14:03 | <wanderview> | and in an "infinite" loop, it would have to GC at some point |
| 14:03 | <wanderview> | I guess that would be on I/O |
| 14:05 | <smaug____> | wanderview: you don't have results for nightly/desktop ? |
| 14:05 | <smaug____> | (though, I guess nightly has those few regressions atm) |
| 14:05 | <wanderview> | smaug____: I didn't measure nightly, but I could... things are worse there, though, because of the async stacks |
| 14:06 | <smaug____> | right |
| 17:18 | <wanderview> | jsbell: do you follow your github/critic email? you do you want me to paste the new review links to you here or in a separate email? |
| 17:22 | <jsbell> | wanderview: I have them all, just need to find time to get to them :( |
| 17:30 | <trevnorris> | Domenic: strange thing. using "this.constructor" in a class constructor makes V8 barf on performance: https://gist.github.com/trevnorris/0b7b208e420a4d8f7fc2 |
| 17:30 | <trevnorris> | (done using latest 4.4 release) |
| 17:33 | <wanderview> | jsbell: cool... didn't want to spam you here if you checked that mail (seems like a lot of people mute github mail)... no rush on the review, just didn't want them to get lost |
| 17:33 | <wanderview> | thanks |
| 17:33 | <wanderview> | and I have two more PRs to write |
| 18:29 | <gsnedders> | jgraham: https://critic.hoppipolla.co.uk/r/4798 plz |
| 18:43 | <wanderview> | jsbell: does blink still need the MessageChannel thing for the SW tests? or do you support the Client postMessage() now? |
| 20:24 | <jsbell> | wanderview: sorry, was afk. We support postMessage now, not sure if it where the message is delivered is in sync w/ the latest spec though... |
| 20:25 | <wanderview> | jsbell: the comment in the code indicates its actually a problem with MessageEvent.source not being set when doing ServiceWorker.postMessage() |
| 20:25 | <jsbell> | that too... |
| 20:25 | <wanderview> | jsbell: I tried to make it favor MessageChannel for now, but fallback to ServiceWorker.postMessage()... just let me know in the review if thats not needed |
| 20:26 | <jsbell> | wanderview: noted |
| 20:26 | <wanderview> | thanks! |
| 20:31 | <wanderview> | hmm... or the MessageChannel code I was just looking at doesn't even exist in wpt upstream :-\ |
| 20:40 | <wanderview> | oh... its in the testharness.js submodule... oops |
| 21:20 | <Ms2ger> | "An extensive test suite for this specification <http://w3c-test.org/dom/>; is available" |
| 21:20 | Ms2ger | cackles maniacally |
| 21:24 | <jgraham> | Where does it say that? |
| 21:25 | <jgraham> | And can we make it instead say "a somewhat lacking testsuite, that you should certainly contribute to, covers several of the features in this specification" |
| 21:26 | <jgraham> | gsnedders: Review done |
| 21:29 | <Ms2ger> | tr/dom/ |
| 21:29 | <Ms2ger> | Quoted by ArtB |
| 21:37 | <gsnedders> | jgraham: we're caring about performance of rarely run bits of test harness code now? |
| 21:38 | <jgraham> | gsnedders: Well really I care about removing one easy-to-understand line and replacing it with regexps + an implementation of UTF16 decoding |
| 21:38 | <jgraham> | But I also think it will be slower :p |
| 21:38 | <gsnedders> | jgraham: I'm just as worried about it also converting things like \xff and \0 |
| 21:39 | <jgraham> | Don't we control the data format here? |
| 21:39 | <gsnedders> | yeah, I know |
| 21:40 | <gsnedders> | I'd just rather follow the shared definition of the format instead of not |
| 21:41 | <jgraham> | Well whatever, I guess, but I think that implementing that ourselves when there's a library that does basically the right thing is crazy |
| 21:42 | <gsnedders> | ohhhh |
| 21:42 | <gsnedders> | now I rememeber reading the docs |
| 21:42 | <gsnedders> | "Decodes from Latin-1 source code. Beware that Python source code actually uses UTF-8 by default." |
| 21:43 | <gsnedders> | jgraham: that's why we can't |
| 21:43 | <jgraham> | Well comment then |
| 21:44 | <gsnedders> | that would be a good idea given I'd entirely forgotten :P |
| 22:05 | <caitp> | i'll buy someone a beer if they can explain to me how to read the mozilla telemetry dashboard's graphs |
| 22:05 | <trevnorris> | caitp: first you drink that beer, then another, and maybe one more. |
| 22:06 | <caitp> | i'm not really a beer person, but if you can explain the graphs, you can have your choice of whatever brew you like |
| 22:06 | <gsnedders> | caitp: what graph are you looking at, and what's not clear? |
| 22:07 | <gsnedders> | jgraham: |
| 22:07 | <gsnedders> | Merge 7e4dc99a adds merged-in commits. Please push the merge manually |
| 22:07 | <caitp> | someone asked how much of the web was using http2, and chromestatus doesn't have a metric for it, so I was looking at mozilla's spdy telemetry (spdy_chunk_received should be a reasonably good measure?) |
| 22:07 | gsnedders | grumbles at Critic |
| 22:08 | <caitp> | i'm not sure how you'd draw a "% of the web" conclusion from it, although some people apparently have |
| 22:09 | <gsnedders> | caitp: HTTP_RESPONSE_VERSION seems better |
| 22:09 | <jgraham> | gsnedders: Don't push merge commits? |
| 22:10 | <gsnedders> | if you change it to be a table, and cross-ref with nsHttp.h, you'll find "9" refers to HTTP/0.9, "10" HTTP/1.0, "11" HTTP/1.1, "20" HTTP/2.0 |
| 22:10 | <gsnedders> | jgraham: so never merge in master? |
| 22:10 | gsnedders | is used to Critic coping fine with merges from master… |
| 22:11 | <caitp> | ah I see |
| 22:11 | <gsnedders> | caitp: using the latest released version will probably give you better data |
| 22:11 | <jgraham> | gsnedders: Merging in master doesn't really help anyone |
| 22:11 | <caitp> | yeah i'm looking at rel39 |
| 22:11 | <gsnedders> | jgraham: it gets rid of merge conflicts sooner rather than later |
| 22:11 | <jgraham> | gsnedders: If you need to do that for some reason, push new commits and then make a move-type rebase |
| 22:12 | <gsnedders> | jgraham: your review tools are too fussy nowadays! |
| 22:12 | <jgraham> | Otherwise you end up with an even more confuisng history than normal |
| 22:12 | <jgraham> | Well yes, it is a bit fussy, but in this case it's right |
| 22:12 | <jgraham> | (it would be better if you could rebase and push new commits at the same time) |
| 22:13 | <gsnedders> | Soz, I'm still not used to Critic coping with rebases. |
| 22:14 | <gsnedders> | caitp: really the trick most of the time is to guess probable strings related to what you want, then check in the code to make sure it's getting the data you want :P |
| 22:15 | <gsnedders> | (in my experience) |
| 22:15 | <caitp> | well, using that table it came out to about 18% of submissions |
| 22:16 | <caitp> | offset that by the number of people only browsing facebook, and it seems not inaccurate |
| 22:16 | <caitp> | *taken with grain of salt |
| 22:16 | <gsnedders> | caitp: huh, for me on rel37 it's 10% |
| 22:17 | <caitp> | oh. i mathed wrong |
| 22:17 | <gsnedders> | :) |
| 22:17 | <caitp> | didn't add the 20* items to the total before calculating |
| 22:33 | <gsnedders> | SimonSapin: hah, I just have an odd habit of maintaining stuff in languages I don't use much :) |
| 22:35 | <SimonSapin> | gsnedders: oh yeah, I’m still maintaining some python libraries |
| 22:35 | <SimonSapin> | kind of |