| 12:30 | <Ms2ger> | "XML Interfaces to the Internet of Things with XForms" |
| 13:26 | <TabAtkins> | Ms2ger: Why you gotta tease us like that? |
| 13:28 | <gsnedders> | TabAtkins: Ms2ger just knows what you like to hear first thing in the mornin' |
| 13:29 | <TabAtkins> | Well, he's not wrong. |
| 13:30 | <gsnedders> | He's sufficiently advanced AI, of course he's not wrong. |
| 13:31 | <TabAtkins> | I've seen him, and I don't think it was a skinvelope (unlike bz's remote-operated body). |
| 13:31 | <TabAtkins> | Wait, is bz or bzed bzbarsky? |
| 13:32 | <jgraham> | bz |
| 13:33 | <gsnedders> | Pretty sure people having "seen" either Ms2ger or bz is just a conspiracy to make people believe they're human. |
| 13:34 | <gsnedders> | Ms2ger doesn't even have a real name! |
| 13:34 | <BigPants> | Hey guys, I asked this a few days back but I don't think a lot of people were around... what do you think of exposing the dirty flag on input fields? Is that something that's been discussed before? |
| 13:36 | <BigPants> | Maybe there's a better place to ask? |
| 13:39 | <gsnedders> | BigPants: here and the mailing list are probably the best places; I don't think it's been discussed before, but it needs though as to whether there are any subtle implications of doing so. What's the use-case for exposing it? |
| 13:45 | <BigPants> | gsnedders: It would be a lot easier to make use of something like that than to hack together your own dirty checking in javascript (or use a library that does it for you) if you want to submit only the fields in a form that's been changed. Big forms where users change only minor details benefit quite a lot from only sending dirty fields |
| 14:44 | <wanderview> | Domenic: ping |
| 14:49 | <wanderview> | Domenic: is there a solution for the chained resolved promises causing excessive memory pressure? |
| 14:50 | <wanderview> | Domenic: I am now seeing about a 10% penalty promise returning read() vs sync read()... but I changed my test to chain promises together |
| 14:55 | <wanderview> | Domenic: actually, I added an unchained path to compare, and I see the 10% penalty regardless... hmm |
| 15:16 | <Domenic> | wanderview: one of the Bugzilla patches you linked me to was a mitigation, I am pretty sure ... Chrome also has a mitigation I believe, although a less spec-compliant one :-/ |
| 15:17 | <wanderview> | Domenic: well, it seems unrelated to the chaining... let me push the code to repo and let you look at it |
| 15:17 | <wanderview> | Domenic: sample output I am seeing on my desktop here: https://pastebin.mozilla.org/8833452 |
| 15:18 | <wanderview> | async cases have lower throughput and about a 10ms latency penalty there |
| 15:18 | <wanderview> | I haven't tried with bluebird yet |
| 15:19 | <wanderview> | Domenic: look at the various Pump classes in here and tell me if I'm doing something stupid: https://github.com/wanderview/streams-time-echo/blob/master/client.js |
| 15:21 | <Domenic> | Probably doesn't matter much but while (chunk) isn't exactly reflective of how the sync API would have to work... it'd have to be a while (self._parser.state === "readable"), with state being a getter |
| 15:23 | <Domenic> | Similarly async is using falsy/truthy chunks instead of { value, done } |
| 15:24 | <Domenic> | although actually async isn't testing truthiness of the chunks; the asymmetry there is confusing to me. |
| 15:25 | <wanderview> | Domenic: the truthiness test was just for backpressure signal... which the async gets via the promise... |
| 15:25 | <Domenic> | executeTestList is broken, you can't return from inside `new Promise` |
| 15:25 | <Domenic> | wanderview: ah ok I thought it was done-ness signal |
| 15:25 | <Domenic> | wanderview: but you need to allow falsy chunks anyway, so you need a separate .state property |
| 15:25 | <wanderview> | Domenic: I'm using the web socket state for close signal |
| 15:26 | <wanderview> | hmm, let me fix executeTestList |
| 15:27 | <Domenic> | not sure why it's promise-returning at all honestly |
| 15:29 | <wanderview> | yea, it doesn't need to be |
| 15:30 | <wanderview> | Domenic: I seem to get bimodal results... I wonder if the lower mode is just hitting that pathological stream chunking I saw before |
| 15:37 | <wanderview> | Domenic: ok... things seem more equivalent now on my desktop... let me test on mobile |
| 15:37 | <wanderview> | I assume there is a canary for android? |
| 15:38 | <Domenic> | wanderview: no, but there's a dev, which will be just a week behind at most |
| 15:39 | <wanderview> | Domenic: got it... I'll have to sort out the IPs on my network to connect my mobile to the test server |
| 15:39 | <Domenic> | Can you push the code changes? |
| 15:40 | <wanderview> | Domenic: sure... I only fixed the executeTestList() thing |
| 15:40 | <Domenic> | Ah OK |
| 15:40 | <Domenic> | Is that what changed the results you think? |
| 15:40 | <wanderview> | I don't know... its possible |
| 15:41 | <wanderview> | it seems very sensitive |
| 15:41 | <wanderview> | I also added a bluebird.html |
| 15:41 | <Domenic> | Oh nice |
| 15:41 | <wanderview> | Domenic: but even with native promises I don't see much difference: https://pastebin.mozilla.org/8833455 |
| 15:42 | <wanderview> | Domenic: I'm going to re-run the tests on a more idle machine without a VM, etc... could be noise from other stuff on my desktop |
| 15:42 | <wanderview> | will do all that after lunch |
| 15:43 | <wanderview> | Domenic: one difference is now I'm running with devtools closed... maybe it was enabling some debugging in promises that was penalizing things |
| 15:43 | <Domenic> | Oh yeah it probably was |
| 15:44 | <Domenic> | I don't know the details but I do know devtools has a lot of hooks into promises and I assume that they're smart enough to turn those off when devtools is closed |
| 15:44 | <Domenic> | or at least some of them |
| 16:02 | <Ms2ger> | So node.deleteData(2, -1) crashes Servo \o/ |
| 16:03 | <jgraham> | Ms2ger: Which kind of crashes? |
| 16:24 | <Ms2ger> | Overflow |
| 16:25 | <jgraham> | Ah |
| 16:25 | <Ms2ger> | Which is all hardware limitations, clearly :) |
| 16:25 | <jgraham> | I was just checkin it wasn't something more untoward :) |
| 16:34 | <gsnedders> | Ms2ger: what overflows? the -1? |
| 16:35 | <gsnedders> | oh you're talking about this in #servo |
| 16:35 | <Ms2ger> | Yeah |
| 16:35 | <Ms2ger> | -1 is wrapped to 2**32-1, and then the sum overflows |
| 20:12 | <smaug____> | dglazkov: sorry, forgot to answer to custom elements doodle |
| 20:12 | <smaug____> | (in theory july 21 should be ok) |
| 20:20 | <dglazkov> | smaug____: \o/ |
| 20:21 | <wanderview> | Domenic: I think whatever bug was causing huge memory issues in chrome with your streams demo is causing similar havoc with my time echo benchmark... it basically blows up with an OOM on my mac laptop |
| 20:21 | <wanderview> | runs fine on my windows desktop |
| 20:24 | <Domenic> | O_o |
| 20:25 | <Domenic> | You're not even using Chrome streams, right? |
| 20:25 | <Domenic> | Just web sockets? |
| 20:25 | <wanderview> | Domenic: remember the chained promise bug where they said it only blew up memory on mac... I seem to be getting the same problem |
| 20:25 | <Domenic> | I ... I guess .... |
| 20:25 | <wanderview> | Domenic: I am using chrome streams to read from the Response... I only use web sockets to upload back to the node.js server |
| 20:25 | <wanderview> | or I am doing something stupid |
| 20:26 | <Domenic> | Ah OK I missed that |
| 20:26 | <Domenic> | Maybe ... maybe the GC is bad on mac? |
| 20:26 | <wanderview> | I don't know... I'm going to skip mac and just try my android device |
| 20:26 | <Domenic> | Or the streams I guess... so strange. |
| 20:26 | <wanderview> | it could also be a bug in my server... what I ctrl-z the server and memory keeps climbing in chrome... its very weird |
| 20:27 | <wanderview> | sampling the process shows a bunch of string operations being done |
| 20:30 | <wanderview> | Domenic: I don't understand what could be different on mac... GC and stuff seems like it should be the same... maybe some IPC problem specific to streams and mac? |
| 20:31 | <Domenic> | Yeah ... Tokyo should be waking up in a few hours... I guess this might be worth filing a crbug for? |
| 20:31 | <Domenic> | String operations ... strange ... |
| 20:32 | <wanderview> | I didn't look at the sample long... |
| 20:34 | <jsbell> | Domenic: Are transform streams to the point where we should discuss how to bolt them onto TextEncoder/Decoder ? |
| 20:35 | <Domenic> | jsbell: no :(. they are still languishing somewhat unloved. I gotta kick the tires on writable and transform... |
| 20:35 | <Domenic> | I should try to find some Chrome feature that requires writable so we can whip them into shape |
| 20:37 | <jsbell> | Domenic: no worries; ping me if the status changes (and/or I'll continue to low frequency poll) |
| 20:41 | <Domenic> | for sure |
| 21:10 | <wanderview> | Domenic: I see a penalty for promise read() on my nexus5 with native promises... but its pretty equivalent with bluebird |
| 21:12 | <wanderview> | its hard to make this benchmark reliable with the body stream without back pressure... I have to implement my own back pressure mechanism, but I risk deadlock then if chrome decides to buffer things right as I'm doing backpressure |
| 21:25 | <wanderview> | gah.. or not... these tests are so sensitive |
| 21:33 | <wanderview> | Domenic: I ran some more tests and it looks like a 5% penalty for promise read vs sync read... I'll post data in the github issue later... I'm not sure if that is a big enough difference to worry about |
| 21:33 | wanderview | runs to dinner... |
| 21:35 | <Domenic> | wanderview: thanks for all the work!! |
| 21:35 | <wanderview> | oh... and that penalty only shows for mobile... desktop is fast enough you can't see it with this test |
| 22:28 | <jsbell> | The IndexedDB spec is so old it cites "geocities.com" as an example. (Will definitely leave that in for v2 because nostalgia) |