| 09:50 | <gsnedders> | I feel like I'm missing something about DNSSEC, what exactly is signed by the root anchors? The results returned by the root servers? |
| 09:59 | <gsnedders> | the lookup includes an RRSIG record, okay |
| 12:27 | <gsnedders> | GPHemsley: In what sense is PDF scripted but not PostScript (in MIME Sniffing)? Does PDF allow access to things outside of the input and PostScript not? |
| 12:35 | <jgraham> | gsnedders: Acrobat certainly allows javascript and seems to have external communication APIs |
| 12:37 | <gsnedders> | Right, I know PDF allows JS but wasn't sure if it allowed external communication. PS is itself Turing-complete so the only question is whether it allows external communication. |
| 12:38 | <jgraham> | Yeah |
| 12:38 | <jgraham> | So I guess it must theoretically be possible c.f. the HTTP server in pure postscript, but I don't know if that depends on specific extensions |
| 12:42 | <JakeA> | Domenic: thinking about how to explain transactions in stores. I keep coming back to things like store.transaction(function{ /* all store operations in here will be transactional */ }).then(...) |
| 12:42 | <JakeA> | then throw up in my mouth |
| 12:43 | <JakeA> | anything in the DOM that does it better? |
| 12:43 | <tobie> | keep calm and swallow it back. |
| 12:43 | <jgraham> | gsnedders: Postscript seems to have file IO, but not network IO except to the extent that you can make a correspondence between the two |
| 12:44 | <gsnedders> | jgraham: so has network IO on any POSIX system :P |
| 12:46 | <jgraham> | gsnedders: For example |
| 12:46 | <gsnedders> | GPHemsley: then PS should surely be considered a scriptable type in MIME Sniffing |
| 13:07 | <Domenic> | JakeA: not that I can think of ... might be worth surveying the LevelDB APIs people have put on npm. |
| 13:07 | <Domenic> | JakeA: I am starting to feel like `store.transaction({ add: [...], remove: [...] })` would make sense? |
| 13:08 | <Domenic> | Or I guess put: ..., delete: ... might be more accurate |
| 13:08 | <JakeA> | Domenic: That misses interleaving put & delete. Also, since put takes 2 args it looks uuuuuugly |
| 13:09 | <JakeA> | store.transaction({ put: [[request, response], [request2, response2]] }) |
| 13:09 | <Domenic> | JakeA: ugly seems OK for a low-level primitive |
| 13:12 | <Domenic> | I will ask the levelDB folks in #stackvm |
| 13:13 | <JakeA> | https://gist.github.com/jakearchibald/0700c1c622c994c2d335 is ugly but it allows interleaving delete & put |
| 13:14 | <Domenic> | JakeA: my main problem with such a thing is that it is a bit too magical. E.g. it looks like it's function scoped but if you do non-store things inside that function, or do anything async, then it's no longer part of the transaction. |
| 13:14 | <Domenic> | Very leaky abstraction |
| 13:14 | <JakeA> | fair |
| 13:15 | <JakeA> | especially when it came to transactions across multiple stores |
| 13:15 | <JakeA> | (which wouldn't work, but may appear if it did) |
| 13:16 | <Domenic> | JakeA: stackvm people suggest https://github.com/rvagg/node-levelup#batch_chained |
| 13:16 | <Domenic> | Very interesting |
| 13:17 | <Domenic> | Feels less like composing nice APIs out of low-level ugly ones, but is a pretty nice end result |
| 13:22 | <JakeA> | That works for me |
| 13:22 | <JakeA> | Domenic: cheers! |
| 13:29 | <Domenic> | :) |
| 13:45 | <Domenic> | JakeA: Substack likes https://github.com/rvagg/node-levelup#dbbatcharray-options-callback-array-form more because it allows you to compose a transaction as an object |
| 13:54 | <JakeA> | Domenic: uglier, but simpler. Less sugar is fine for this method |
| 14:07 | <tobie> | chainable batch object lets you fail faster and more precisely, though (e.g. if you del(key, value)) |
| 14:11 | <tobie> | Domenic: unrelated: re-reading up on Promises today, bumped into wikipedia's definition of Promises where it claims the object given to the client is a future (not a promise). Any idea whether that's true, and if so, why the terminology was changed in JS from something correct to something not? |
| 14:12 | <Ms2ger> | What's "correct"? :) |
| 14:16 | <caitp-> | does it really matter what you call it |
| 14:17 | <tobie> | caitp-: yeah, it's kind of useful if the same name describes the same pattern in different languages. |
| 14:18 | <Domenic> | JakeA: I think there are at least two promise lineages. Brb. |
| 14:19 | <tobie> | caitp: imagine if we had decided to call promises threads instead. :) |
| 14:20 | <tobie> | Domenic: that might explain it. |
| 14:20 | <caitp> | then we could be pretentious and explain the differences between javascript threads and OS threads to people |
| 14:20 | <caitp> | and be the life of the dinner party |
| 14:20 | <tobie> | Please don't invite me to your dinner parties. |
| 14:20 | <caitp> | :d |
| 14:22 | <tobie> | Ms2ger: poor choice of words, admittedly, but does it obscure the gist of the question? |
| 14:22 | <caitp> | I'm not sure the audience of javascript has for the most part had much exposure to other languages implementing the same pattern but named Futures --- although dart might change that |
| 14:24 | <tobie> | that doesn't seem to be a very future proof argument. |
| 14:24 | <tobie> | Anyway, I'm disputing the naming choice. Just curious of its history and the rationale behind it. |
| 14:25 | <tobie> | * I'm NOT disputing |
| 14:25 | tobie | go away, Freud. |
| 14:26 | <caitp> | well, they're already pretty widely used (jQuery.Deferred, etc etc etc) by web developers, and usually called Promises in web-land, so that might have something to do with it |
| 14:31 | <jwalden> | roses by any other names |
| 14:32 | <tobie> | JakeA, Domenic: in case that got lost in the unrelated conversation one of the benefits of chainable batch object is it lets you fail faster and more precisely (e.g. if you del(key, value) you can error immediately). |
| 14:33 | <jgraham> | "roses" you say? I assume that you are thinking that they are marketed as providing great beauty, but in reality there's a lot of specialised knowledge needed to make them grow right, and even then you have to be careful of thorns? Sounds reasonable. |
| 14:34 | <JakeA> | Hmm, I'm not too worried about that, this is a very low level part of the API |
| 15:03 | <Domenic> | JakeA: tobie: IIRC it's E -> Python, C#, F#, JavaScript; vs. Java -> Dart, Scala, others |
| 15:08 | <tobie> | Domenic: sounds fun. Scramble them some more to find out which languages favor assert(expected, actual) and which ones prefer assert(actual, expected) |
| 15:08 | <tobie> | :/ |
| 17:22 | <Hixie> | anyone know anything about deletableBindings in the JS spec, 15.1.7 Runtime Semantics: ScriptEvaluation? jorendorff maybe? |
| 17:23 | <jorendorff> | yeah, let me look |
| 17:24 | <jorendorff> | Hixie: what step? |
| 17:24 | <jorendorff> | oh, the parameter |
| 17:25 | <Hixie> | yeah, the parameter |
| 17:25 | <jorendorff> | Hixie: It's legacy cruft, required for non-strict direct eval. |
| 17:25 | <jorendorff> | Hixie: Inside a JS function, if you do |eval("var x;")| then, bizarrely, the local variable x can be deleted using |delete x| |
| 17:25 | <Hixie> | so i always pass false when evaluating a <script>? |
| 17:25 | <jorendorff> | yes |
| 17:25 | <Hixie> | k, thanks |
| 17:27 | <Domenic> | Hixie: I know you were working on event loop integration a while ago. Where did that end up? |
| 17:27 | <Hixie> | got sidetracked by my work on my new pipeline, but i'm working on it again as we speak |
| 17:28 | <Hixie> | first step is working out how HTML and ES should integrate in general for legacy <script> evaluation |
| 17:29 | <JakeA> | Domenic: tobie: how about store.add(request) which resolves to a response, or store.add([request]) which resolves to an array of responses (one, in this case) |
| 17:32 | <Domenic> | Hixie: nice. My big concern is that we normatively specify promises use microtasks |
| 17:32 | <Domenic> | JakeA: I hate overloading, but that is my only objection. |
| 17:32 | <Domenic> | JakeA: what does var r = new Request(); r[Symbol.iterator] = ...; store.add(r) do |
| 17:34 | <Hixie> | Domenic: yeah. unfortunately while doing this i discovered we had much bigger problems. Like, ES 9.5 and 9.5.1 aren't invoked at all for HTML yet. |
| 17:34 | <JakeA> | Domenic: reject, unless it provides requests or url strings |
| 17:34 | <Domenic> | JakeA: yes, the iterator would be an iterator of requests. BUT IT IS ALSO ITSELF A REQUEST!?! |
| 17:34 | <Domenic> | Hixie: ES6? I imagine because they only recently came into existence :P |
| 17:35 | <Domenic> | Hixie: the issue is that Firefox currently uses macrotasks and there's no spec we can point them to to say that they're doing it wrong |
| 17:36 | <Hixie> | Domenic: yeah, but there's no way to write the microtask spec until we have a foundation to write it on :-) |
| 17:36 | <Ms2ger> | Hixie, this would be a good time to remove references to not-JS-languages-in-<script> in the spec ;) |
| 17:38 | <Hixie> | Ms2ger: i'll get right on that as soon as people stop trying to put non-JS-languages-in-<script>... |
| 17:38 | <JakeA> | Domenic: yep, it'll either treat it as one or the other. |
| 17:38 | <Domenic> | JakeA: and thus, why I hate overloading ;) |
| 17:46 | <JakeA> | Domenic: yeah, but what if I overwrite querySelectorAll to return a random number? |
| 17:46 | <JakeA> | Domenic: crazy stuff will happen. Answer is, don't do that. |
| 17:49 | <Hixie> | the ES spec really is written from the point of view of ES being the core of the world |
| 17:49 | <Domenic> | JakeA: don't overload your methods? Yes, I agree ;) |
| 17:49 | <Hixie> | as opposed to a library that the browser invokes |
| 17:50 | <Domenic> | Hixie: I don't *think* that was Allen's intention... he might be open to changing things |
| 17:51 | <Hixie> | e.g. NextTask is one task |
| 17:51 | <Hixie> | er, one algorithm |
| 17:51 | <Hixie> | called from within other ES algorithms |
| 17:51 | <Hixie> | instead of "InvokeTask" being the top of the ES "stack" |
| 18:35 | <Hixie> | jorendorff, Domenic: this is what i have so far: http://www.hixie.ch/specs/js/loader |
| 18:35 | <jorendorff> | NextTask makes no sense |
| 18:37 | <Hixie> | in ES? or in my strawman above? |
| 18:37 | <Hixie> | i tried sending feedback about turning it inside out in the ES spec, but allen seemed unimpressed |
| 18:37 | <Domenic> | yeah :-/ |
| 18:38 | <jorendorff> | Hixie: in ES. I don't know why Allen wrote it that way. |
| 18:38 | <Domenic> | JakeA: "permacache" haha |
| 18:38 | <Hixie> | jorendorff: ah. yeah. i agree. kinda just working with what i've got at this point. |
| 18:54 | <JakeA> | Domenic: my favourite was "history", but that was down to the shitty 140 char explanation |
| 18:55 | <Domenic> | JakeA: permacache, just like fetchAndStore, seems nicely descriptive to me ;) |
| 18:55 | <TabAtkins> | tobie: What caitp said - the naming is actually remarkably inconsistent across various languages and implementations, as is the exposed API. |
| 18:56 | <TabAtkins> | Promise/Deferred/Future all describe roughly the same thing, depending on what language/library you're using. |
| 18:57 | <Domenic> | TabAtkins: or PromiseCapability X_x |
| 18:57 | <TabAtkins> | wikipedia notes that the terms are used somewhat interchangeably. |
| 19:09 | <TabAtkins> | For whatever reason, the person who wrote that article settled on "Future" for JS's Promise, and "Promise" for JS's resolve/reject functions. |
| 19:12 | <Domenic> | Nothing can be as bad as Wikipedia's JavaScript article |
| 19:23 | <gsnedders> | Domenic: that looks a heckuva lot better than it did when I last looked at it |
| 19:24 | <Domenic> | gsnedders: you're right! However this part is still horrid. https://en.wikipedia.org/wiki/JavaScript#Version_history |
| 19:24 | <gsnedders> | Domenic: totally |
| 19:25 | <gsnedders> | Domenic: I'm not saying it ain't bad, I'm saying it could be worse |
| 19:25 | <Domenic> | Yeah |
| 19:25 | <Domenic> | Before that was 1/3 of the article IIRC |
| 19:26 | <Domenic> | First we need to fix MDN to move all the Mozilla "JS 1.8" etc. stuff into a silo, away from the limelight |
| 19:26 | <Domenic> | Then we can fix wikipedia |
| 19:26 | <Domenic> | And by "we" I mean "probably not me" |
| 19:29 | <SamB> | are you guys allowed to edit that stuff |
| 19:30 | <Domenic> | MDN certainly |
| 19:30 | <SamB> | I was referring to WP:COI |
| 19:30 | <SamB> | wrt the wikipedia article |
| 19:30 | <Domenic> | I don't even know what that means |
| 19:30 | <gsnedders> | SamB: sure, provided you act in a neutral manner |
| 19:31 | <SamB> | what, you guys aren't employed by JavaScript? |
| 19:31 | <gsnedders> | SamB: WP:COI doesn't prohibit editing any article you have an interest in; it merely prevents you from acting in a self-interested manner |
| 19:40 | <SamB> | clearly I have not actually read WP:COI in a while |
| 20:00 | <gsnedders> | SamB: you've never been outright forbidden from it |
| 20:00 | <gsnedders> | SamB: I mean essentially it's just WP:NPOV |
| 20:29 | <Hixie> | zcorpan: oh man, sorry, i totally forgot to do those PRs. Thanks for doing them. |
| 20:59 | <Hixie> | TabAtkins: you around? |
| 20:59 | <TabAtkins> | pong |
| 20:59 | <Hixie> | hey |
| 20:59 | <Hixie> | do you know if there's any chance of a display-box: newline? see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 for context |
| 21:00 | <TabAtkins> | We discussed it on the call but didn't get consensus, so I'mma work on it soonish. |
| 21:00 | <TabAtkins> | And I actually still have that bug open in my tabs here. |
| 21:00 | <Hixie> | what's the "nay" camp's opinion? |
| 21:04 | <TabAtkins> | Specialty display types shouldn't be necessary, as we can just pattern-match on particular styles. |
| 21:05 | <Hixie> | interesting idea |
| 21:05 | <Hixie> | how many of the vendors were on that side? |
| 21:06 | <TabAtkins> | fantasai, mainly. |
| 21:06 | <TabAtkins> | I'd need to review the minutes, though, because I'm biased heavily in the other camp. |
| 21:06 | <Hixie> | unfortunately there don't appear to be any minutes for that specific meeting |
| 21:07 | <Hixie> | (25th of june, if i'm reading the mailing list entrails right) |
| 21:07 | <Hixie> | i checked both lists |
| 21:07 | <TabAtkins> | http://lists.w3.org/Archives/Public/www-style/2014Jun/0398.html |
| 21:07 | <TabAtkins> | You blind, bro? |
| 21:07 | <Hixie> | wow, how did i miss that |
| 21:08 | <Hixie> | oh, heh, it was the one after the last one i opened, before i'd found the agenda |
| 21:08 | <Hixie> | d'oh |
| 21:10 | <Hixie> | looks like no implementors were on board with pattern matching particularly |
| 21:11 | <TabAtkins> | Yeah, that's what I remembered, but didn't want to claim it until I'd read. |
| 21:11 | <Hixie> | btw the biggest problem with pattern matching / special case logic for <br> isn't the performance aspect, that can probably be done pretty efficiently |
| 21:11 | <Hixie> | the biggest problem is that because it's special-cased, you'll get special bugs. |
| 21:11 | <TabAtkins> | Yup, indeed. |
| 21:11 | <TabAtkins> | I don't like pattern-matching for that reason. |
| 21:11 | <Hixie> | like, some new property is added, and it matches either way, and you end up with the wrong code path just for that specific combination of properties |
| 21:11 | <Hixie> | anyway |
| 21:11 | <Hixie> | ok |
| 21:11 | <Hixie> | you any objection to my just speccing it in HTML? |
| 21:12 | <TabAtkins> | I'm going to put it in Display, so whatevs. |
| 21:12 | <Hixie> | oh ok, cool |
| 21:12 | <TabAtkins> | Want me to just put it in now, and have you ref it as unstable? |
| 21:12 | <Hixie> | no rush. |
| 21:12 | <Hixie> | i'll roll this one to the bottom of my pile and will get back to you in a few weeks. |
| 21:48 | <TabAtkins> | Hixie: What element autolink in your preprocessor? |
| 21:48 | <TabAtkins> | Looks like <code> does? |
| 21:48 | <Hixie> | code, span, var, and i. |
| 21:49 | <TabAtkins> | kk. Confused why all the <var>s in the spec *lost* their data-x attrs, then. |
| 21:49 | <Hixie> | var and i are special in that unles they have a data-x, they won't cross-ref |
| 21:49 | <Hixie> | i really should probably change from <span> to <a> |
| 21:52 | <Hixie> | TabAtkins: since it seems to be just us working today... any news on https://www.w3.org/Bugs/Public/show_bug.cgi?id=24991 ? |
| 21:53 | <TabAtkins> | In what way? Was I supposed to do something? |
| 21:54 | <Hixie> | apparently you talked about it in a telecon http://lists.w3.org/Archives/Public/www-style/2014May/0024.html |
| 21:54 | <Hixie> | i guess http://lists.w3.org/Archives/Public/www-style/2014May/0056.html says it's in |
| 21:54 | <Hixie> | so i should just use it? |
| 21:55 | <Hixie> | "bert: So let's say I want to use JS" wow |
| 21:56 | <jgraham> | Wow that he might want to use JS, or wow that that was a line from a telecon in 2014? |
| 21:56 | <Hixie> | more the former |
| 22:02 | <TabAtkins> | Hixie: Ah, whoops, I never made that change. |
| 22:02 | TabAtkins | desperately needs to just crank through all the minutes and find thinks he hasn't done yet. |
| 22:02 | <Hixie> | heh |
| 22:02 | <Hixie> | that's what i use bug reports for |
| 22:02 | <Hixie> | (or e-mails to whatwg) |
| 22:03 | <TabAtkins> | Hixie: Define it in HTML, lemme know the anchor, I'll add it to Selectors and link to HTML for the lang-specific definition. |
| 22:03 | <Hixie> | roger |
| 22:03 | <Hixie> | anchor will be selector-modal |
| 22:03 | <caitp> | arv_, do you know if Object.observe (& related api) was ever in the harmony draft at all, and what happened to it if it was? |
| 22:03 | <caitp> | and why not if it wasn't :p |
| 22:03 | <caitp> | #jslang is a bit quiet today, so I inquire here |
| 22:03 | <arv_> | caitp: It was decided that it would go in ES7 |
| 22:04 | <arv_> | caitp: and it uses the new process (waterfall, ship when ready model) |
| 22:04 | <caitp> | hmm I see |
| 22:09 | <caitp> | so was the actual design finalized? or is that still likely/possible to change? |
| 22:10 | <TabAtkins> | Well, it's shipping now, so pretty final. |
| 22:10 | <caitp> | shipping in a single browser |
| 22:10 | <caitp> | behind flags |
| 22:15 | <caitp> | anyways, I haven't really reviewed it yet, but Rob Eisenberg put together some tests http://jsperf.com/observing-objects using different strategies, and from his results it looks actually worse to depend on O.o by quite a bit compared to dirty checking. (but obviously prone to all the usual issues with jsperf, and possibly very bad tests) |
| 22:16 | <caitp> | so I just wanted to see if anything in the specification had changed, but couldn't find any of it :> |
| 22:17 | <gsnedders> | caitp: is that not QoI? |
| 22:18 | <caitp> | well it might be a QoI issue, or it might be a fundamental problem with the algorithms, or it might be just bad tests |
| 22:19 | <caitp> | or a mix of 2 or all 3 |
| 22:19 | <gsnedders> | I suspect it's the fact that normal property accesses are ridiculously well optimized, and Object.observe is a slow-case compared with that |
| 22:20 | <gsnedders> | I suspect observing it will always be slower than checking for changed properties |
| 22:20 | <caitp> | yes |
| 22:20 | <caitp> | but 1:100 might not be a very good ratio |
| 22:20 | <gsnedders> | Because fundementally in your baseline code you'll always generate simple property accesses and slowcase if there's an observer |
| 22:22 | <caitp> | right, but what it comes down to is it might not even be worth using if it's cheaper without |
| 22:23 | <gsnedders> | idk, I very much suspect the V8 impl is just unoptimized |
| 22:24 | <caitp> | could be, should get mi�ko over there :p |
| 22:31 | <TabAtkins> | No, I think it's shipping publicly in the upcoming Chrome. (I think?) |
| 22:32 | <caitp> | oh, no apparently it's enabled by default in m36 |
| 22:37 | <bretolius> | sort of related… anyone have the w3c irc network url with the ssl port? |
| 22:39 | <TabAtkins> | bretolius: irc.w3.org:6667 |
| 22:39 | <bretolius> | TabAtkins ty :) |
| 22:40 | <caitp> | that doesn't look like an ssl port |
| 22:41 | <TabAtkins> | Eh, it's the only port I kno. |
| 22:41 | <TabAtkins> | know |
| 22:50 | <Hixie> | can someone check the "Manipulation of the execution context stack" thread on es-discuss to see if i'm missing something? |
| 22:50 | <Hixie> | i just don't understand what allen is saying |