/irc-logs / freenode / #whatwg / 2015-04-08 / end

Options:

Previous day, Next day

  1. # Session Start: Wed Apr 08 00:00:00 2015
  2. # Session Ident: #whatwg
  3. # [00:05] * Krinkle is now known as Krinkle|detached
  4. # [00:06] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Read error: Connection reset by peer)
  5. # [00:07] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
  6. # [00:08] * Joins: jwalden (~waldo@216.3.171.26)
  7. # [00:10] * Joins: jsbell (jsbell@nat/google/x-lkswotskrwfavapa)
  8. # [00:14] * Quits: plutoniix (~plutoniix@node-1a3k.pool-101-109.dynamic.totbb.net) (Quit: จรลี จรลา)
  9. # [00:22] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
  10. # [00:24] * Quits: bzed (~bzed@devel.recluse.de) (Read error: Connection reset by peer)
  11. # [00:24] * Joins: bzed (~bzed@devel.recluse.de)
  12. # [00:27] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  13. # [00:30] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
  14. # [00:30] * Joins: mven (~textual@cpe-72-183-104-138.austin.res.rr.com)
  15. # [00:30] * Quits: mven (~textual@cpe-72-183-104-138.austin.res.rr.com) (Excess Flood)
  16. # [00:32] * Joins: benwerd_ (~benwerd@178.62.73.90)
  17. # [00:32] * Quits: benwerd (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
  18. # [00:32] * Joins: benwerd (~benwerd@199.87.84.238)
  19. # [00:32] * Quits: Joseph_Silber (~JosephSil@ool-43513ca2.dyn.optonline.net) (Ping timeout: 244 seconds)
  20. # [00:35] * Joins: rcombs (~rcombs@rcombs.me)
  21. # [00:35] <wanderview> Domenic: has the performance impact of always returning a Promise from read() and write() been discussed somewhere?
  22. # [00:36] <Domenic> wanderview: yeah. promises are cheap when well-optimized, and certainly cheaper than I/O.
  23. # [00:36] * Quits: benwerd_ (~benwerd@178.62.73.90) (Ping timeout: 265 seconds)
  24. # [00:37] <wanderview> Domenic: I guess I'm curious about how one optimizes out the object creation and the required async micro-task cost... it seems those are harder things to optimize out than say the generator object creation
  25. # [00:38] * heycam|away is now known as heycam
  26. # [00:38] <Domenic> wanderview: yeah you don't optimize out object creation, but VMs are good at creating objects. The micro-task cost we discussed and eventually landed on the fact that most reads are going to be async anyway, so the microtask adds no extra overhead.
  27. # [00:38] <wanderview> Domenic: I mean.. I'm willing to accept Promise costs periodically... but once every 4096 bytes may be a bit much...
  28. # [00:39] <wanderview> Domenic: in the case where you have chunks buffered up... it seems like you would want to be able to get all of them synchronously, though... no?
  29. # [00:39] <Domenic> right, that was the original design with while (rs.state === "readable") { rs.read(); }
  30. # [00:39] <Domenic> (read() being sync in that case)
  31. # [00:39] <wanderview> Domenic: I vaguely remember that... what was the issue that forced the change?
  32. # [00:41] <Domenic> wanderview: a combination of wanting rs.readInto(buffer) + non-epoll streams who do their work in a threadpool or similar means you need something like async read(), or setAllocator
  33. # [00:41] <wanderview> Domenic: is ReadableByteStream or the new precise-flow-control stuff solving this by letting me say "read up to this much data before resolving"?
  34. # [00:41] <Domenic> Unclear how setAllocator would work though given that I/O is IPC though, now that I think about it
  35. # [00:42] <wanderview> Domenic: I/O doesn't have to be IPC... you can open a file descriptor in the parent and then dup(2) it to the child process... then file reads are in the child process
  36. # [00:42] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
  37. # [00:42] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
  38. # [00:42] * Joins: scor (~scor@drupal.org/user/52142/view)
  39. # [00:42] <Domenic> wanderview: the intent of ReadableByteStream's read(view) is that view.byteLength is at least a hint, although I think we didn't want to make it binding...
  40. # [00:42] <wanderview> Domenic: network is probably always in the parent process behind IPC, though (because of http 1.1 channels multiplexed on same socket, etc)
  41. # [00:42] <Domenic> wanderview: ah OK, just was thinking of the other day when you were talking about IPC costs...
  42. # [00:43] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 250 seconds)
  43. # [00:43] <Domenic> my vision of read(view) was that you'd pass that view pretty directly to read(2)
  44. # [00:43] <Domenic> so for socket streams you might get back less than view.byteLength
  45. # [00:43] <Domenic> but for file streams, unless you're at end of file, you'll probably get view fully filled
  46. # [00:43] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  47. # [00:44] <Domenic> IIRC read(2) has an option to not return until the buffer is filled ... but it doesn't work with nonblocking sockets?
  48. # [00:44] <Domenic> Ah no, it's recv(2). MSG_WAITALL
  49. # [00:45] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  50. # [00:46] <Domenic> we could make the implementation concatenate buffers i guess? or let that be an option!? i don't see any reason why it's impossible, I was just going for the more direct mapping
  51. # [00:47] <Domenic> it's a latency vs. efficiency thing i guess, which perhaps is best to leave to applications to decide?
  52. # [00:48] <wanderview> sorry, on phone
  53. # [00:48] <Domenic> np
  54. # [00:48] <Domenic> reminds me of this issue https://github.com/whatwg/streams/issues/171
  55. # [00:50] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
  56. # [00:51] <Domenic> It is true in general that browser promise impls are wildly unoptimized. User-land versions regularly achieve 4x performance and 1/4th the memory consumption, and they don't even have access to all the tricks browsers do (like skipping the microtask queue if calling in from C++)
  57. # [00:51] <wanderview> Domenic: I wonder if we could do something like .read(numDesiredChunks)
  58. # [00:52] <wanderview> and the promise resolves when that many are available
  59. # [00:52] <Domenic> wanderview: that seems pretty reasonable. Would kind of want to see data that this was a bottleneck, or a non-performance use case, before doing so.
  60. # [00:53] <Domenic> I'll file an issue to track to see if anyone has non-perf use cases
  61. # [00:53] <wanderview> Domenic: it seems more appropriate for ReadableByteStream... but might be usable in ReadableStream
  62. # [00:54] <Domenic> wanderview: maybe for RBS it's .read(view, { waitUntilFull: true })
  63. # [00:54] <wanderview> Domenic: thinking of when you are reading some framed protocol... you probably don't want to get woken up until the next frame is completely there
  64. # [00:54] <wanderview> Domenic: I don't think c++ can skip the microtask, can it? I mean.. it seems like it risks accidentally breaking the micro task guarantee in your API
  65. # [00:56] <Domenic> wanderview: it's hard to say precisely what I mean here as the area is so complicated. But the main idea is that C++ always enters back into JS from a clean stack, and that's what microtasks guarantee: a clean stack. One way of seeing this is that the very first thing done after transitioning from C++ to JS is to exhaust the microtask queue. So the very
  66. # [00:56] <Domenic> first thing that happens on the JS side, after doing resolve_promise_from_cpp(cpp_p, cpp_v), is calling p's onFulfilled handler with v
  67. # [00:57] <Domenic> IIUC SpiderMonkey doesn't actually implement a microtask queue and just uses their task queue, so maybe it is not so efficient in SpiderMonkey.
  68. # [00:58] * Joins: scor (~scor@drupal.org/user/52142/view)
  69. # [00:59] <wanderview> Domenic: right... but its still an async runnable even if it skips to the head of the (micro)task queue
  70. # [00:59] <othermaciej> the spec says to drain the microtask queue between every regular task queue item
  71. # [00:59] <othermaciej> (if I read it correctly)
  72. # [01:00] <wanderview> and I guess unwinding and rewinding the stack has noticeable perf impacts when done in too tight a loop
  73. # [01:00] <othermaciej> and after completing execution of a <script> element
  74. # [01:00] <othermaciej> I don’t believe it says to do anything on entry from C++ to JS
  75. # [01:00] * Joins: KevinMarks_ (~KevinMark@sjspeed.wiline.com)
  76. # [01:01] <othermaciej> it might be you can do it like that and have no observable behavior difference but it is not obvious how offhand
  77. # [01:02] <othermaciej> in particular, you can exit JS to C++ and re-enter JS sometimes without having performed microtasks
  78. # [01:02] <Domenic> othermaciej: hmm, maybe i am confused. But that was my interpretation of the spec, modulo the spec not having any "entry from C++ to JS" concept.
  79. # [01:02] <Domenic> Oh, that makes sense
  80. # [01:02] <othermaciej> this will occur if you have multiple event handlers for the same event, for instance
  81. # [01:02] <Domenic> Or just arr.forEach(cb), where hypothetically forEach is implemented in C++.
  82. # [01:02] * Joins: satazor (~satazor@117.195.115.89.rev.vodafone.pt)
  83. # [01:03] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  84. # [01:03] <othermaciej> the spec is closer to saying that microtasks are run on *exit* from JS to C++, except only if you are on a “clean stack”
  85. # [01:03] <othermaciej> where “clean” == in the top level event loop or in the html parser
  86. # [01:04] <othermaciej> and also it sometimes drains the queue on times you didn’t just exit from JS, in case right when you exited, you did not have a clean stack
  87. # [01:04] <othermaciej> that is how I understand it anyway
  88. # [01:05] * Krinkle|detached is now known as Krinkle
  89. # [01:05] <Domenic> I guess the point I was really trying to make was: in Node.js, if you do `fs.readFile(..., result => resolvePromise(p, result))`, resolvePromise has to actually schedule a microtask to ensure p's handlers are called with a clean stack. So we wait for all the rest of the JS in that event loop turn to run, then unwind the stack, then run the microtask queue,
  90. # [01:05] <Domenic> with several (perf-impacting) C++-to-JS transitions. Whereas in browsers, you don't have to pay that cost.
  91. # [01:06] <Domenic> JS environments which try to completely control the event queue, like Angular, do similar optimizations
  92. # [01:07] <Domenic> where they technically run their promise handlers "sync" but if you're programming correctly-according-to-Angular, it's unobservable.
  93. # [01:07] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
  94. # [01:11] * Joins: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net)
  95. # [01:15] * Krinkle is now known as Krinkle|detached
  96. # [01:21] * Krinkle|detached is now known as Krinkle
  97. # [01:21] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  98. # [01:22] <wanderview> Domenic: are you trying to add an interface contract definition for ReadableStream and WritableStream in this issue? https://github.com/whatwg/streams/issues/312
  99. # [01:23] <Domenic> wanderview: that thread has lost me a bit tbh...
  100. # [01:23] <wanderview> Domenic: I think it would be really helpful to have definitions of ReadableStream and WritableStream separate from the default implementation adapting JS functions
  101. # [01:25] <Domenic> wanderview: all ReadableStream instances must necessarily adapt JS functions (or JS manifestations of C++ functions)... other things obeying the "readable stream contract" might work differently though
  102. # [01:25] <Domenic> the necessity is because myFetchReadableStream.read === myFileReadableStream.read, if both variables are ReadableStreams.
  103. # [01:26] <wanderview> Domenic: so a DOM created ReadableStream representing some C++ implementation like a file stream has to be created through the ReadableStream Constructor?
  104. # [01:26] <wanderview> Domenic: why is myFetchReadableStream.read === myFileReadableStream.read a necessity?
  105. # [01:26] <Domenic> wanderview: I mean, it has to obey the observable invariants; if there are tricks you have for getting around that, use them, but...
  106. # [01:27] <Domenic> wanderview: if they are both ReadableStreams then they have the same prototype and thus the same method
  107. # [01:27] <Domenic> wanderview: if one is a FetchReadableStream and another is a FileReadableStream then yeah they can be different
  108. # [01:27] <Domenic> wanderview: analogy---promises
  109. # [01:27] <Domenic> wanderview: all C++-created promises are, at least in V8/Blink, created "via the Promise constructor"
  110. # [01:27] <wanderview> Domenic: I guess what I am saying is, it would be nice if the spec defined the observable invariants instead of making me try to dig them out of a pile of js
  111. # [01:28] <Domenic> even though the promises will be backed by very different behavior
  112. # [01:28] <Domenic> yeah, agreed on that. We want that anyway so we can say---or better, programatically test---that ReadableByteStream behaves the same as ReadableStream.
  113. # [01:28] <Domenic> the templated tests are a start
  114. # [01:30] * Joins: eBureau (~Bruno@181.164.77.172)
  115. # [01:31] * Krinkle is now known as Krinkle|detached
  116. # [01:32] <wanderview> Domenic: so you are saying you want JS-created ReadableStream objects to have exactly the same prototype as DOM API created ReadableStream objects?
  117. # [01:33] <Domenic> wanderview: yeah, exactly, just like Promise.
  118. # [01:33] <wanderview> Domenic: pretend I don't know much about Promise :-)
  119. # [01:34] <Domenic> hmm, well, then, yes. The underlying source is meant to provide the customization hooks
  120. # [01:34] <Domenic> The underlying source could be a JS facade over a C++ object, for sure
  121. # [01:34] <wanderview> Domenic: I guess then it would be nice to have a source interface definition... and separate out the js-adapter specifics into a separate implementation of that interface
  122. # [01:35] * Joins: rcombs (~rcombs@rcombs.me)
  123. # [01:35] <Domenic> hmm what's a "source interface definition"?
  124. # [01:35] <wanderview> Domenic: the underlying source
  125. # [01:35] <Domenic> https://streams.spec.whatwg.org/#rs-constructor kind of tries
  126. # [01:36] <Domenic> what are js-adapter specifics? there are no implementations of the underlying source interface in the streams spec
  127. # [01:36] <Domenic> fetch-with-streams has one
  128. # [01:36] <wanderview> Domenic: nm... I don't think what I asked makes sense
  129. # [01:37] <wanderview> Domenic: do you anticipate things like ReadableStream.pipeTo() operating on the public ws.write() method? so allowing monkey patching
  130. # [01:38] <wanderview> the current text pointing at the ref implementation suggests it does
  131. # [01:38] <Domenic> An implementation could always do something like ReadableStream.prototype.read = function () { switch (this@[[hiddenType]]) { case "user-created": return userCreatedImpl(this); case "fetch": return fetchStreamImpl(this); } }; where user-created follows more or less the exact spec algorithm and fetchStreamImpl manages to maintain all its observable invariants
  132. # [01:38] <Domenic> but is implemented differently.
  133. # [01:39] <Domenic> Then we have to tease out what the observable invariants are. I guess maybe that's what you're asking for.
  134. # [01:39] <wanderview> Domenic: I'm asking about monkey-patching .write in this case
  135. # [01:39] <Domenic> sorry I was still on the previous subject
  136. # [01:39] <wanderview> but I guess .read is the same
  137. # [01:39] * Quits: benwerd (~benwerd@199.87.84.238)
  138. # [01:40] <wanderview> Domenic: I think the "underlying source" model maps reasonably well to the DOM idiom of having an "inner object"
  139. # [01:40] <Domenic> hmm interesting
  140. # [01:40] <wanderview> but I guess DOM APIs typically operate explicitly on the inner objects... not on the public APIs
  141. # [01:40] <Domenic> Ah interesting
  142. # [01:40] <wanderview> so rs.pipe(ws) would do something like "write data to ws's underlying sink" instead of calling ws.write()
  143. # [01:41] <Domenic> regarding monkey-patching write and pipeTo... I'm a bit torn on how to handle this. I've probably given up on it using `this.read()` etc.; it can use tamper-proof versions for operating on `this` to reduce complexity. But it seems quite important to allow polymorphic dispatch on the *argument*.
  144. # [01:41] <wanderview> Domenic: the polymorphism is achieved in this spec by swapping out the underlying sink, no?
  145. # [01:41] <Domenic> That said as we went through in some thread a while ago it's hard to make that work while still allowing unobservable off-main-thread piping
  146. # [01:42] <Domenic> wanderview: heh, I guess that is where my argument leads...
  147. # [01:42] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  148. # [01:42] <Domenic> wanderview: my hope was that you could create structurally similar writable streams that obey the same contract without being exactly WritableStreams
  149. # [01:42] <wanderview> Domenic: going to the inner objects is nice for DOM people like me... but I wonder if its not very javascripty
  150. # [01:42] <Domenic> Yeah, it's definitely not very JavaScriptey. But neither is off-main-thread piping :P
  151. # [01:42] <wanderview> Domenic: that seems at odds with requiring prototypes to be exact matches
  152. # [01:43] <Domenic> wanderview: nothing requires the prototypes to be exact matches, I was just saying, if they are, then they need to be the same impl
  153. # [01:43] <wanderview> Domenic: if you want pure duck types then I don't think we should require exact prototype matches
  154. # [01:43] <Domenic> wanderview: you *could* have separate FetchReadableStream that is written from scratch in its own spec and doesn't reference the stream spec at all, except trying to be duck-compatible.
  155. # [01:43] <Domenic> But that seems like a waste of effort.
  156. # [01:43] <wanderview> Domenic: like... I think the JS adapter stuff should be in a JSReadableStream that chains from ReadableStream, etc
  157. # [01:44] <Domenic> Anyway, my hope might be silly, is where I was going with that.
  158. # [01:44] <wanderview> and there is no spec'd concrete implementation of ReadableStream
  159. # [01:44] <Domenic> This just feels very silly when you go back to the promise analogy
  160. # [01:45] <Domenic> We don't have every promise-returning API on the web platform creating their own version of the Promise class just so they can get different backing behavior
  161. # [01:45] <wanderview> Domenic: I don't think we have the optimization concerns with off-main-thread piping, etc, with Promises that we do here...
  162. # [01:45] * Quits: bholley (~bholley@50.174.198.217)
  163. # [01:45] <wanderview> something has to give here :-) I don't think all these requirements are compatible
  164. # [01:46] <Domenic> I am leaning toward abandoning duck-compatibility for writable streams
  165. # [01:46] <wanderview> Domenic: what about for ReadableStreams?
  166. # [01:47] <Domenic> wanderview: unsure, nothing accepts them right now (except their own methods, and JS functions which will operate on a duck level)
  167. # [01:47] <wanderview> Domenic: but their own methods will operate directly on underlying source?
  168. # [01:47] <Domenic> wanderview: yeah, definitely.
  169. # [01:48] <wanderview> Domenic: is there an existing issue for this or shall I write a new one?
  170. # [01:48] <Domenic> wanderview: well, I was for a while planning on making pipeTo operate in terms of this.read() and friends, but after doing TeeReadableStream I am leaning away from that.
  171. # [01:48] <wanderview> I think it was partially discussed in the transfer issue, but seems it deserves its own issue
  172. # [01:48] <Domenic> wanderview: we kind of got sidetracked in the ... web socket issue, was it? into these
  173. # [01:48] <Domenic> ah yeah
  174. # [01:48] <wanderview> Domenic: I'll write one
  175. # [01:49] <Domenic> ok cool
  176. # [01:49] <Domenic> Hmm, promises enable duck-compatibility with Promise.resolve casting .then'ables ..... that's a more sound model actually. Also a complicated one that we probably don't need to build in to the platform?
  177. # [01:50] <Domenic> It should be pretty straightforward to write a JS function duckReadableStreamToRealReadableStream
  178. # [01:50] <Domenic> Then people can use that if they need to
  179. # [01:50] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
  180. # [01:51] <wanderview> Domenic: I do think a ReadableStream wrapper constructor would be nice... making it take a duck typed stream would be reasonably
  181. # [01:51] <Domenic> The promise-esque alternative being that we have ReadableStream.cast = duckReadableStreamToRealReadableStream and every ReadableStream-accepting API does ReadableStream.cast first (like all promise-accepting APIs do Promise.resolve first). Really unnecessary.
  182. # [01:52] <Domenic> brb cafe closing!!
  183. # [01:52] * wanderview forgot he was in pacific time zone.
  184. # [01:53] * Quits: jernoble (~jernoble@17.202.49.155) (Quit: Computer has gone to sleep.)
  185. # [01:53] * Quits: jwalden (~waldo@216.3.171.26) (Quit: about to board, see you once in the sky)
  186. # [01:54] * Joins: rcombs (~rcombs@rcombs.me)
  187. # [01:55] * Quits: satazor (~satazor@117.195.115.89.rev.vodafone.pt) (Remote host closed the connection)
  188. # [02:02] * Joins: eBureau (~Bruno@181.164.77.172)
  189. # [02:03] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  190. # [02:04] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  191. # [02:04] * Joins: scor (~scor@drupal.org/user/52142/view)
  192. # [02:06] * Quits: ap (~ap@17.114.216.168)
  193. # [02:07] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
  194. # [02:07] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  195. # [02:10] * Quits: dbaron (~dbaron@2620:101:80fb:224:2d19:d044:d21e:612e) (Ping timeout: 245 seconds)
  196. # [02:12] <Domenic> ok, back, although i should probably head out for the day
  197. # [02:12] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  198. # [02:13] <terinjokes> Domenic: you should go home
  199. # [02:13] <Domenic> this Promise.resolve analogy soothes me greatly
  200. # [02:13] <Domenic> (in general any time I can analogy to promises, I feel more confident)
  201. # [02:14] <Domenic> we can let pipeTo only accept true WritableStreams, and if in the future that becomes limiting we can add WritableStream.cast or similar as a mechanism for coping
  202. # [02:16] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
  203. # [02:20] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Ping timeout: 250 seconds)
  204. # [02:21] * Joins: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th)
  205. # [02:21] <wanderview> Domenic: https://github.com/whatwg/streams/issues/321
  206. # [02:21] <wanderview> have a good night!
  207. # [02:24] * Quits: jyasskin (~jyasskin@216.239.45.64) (Quit: My computer has gone to sleep. ZZZzzz…)
  208. # [02:26] * Joins: rcombs (~rcombs@rcombs.me)
  209. # [02:26] * Joins: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca)
  210. # [02:27] * Quits: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th) (Read error: Connection reset by peer)
  211. # [02:28] * Joins: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th)
  212. # [02:28] * Quits: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca) (Remote host closed the connection)
  213. # [02:29] * Quits: jsbell (jsbell@nat/google/x-lkswotskrwfavapa) (Quit: There's no place like home...)
  214. # [02:29] * Joins: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca)
  215. # [02:31] * Quits: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th) (Read error: Connection reset by peer)
  216. # [02:31] * Joins: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th)
  217. # [02:31] * Quits: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca) (Client Quit)
  218. # [02:32] * Joins: mven (~textual@cpe-72-183-104-138.austin.res.rr.com)
  219. # [02:32] * Quits: mven (~textual@cpe-72-183-104-138.austin.res.rr.com) (Excess Flood)
  220. # [02:38] * Quits: bzed (~bzed@devel.recluse.de) (Remote host closed the connection)
  221. # [02:41] * Joins: bzed (~bzed@devel.recluse.de)
  222. # [02:42] * Joins: jacobolu_ (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
  223. # [02:42] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 272 seconds)
  224. # [02:43] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  225. # [02:44] * Joins: jwalden (~waldo@67.142.235.252)
  226. # [02:45] * Quits: bnicholson (~bnicholso@2620:101:80fc:224:d1a2:1dd0:3450:b5cf) (Quit: This computer has gone to sleep)
  227. # [02:46] * Quits: jacobolu_ (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
  228. # [02:46] * Joins: rcombs (~rcombs@rcombs.me)
  229. # [02:46] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
  230. # [02:56] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  231. # [02:57] * Joins: rcombs (~rcombs@rcombs.me)
  232. # [02:57] * Joins: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net)
  233. # [02:57] * Joins: jyasskin (~jyasskin@216.239.45.64)
  234. # [03:01] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-tpiowtciyqvrzpzh) (Quit: Connection closed for inactivity)
  235. # [03:04] * Quits: othermaciej (~mjs@17.244.161.57) (Quit: othermaciej)
  236. # [03:04] * Quits: KevinMarks_ (~KevinMark@sjspeed.wiline.com) (Ping timeout: 250 seconds)
  237. # [03:10] * Quits: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru) (Quit: Textual IRC Client: www.textualapp.com)
  238. # [03:12] * Quits: jyasskin (~jyasskin@216.239.45.64) (Quit: My computer has gone to sleep. ZZZzzz…)
  239. # [03:13] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
  240. # [03:17] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
  241. # [03:17] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
  242. # [03:17] * Joins: scor (~scor@drupal.org/user/52142/view)
  243. # [03:18] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  244. # [03:19] * Joins: weinig (~weinig@17.244.160.230)
  245. # [03:23] * Joins: othermaciej (~mjs@76.74.153.41)
  246. # [03:30] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
  247. # [03:30] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
  248. # [03:31] * Quits: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net) (Client Quit)
  249. # [03:31] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
  250. # [03:31] * Joins: tripu (~tripu@p7223-ipngn11001marunouchi.tokyo.ocn.ne.jp)
  251. # [03:38] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
  252. # [03:43] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  253. # [03:44] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  254. # [03:51] * Joins: scor (~scor@drupal.org/user/52142/view)
  255. # [03:56] * Joins: svl (~me@200.123.210.20)
  256. # [03:57] * Quits: strugee (~strugee@2602:d8:a048:e600:224:8cff:fec0:402) (Ping timeout: 265 seconds)
  257. # [03:57] * Joins: strugee (~strugee@2602:d8:a048:e600:224:8cff:fec0:402)
  258. # [03:57] * Quits: iamstef (sid12605@gateway/web/irccloud.com/x-iozjblydqusrmjjq) (Ping timeout: 265 seconds)
  259. # [03:57] * Quits: JonathanNeal (sid5831@gateway/web/irccloud.com/x-umlrbilawxeqxtwm) (Ping timeout: 265 seconds)
  260. # [03:57] * Quits: parshap (sid18846@gateway/web/irccloud.com/x-qtjrafxbnoaqnudr) (Ping timeout: 265 seconds)
  261. # [03:57] * Quits: ato (sid16069@gateway/web/irccloud.com/x-csfyqyroxqqulajk) (Ping timeout: 265 seconds)
  262. # [03:58] * Quits: arv (sid4269@gateway/web/irccloud.com/x-jobczpfaxqxqjygr) (Ping timeout: 265 seconds)
  263. # [03:58] * Joins: ato (sid16069@gateway/web/irccloud.com/x-ukkfrhsyfivwdmdz)
  264. # [03:58] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 265 seconds)
  265. # [03:59] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-hpiomwiwhdqxlgju) (Ping timeout: 265 seconds)
  266. # [03:59] * Quits: svl (~me@200.123.210.20) (Read error: Connection reset by peer)
  267. # [04:00] * Joins: arv (sid4269@gateway/web/irccloud.com/x-eorwzpxtjneavgjl)
  268. # [04:01] * Joins: JonathanNeal (sid5831@gateway/web/irccloud.com/x-fuxitvwitojnboku)
  269. # [04:01] * Joins: iamstef (sid12605@gateway/web/irccloud.com/x-ymqpvjqghqivufvi)
  270. # [04:01] * Joins: parshap (sid18846@gateway/web/irccloud.com/x-aobwogvcedhpopls)
  271. # [04:02] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-uzxurnbyhpawtjai)
  272. # [04:05] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
  273. # [04:06] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
  274. # [04:08] * Quits: jwalden (~waldo@67.142.235.252) (Quit: landing, g'bye)
  275. # [04:12] * Quits: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
  276. # [04:13] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  277. # [04:21] * Quits: othermaciej (~mjs@76.74.153.41) (Quit: othermaciej)
  278. # [04:23] * Joins: svl (~me@200.123.210.20)
  279. # [04:25] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-uzxurnbyhpawtjai) (Quit: Connection closed for inactivity)
  280. # [04:29] * Quits: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th) (Read error: Connection reset by peer)
  281. # [04:31] * Joins: plutoniix (~plutoniix@ppp-58-11-121-178.revip2.asianet.co.th)
  282. # [04:31] * Quits: weinig (~weinig@17.244.160.230) (Quit: weinig)
  283. # [04:43] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
  284. # [04:58] * Quits: svl (~me@200.123.210.20) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  285. # [05:04] * heycam is now known as heycam|away
  286. # [05:09] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
  287. # [05:10] * Joins: xiinotulp (~plutoniix@119.63.87.222)
  288. # [05:12] * Quits: plutoniix (~plutoniix@ppp-58-11-121-178.revip2.asianet.co.th) (Ping timeout: 250 seconds)
  289. # [05:14] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 252 seconds)
  290. # [05:18] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
  291. # [05:18] * xiinotulp is now known as plutoniix
  292. # [05:23] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  293. # [05:27] * Joins: weinig (~weinig@c-98-234-191-242.hsd1.ca.comcast.net)
  294. # [05:28] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 245 seconds)
  295. # [05:31] * Joins: eBureau (~Bruno@181.164.77.172)
  296. # [05:32] * Quits: weinig (~weinig@c-98-234-191-242.hsd1.ca.comcast.net) (Quit: weinig)
  297. # [05:43] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  298. # [05:47] * Quits: rniwa (~rniwa@17.245.30.85) (Quit: My Mac has gone to sleep. ZZZzzz…)
  299. # [05:48] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 245 seconds)
  300. # [05:53] * heycam|away is now known as heycam
  301. # [05:54] * Joins: jyasskin (~jyasskin@172.56.38.23)
  302. # [06:02] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  303. # [06:27] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
  304. # [06:31] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  305. # [06:36] * Quits: jyasskin (~jyasskin@172.56.38.23) (Ping timeout: 265 seconds)
  306. # [06:38] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
  307. # [06:38] * Joins: jyasskin (~jyasskin@172.56.38.23)
  308. # [06:57] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 250 seconds)
  309. # [06:58] * Quits: jyasskin (~jyasskin@172.56.38.23) (Ping timeout: 244 seconds)
  310. # [07:00] * Joins: jyasskin (~jyasskin@172.56.38.23)
  311. # [07:01] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  312. # [07:09] * Joins: ^esc (~esc-ape@77.119.129.86.wireless.dyn.drei.com)
  313. # [07:11] * Quits: jyasskin (~jyasskin@172.56.38.23) (Ping timeout: 250 seconds)
  314. # [07:12] * Quits: ^esc_ (~esc-ape@91.141.0.146.wireless.dyn.drei.com) (Ping timeout: 264 seconds)
  315. # [07:17] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 256 seconds)
  316. # [07:18] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 265 seconds)
  317. # [07:18] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  318. # [07:20] * Joins: hgl (~hgl@unaffiliated/hgl)
  319. # [07:21] * Quits: beverloo (beverloo@nat/google/x-evgnfcezfeuubipj) (Ping timeout: 256 seconds)
  320. # [07:22] * Joins: karlcow (~karl@nerval.la-grange.net)
  321. # [07:23] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 256 seconds)
  322. # [07:25] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  323. # [07:25] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Max SendQ exceeded)
  324. # [07:25] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  325. # [07:25] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Max SendQ exceeded)
  326. # [07:26] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  327. # [07:26] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Ping timeout: 272 seconds)
  328. # [07:28] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  329. # [07:31] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 255 seconds)
  330. # [07:33] * Joins: beverloo (beverloo@nat/google/x-oeiuycibigsenuli)
  331. # [07:38] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  332. # [07:40] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  333. # [07:40] * Quits: KevinMarks (~yaaic@2607:fb90:515:f7fd:b63c:d5fd:e9ef:19f4) (Ping timeout: 245 seconds)
  334. # [07:59] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-nhdglwyqqzkwtyhk) (Quit: Connection closed for inactivity)
  335. # [08:01] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
  336. # [08:03] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  337. # [08:06] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  338. # [08:07] * Joins: othermaciej (~mjs@c-71-198-213-78.hsd1.ca.comcast.net)
  339. # [08:13] * Joins: KevinMarks (~yaaic@2607:fb90:22cf:3e:3247:fe5f:f03e:11d3)
  340. # [08:16] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
  341. # [08:16] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 256 seconds)
  342. # [08:28] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  343. # [08:33] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  344. # [08:34] <JakeA> annevk: https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-90819078 - I don't understand "wait with overrideRequestURL"
  345. # [08:42] * heycam is now known as heycam|away
  346. # [08:47] * Joins: markkes (~markkes@62.207.90.201)
  347. # [08:50] <annevk> JakeA: just not implement it
  348. # [08:51] <annevk> JakeA: what you argue for would be a new special case that did not exist before; the case the implementers brought up was not considered when we figured it as a shorthand for short-circuiting redirects
  349. # [08:52] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
  350. # [08:53] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
  351. # [08:55] <JakeA> annevk: we've got some internal customers for this, I'll find out if the API works for them. But yeah, in that case it isn't exactly like a redirect.
  352. # [08:55] <annevk> JakeA: it would be interesting to hear why they can't use Response.redirect()
  353. # [08:58] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
  354. # [08:59] * Joins: mpt (~mpt@canonical/mpt)
  355. # [09:02] <JakeA> annevk: yeah, I'm digging into that and building them an example
  356. # [09:02] * Quits: dshwang (~dshwang@192.55.54.36) (Remote host closed the connection)
  357. # [09:03] * Joins: dshwang (~dshwang@192.55.54.36)
  358. # [09:06] * Quits: roc (~chatzilla@2001:cb0:b202:224:2677:3ff:fece:dc64) (Remote host closed the connection)
  359. # [09:08] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-klwoysokbwvhatmi)
  360. # [09:22] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  361. # [09:23] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
  362. # [09:23] * Joins: hasather (~hasather@80.91.33.141)
  363. # [09:24] * Quits: KevinMarks (~yaaic@2607:fb90:22cf:3e:3247:fe5f:f03e:11d3) (Ping timeout: 245 seconds)
  364. # [09:28] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  365. # [09:30] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  366. # [09:36] * Joins: Ms2ger (~Ms2ger@193.190.253.150)
  367. # [09:40] * Joins: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
  368. # [09:57] <annevk> Is anyone using https://atom.io/?
  369. # [10:01] * Quits: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net) (Ping timeout: 264 seconds)
  370. # [10:12] * Quits: abarth (sid5294@gateway/web/irccloud.com/x-pgwwpidtkiwrrypa) (Ping timeout: 256 seconds)
  371. # [10:13] * c74d is now known as Guest42134
  372. # [10:13] * Joins: abarth (sid5294@gateway/web/irccloud.com/x-xiccuqxrdtvqosfj)
  373. # [10:13] * Quits: remysharp (sid4345@gateway/web/irccloud.com/x-htkrakyoltfkvkvi) (Ping timeout: 256 seconds)
  374. # [10:13] * Quits: Guest42134 (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (Ping timeout: 256 seconds)
  375. # [10:14] * Joins: remysharp (sid4345@gateway/web/irccloud.com/x-zvcynrkwvslzrzyu)
  376. # [10:17] * Joins: satazor (~satazor@117.195.115.89.rev.vodafone.pt)
  377. # [10:22] * Joins: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
  378. # [10:25] * Joins: calvaris (~calvaris@fanzine.igalia.com)
  379. # [10:31] * Quits: satazor (~satazor@117.195.115.89.rev.vodafone.pt) (Remote host closed the connection)
  380. # [10:38] <philipj> annevk: I think the general situation is that Content-Type is ignored for both media elements and <track>
  381. # [10:39] <philipj> there's a bit of a history, but since Microsoft caved and started ignoring it in IE I think there's no turning back (which I'm happy about)
  382. # [10:39] <annevk> philipj: so for X-Content-Type-Options: nosniff we want to give server administrators the feature of enforcing Content-Type for resources so they can't be used in an unexpected context
  383. # [10:40] <annevk> philipj: this requires a whitelist of MIME types for audio/video and a separate set for track
  384. # [10:40] <philipj> uh, ok, I couldn't say how that currently works
  385. # [10:41] <annevk> philipj: it doesn't for those contexts
  386. # [10:41] <annevk> philipj: well, it might in IE
  387. # [10:41] <annevk> I haven't tested IE yet
  388. # [10:41] <philipj> for <track> there's just no code that looks at Content-Type, at least not in Blink, if it's not WebVTT then it won't work
  389. # [10:56] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
  390. # [10:59] * Quits: 6JTAAT81B (~scrollbac@gateway/web/scrollback.io/x-ezmprbpfafhspsfx) (Ping timeout: 252 seconds)
  391. # [11:00] * Joins: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr)
  392. # [11:04] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  393. # [11:04] * Joins: karlcow (~karl@nerval.la-grange.net)
  394. # [11:04] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  395. # [11:09] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Remote host closed the connection)
  396. # [11:09] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  397. # [11:14] * Quits: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 256 seconds)
  398. # [11:15] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  399. # [11:15] * Quits: tripu (~tripu@p7223-ipngn11001marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving)
  400. # [11:19] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  401. # [11:21] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  402. # [11:25] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  403. # [11:30] <annevk> philipj: okay, so we could just make the whitelist text/webvtt
  404. # [11:30] <annevk> philipj: for CSS it's text/css at the moment
  405. # [11:30] <annevk> philipj: only unclear thing then is the MIME types for audio/video which is somewhat of a trainwreck
  406. # [11:31] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Ping timeout: 256 seconds)
  407. # [11:34] * Joins: satazor (~satazor@bl6-111-97.dsl.telepac.pt)
  408. # [11:37] * Quits: satazor (~satazor@bl6-111-97.dsl.telepac.pt) (Read error: Connection reset by peer)
  409. # [11:42] <annevk> text/vtt*
  410. # [11:46] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 255 seconds)
  411. # [11:47] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  412. # [11:51] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  413. # [11:54] <annevk> http://w3cdreams.tumblr.com/
  414. # [11:55] * Joins: jamesheston (~jameshest@wsip-98-173-32-122.sd.sd.cox.net)
  415. # [11:57] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  416. # [11:58] <jgraham> Wow, well I was enjoying that and then the Service Worker thing guenuninely made me feel ill
  417. # [11:59] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  418. # [12:05] * Joins: satazor (~satazor@bl6-111-97.dsl.telepac.pt)
  419. # [12:07] <annevk> jgraham: hypno cat?
  420. # [12:08] * Quits: satazor (~satazor@bl6-111-97.dsl.telepac.pt) (Read error: Connection reset by peer)
  421. # [12:09] <jgraham> Possibly
  422. # [12:10] <jgraham> Also made me unable to spell genuinely
  423. # [12:14] <zcorpan> just need to let the eyes follow the circles a few laps and then you'll feel better again
  424. # [12:14] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  425. # [12:15] * Quits: plutoniix (~plutoniix@119.63.87.222) (Quit: จรลี จรลา)
  426. # [12:19] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
  427. # [12:19] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
  428. # [12:19] * Joins: scor (~scor@drupal.org/user/52142/view)
  429. # [12:20] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  430. # [12:20] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  431. # [12:31] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  432. # [12:35] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  433. # [12:41] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
  434. # [12:45] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
  435. # [12:56] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  436. # [12:57] * Quits: jamesheston (~jameshest@wsip-98-173-32-122.sd.sd.cox.net) (Quit: Textual IRC Client: www.textualapp.com)
  437. # [12:57] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-dxjhreefmwsgkaqr)
  438. # [13:11] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  439. # [13:13] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-ijppgawzergdqrxb)
  440. # [13:14] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  441. # [13:29] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
  442. # [13:40] * Quits: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net) (Quit: eric_carlson)
  443. # [13:45] * Joins: scor (scor@nat/acquia/x-lkuznhmniecwxuhl)
  444. # [13:45] * Quits: scor (scor@nat/acquia/x-lkuznhmniecwxuhl) (Changing host)
  445. # [13:45] * Joins: scor (scor@drupal.org/user/52142/view)
  446. # [13:50] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 240 seconds)
  447. # [13:54] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
  448. # [13:56] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
  449. # [13:59] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 264 seconds)
  450. # [13:59] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
  451. # [14:00] * Joins: sarri (~sari@p50995cae.dip0.t-ipconnect.de)
  452. # [14:00] * Quits: sarri (~sari@p50995cae.dip0.t-ipconnect.de) (Changing host)
  453. # [14:00] * Joins: sarri (~sari@unaffiliated/sarri)
  454. # [14:16] * Joins: Kolombiken (~Adium@94.137.124.2)
  455. # [14:33] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
  456. # [14:36] * Joins: plutoniix (~plutoniix@node-krx.pool-101-108.dynamic.totbb.net)
  457. # [14:43] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Ping timeout: 245 seconds)
  458. # [14:44] * Joins: calvaris (~calvaris@fanzine.igalia.com)
  459. # [14:49] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  460. # [14:52] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 252 seconds)
  461. # [14:55] * Joins: hgl (~hgl@unaffiliated/hgl)
  462. # [14:57] * Joins: r2 (~r2@200.80.227.70)
  463. # [14:59] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  464. # [15:01] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
  465. # [15:02] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
  466. # [15:05] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-dxjhreefmwsgkaqr) (Quit: Connection closed for inactivity)
  467. # [15:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  468. # [15:08] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  469. # [15:11] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  470. # [15:15] * Quits: g4 (~g4@unaffiliated/gormer) (Remote host closed the connection)
  471. # [15:18] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
  472. # [15:23] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
  473. # [15:27] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-wmjnceqrtmnuhbzo)
  474. # [15:27] * Joins: ato_ (~sid11@2620:101:8016:74::4:b)
  475. # [15:27] * Quits: ato (sid16069@gateway/web/irccloud.com/x-ukkfrhsyfivwdmdz)
  476. # [15:27] * ato_ is now known as ato
  477. # [15:31] * Joins: newtron (~newtron@199.71.174.203)
  478. # [15:33] * Joins: g4 (~g4@unaffiliated/gormer)
  479. # [15:34] * Joins: jsx (uid48919@fsf/intern/jsx)
  480. # [15:37] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Quit: Leaving...)
  481. # [15:38] * Joins: TallTed (~Thud@63.119.36.36)
  482. # [15:41] * Joins: wilsonpage (~wilsonpag@94.118.128.13)
  483. # [15:43] * Joins: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com)
  484. # [15:50] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
  485. # [15:53] * Quits: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru) (Quit: My Mac has gone to sleep. ZZZzzz…)
  486. # [15:53] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: This computer has gone to sleep)
  487. # [15:54] * Joins: karlcow (~karl@nerval.la-grange.net)
  488. # [15:56] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 245 seconds)
  489. # [15:57] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
  490. # [15:58] * Joins: hgl (~hgl@unaffiliated/hgl)
  491. # [15:59] * Joins: eric_carlson (~ericc@17.202.49.252)
  492. # [16:01] * Joins: eBureau (~Bruno@181.164.77.172)
  493. # [16:08] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  494. # [16:09] * Joins: boogyman__ (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263)
  495. # [16:09] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Ping timeout: 256 seconds)
  496. # [16:11] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 245 seconds)
  497. # [16:11] * boogyman__ is now known as boogyman
  498. # [16:11] * Quits: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com) (Ping timeout: 256 seconds)
  499. # [16:11] * boogyman is now known as Guest37534
  500. # [16:12] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
  501. # [16:12] * Joins: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com)
  502. # [16:16] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
  503. # [16:22] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Ping timeout: 244 seconds)
  504. # [16:23] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  505. # [16:23] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
  506. # [16:24] * Joins: karlcow (~karl@nerval.la-grange.net)
  507. # [16:24] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  508. # [16:24] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
  509. # [16:30] * Joins: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com)
  510. # [16:31] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Remote host closed the connection)
  511. # [16:32] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 255 seconds)
  512. # [16:34] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
  513. # [16:36] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  514. # [16:38] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
  515. # [16:40] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
  516. # [16:49] <wanderview> Domenic: you said there were user space Promise libs that were faster than browser implementations... can you point me at one you recommend for perf?
  517. # [16:49] <bradleymeck> wanderview: bluebird
  518. # [16:50] <Domenic> yep
  519. # [16:51] * Quits: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com) (Ping timeout: 256 seconds)
  520. # [16:53] <wanderview> Domenic: should I just be able to drop this in with the stream reference impl?
  521. # [16:53] * Joins: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com)
  522. # [16:54] <Domenic> wanderview: ugh, the reference impl is so un-optimized...
  523. # [16:54] <Domenic> wanderview: but, yeah, if you do global.Promise = require('bluebird') it should be drop-in-able
  524. # [16:55] <Domenic> But I mean, all the asserts (in loops too!) and try/catches and the hilarious queue-with-sizes implementation will dwarf the performance change I think
  525. # [16:59] <wanderview> Domenic: meeting now... but I'll try to describe the case I'm concerned with... I can write something not use ref impl, but just something similar to tease out the Promise impact
  526. # [16:59] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
  527. # [16:59] * Joins: ehsan_ (~ehsan@67.213.81.142)
  528. # [17:00] <Domenic> wanderview: OK cool. Be sure it does actual I/O too :)
  529. # [17:01] <wanderview> Domenic: javascript consumers may not do actual I/O
  530. # [17:01] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-klwoysokbwvhatmi) (Quit: Connection closed for inactivity)
  531. # [17:02] <Domenic> Ultimately the stream should be grounded in some I/O, most likely
  532. # [17:03] <Domenic> E.g. maybe your stream vends JS objects but it's derived from some stream that read from a file/network
  533. # [17:07] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
  534. # [17:08] * Quits: markkes (~markkes@62.207.90.201) (Quit: markkes)
  535. # [17:10] * Quits: hasather (~hasather@80.91.33.141) (Read error: Connection reset by peer)
  536. # [17:12] * Joins: hasather (~hasather@80.91.33.141)
  537. # [17:12] * Quits: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com) (Read error: Connection reset by peer)
  538. # [17:13] * Joins: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com)
  539. # [17:15] * Quits: g4 (~g4@unaffiliated/gormer) (Quit: Leaving)
  540. # [17:19] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  541. # [17:22] * Joins: eBureau (~Bruno@181.164.77.172)
  542. # [17:23] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  543. # [17:26] * Quits: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com) (Quit: This computer has gone to sleep)
  544. # [17:30] * Joins: hemanth (~hemanth@122.167.67.18)
  545. # [17:33] <wanderview> Domenic: is it not reasonable for js to do in-memory operations like your stream demo where its searching for a particular value? that is not I/O related
  546. # [17:33] * Quits: ehsan_ (~ehsan@67.213.81.142) (Remote host closed the connection)
  547. # [17:34] <Domenic> wanderview: how is that no I/O related?
  548. # [17:34] <Domenic> wanderview: the stream is a fetch stream
  549. # [17:34] * Joins: KevinMarks (~yaaic@2607:fb90:5c4:383:ff43:1a9:f55f:1b6b)
  550. # [17:34] <wanderview> Domenic: I thought you meant on the consumption side you wanted it to be I/O
  551. # [17:34] <Domenic> wanderview: oh, no, i just meant that each promise produced from the reader should correspond to doing some I/O
  552. # [17:35] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
  553. # [17:35] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-wmjnceqrtmnuhbzo) (Quit: Connection closed for inactivity)
  554. # [17:36] <Domenic> i.e., don't test for (let i = 0; i < 1000; ++i) { Promise.resolve(5).then(foo); }; test for (let i = 0; i < 1000; ++i) { fs.read(fd, ...).then(foo); })
  555. # [17:36] <wanderview> Domenic: the main case I can think of that concerns me is where you write data to a pipe buffer... and then want to read it starting at some later time... in that case the pipe .read() is not related to I/O until the buffer is drained... and draining the buffer will be much slower than with sync .read()
  556. # [17:36] * Joins: hasather (~hasather@80.91.33.141)
  557. # [17:36] * Joins: KevinMarks___ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  558. # [17:36] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  559. # [17:36] <Domenic> "much" slower citation needed... especially since sync read() would need to use async .ready or similar for backpressure signals
  560. # [17:36] <wanderview> Domenic: thats why I want to test with real Promises :-)
  561. # [17:37] <Domenic> sounds good :)
  562. # [17:37] <wanderview> Domenic: I agree at least one async operation is needed... but doing it on every buffered chunk seems potentially not good
  563. # [17:38] <wanderview> Domenic: I'm going to put this in the batch read issue... I think some kind of .readAllAvailable() would solve this... give me an array of all available chunks... so you get an array of length 1 or greater
  564. # [17:38] * Quits: KevinMarks (~yaaic@2607:fb90:5c4:383:ff43:1a9:f55f:1b6b) (Ping timeout: 245 seconds)
  565. # [17:38] <wanderview> for cases where you just want to read as fast as possible
  566. # [17:38] <Domenic> wanderview: sounds good, yeah. Or 0 chunks if end of stream.
  567. # [17:40] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  568. # [17:43] * Quits: KevinMarks___ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 265 seconds)
  569. # [17:46] * Joins: KevinMarks__ (~yaaic@2607:fb90:5a4:3009:490a:16c7:81b7:fdcd)
  570. # [17:48] * Quits: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 244 seconds)
  571. # [17:49] <wanderview> Domenic: I guess my concern here started by looking at the current rs.pipeTo() implementation... since it waits for each .read() to resolve before calling .read() again... you can't get any pipelining going that way... and then I started to wonder if it should do two .read() calls... so while its writing the first its already started the async process to get
  572. # [17:49] <wanderview> the next, etc
  573. # [17:49] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
  574. # [17:50] <Domenic> wanderview: right, but that should only delay at most a microtask, and then it will resolve and immediately call read() again, and the stack only has to unwind one frame since we're already in the microtask loop... it's one extra frame per loop iteration basically.
  575. # [17:55] * Joins: svl (~me@200.123.210.20)
  576. # [17:56] * Quits: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com) (Quit: bradleymeck)
  577. # [17:56] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
  578. # [17:57] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
  579. # [17:57] * Joins: jdaggett_ (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp)
  580. # [17:57] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
  581. # [17:59] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
  582. # [17:59] <JakeA> wanderview: I've been thinking about cache.add[All]. I've been seeing a lot of examples check the status code of responses before putting them into the cache. Maybe we should revisit the idea of checking response.ok before caching (as an option). This would of course fail on all opaque responses. Do you think it's still useful?
  583. # [18:02] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Read error: Connection reset by peer)
  584. # [18:02] <wanderview> JakeA: in a meeting
  585. # [18:02] <JakeA> no rush
  586. # [18:03] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
  587. # [18:03] * Joins: adactio (~adactio@212.42.170.121)
  588. # [18:03] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
  589. # [18:06] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
  590. # [18:06] * Joins: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com)
  591. # [18:06] * Joins: ap (~ap@17.202.44.214)
  592. # [18:09] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-ncoqwrllfdpdgzzg)
  593. # [18:11] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  594. # [18:17] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
  595. # [18:19] * Joins: eBureau (~Bruno@181.164.77.172)
  596. # [18:19] * Quits: hemanth (~hemanth@122.167.67.18) (Quit: This computer has gone to sleep)
  597. # [18:29] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
  598. # [18:30] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  599. # [18:38] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  600. # [18:41] * Quits: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru) (Quit: My Mac has gone to sleep. ZZZzzz…)
  601. # [18:43] * Joins: ehsan_ (~ehsan@2001:450:1f:224:d4de:dec7:880f:bcc7)
  602. # [18:44] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-jncnmqtebpqdprfm)
  603. # [18:47] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
  604. # [18:52] * Joins: KevinMarks (~KevinMark@172.56.16.98)
  605. # [18:53] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
  606. # [18:53] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  607. # [18:59] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
  608. # [19:01] * Quits: adactio (~adactio@212.42.170.121) (Quit: adactio)
  609. # [19:01] * Krinkle|detached is now known as Krinkle
  610. # [19:02] * Quits: jdaggett_ (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett_)
  611. # [19:03] <annevk> JakeA: should it not be added to fetch() then?
  612. # [19:05] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  613. # [19:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
  614. # [19:07] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  615. # [19:08] * Quits: KevinMarks (~KevinMark@172.56.16.98) (Ping timeout: 250 seconds)
  616. # [19:12] <wanderview> JakeA: that sounds fine to me... I don't really have an opinion... whatever developers want/expect
  617. # [19:12] * Quits: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com) (Quit: Leaving)
  618. # [19:12] <wanderview> not sure I understand the opaque response thing, though
  619. # [19:12] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
  620. # [19:12] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 255 seconds)
  621. # [19:12] <annevk> Domenic: the post-ES6 specification plan sounds rather lovely
  622. # [19:12] * Joins: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com)
  623. # [19:12] <Domenic> :)
  624. # [19:12] <Domenic> we'll see if we can pull it off...
  625. # [19:13] <annevk> Domenic: I wonder if WHATWG can gradually convert to that as well
  626. # [19:13] <wanderview> what plan?
  627. # [19:13] <annevk> wanderview: https://esdiscuss.org/topic/the-great-tooling-revolution
  628. # [19:16] * Joins: iandevlin (~iandevlin@dslb-088-070-108-065.088.070.pools.vodafone-ip.de)
  629. # [19:16] <Domenic> annevk: you mean the two-impls thing?
  630. # [19:16] <annevk> Domenic: the tooling and writing style
  631. # [19:16] <Domenic> annevk: ah interesting.
  632. # [19:16] * Joins: eBureau (~Bruno@181.164.77.172)
  633. # [19:16] * Quits: iandevlin (~iandevlin@dslb-088-070-108-065.088.070.pools.vodafone-ip.de) (Client Quit)
  634. # [19:16] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
  635. # [19:16] <annevk> having said that, ES6 is rather hard to digest, but some of the algorithm shorthands you're introducing seem nice
  636. # [19:16] <Domenic> Yeah, I was going to say, "Ecmaspeak"'s evolution into something more user-friendly is still in progress (cf. https://streams.spec.whatwg.org/#conventions)
  637. # [19:16] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  638. # [19:16] <Domenic> And it's unclear the value of Ecmaspeak vs. some kind of "spec ES"
  639. # [19:17] <wanderview> Domenic: what does chrome's shipping Response body stream do for a Response returned from cache.match()? does it stream from disk?
  640. # [19:17] <Domenic> wanderview: good... question...... tyoshino are you awake perchance?
  641. # [19:17] <wanderview> I mean... is that implemented in this first version
  642. # [19:17] <Domenic> oh hi yhirano_ is in here too
  643. # [19:18] <Domenic> Maybe the thing to do is ask on the blink-dev Intent to Ship thread?
  644. # [19:19] * Quits: othermaciej (~mjs@c-71-198-213-78.hsd1.ca.comcast.net) (Quit: othermaciej)
  645. # [19:19] * Joins: hemanth (~hemanth@122.167.67.18)
  646. # [19:20] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
  647. # [19:20] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
  648. # [19:23] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  649. # [19:24] <wanderview> Domenic: ok, will do... mainly just curious
  650. # [19:25] <wanderview> Domenic: what is WritableStream.getWriter() you to mention in that issue update? I don;t see that in the spec
  651. # [19:26] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
  652. # [19:28] * Joins: othermaciej (~mjs@76.74.153.41)
  653. # [19:31] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
  654. # [19:33] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  655. # [19:42] * Joins: KevinMarks (~KevinMark@sjspeed.wiline.com)
  656. # [19:54] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
  657. # [19:54] * Joins: hasather (~hasather@80.91.33.141)
  658. # [19:57] <Domenic> wanderview: https://github.com/whatwg/streams/issues/319 :-S
  659. # [19:57] <wanderview> ok... so not spec'd yet
  660. # [19:57] <wanderview> wasn't sure if it was coming or previous-and-gone
  661. # [19:58] <Domenic> heh... yeah
  662. # [19:58] <Domenic> wanderview: related https://github.com/whatwg/streams/commit/d757e05cf27f73488d13825e51ce5706a759ab27
  663. # [20:01] <wanderview> Domenic: I didn't want to bikeshed more in the "getReader is named poorly" issue... but take() is also widely used for locking concepts :-)
  664. # [20:05] * Quits: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
  665. # [20:06] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
  666. # [20:06] * Quits: wilsonpage (~wilsonpag@94.118.128.13) (Quit: My Mac has gone to sleep. ZZZzzz…)
  667. # [20:06] <Domenic> meeeeeeeeeeehhhhhh
  668. # [20:08] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  669. # [20:09] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  670. # [20:09] <wanderview> Domenic: getReader() does not unlock if the reader gets GC'd right? or rather, the whole stream has to be GC'd in addition to the reader?
  671. # [20:09] <Domenic> wanderview: right. (and in the latter case i'm not sure there's a difference.)
  672. # [20:10] <Domenic> wanderview: webkit has a test showing this
  673. # [20:10] <Domenic> unsure how/whether to put it in the general suite...
  674. # [20:10] * Quits: svl (~me@200.123.210.20) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  675. # [20:11] <wanderview> Domenic: I really dislike stuff with explicit release like revokeObjectUrl()... so many leaks in code that use them... the error paths are atrocious
  676. # [20:11] <wanderview> from my experience with code in fxos trying to use that kind of API
  677. # [20:11] <Domenic> wanderview: well this case is pretty different, since it's not like you could successfully get another reader by waiting for GC of the first one, since that's unreliable
  678. # [20:12] <Domenic> that's a fair argument for the lifecycle management thread though
  679. # [20:12] <wanderview> yea
  680. # [20:12] <wanderview> I think I mentioned it there
  681. # [20:13] <wanderview> Domenic: is there a finally thing on promises for people to always return the reader?
  682. # [20:13] <wanderview> maybe that makes it less of a problem
  683. # [20:13] * Quits: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr) (Ping timeout: 265 seconds)
  684. # [20:14] <Domenic> wanderview: we've been wanting to add finally to promises for a long time, and this cancelable promise stuff might push it over the line.
  685. # [20:16] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Ping timeout: 265 seconds)
  686. # [20:16] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Quit: Leaving...)
  687. # [20:16] <wanderview> Domenic: I guess its not a huge problem here... since lock is released automatically on close
  688. # [20:16] <wanderview> its optimized for single reader case... which is what we want
  689. # [20:17] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 256 seconds)
  690. # [20:20] * Joins: karlcow (~karl@nerval.la-grange.net)
  691. # [20:21] * Quits: KevinMarks__ (~yaaic@2607:fb90:5a4:3009:490a:16c7:81b7:fdcd) (Ping timeout: 245 seconds)
  692. # [20:21] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  693. # [20:21] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
  694. # [20:21] <Domenic> wanderview: yeah, that's kind of the idea. if anyone's doing something tricky like parsing a header portion then passing the partially-read stream on to someone else, they can probably remember to release the lock. Although I agree finally would be nice.
  695. # [20:21] * Joins: KevinMarks__ (~yaaic@2607:fb90:5ca:3eb:1d11:c7f0:4077:e151)
  696. # [20:22] <wanderview> Domenic: that seems like something easier down with pipeThrough()... although it would be nice to remove the header transform piece after its done
  697. # [20:22] <Domenic> hmm yeah that's true
  698. # [20:23] <wanderview> ^down^done
  699. # [20:23] <Domenic> i guess most uses of readers are hidden behind the higher-level methods like pipe*() and tee()
  700. # [20:27] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
  701. # [20:29] * Quits: KevinMarks__ (~yaaic@2607:fb90:5ca:3eb:1d11:c7f0:4077:e151) (Ping timeout: 245 seconds)
  702. # [20:32] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  703. # [20:34] * Joins: rniwa (~rniwa@17.245.30.85)
  704. # [20:35] * Quits: othermaciej (~mjs@76.74.153.41) (Quit: othermaciej)
  705. # [20:35] * Quits: rniwa (~rniwa@17.245.30.85) (Client Quit)
  706. # [20:38] * Quits: hemanth (~hemanth@122.167.67.18) (Quit: This computer has gone to sleep)
  707. # [20:38] * Joins: rniwa (~rniwa@17.245.30.85)
  708. # [20:38] * Joins: calvaris (~calvaris@254.126.27.77.dynamic.mundo-r.com)
  709. # [20:38] * Quits: rniwa (~rniwa@17.245.30.85) (Client Quit)
  710. # [20:39] <calvaris> sorry, I just fell and I don't know if you read what I said but
  711. # [20:39] <calvaris> wanderview: I have a pull request with that test
  712. # [20:39] <calvaris> all custom tests that we had for WK are now there and waiting for Domenic to merge them
  713. # [20:40] <wanderview> calvaris: which test?
  714. # [20:41] * Joins: othermaciej (~mjs@17.244.160.90)
  715. # [20:41] <calvaris> the one for the garbage collection regarding the reader
  716. # [20:41] <wanderview> Domenic: btw, we apparently do implement microtask queue in gecko now
  717. # [20:41] <wanderview> calvaris: ah, cool
  718. # [20:42] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
  719. # [20:42] <Domenic> wanderview: ah that's excellent
  720. # [20:42] <wanderview> Domenic: I still don't think our c++ can optimize around them, though... since js can call into c++ with js still on the stack
  721. # [20:43] * Joins: benwerd (~benwerd@199.87.84.238)
  722. # [20:46] * Joins: josemanuel (~josemanue@6.27.11.37.dynamic.jazztel.es)
  723. # [20:47] * Joins: Maurice` (~copyman@unaffiliated/maurice)
  724. # [20:48] * Guest37534 is now known as boogyman
  725. # [20:48] * Quits: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263) (Changing host)
  726. # [20:48] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
  727. # [20:49] * Joins: dbaron (~dbaron@2620:101:80fb:224:2d19:d044:d21e:612e)
  728. # [20:49] * Quits: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com) (Quit: This computer has gone to sleep)
  729. # [20:50] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  730. # [20:54] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
  731. # [20:55] * Joins: hasather (~hasather@80.91.33.141)
  732. # [20:55] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-jncnmqtebpqdprfm) (Quit: Connection closed for inactivity)
  733. # [20:58] * Quits: othermaciej (~mjs@17.244.160.90) (Quit: othermaciej)
  734. # [20:58] * Joins: rniwa (~rniwa@17.245.30.85)
  735. # [20:59] * Quits: rniwa (~rniwa@17.245.30.85) (Client Quit)
  736. # [21:01] * Quits: r2 (~r2@200.80.227.70) (Read error: Connection reset by peer)
  737. # [21:02] * Joins: KevinMarks__ (~yaaic@2607:fb90:5c8:ef08:c85e:14ca:36b6:26da)
  738. # [21:02] * Joins: othermaciej (~mjs@17.244.160.90)
  739. # [21:04] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Read error: No route to host)
  740. # [21:05] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
  741. # [21:06] * Quits: KevinMarks__ (~yaaic@2607:fb90:5c8:ef08:c85e:14ca:36b6:26da) (Ping timeout: 245 seconds)
  742. # [21:07] * Joins: rniwa (~rniwa@17.245.30.85)
  743. # [21:09] * Quits: eric_carlson (~ericc@17.202.49.252) (Quit: eric_carlson)
  744. # [21:11] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  745. # [21:12] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
  746. # [21:12] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
  747. # [21:12] * Joins: scor (~scor@drupal.org/user/52142/view)
  748. # [21:13] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
  749. # [21:14] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  750. # [21:15] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  751. # [21:16] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
  752. # [21:16] * Joins: scor (~scor@drupal.org/user/52142/view)
  753. # [21:17] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  754. # [21:17] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 252 seconds)
  755. # [21:19] * Joins: hgl (~hgl@unaffiliated/hgl)
  756. # [21:22] * Quits: calvaris (~calvaris@254.126.27.77.dynamic.mundo-r.com) (Ping timeout: 240 seconds)
  757. # [21:23] * Krinkle is now known as Krinkle|detached
  758. # [21:25] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
  759. # [21:25] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
  760. # [21:25] * Joins: scor (~scor@drupal.org/user/52142/view)
  761. # [21:25] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-plqsjkpysnzhgwvh)
  762. # [21:26] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  763. # [21:28] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
  764. # [21:28] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
  765. # [21:28] * Joins: scor (~scor@drupal.org/user/52142/view)
  766. # [21:29] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Read error: Connection reset by peer)
  767. # [21:29] * Quits: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3) (Quit: installing updates'n'stuff, back shortly)
  768. # [21:30] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
  769. # [21:31] * Quits: KevinMarks (~KevinMark@sjspeed.wiline.com) (Ping timeout: 244 seconds)
  770. # [21:34] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
  771. # [21:36] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
  772. # [21:36] * Quits: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net) (Max SendQ exceeded)
  773. # [21:36] * Joins: eric_carlson (~ericc@17.202.49.252)
  774. # [21:36] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
  775. # [21:36] * Quits: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net) (Client Quit)
  776. # [21:38] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
  777. # [21:38] * Quits: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net) (Max SendQ exceeded)
  778. # [21:39] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  779. # [21:40] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
  780. # [21:40] * Parts: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
  781. # [21:41] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
  782. # [21:41] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
  783. # [21:41] * Joins: scor (~scor@drupal.org/user/52142/view)
  784. # [21:41] * Quits: othermaciej (~mjs@17.244.160.90) (Quit: othermaciej)
  785. # [21:42] * Joins: othermaciej (~mjs@17.244.160.90)
  786. # [21:43] * Quits: othermaciej (~mjs@17.244.160.90) (Client Quit)
  787. # [21:44] * Joins: othermaciej (~mjs@17.244.160.90)
  788. # [21:50] * Quits: othermaciej (~mjs@17.244.160.90) (Quit: othermaciej)
  789. # [21:50] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  790. # [21:50] * Joins: othermaciej (~mjs@17.244.160.90)
  791. # [21:51] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Remote host closed the connection)
  792. # [21:54] * Quits: othermaciej (~mjs@17.244.160.90) (Client Quit)
  793. # [21:56] <trevnorris> Domenic: "Cheaper than I/O" doesn't say a lot and Promise instantiation speed isn't the only thing to consider. It's the complete time from .push() to .read().
  794. # [21:56] * Joins: bnicholson (~bnicholso@2620:101:80fb:224:f422:186:fa95:1a4c)
  795. # [21:56] * Joins: othermaciej (~mjs@17.244.160.90)
  796. # [21:57] * Quits: othermaciej (~mjs@17.244.160.90) (Client Quit)
  797. # [21:57] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
  798. # [22:00] * Joins: othermaciej (~mjs@17.244.160.90)
  799. # [22:07] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Quit: bradleymeck)
  800. # [22:09] * Quits: Kolombiken (~Adium@94.137.124.2) (Quit: Leaving.)
  801. # [22:11] * Joins: zenith_ (~zenith@142.150.23.90)
  802. # [22:16] * Joins: ato_ (sid16069@gateway/web/irccloud.com/x-schsaawoueitwdop)
  803. # [22:18] * Quits: eric_carlson (~ericc@17.202.49.252) (Ping timeout: 252 seconds)
  804. # [22:18] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 244 seconds)
  805. # [22:18] * Quits: ato_ (sid16069@gateway/web/irccloud.com/x-schsaawoueitwdop) (Client Quit)
  806. # [22:19] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
  807. # [22:19] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
  808. # [22:19] * Joins: KevinMarks (~KevinMark@sjspeed.wiline.com)
  809. # [22:19] * Joins: eric_carlson (~ericc@17.202.49.94)
  810. # [22:19] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 240 seconds)
  811. # [22:20] * Joins: lnr (~lnr@aim.engr.arizona.edu)
  812. # [22:21] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
  813. # [22:21] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
  814. # [22:21] * Joins: scor (~scor@drupal.org/user/52142/view)
  815. # [22:22] * Joins: benwerd_ (~benwerd@178.62.0.159)
  816. # [22:22] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
  817. # [22:22] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
  818. # [22:24] * Quits: benwerd (~benwerd@199.87.84.238) (Ping timeout: 245 seconds)
  819. # [22:24] * Joins: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
  820. # [22:26] * Joins: benwerd (~benwerd@199.87.84.238)
  821. # [22:27] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  822. # [22:30] * Quits: benwerd_ (~benwerd@178.62.0.159) (Ping timeout: 252 seconds)
  823. # [22:30] * Joins: hasather_ (~hasather@cm-84.210.170.16.getinternet.no)
  824. # [22:34] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Quit: Leaving.)
  825. # [22:36] * Joins: capella-s3 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com)
  826. # [22:39] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
  827. # [22:42] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 250 seconds)
  828. # [22:42] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
  829. # [22:48] * Quits: eric_carlson (~ericc@17.202.49.94) (Ping timeout: 250 seconds)
  830. # [22:49] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
  831. # [22:59] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
  832. # [23:04] * Quits: Ms2ger (~Ms2ger@193.190.253.150) (Quit: nn)
  833. # [23:04] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 245 seconds)
  834. # [23:07] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
  835. # [23:09] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  836. # [23:10] * Quits: dbaron (~dbaron@2620:101:80fb:224:2d19:d044:d21e:612e) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  837. # [23:11] * Joins: dbaron (~dbaron@guest-nat.p2p.sfo1.mozilla.com)
  838. # [23:12] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Remote host closed the connection)
  839. # [23:12] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
  840. # [23:14] * Quits: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net) (Quit: ZZZzzz…)
  841. # [23:14] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
  842. # [23:15] * Quits: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net) (Client Quit)
  843. # [23:18] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Read error: Connection reset by peer)
  844. # [23:19] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
  845. # [23:19] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  846. # [23:20] <wanderview> Domenic: what does it mean for a ReadableStream to .pipeTo() a WritableByteStream... what if the RS produces non-byte things?
  847. # [23:20] <Domenic> wanderview: calling .write() (or the equivalent internal operation if we move to that model) will error, causing the pipe to error.
  848. # [23:21] <wanderview> Domenic: but if the ReadableStream passes Uint8Array chunks, then its ok?
  849. # [23:21] <Domenic> wanderview: yes, I would really like that to work
  850. # [23:22] <Domenic> wanderview: maybe allow any of the "BufferView" types
  851. # [23:22] * Quits: TallTed (~Thud@63.119.36.36)
  852. # [23:22] <wanderview> or just ArrayBuffer, I presume?
  853. # [23:23] * Quits: hasather_ (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
  854. # [23:24] * Quits: Maurice` (~copyman@unaffiliated/maurice)
  855. # [23:25] <Domenic> wanderview: right, I forgot what the type was called that is a union of all typed arrays + ArrayBuffer + DataView
  856. # [23:25] * Quits: josemanuel (~josemanue@6.27.11.37.dynamic.jazztel.es) (Quit: Saliendo)
  857. # [23:26] <Domenic> "BufferSource" apparently
  858. # [23:26] * Quits: KevinMarks (~KevinMark@sjspeed.wiline.com) (Ping timeout: 248 seconds)
  859. # [23:27] <wanderview> Domenic: where is the latest ReadableByteStream proposal?
  860. # [23:27] <Domenic> wanderview: https://github.com/whatwg/streams/blob/asyncbytestream/BinaryExtension.md
  861. # [23:27] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  862. # [23:29] * Joins: KevinMarks (~yaaic@sfspeed.wiline.com)
  863. # [23:29] <wanderview> Domenic: so... its starting to feel to me like we should not have a ReadableByteStream at all... if the underlying source of the stream operates on bytes, then the specialization has already occurred... getReader() can just return a ByobReader
  864. # [23:29] <wanderview> or am I missing something?
  865. # [23:29] <TabAtkins> bring-your-own-beerReader
  866. # [23:29] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Ping timeout: 252 seconds)
  867. # [23:30] * wanderview didn't name it. :-)
  868. # [23:30] <wanderview> ByobByteStreamReader
  869. # [23:31] * Joins: KevinMarks_ (~yaaic@2607:fb90:538:fe9e:b14f:3c3b:7fa7:b398)
  870. # [23:31] <Domenic> wanderview: hmm, but adding the BYOB layer changes things quite a lot, adding complexity specifically for the byte case. You would advocate building that complexity into the readable stream itself?
  871. # [23:32] <wanderview> Domenic: if a view is not passed to .read()... can it not just do a "get me the next chunk" semantics pretty easily?
  872. # [23:32] <trevnorris> Domenic: spec probably can't define any implementation details, can it?
  873. # [23:32] <Domenic> wanderview: for example the underlying source needs some kind of hook read(view) -> promise that fills view, and inside the stream/reader mechanisms you need something such that byobReader.read(view) transfers view to view2 then passes view2 to the read hook on the source
  874. # [23:32] <Domenic> trevnorris: it can define anything observable
  875. # [23:33] <Domenic> trevnorris: including creation APIs
  876. # [23:33] * Quits: KevinMarks (~yaaic@sfspeed.wiline.com) (Ping timeout: 245 seconds)
  877. # [23:33] <Domenic> wanderview: the idea is you should opt in to one mode or the other (BYOB or auto-flowing)
  878. # [23:34] <wanderview> Domenic: then keep it getByobReader(), but have it reject on streams that don't have the right underlying source
  879. # [23:34] <Domenic> for example BYOB doesn't have a high water mark or queue in general (although it does probably keep one around since kernel buffers are finite... unsure if that's observable to spec or can be part of the underlying source details)
  880. # [23:34] <Domenic> wanderview: ick, that's a very bad API. It would be like Node having a tagName that throws an exception when you try to use it on Comment nodes
  881. # [23:34] <trevnorris> Domenic: my implementations tie a C++ class to every JS stream, on which a class method can be defined to receive incoming data. .pipe() can detect that and short circuit the JS call by passing from the internal C++ to the implementation defined method.
  882. # [23:35] <trevnorris> unfortunately it depends on certain V8-isms that i'm not sure are currently possible in other engines.
  883. # [23:35] <Domenic> trevnorris: right, in that case the spec's job is to make your short circuit unobservable
  884. # [23:35] <Domenic> trevnorris: and that means completely unobservable, even if someone overwrites dest.write to log when called or similar ;)
  885. # [23:35] <wanderview> Domenic: what does ReadableByteStream get you beyond the Byob capacility? It doesn't seem like anything... so maybe it should be a ByobReadableStream
  886. # [23:36] <Domenic> wanderview: yes, that is indeed the real delta. We figured it was a more user-friendly name? But no real opposition to renaming it
  887. # [23:36] <wanderview> Domenic: I guess the problem with that is the producer of the stream does not know if the user wants Byob semantics
  888. # [23:36] <Domenic> Actually we are kind of hoping not to use the term "BYOB" in public API. The fact that's in tyoshino's doc is largely just as a placeholder :)
  889. # [23:36] <wanderview> ^user^consumer
  890. # [23:37] <wanderview> I know
  891. # [23:37] <wanderview> Domenic: it just feels the "type" of the stream is determined by the underlying source... and having to have a special shell around particular underlying sources is clumsy... ReadableStream should just enable the extra features if its constructed with a byte oriented underlying source
  892. # [23:37] <Domenic> wanderview: the hope is that it is efficient for streams like fetch/fs/etc. that are bytes-backed to implement ReadableByteStream, and then consumers who want to opt in to BYOB behavior can use .getByobReader(), and normal people (including those agnostic to the chunk type) can just use .getReader()
  893. # [23:38] * Quits: mrbkap (~mrbkap@63.245.214.133) (Quit: leaving)
  894. # [23:38] <Domenic> wanderview: I don't agree with that. The logical conclusion of that argument is that streams should be able to bake me a cake if I give them the right underlying source.
  895. # [23:39] <Domenic> Adding fundamentally new capabilities, instead of just different behavior, should require a new type.
  896. # [23:39] * wanderview likes cake.
  897. # [23:39] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  898. # [23:39] <wanderview> Domenic: what do you anticipate being different about a WritableByteStream?
  899. # [23:40] <Domenic> wanderview: hazy right now, but one big thing is it will need to detach any passed-in buffers since they might be sent off thread
  900. # [23:41] <wanderview> Domenic: that... seems hard without including it in the WritableStream contract
  901. # [23:41] <Domenic> hmm how so?
  902. # [23:42] <wanderview> Domenic: isn't that an optimizaiton that should be negotiated by native underlying source to native underlying sink?
  903. # [23:42] <Domenic> wanderview: I am talking about var a = new Uint8Array([5, 10, 15, 20]); fileStream.write(a)
  904. # [23:43] <Domenic> I want to send the backing memory of a off into the thread that does file I/O
  905. # [23:43] <Domenic> and I am pretty sure we don't want to let people do a[0] = 7 and have that mutate the memory, maybe before the write, maybe after the write
  906. # [23:43] <wanderview> Domenic: you're talking about effectively making the chunk disappear from content... if under normal circumstances I can do ws.write(chunk); muchAroundWithChunk(chunk); ... how will code based just on WritableStream know that .write() suddently doesn't work that way because it has a WBS?
  907. # [23:44] <wanderview> Domenic: I guess I'm saying WritableStream.write() contract should say "don't expect the chunk to exist in its current form after this call" regardless of WritableStream vs WritableByteStream
  908. # [23:44] * Joins: jernoble (~jernoble@17.202.46.221)
  909. # [23:44] <Domenic> wanderview: that's fair, although I'm not sure in practice how worried we should be. But one easy fix is to add .getTransferringWriter() or similar, whereas .getWriter() does copies?? I dunno.
  910. # [23:45] <Domenic> wanderview: I just have no idea how to enforce that contract
  911. # [23:45] <Domenic> if it's not true for most writable streams, then people might assume it, no matter if the spec has some kind of "don't assume this please" note.
  912. # [23:45] <wanderview> Domenic: maybe its not enforceable... but we can at least say "told you so" when people' stuff breaks :-)
  913. # [23:45] <Domenic> heh, ok
  914. # [23:46] <wanderview> Domenic: it just seems stuff like ByobReader and maybe this TransferringWriter are opportunistic things... optimize in this fashion if its available... otherwise use the lesser stuff
  915. # [23:46] <wanderview> Domenic: and I guess in your mind the right way to "check if its available" is to do an instanceof on the prototype?
  916. # [23:47] <Domenic> wanderview: I don't see how to make ByobReader opportunistic. E.g. no way to do https://gist.github.com/domenic/65921459ef7a31ec2839#reading-a-file-chunkwise (old API I think) without explicitly doing things with JS
  917. # [23:47] <Domenic> wanderview: check if what is available?
  918. # [23:47] <wanderview> Domenic: check if ByobReader is available on a RS, for example
  919. # [23:47] <Domenic> wanderview: if (rs.getByobReader) { ... }
  920. # [23:50] <wanderview> Domenic: can't see much difference between that and getByobReader() returning null if its not supported
  921. # [23:50] <Domenic> wanderview: it's just basic API design... we don't add everything onto a single object. New classes of objects get ... new classes.
  922. # [23:50] <Domenic> Node vs. Element, etc.
  923. # [23:50] <wanderview> Domenic: I think I dislike mixing that with the revealing constructor pattern... the constructor is not revealing all the behavior
  924. # [23:51] <wanderview> Domenic: if we had a revealing factory method that could construct the right type... it might seem a bit better to me
  925. # [23:51] <Domenic> wanderview: I don't see how they're related. Revealing constructor pattern lets you customize a type's behavior. You can have different revealing constructors for different types. We don't use the same type for Promise and ReadableStream, even though they both have customizable behavior via the revealing constructor pattern.
  926. # [23:51] <Domenic> why would you say the constructor is not revealing all the behavior?
  927. # [23:52] <wanderview> Domenic: why would you ever do new ReadableStream(myByteSource)? shouldn't you *always* do new ReadableByteStream(myByteSource)?
  928. # [23:52] <Domenic> wanderview: yes?
  929. # [23:53] <Domenic> did i say otherwise?
  930. # [23:53] <wanderview> Domenic: no... but it feels weird to leave that as a footgun for people
  931. # [23:53] <Domenic> it's the same footgun as new Promise(myByteSource) ... not really worried.
  932. # [23:53] <wanderview> the type is really associated with the source, not the wrapper object
  933. # [23:53] <Domenic> or new WritableStream(myByteSource)
  934. # [23:54] <wanderview> Domenic: except those will fail... ReadableStream(myByteSource) will work, but just prevent consumers from optimizing
  935. # [23:54] <Domenic> The source is an adapter between the conceptual source and the concrete readable stream type
  936. # [23:54] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
  937. # [23:54] <Domenic> wanderview: why would it work?
  938. # [23:55] <wanderview> Domenic: err... from what I can tell new ReadableStream() and new ReadableByteStream() expect the same properties on the passed duck typed source?
  939. # [23:55] <wanderview> is that not true?
  940. # [23:55] <Domenic> wanderview: the argument for ReadableByteStream() is not specced at all yet :)
  941. # [23:56] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  942. # [23:56] <Domenic> wanderview: it will probably be something like { start() { }, read(view), cancel(reason) { } }
  943. # [23:56] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
  944. # [23:57] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  945. # [23:57] <wanderview> ok
  946. # [23:58] <wanderview> Domenic: going back to WritableByteStream... one optimization we have in our native streams is the writing side can pass its destination back into the person doing the write... so in theory this could be passed back to read(view) or something to all a ReadableByteStream to write directly into a WritableByteStream
  947. # [23:59] <Domenic> wanderview: good point, i forgot that was also something we definitely want out of ReadableByteStream + WritableByteStream pipes
  948. # Session Close: Thu Apr 09 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn