| 07:10 | <annevk> | MikeSmith: you around? |
| 07:11 | <annevk> | MikeSmith: are you okay with giving @dstorey access to platform.html5.org directly? |
| 07:28 | <MikeSmith> | annevk: here now |
| 07:28 | <MikeSmith> | yeah David should just have push access |
| 07:28 | <MikeSmith> | or even owner perms |
| 07:31 | <MikeSmith> | ah but if we give somebody owner perms to one repo then we hit the issue that then have owner perms for everything else in the whole whatwg github org too |
| 07:31 | <MikeSmith> | at least that's still the way the github ACLs worked last time I checked |
| 07:36 | <annevk> | MikeSmith: I added a team |
| 07:37 | <annevk> | MikeSmith: the new policy is that one of the owners creates a team for the repo and just adds people there |
| 07:37 | <annevk> | add* |
| 07:37 | <MikeSmith> | ok |
| 07:37 | <MikeSmith> | that's the best way I think |
| 08:39 | <zcorpan_> | hsivonen: your msdn quirks mode link appears broken. i found https://msdn.microsoft.com/en-us/library/gg558056(v=vs.85).aspx , not sure if it's the same as your original link |
| 08:42 | <zcorpan_> | hsivonen: or maybe https://msdn.microsoft.com/en-us/library/ff406036(v=vs.85).aspx or https://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx |
| 08:44 | zcorpan_ | notes msdn has nice diagrams for this |
| 08:45 | <zcorpan_> | ........ wat https://msdn.microsoft.com/en-us/library/hh834788(v=vs.85).aspx |
| 09:19 | <annevk> | MikeSmith: I also opened issues for whatwg/platform.html5.org |
| 09:21 | <pi-> | I've been looking at how to handle a click at a particular location on a canvas that has been translated and rotated. It seems that Canvas's context is lacking a getCurrentTransform(). A bit of googling finds https://bugzilla.mozilla.org/show_bug.cgi?id=408804 then https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/currentTransform |
| 09:21 | <pi-> | It seems rather scary to me that such a basic thing still hasn't made its way in... |
| 09:23 | <pi-> | https://html.spec.whatwg.org/multipage/scripting.html#transformations <-- it seems to be in the living standard. But only Chrome has implemented it as far as I can see. |
| 09:36 | <MikeSmith> | hsivonen: r? https://bugzilla.mozilla.org/attachment.cgi?id=8591559&action=edit |
| 09:36 | <MikeSmith> | annevk: issues? /me looks |
| 09:37 | <MikeSmith> | annevk: I guess you mean you enabled the issue tracker for the repo? |
| 09:37 | <annevk> | MikeSmith: you couldn't raise issues before, I don't think anyone has raised any yet though in the couple of minutes since I opened them ;-) |
| 09:37 | <MikeSmith> | hai |
| 09:37 | <MikeSmith> | I didn't know we didn't have it enabled before |
| 09:37 | <annevk> | Yeah surprised me too |
| 09:38 | <annevk> | In general I'm moving towards GitHub issues for specifications |
| 09:38 | <annevk> | Domenic was right |
| 09:41 | <MikeSmith> | yeah Github has won |
| 09:44 | <MikeSmith> | speaking of Github I wish the http://hg.mozilla.org/projects/htmlparser/ sources had a real home in Github |
| 09:45 | <MikeSmith> | I guess mozilla-central is mirrored in Github |
| 09:45 | <MikeSmith> | dunno why that projects tree isn't yet |
| 09:47 | <jgraham> | Because no one cares about it, I guess |
| 09:47 | <MikeSmith> | well that's sad then |
| 09:47 | <MikeSmith> | someone should care |
| 09:47 | <MikeSmith> | I mean, I care |
| 09:47 | <MikeSmith> | others should care like I do |
| 09:48 | <jgraham> | I guess there are higher priority things to work on than mirroring little-used trees onto gh |
| 09:48 | <MikeSmith> | christ |
| 09:48 | <MikeSmith> | yeah, that's the right attitude to have |
| 09:49 | <jgraham> | Honestly, you should be glad that no one has managed to get it moved into m-c yet |
| 09:49 | <MikeSmith> | heh |
| 09:49 | <MikeSmith> | true I guess |
| 09:49 | <MikeSmith> | point taken |
| 09:49 | MikeSmith | counts his blessings |
| 09:49 | <jgraham> | There's a group of people who believe that having a single repo with all Mozilla-related code in is a great idea because it solves versioning problems |
| 09:49 | <MikeSmith> | oh boy |
| 09:50 | <jgraham> | The argument is "it works for Facebook and Google, so it must be good" |
| 09:50 | <MikeSmith> | sure yeah it solves that one problem of course |
| 09:50 | <MikeSmith> | heh |
| 09:50 | <jgraham> | Seriously |
| 09:50 | <MikeSmith> | yeah I hear that argument a lot |
| 09:50 | <MikeSmith> | jesus |
| 09:50 | <MikeSmith> | well those people should get re-educated |
| 09:51 | <jgraham> | Anyway, I'm hoping that pointing out that Facebook and Google have ~0 external contributers whereas Mozilla has many is enoeugh of a clue that we might have different needs |
| 09:51 | <MikeSmith> | bingo |
| 09:52 | <annevk> | MikeSmith: you could start a GitHub mirror perhaps? |
| 09:52 | <MikeSmith> | jgraham: well please continue to fight the good fight there |
| 09:52 | <MikeSmith> | annevk: did already https://github.com/validator/htmlparser/ |
| 09:52 | <MikeSmith> | I just prefer to make other people do work for me whenever I can |
| 09:53 | <MikeSmith> | not that it's a huge amount of work |
| 09:53 | <MikeSmith> | but I just don't have it automated |
| 09:54 | <MikeSmith> | the mirroring I mean |
| 09:54 | <MikeSmith> | I could automate more of it instead of complaining |
| 09:54 | <jgraham> | MikeSmith: It's possible that if you file a bug on releng they could add it to the list of repos mirrored on gh |
| 09:54 | <MikeSmith> | oh |
| 09:54 | <MikeSmith> | ok |
| 09:55 | <MikeSmith> | will do that |
| 11:00 | <annevk> | JakeA: alternative API would be to expose client request contexts as a static on Request; might also be useful for other things; or we could have both, meh |
| 11:03 | <annevk> | Question about English, if you have "the range 0x00 to 0xFF" is that unambiguous or should I really start using "the range 0x00 to 0xFF inclusive"? Does the latter notation require a comma? |
| 11:03 | <annevk> | This affects the Encoding Standard the most, but also various other features elsewhere |
| 11:04 | <jgraham> | I think people assume inclusive unless otherwise stated, but a mathematician would be annoyed by the lack of specificity |
| 11:05 | <annevk> | English or American mathematician? |
| 11:06 | <jgraham> | Either? |
| 11:06 | <annevk> | It seems ECMAScript uses both styles (with a comma for the latter) |
| 11:08 | <annevk> | Hmm, ECMAScript uses a number of styles... |
| 11:10 | <annevk> | jgraham: I guess I should start adding ", inclusive" then or use "the inclusive range"... |
| 11:11 | <jgraham> | I prefer ", inclusive" fwiw |
| 11:12 | <annevk> | jgraham: any particular reason? |
| 11:12 | <annevk> | jgraham: so that the word is closer to the actual range? |
| 11:12 | <jgraham> | It sounds better |
| 11:13 | <Ms2ger> | As a mathematician, this isn't anywhere near the top of my specificity complaints :) |
| 11:14 | <annevk> | Are we now talking CSS? |
| 11:14 | <Ms2ger> | Ha |
| 11:15 | <jgraham> | As a non-mathematician, my top specificity complaint is Ms2ger's lack of specificity about his top specificity complaints |
| 11:16 | <Ms2ger> | Go look at dark matter :) |
| 11:17 | <jgraham> | The thing about dark matter, it's main distinguishing feature, is that it's dark. |
| 11:17 | <MikeSmith> | heh |
| 11:18 | <jgraham> | (with apologies to Red Dwarf) |
| 11:18 | <jgraham> | Although they probably didn't put in a bogus apostrophy |
| 11:18 | <MikeSmith> | https://twitter.com/robinberjon/status/587564856406122496 from darobin |
| 11:19 | <MikeSmith> | "Have any of you tried https://reviewable.io/ for GitHub code reviews? I’d love to hear how you feel it compares to Critic for instance." |
| 11:19 | <jgraham> | MikeSmith: So would I |
| 11:20 | <jgraham> | I imagine it's more polished, at least :) |
| 11:20 | <MikeSmith> | that's not stretching your imagination much 😀 |
| 11:21 | <MikeSmith> | personally I guess I don't care so much about polish |
| 11:21 | <MikeSmith> | I think Critic gets the job done pretty well |
| 11:22 | <jgraham> | Seems like the sort of thing that is hoping to exit by being bought by Google and then shut down. Or, in the best case, GitHub and then shut down. |
| 11:22 | <MikeSmith> | the Critic UX quirks aren't too painful |
| 11:22 | <MikeSmith> | yeah maybe so |
| 11:22 | <MikeSmith> | anyway I guess I should take a look |
| 11:23 | <MikeSmith> | might actually be good |
| 11:23 | <jgraham> | Yeah, yeah, I agree, it might be great! |
| 11:23 | <jgraham> | I have to say I'm baffled by the UI at first glance though |
| 11:23 | <MikeSmith> | yeah? |
| 11:24 | <MikeSmith> | I would think for $279 / month you shouldn't be initially baffled by the UI |
| 11:24 | <jgraham> | Well https://reviewable.io/reviews/Reviewable/demo/1 has a table with like 3 different barely-distinguishable colours and some eye icons and some brackets that move when you click |
| 11:24 | MikeSmith | looks |
| 11:25 | <jgraham> | And I don't know what any of that means :) |
| 11:25 | <MikeSmith> | oh man yeah |
| 11:26 | <jgraham> | Oh, the brackets seem to be a revision range, but I'm not sure where that applies |
| 11:26 | <MikeSmith> | yeah it lets you narrow to the range |
| 11:27 | <MikeSmith> | what range I don't know |
| 11:27 | <MikeSmith> | are they revision numbers? |
| 11:27 | <MikeSmith> | what are r1-r4 |
| 11:28 | <MikeSmith> | and what is that upside-down T thing |
| 11:29 | <MikeSmith> | no tooltips on hover to provide clues |
| 11:31 | <jgraham> | MikeSmith: Anyway I would say set it up on some repo and try it out |
| 11:31 | <MikeSmith> | I think I will wait for darobin to do that |
| 11:32 | <MikeSmith> | my initial reaction is that it's no less unintuitive than Critic is |
| 11:32 | <MikeSmith> | and wouldn't seem to have any less of a learning curve |
| 11:34 | <JakeA> | annevk: in terms of ranges, I think being specific is best. "You can take between 3 and 5 sweets", I assume taking 3 and 5 is acceptable. "Drinks are cheaper between 15:00-17:00", I assume drinks are more expensive at 17:00. |
| 12:09 | <annevk> | jgraham: JakeA: here's Fetch using ", inclusive": https://github.com/whatwg/fetch/commit/6bfbf2c55fe4991bb9b4b2f5c0377fdd626aa58f |
| 12:10 | <JakeA> | +1 |
| 12:14 | <jgraham> | annevk: Looks good. |
| 12:27 | <darobin> | MikeSmith, jgraham: part of my interest isn't just the UI (which seems to be more or less on par with Critic except with nicer colours) but also the ease of setting up for new repos |
| 12:29 | <jgraham> | darobin: Weirdly (and I never thought I would say this), I dispute the nicer colours :p I acutally found the use of colour hard to understand. |
| 12:30 | <darobin> | jgraham: yeah, it's a matter of taste there, I fully agree |
| 12:32 | <jgraham> | FWIW, if I were looking for alternatives to critic, "easier to set up" would not be a big deciding factor. I mean critic is not that hard to set up. "Better supported", "more reliable" and "equally good workflow" would be the deciding aspects for me |
| 12:34 | <jgraham> | My main concern with using it would be whether it's going to be Yet Another Shortlived-Sharecropping-Startup |
| 12:58 | <darobin> | jgraham++ # Galápagos Syndrome |
| 12:58 | <darobin> | jgraham: yeah, I just wanted to put it out there as an option for people to experiment with |
| 12:58 | <darobin> | if it does get used, we'll need a way to back up the data |
| 13:00 | <annevk> | Domenic: any reason streams expose a view rather than the buffer? |
| 13:00 | <annevk> | Domenic: https://github.com/yutakahirano/fetch-with-streams/pull/34 |
| 13:43 | <wanderview> | annevk: my guess is its a convenience |
| 13:44 | <wanderview> | but an opinionated one |
| 13:45 | <annevk> | wanderview: yeah, it seems you might get network data you want to read as int32 or some such |
| 13:46 | <wanderview> | annevk: I wrote in the issue... but you can use .buffer to convert to the other view |
| 13:46 | <wanderview> | I believe |
| 13:46 | <annevk> | wanderview: sure |
| 13:46 | <annevk> | wanderview: but that's still a layer of abstraction added that you might not need/want |
| 13:46 | <wanderview> | annevk: I think this is really people saying "I don't like ArrayBuffer" :-) |
| 13:46 | <annevk> | wanderview: and an extra object allocation |
| 13:47 | <annevk> | wanderview: well, Typed Arrays happened and TC39 let it go |
| 14:13 | <wanderview> | Domenic: do envision types like ReadableStream being DOM interfaces or being part of the js engine? |
| 14:14 | <wanderview> | Domenic: asking since streams is a whatwg spec... which I guess seems DOM related to me and less a language thing |
| 14:14 | <annevk> | wanderview: he prefers that they are indistinguishable |
| 14:16 | <wanderview> | annevk: from content sure |
| 14:36 | <Ms2ger> | https://github.com/servo/html5ever/pull/125 |
| 14:37 | <Domenic> | wanderview: this is an area where my view of the world and what is differ enough that my opinion shouldn't be taken too seriously ... IMO I think URL, Encoding, and Streams should all be implemented as part of the JS engine. In reality, V8 at least says they'd rather only have one standards body to look to for consensus on what to implement. |
| 14:39 | <Domenic> | annevk: a view gives the tuple (buffer, bytesRead, offset) https://esdiscuss.org/topic/idiomatic-representation-of-buffer-bytesread which is useful when re-using buffers |
| 14:41 | <annevk> | Domenic: I see, so we assume some kind of new transfer semantic to appear? |
| 14:41 | <annevk> | Domenic: that we don't want developers to use themselves? |
| 14:41 | <wanderview> | Domenic: in the long run I probably want the outer stream objects (ReadableStream/WritableStream) in spidermonkey so I can self-host and avoid js->c++->js penalties for pure js streams |
| 14:42 | <Domenic> | annevk: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer |
| 14:43 | <Domenic> | wanderview: yeah that's what Safari seems to be doing looking at their code |
| 14:43 | <annevk> | Domenic: sure, but your proposal is that streams invokes that API rather than the developer, right? |
| 14:43 | <Domenic> | annevk: yeah, it hides it from them in general, since it needs to enforce that the buffers get detached. |
| 14:44 | <Domenic> | wanderview: and I'm going to Munich in a week to work on self-hosted streams as a "V8 extension"... would still live inside the Blink codebase though |
| 14:45 | <annevk> | Domenic: you won't be in SF the week of April 20? |
| 14:45 | <wanderview> | Domenic: I think I'm going to try to get some kind of system level test running |
| 14:45 | <Domenic> | annevk: only the 24th... regretting it now |
| 14:46 | <annevk> | Domenic: say hi to Jochen and Mike :-) |
| 14:46 | <Domenic> | annevk: oh yeah don't you live nearby there now? |
| 14:47 | <annevk> | Domenic: reasonably but still some mountains away |
| 14:48 | annevk | is trying to digest the ArrayBufferView vs ArrayBuffer arguments |
| 14:49 | <caitp> | ... is mootools broken by es6 again? |
| 14:49 | <caitp> | it never ends :> |
| 14:50 | <Domenic> | we must make a pact to no longer implement any es6 features until jsfiddle stops using mootools |
| 14:50 | <gsnedders> | caitp: this happened with ES5 too |
| 14:51 | <caitp> | yes |
| 14:53 | <wanderview> | Domenic: the test I am planning: node server that constantly sends Message blocks containing a timestamp, fetch() body stream, Transform to parse Message blocks, WritableStream consumer that does fetch() PUT to send timestamp back to server, server compares current time to received timestamp |
| 14:53 | <wanderview> | Domenic: then I will measure throughput (messages per second) and latency (timestamp differences) |
| 14:53 | <wanderview> | Domenic: is that an adequate system test for you? |
| 14:54 | <gsnedders> | It's sad that Mootools is still causing this much in way of problems and didn't fix all the problems when it first happened… |
| 14:54 | <wanderview> | maybe an extra Transform in there to trigger .read() on the output of parse Transform |
| 14:54 | <Domenic> | wanderview: yes, thank you :). Will you be doing tests of e.g. manually-scheduled microtasks to eliminate impl-specific promise overhead? (I haven't caught up on that thread yet.) |
| 14:54 | <wanderview> | or just a manual read loop |
| 14:54 | <wanderview> | Domenic: I was not planning to do manually scheduled microtasks, no... |
| 14:55 | <wanderview> | Domenic: I was just going to prototype fetch body streams to test possible implementations in the browser... if I can do it in a day or two |
| 14:56 | <Domenic> | wanderview: I think that would be prudent. Unless we believe promises will be forever slow, we shouldn't necessarily draw conclusions from their current performance, but instead look at the performance of lower-level primitives like microtasks. |
| 14:56 | <wanderview> | Domenic: the code trevnorris posted suggests to me its not the async schedule that was the problem, but instead the GC/CC |
| 14:56 | <Domenic> | wanderview: right, so the question is do we ever believe promises will get good GC support, or do we design against the current landscape? |
| 14:57 | <wanderview> | Domenic: its really hard to reason about possible future optimizations... |
| 14:57 | <wanderview> | Domenic: unless its a well known optimization as was the case with the "generators make a function each time" thing |
| 14:57 | <wanderview> | ^function^objet |
| 14:57 | <wanderview> | object |
| 14:57 | <Domenic> | well, I'm no expert, but it seems like there are two well-known optimizations here that are not being applied (although they might be hard) |
| 14:58 | <Domenic> | 1) for p.then(), if the return value is not used, don't allocate it |
| 14:58 | <Domenic> | 2) for var q = p.then(f, r); var w = q.then(f2, r2), since q only lives for one turn, make sure it stays in the young generation |
| 14:59 | <wanderview> | Domenic: I asked about (2) today... its unclear if we can do that in gecko any time soon |
| 15:00 | <annevk> | Maybe ask Mark Miller? He's been doing research into this for a long time, no? |
| 15:00 | <Domenic> | same in V8 |
| 15:00 | <Domenic> | just unclear we want to design an API to work around it, or we want to use the existence of an API that stress-tests promises to put pressure on the engines to compete on performance |
| 15:01 | <wanderview> | Domenic: if we have a real system test we can also more easily profile to see what the bottle neck is... maybe reason about what possible optimizations would do |
| 15:01 | <Domenic> | i wonder what chakra does... |
| 15:01 | <Domenic> | wanderview: yeah, that's a good point |
| 15:01 | <wanderview> | Domenic: if its GC/CC, though... I guess thats hard to predict |
| 15:01 | <Domenic> | e.g. sub in a promise implementation that is non-comformant and doesn't return anything from .then |
| 15:02 | <wanderview> | Domenic: my gut is that we are unlikely to see 300% improvements... but maybe there is a tipping point for number of objects which would grant that kind of improvement |
| 15:02 | <bradleymeck> | Domenic: can you go into a bit more depth on #1 , it seems like it would need to know if the promise will eventually have a .then attached? |
| 15:02 | <Domenic> | bradleymeck: I meant in the case where it clearly does not, via escape analysis |
| 15:02 | <bradleymeck> | ah |
| 15:03 | <wanderview> | Domenic: also, I was going to implement sync, async-with-promise, and async-with-callback if I can |
| 15:03 | <wanderview> | if I can without clamping the callback |
| 15:03 | <Domenic> | bradleymeck: like the code literally `p.then(f, r)`, the return value is not used (equivalent to `{ let q = p.then(f, r); }`) |
| 15:03 | <bradleymeck> | I would love more escape analysis optimizations they are fancy and can do magical things |
| 15:03 | <wanderview> | I think I can expose an intrinsic which does that |
| 15:03 | <bradleymeck> | yea, that would be nice |
| 15:03 | <Domenic> | wanderview: yeah makes sense, the general integration-test-framework seems like a great place to start with and then tweak the guts of. |
| 15:04 | <Domenic> | wanderview: also I think we should not trust benchmark.js and just do more manual looping... or at least make it optional... I think it is largely the source of our timer woes |
| 15:04 | <wanderview> | Domenic: my only fear is that this may take me a week or so... and the implementation of async read ship is sailing away |
| 15:04 | <wanderview> | Domenic: you brought benchmark.js to the party :-) |
| 15:04 | <wanderview> | but sure |
| 15:04 | <Domenic> | yeah, well we needed something that would run the test more than once to get rid of the crazy variance, but little did i know... |
| 15:05 | <wanderview> | Domenic: I'm just going to let this thing run open loop... stream data from server to browser and back to server as fast as possible... then dump latency and throughput number continuously |
| 15:05 | <MikeSmith> | annevk: it seems like https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit should have some attribution |
| 15:05 | <wanderview> | well... periodically |
| 15:05 | <bradleymeck> | wanderview: post it somewhere public? would like other people's benchmarks that aren't from me or trevor |
| 15:06 | <MikeSmith> | annevk: somebody just browsing to that URL from somehwere may otherwise have no clue where it came from |
| 15:06 | <wanderview> | bradleymeck: of course! it will be in the github issue once its working |
| 15:06 | <bradleymeck> | <3 |
| 15:07 | <annevk> | MikeSmith: I recommend asking Richard Barnes directly, not sure I have editing rights |
| 15:07 | wanderview | steps away for a bit |
| 15:07 | <MikeSmith> | annevk: ok |
| 16:17 | <SamB_7> | Is https://whatwg.org/style/specification in a repository somewhere? |
| 16:18 | <Domenic> | I really wish it were |
| 16:20 | <darobin> | heh |
| 16:21 | <zcorpan> | Hixie: ^ |
| 16:21 | <darobin> | that should really go into https://github.com/whatwg/resources.whatwg.org |
| 16:21 | <SamB_7> | you'd think, yeah |
| 16:30 | <Domenic> | I think Allen just adopted another piece of https://streams.spec.whatwg.org/#conventions ... ES spec is slowly becoming more readable. https://bugs.ecmascript.org/show_bug.cgi?id=4273 |
| 16:30 | <Domenic> | (Streams's "call-with-rethrow" => ES's new "Perform") |
| 16:37 | <annevk_> | Domenic: maybe not: https://twitter.com/awbjs/status/587654507997167618 |
| 16:37 | <Domenic> | oh :( |
| 16:37 | <Domenic> | I think we have some of those, but honestly I'd rather do something like Assert-does-not-throw |
| 16:40 | <wanderview> | Domenic: do you think it would be possible to make the ReadableStream lock a function of the underlying source? |
| 16:40 | <Domenic> | wanderview: hmm say more... |
| 16:41 | <wanderview> | Domenic: for the case where the underlying source is native... its really the place I want to lock instead of js outer object... for example, to prevent Response.text() which is also implemented in c++ |
| 16:41 | <wanderview> | I guess I can do this with equivalent magic, but doesn't need to be in the spec |
| 16:41 | <Domenic> | wanderview: hmm does this have user-observable implications though? |
| 16:41 | <Domenic> | yeah |
| 16:41 | <Domenic> | I mean conceptually Response.text() does this.body.getReader() |
| 16:42 | <Domenic> | And presumably will be specced that way? |
| 16:42 | <Domenic> | But I'm open to ideas here if we can develop them a bit more. |
| 16:42 | <wanderview> | Domenic: I don't remember what the fetch-with-streams thing says |
| 16:43 | <Domenic> | ah yeah it does. They all indirect through "Response's associated consume body algorithm" which acquires a reader |
| 16:44 | <SamB_7> | what is this "lock" of which you speak? |
| 16:44 | <Domenic> | It then says "Let chunks be the result of using implementation-specific mechanisms to repeatedly read from stream, using the exclusive access granted by reader, until stream becomes closed or errored." which IMO is a nice turn of phrase. |
| 16:44 | <SamB_7> | did JS get threading or something? |
| 16:44 | <Domenic> | SamB_7: https://streams.spec.whatwg.org/#locking |
| 16:44 | <wanderview> | SamB_7: its a lock on a stream |
| 17:01 | <annevk> | Domenic: I don't understand the reusing buffers argument and I'm having trouble finding a good reference for it |
| 17:01 | <Domenic> | annevk: let me update one of the old examples |
| 17:03 | <wanderview> | Domenic: btw, if you think you will have a self-hosted Transform next week, we could run my integration test in both firefox and chrome... that would help isolate implementation issues |
| 17:06 | <wanderview> | Domenic: tyoshino's patch to remove setTimeout from benchmark.js does help a lot, btw... even bluebird avoids the clamping now |
| 17:09 | <Domenic> | annevk: https://gist.github.com/domenic/dab9e8da245cb4fe6027 |
| 17:10 | <Domenic> | wanderview: hmm ok, I can try to do that... hmm. |
| 17:10 | Domenic | lunches |
| 17:11 | <annevk> | Domenic: doesn't that reuse the view, not the buffer? |
| 17:18 | <annevk> | I think I sort of get it now |
| 17:20 | SamB_7 | wonders why the underlying source wouldn't just be locked to the stream itself? |
| 17:48 | <Domenic> | annevk: each result.value is a distinct view, backed by the same buffer |
| 18:50 | <annevk> | Domenic: but different parts of that buffer? |
| 18:50 | <Domenic> | annevk: nah same part, when you're passing it back in to .read() you're saying "I don't want these bytes any more, please overwrite them." |
| 18:50 | <annevk> | Domenic: what happens to the old references of the buffer while you write to it asynchronously? |
| 18:51 | <Domenic> | annevk: ok, I have to be more careful about what I mean by same "buffer." Different array buffer, same backing memory |
| 18:51 | <annevk> | Domenic: so how can that not work if you simply return an ArrayBuffer? |
| 18:52 | <Domenic> | annevk: we'd need to return { buffer, bytesRead } |
| 18:52 | <annevk> | Domenic: why can't you allocate an ArrayBuffer of the correct size? |
| 18:53 | <Domenic> | annevk: because then it will continually shrink as you keep passing it through the funnel... |
| 18:54 | <Domenic> | (typing out a scenario here) |
| 18:54 | <annevk> | I guess I was imagining you'd have chunk size separate |
| 18:55 | <annevk> | and just allocate for whatever you read |
| 18:55 | <Domenic> | Allocate 10 MiB ArrayBuffer ab. Pass it into read() which transfers it to a new 10 MiB ArrayBuffer ab2 and then passes that to read(2) or equivalent. read(2) only gets 2 MiB from the socket. So now we transfer the backing memory to a new ArrayBuffer ab3 of size 2 MiB, which we return the user. But what happened to the extra 8 MiB? It was released as free |
| 18:55 | <Domenic> | since nobody has an ArrayBuffer that references it anymore. |
| 18:56 | <Domenic> | (so now you pass back in ab3 to another call to read(), but the most you can get is 2 MiB... maybe it gives you back 512 KiB, freeing the other 1.5 MiB ... sad times.) |
| 18:59 | <Domenic> | If we didn't have to do the transfer thing, we could just return Promise<number of bytes read> and modify the buffer in place |
| 18:59 | <Domenic> | Since we have to transfer it becomes Promise<{ newBufferWithSameBackingMemory, bytesRead }>, which we collapse into Promise<ABC> |
| 19:00 | <Domenic> | *ABV |
| 19:01 | <annevk> | Thanks for going into detail |
| 19:02 | <annevk> | Sounds reasonable, will probably have to review tomorrow |
| 19:02 | <Domenic> | any time, thanks for the review |
| 19:40 | <miketaylr> | zcorpan: too speedy https://cloudup.com/cbFFdNafldu |
| 19:41 | <wanderview> | Domenic: I guess I would slice the buffer if the "available bytes" was something huge... cap it some value to avoid blowing up memory with a single contiguous buffer |
| 19:42 | <zcorpan> | miketaylr: ba dum tsss |
| 19:57 | <Domenic> | TabAtkins: any way to do appendices in Bikeshed? |
| 19:58 | <TabAtkins> | Domenic: I mean, you can just add an appendix. It's a section like any other. What are you wanting, specifically? |
| 19:59 | <Domenic> | TabAtkins: starting with A instead of a number, I guess. |
| 20:00 | <TabAtkins> | Nothing special for that, no. |
| 20:00 | <TabAtkins> | Just put "Appendix A: Foo" in the title. |
| 20:00 | <Domenic> | heh "7: Appendix A: Foo" |
| 20:00 | <TabAtkins> | <h2 class="no-num"> |
| 20:00 | <Domenic> | Right! |
| 20:40 | <terinjokes> | what does "These attributes are not intended for use by software that is not known to the administrators of the site that uses the attributes." |
| 20:40 | <terinjokes> | mean (from the HTML5 spec) |
| 20:43 | <caitp-> | i think it means "there are no standard data-* attributes that client software can depend on being there, if you need that, use microdata" |
| 20:46 | <terinjokes> | caitp-: so data-* should only be used by JS the client themselves write? |
| 20:46 | <caitp-> | i guess |
| 20:46 | <caitp-> | or whatever libraries they want to use |
| 20:46 | <caitp-> | but not client software |
| 20:46 | <terinjokes> | or if they include my script, me using those data attributes are acceptable |
| 20:47 | <terinjokes> | cool. we had a small discussion with a customer about what it means |
| 20:47 | <caitp-> | i'd ask hixie or someone for clarification, maybe they meant something else, but that's how it reads to me |
| 20:48 | <caitp-> | like, google shouldn't be using data- attributes to help rank a site |
| 20:49 | <terinjokes> | right, that makes sense |
| 20:51 | <TabAtkins> | That's correct. data-* aren't meant to be used for standardized markup across unrelated documents. |
| 20:52 | <terinjokes> | and i assume that using attributes that do no exist are bad (as they might have future specified manning, ala JavaScript prototype fun) |
| 20:54 | <bradleymeck> | terinjokes: you can upgrade from dangerous prefixes to unprefixed (css prefix fiasco), the reverse is more difficult (ala js prototype madness) |
| 20:55 | <terinjokes> | bradleymeck: yep, yep |
| 20:55 | terinjokes | spends 5 minutes fixing the bug |