| 00:21 | <TabAtkins> | Domenic: Isn't JS already doing bignums? |
| 00:22 | <Domenic> | TabAtkins: yep. Most recent stuff is at https://github.com/nikomatsakis/typed-objects-explainer/ |
| 03:03 | <MikeSmith> | Streusel: btw the W3C validator is up-to-date now with the latest meta@name values in the wiki (went in along with other changes I pushed yesterday) |
| 03:13 | <Streusel> | awsum, thanks for letting me know |
| 06:34 | <annevk> | Hixie_: the resource hints thread on WHATWG impacts your research on reconciling dependency management |
| 07:27 | <zcorpan> | what's the use case for relList again? |
| 07:47 | <Ms2ger> | zcorpan, convenience, I guess? |
| 07:47 | <Ms2ger> | Might not be as useful as classList, I guess |
| 07:47 | <zcorpan> | Ms2ger: convenience seems moot if it's something nobody ever does |
| 07:47 | <Ms2ger> | Yeah |
| 07:48 | <Ms2ger> | Does anyone implement it yet? |
| 07:48 | <zcorpan> | gecko according to caniuse |
| 07:49 | <Ms2ger> | Hmm |
| 07:50 | <Ms2ger> | Caniuse is correct |
| 07:50 | <Ms2ger> | karlcow filed the bug |
| 07:54 | <Ms2ger> | zcorpan, r? https://critic.hoppipolla.co.uk/r/2323 if you're interested in selectorsapi tests :) |
| 07:56 | <zcorpan> | Ms2ger: yeah i was checking that briefly and concluded that it required more mental stress than i was prepared for at this time :-) will check again later |
| 07:56 | <Ms2ger> | Heh |
| 13:30 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/403#issuecomment-51711008 - why must URL parsing happen before the async steps? |
| 13:58 | <annevk> | JakeA: as I said, it grabs global state |
| 14:02 | <JakeA> | annevk: the parsing does, or just getting the document url for use as the base? |
| 14:03 | <annevk> | JakeA: the parsing does if you use the generic parser |
| 14:04 | <annevk> | JakeA: which might not be needed here |
| 14:04 | <annevk> | JakeA: you could probably use the base URL parser if you want to do parsing async |
| 14:04 | <JakeA> | annevk: it doesn't need to be async, just getting an understanding of the issue |
| 14:06 | <annevk> | JakeA: so yeah, the parsing could probably be async, but typically we do all that on the "main thread" |
| 14:22 | <zcorpan> | was there a flowchart for how <object> loading works? Hixie_? |
| 14:46 | <JakeA> | annevk: is it just the url stuff that's problematic in [[Register]], I can't see anything else |
| 14:47 | <annevk> | JakeA: origin comparisons potentially |
| 14:48 | <annevk> | JakeA: [[GetRegistration]]'s for each might race? |
| 14:48 | <JakeA> | annevk: would you parse the document url before async to work around that? |
| 14:49 | <annevk> | JakeA: I would probably do the security check sync |
| 14:49 | <annevk> | JakeA: ah yes |
| 14:49 | <JakeA> | makes sense |
| 14:50 | <annevk> | JakeA: that's how these algorithms typically go |
| 14:51 | <annevk> | JakeA: I guess the only difference with the normal way is that here fetching isn't starting yet |
| 14:51 | <annevk> | JakeA: in terms of language "Browsers may ignore this potentially secure origin rule for development purposes only." is problematic |
| 14:52 | <annevk> | JakeA: you cannot make normative (MAY) statements in a Note |
| 14:53 | <JakeA> | annevk: should that note be there at all, or is it implicit that developer tools can alter spec behaviour? |
| 14:53 | <annevk> | JakeA: prolly better as "If the origin of scriptURL is not potentially secure and developer tools are not enabled," |
| 14:53 | <annevk> | JakeA: yeah |
| 14:53 | <annevk> | actually yes |
| 14:54 | <annevk> | "Note: Developer tools are expected to enable easier experimentation." |
| 14:55 | <annevk> | JakeA: but I think instead of saying "potentially secure" you just want to say if the scriptURL's scheme is not https |
| 14:55 | <annevk> | JakeA: because we want this to be a networked resource |
| 14:57 | <JakeA> | annevk: we should include private origins too, then asset it's a network resource in a separate step |
| 14:57 | <JakeA> | (localhost for example) |
| 14:58 | <annevk> | JakeA: localhost is not a potentially secure origin afaict |
| 14:58 | <annevk> | oh sorry |
| 14:58 | annevk | needs to read |
| 15:01 | <JakeA> | annevk: regarding "Run the following substeps asynchronously:", should that be switched for "queue a task to run the following steps synchronously"? |
| 15:01 | <annevk> | no |
| 15:02 | <annevk> | most of that should probably be async |
| 15:02 | <annevk> | although you need to be careful with regards to racing |
| 15:03 | <JakeA> | yeah, that's my worry |
| 15:04 | <annevk> | I suspect the registrations bit is in the same thread where the UA does navigation and maybe history |
| 15:04 | <annevk> | Instead of phrasing it with for/each you might be better of phrasing it in English |
| 15:05 | <annevk> | as an operation that returns a bunch of globally registered things |
| 15:06 | <annevk> | but yeah, it's a similar problem as what I had with fullscreen, you don't really know if someone else is doing the same thing or changing that global registered things thing |
| 15:06 | <annevk> | unless you'd define that part as having its own event loop, etc. |
| 15:09 | <JakeA> | annevk: yeah, register(...); register(...); shouldn't be racey |
| 15:10 | <annevk> | without something like the storage mutex that's hard I think |
| 15:10 | <annevk> | well, there's some ordering guarantees |
| 15:21 | <Hixie_> | zcorpan: it's in the comments. dunno how accurate it is. |
| 15:52 | <ehsan> | JakeA: hey, where is the service worker cache discussion meeting happening? |
| 15:53 | <JakeA> | ehsan: there's a hangout link in the invite |
| 15:53 | <ehsan> | JakeA: not in the one that I received :) |
| 15:54 | <ehsan> | JakeA: can you please paste the link here? |
| 15:55 | <JakeA> | ehsan: https://plus.google.com/hangouts/_/calendar/amFmZmF0aGVjYWtlQGdtYWlsLmNvbQ.h1hjes3p8fo8i8g9mhfbaghpi4 |
| 15:55 | <ehsan> | ta |
| 16:21 | <zcorpan> | Hixie_: does your pipeline strip out comments? |
| 16:21 | <Hixie_> | 5es |
| 16:21 | <Hixie_> | yes even |
| 16:21 | <zcorpan> | ok :-/ |
| 16:22 | <Hixie_> | you wouldn't want to look in the published source anyway |
| 16:22 | <Hixie_> | that's a mess |
| 16:22 | <Hixie_> | look in the pre-pipeline source :-) |
| 16:22 | <zcorpan> | i could have used http://simon.html5.org/sandbox/bookmarklets/reveal-comments |
| 16:36 | <Hixie_> | is ModuleLinkage the same as LinkSet in the ES6 spec? |
| 16:38 | <Hixie_> | ah, no, it's a copy/paste error |
| 16:42 | <Hixie_> | jorendorff: any idea what a Module record is? |
| 16:42 | <Hixie_> | as in, if L is a Loader record, L.[[Modules]][i].[[Module]] |
| 16:43 | <jorendorff> | Hixie_: spec bug. It means a Module object. |
| 16:44 | <Hixie_> | ah ok |
| 16:44 | <caitp> | is the change history for the draft actually available anywhere? man that would be so useful |
| 16:44 | <caitp> | and by "anywhere" I mean publicly |
| 16:44 | <jorendorff> | caitp: NO. |
| 16:45 | <jorendorff> | caitp: the editor refuses to use version control |
| 16:45 | <caitp> | that's unfortunate |
| 16:45 | <jorendorff> | tell me about it |
| 16:46 | <jorendorff> | i didn't have a chance to talk about formal grammars with my 8-yr-old this weekend, but i think i have an approach that... *might* work |
| 16:46 | <jorendorff> | sorry, offtopic |
| 16:46 | <TabAtkins> | jorendorff: Actually, that sounds on-topic and very interesting. Elaborate? |
| 16:46 | <caitp> | i'm excited to hear about the progress on that front =) |
| 16:47 | <Ms2ger> | Sounds off-topic... There's logic in formal grammars :) |
| 16:47 | <jorendorff> | Ms2ger: have you looked at the es6 spec lately? ;) |
| 16:47 | <TabAtkins> | I see you've never tried to use the CSS 2.1 grammar. |
| 16:48 | <jorendorff> | TabAtkins: someone (I think caitp?) made the controversial claim in irc.mozilla.org#jslang that there's no reason formal grammars can't be explained so a typical 5-year-old can understand |
| 16:48 | <Ms2ger> | jorendorff, I try to avoid it in general, not for the grammar in particular :) |
| 16:49 | <jorendorff> | this was in support of the less controversial claim that the ES6 spec is unnecessarily incomprehensible |
| 16:50 | <caitp> | it was me, but I think I might have been exaggerating slightly when saying 5 year olds should thoroughly understand it --- but I think it should be possible to explain these things in ways that are accessible to young people |
| 16:50 | <caitp> | not even necessarily young people |
| 16:50 | <caitp> | 30-somethings with hangovers |
| 16:50 | <caitp> | it should be doable |
| 16:50 | <TabAtkins> | I mean, just post a question to http://www.reddit.com/r/explainlikeimfive/ |
| 16:50 | <Ms2ger> | I certainly won't argue against that |
| 16:50 | <TabAtkins> | And you'll get an answer. |
| 16:56 | <Hixie_> | jorendorff: step 2 of http://people.mozilla.org/~jorendorff/es6-draft.html#sec-createlinkset |
| 16:56 | <Hixie_> | jorendorff: is that a spec bug? |
| 16:58 | <Hixie_> | also how can PromiseBuiltinCapability() ever return an abrupt completion |
| 16:58 | <Hixie_> | isn't that all internal to the spec |
| 16:58 | <jorendorff> | Hixie_: regarding step 2 of CreateLinkSet, yes |
| 16:58 | <Hixie_> | what should it be? |
| 17:01 | <Hixie_> | jorendorff: loader.[[LoaderObj]] ? |
| 17:02 | <jorendorff> | Hixie_: well, *really* there shouldn't be two separate things, a Loader Object and a Loader Record. |
| 17:02 | <jorendorff> | There should just be the Loader Object |
| 17:02 | <jorendorff> | and those Loader Record fields should be internal slots of the object. |
| 17:02 | <jorendorff> | they're 1-to-1 already anyway, the record is stupid |
| 17:03 | <jorendorff> | but to answer your question, yes. |
| 17:10 | <Hixie_> | jorendorff: k |
| 17:11 | <Hixie_> | sweet freaking kittens following this is making my mind melt |
| 17:11 | <Hixie_> | PromiseOfStartLoadPartwayThrough() creates a promise, sets a particular function as the executor, and chains to it synchronously |
| 17:12 | <Hixie_> | AsyncStartLoadPartwayThrough(), that executor, immediately creates a new promise and slaves its own result to that new promise's |
| 17:12 | <Hixie_> | it then either creates YET ANOTHER promise and ASYNCHRONOUSLY jumps to a function it slaves to that promise, OR, it calls another function that does that |
| 17:13 | <Hixie_> | at this point, if you can follow who is actually running, when they'll be running, or what will happen when they return, you're a stronger person than i |
| 17:15 | <Hixie_> | aha! haha! hah! |
| 17:15 | <Hixie_> | i have finally found the function i'm supposed to call! |
| 17:16 | <Hixie_> | LoadModule(loader, name, options) ! |
| 17:16 | <Hixie_> | no idea what i'm supposed to call it with, but that's another story! |
| 17:17 | <annevk> | only took a week :p |
| 17:21 | <Hixie_> | http://www.gliffy.com/go/publish/6040024 ! |
| 17:22 | <Hixie_> | witness the glory |
| 17:35 | <Hixie_> | jorendorff: so, first, how does that look to you? did i make any mistakes? |
| 17:36 | <Hixie_> | jorendorff: second, now that i have a better handle on what's going on beneath the hood, let's talk about what the Web's default Loader should do. |
| 17:36 | <jorendorff> | absolutely |
| 17:36 | <jorendorff> | (to the second, still looking at the first part) |
| 17:36 | <Hixie_> | jorendorff: normalize() -- do we need to change anything here? e.g. is it supposed to resolve the URL or something? |
| 17:38 | <Hixie_> | lol, gliffy's svg export is lame |
| 17:38 | <Hixie_> | http://junkyard.damowmow.com/552 |
| 17:38 | <Hixie_> | half of it just comes out as bitmaps |
| 17:40 | <annevk> | Philips on HDMI-CEC: "The HDMI-CEC functionality on devices from other brands might not work with your TV due to different interpretations of the HDMI-CEC industry standard." |
| 17:40 | <annevk> | "Web pages might not work due to different interpretations of HTML." |
| 17:41 | <caitp> | just imagine if there was some kind of reference implementation that people could use to clarify questions about specs |
| 17:41 | <caitp> | wouldn't that be nifty |
| 17:42 | <annevk> | that just creates more issues |
| 17:43 | <Hixie_> | reference implementations rarely match the spec, so actually, it's like having two specs |
| 17:43 | <Hixie_> | and if you doubt the problems of having two specs, just look at HTML |
| 17:44 | <caitp> | if there's a difference between a reference implementation and the spec it implements, one would err on the side of the reference implementation because there's evidence that it works and isn't just a collection of ideas |
| 17:45 | <Hixie_> | jorendorff: so if i wanted to make it possible to import binary blobs, e.g. import sprites as "spritesheet.png";, what would i return in the fetch hook? the empty string but remember in the backend that this particular load has associated binary data? |
| 17:46 | <Hixie_> | actually i get it doesn't check that the return value is a string |
| 17:49 | <jorendorff> | Hixie_: normalize() converts from (a) literally whatever they put into the import statement, to (b) the name a loaded module is cached under |
| 17:49 | <jorendorff> | so if you want people to be able to... import foo from "../baz.js"; |
| 17:49 | <jorendorff> | but you want it to be cached under a URL |
| 17:49 | <jorendorff> | or something else entirely |
| 17:49 | <Hixie_> | so normalise resolves urls |
| 17:49 | <jorendorff> | no |
| 17:49 | <jorendorff> | that's not the design intent, i misspoke |
| 17:50 | <Hixie_> | oh |
| 17:50 | <Hixie_> | i was gonna say, the spec says locate resolves. |
| 17:50 | <jorendorff> | yeah, locate resolves |
| 17:50 | <Hixie_> | so do we not want import foo from "../baz.js"; to work? |
| 17:50 | <Hixie_> | or? |
| 17:50 | <Hixie_> | i'm confused |
| 17:50 | <Hixie_> | seems like we need normalise to resolve |
| 17:50 | <Hixie_> | and locate to be a no-op |
| 17:51 | <jorendorff> | that's possible, but what i'd like is to have some kind of `myLoaderObject.paths` property that makes it easy to customize that lookup --- require.js has this |
| 17:52 | <jorendorff> | so there's some separation between application code and deployment |
| 17:52 | <Hixie_> | ah |
| 17:52 | <jorendorff> | admittedly the rest of the web platform doesn't exactly have this... |
| 17:52 | <Hixie_> | well it would if we added this |
| 17:52 | <Hixie_> | since this is going to end up being the entire platform's loading mechanism if i have my way |
| 17:52 | <jorendorff> | but like, I just want to say import $ from "jquery"; <--- and be able to share that line of code with people I don't know and have it work for them |
| 17:53 | <jorendorff> | because they've also got "jquery" in their environment |
| 17:53 | <jorendorff> | at a path that's known to them |
| 17:53 | <jorendorff> | Hixie_: yeah! |
| 17:54 | <Hixie_> | so there's a difference between mapping names to URLs, which is what |import $ from "jQuery"| apperas to be, and having your traditional path lookup system |
| 17:54 | <Hixie_> | in particular, path lookup wouldn't work on the web |
| 17:55 | <Hixie_> | (no way to stat efficiently) |
| 17:55 | <jorendorff> | right |
| 17:55 | <Hixie_> | a mapping is hard because it needs a declaration mechanism |
| 17:55 | <Hixie_> | which we could add i guess |
| 17:55 | <jorendorff> | require.js doesn't do that, it's not CLASSPATH |
| 17:55 | <Hixie_> | so you could say <script type=module name=jQuery> |
| 17:55 | <Hixie_> | to declare the mappings |
| 17:55 | <Hixie_> | is that more what you meant? |
| 17:55 | <jorendorff> | yes |
| 17:56 | <Hixie_> | so then what would normalise actually do? |
| 17:56 | <jorendorff> | though i'd like to be able to configure it in js without having to use document.createElement('script') |
| 17:56 | <Hixie_> | still seems like it needs to output a url at the end of the day |
| 17:56 | <Hixie_> | sure |
| 17:56 | <Hixie_> | we'd have an API for it |
| 17:56 | <jorendorff> | k |
| 17:57 | <Hixie_> | (realistically you're going to want to predeclare all your modules, style sheets, etc, declaratively anyway, so we can do prefetching) |
| 17:57 | <jorendorff> | yeah |
| 17:57 | <jorendorff> | ok |
| 17:57 | <Hixie_> | (there's no way the web can wait for ES6's parser to see the "import" declaration) |
| 17:57 | <jorendorff> | Hixie_: ok, so all normalize would do is resolve relative module names to full module names |
| 17:57 | <Hixie_> | (at least not for the near term) |
| 17:57 | <Hixie_> | what's a "full module name"? |
| 17:58 | <Hixie_> | seems like there's one step that takes ambiguous names and outputs full absolute URLs |
| 17:58 | <Hixie_> | and it has to happen before the registry lookup |
| 17:58 | <Hixie_> | i don't see how that gets split in two |
| 17:58 | <jorendorff> | in the design, the module names have a hierarchy that's totally independent of where stuff is located |
| 17:59 | <jorendorff> | i mean, it's not baked in, because you can have normalize be a no-op |
| 17:59 | <jorendorff> | but that was the idea. people want to have packages that contain multiple modules |
| 18:00 | <Hixie_> | what's a "package" in this context? |
| 18:01 | <jorendorff> | like npm, an installable chunk of software. or like java, a directory containing related files of code. either meaning. |
| 18:02 | <jorendorff> | more like npm, not so much like java |
| 18:02 | <Hixie_> | ok but either way you still need to predeclare each file, right? so how does this affect us? |
| 18:02 | <jorendorff> | it affects the author of the package. say my package is called libjorendorff |
| 18:02 | <jorendorff> | and it's big, it's several modules |
| 18:04 | <jorendorff> | if there's a normalize hook, in libjorendorff/factories i can write `import "./pipelines"` and the normalize hook could resolve that to "jorendorff/pipelines" |
| 18:04 | <jorendorff> | that "/" is not a URL path separator |
| 18:04 | <jorendorff> | because that's not a url, it's just a module name |
| 18:04 | <Hixie_> | oh you want the web platform to support that natively? |
| 18:05 | <jorendorff> | a package then doesn't have to depend on its own name, which lets you load multiple versions of it at once under different names (without the cache getting confused) |
| 18:05 | <Hixie_> | this would all still need to happen along with url resolution in the normalise hook, though, right? |
| 18:05 | <Hixie_> | anyway i'm happy to do more than straight forward name lookup followed by url resolution. but i've no idea what it should be exactly, i'd need to be told precisely what people wanted. |
| 18:06 | <jorendorff> | ...i think we could actually supply that |
| 18:06 | <jorendorff> | but so why not convert it to a URL in the locate hook? |
| 18:06 | <jorendorff> | the design intent was that in the web platform, locate() spits out a URL |
| 18:07 | <jorendorff> | but you really want URLs to be the cache key? |
| 18:07 | <Hixie_> | i don't understand how anything else would work |
| 18:07 | <Hixie_> | why would you cache on anything _but_ the url? |
| 18:07 | <jorendorff> | well, so consider python for example |
| 18:08 | <jorendorff> | import sys; print(sys.modules) |
| 18:08 | <jorendorff> | that corresponds exactly to the loader cache. |
| 18:08 | <jorendorff> | it's just a {string: module} dictionary |
| 18:08 | <jorendorff> | but the strings are module names, not filenames. |
| 18:08 | <Hixie_> | say one package does |import image from "foo.png"| and another does |import image from "./foo.png"|, do you want the image to be fetched twice? |
| 18:08 | <Hixie_> | python doesn't have a high download cost |
| 18:09 | <jorendorff> | Hixie_: that's not true, going to disk is slow and loading/parsing code twice would be slow; in addition things wouldn't work properly |
| 18:09 | <Hixie_> | nor, i suspect, does it have a way to map two names to different paths |
| 18:11 | <Hixie_> | (which meaning the same underlying file) |
| 18:11 | <jorendorff> | the difference in stat() performance doesn't seem to bear on this. Python could certainly cache based on filename. Why doesn't it? |
| 18:11 | <Hixie_> | what's the difference between what it does and caching on filenames, in practice? |
| 18:11 | <jorendorff> | Java ClassLoaders don't either, I don't think. I can't think of a system that does... |
| 18:12 | <Hixie_> | do any of those systems have a way to accidentally import the same underlying file under two different import names? |
| 18:12 | <Hixie_> | or is there a 1:1 mapping of their names to the underlying paths? |
| 18:14 | <jorendorff> | Hixie_: let me back up a bit and address your exact example |
| 18:16 | <jorendorff> | Hixie_: |import image from "foo.png"| <--- the design intent was that module names aren't urls; |
| 18:17 | <jorendorff> | Hixie_: dherman proposed you might say somethign like |import image from "url(foo.png)";| or "@foo.png", but I think annevk successfully wtf-orpetoed the proposal |
| 18:18 | <jorendorff> | Hixie_: what i'd like is |import image from "_static/foo.png" where I've already configured <module "_static" href="/static"> |
| 18:18 | <jorendorff> | or something like that |
| 18:18 | <jorendorff> | name="_static |
| 18:18 | <Hixie_> | why would we force authors to have an indirection layer |
| 18:19 | <Hixie_> | i'm all for supporting extra things before we convert to URLs, but realistically, most deployments are just gonna need to refer to local files |
| 18:19 | <Hixie_> | there's no win in forcing authors to declare that "images/" means "images/" before they can use "images/foo.png" as far as i can tell |
| 18:20 | <Hixie_> | i mean, even in java and perl and so on, there's usually a more or less direct mapping between the fully qualified package names and the actual paths to find the files -- it's just that they have search paths that they can quickly stat first |
| 18:21 | <Hixie_> | (bbiab, getting food) |
| 19:21 | <Hixie_> | (back) |
| 19:45 | <Hixie_> | jorendorff: another question, while you're pondering the earlier ones: in practice, we're going to want the browser to manage the loads from multiple origins at the same time (e.g. consider depending on a third-party iframe, which might have its own dependencies). |
| 19:45 | <Hixie_> | jorendorff: but it looks like the Loader object is per-Realm |
| 19:46 | <Hixie_> | jorendorff: do i just make the System Loader object fake its data to the ES6 level and manage it separately at the event-loop or top-level-browsing-context level? |
| 19:46 | <jorendorff> | good questions all |
| 19:46 | <jorendorff> | i don't know |
| 19:47 | <jorendorff> | i'm not super satisfied with the earlier stuff, but i don't see how to make it feel natural for everybody... you can have the default paths be just "load everything relative to this document's url" |
| 19:48 | <jorendorff> | but still if you show example code doing import style from "whatever.css"; there is no way you are going to prevent people from instantly believing that's a URL |
| 19:51 | <Hixie_> | i think there's more or less nothing we can do which is going to make people think that "import foo from bar" isn't going to mean the same as <script type=module name=foo href=bar>, personally |
| 19:52 | <Hixie_> | that it really means <script type=module name=??? href=foo> where "foo" is somethinge else again imho doesn't match the platform aesthetic at all |
| 19:52 | <Hixie_> | er |
| 19:52 | <Hixie_> | i mean <script type=module name=bar href=???> |
| 19:52 | <Hixie_> | even i can't work out what it means |
| 19:58 | <Hixie_> | i wonder what browsers scope their prioritisation decisions to |
| 19:58 | <Hixie_> | top-level browsing contexts? |
| 19:58 | <Hixie_> | event loops? |
| 19:59 | <Hixie_> | the whole UA? |
| 20:06 | <jyasskin_w> | Hixie_: network request prioritization? |
| 20:07 | <Hixie_> | yeah |
| 20:09 | jyasskin_w | forwards the question to willchan |
| 20:11 | <willchan> | jyasskin_w told me there was a question about browser network request prioritization |
| 20:11 | <willchan> | chromium prioritizes everything going through its network stack |
| 20:12 | <Hixie_> | ah ok |
| 20:12 | <Hixie_> | so it's whole-UA |
| 20:12 | <Hixie_> | interesting |
| 20:12 | <willchan> | not everything goes through our network stack though, such as plugin sockets and chrome app sockets, and we have some things that currently skip it like webrtc and what not. but we're fixing that. |
| 20:12 | <willchan> | yes, whole-UA |
| 20:13 | <smaug____> | willchan: so bg tabs don't get lower priority than foreground tab? |
| 20:13 | <willchan> | but most of the prioritization is contextual to a chromium profile. |
| 20:13 | <willchan> | if you're talking about network request prioritization, then no, bg tabs don't currrently get lower priority than foreground tabs. but that's in progress. |
| 20:13 | <smaug____> | (at least in certain cases gecko gives lower priority for bg tabs) |
| 20:21 | <SamB> | is webrtc NOT short for WEB RealTime Clock? |
| 20:22 | <SamB> | smaug____: would be nice if gecko could evict some BG tabs to disk, or perhaps even not touch their arenas often |
| 20:23 | <smaug____> | SamB: sure. Issue is that web pages tend to have rather live data these days |
| 20:23 | <smaug____> | static pages are fine |
| 20:23 | <SamB> | well, yes, I realize it's easiest for static pages |
| 20:24 | <smaug____> | we don't page in those tabs in anyway too often |
| 20:24 | smaug____ | seems to have 176 tabs open atm |
| 20:26 | <SamB> | smaug____: I mean, for example, dialing down the GC frequency for those tabs would seem wise |
| 20:27 | <smaug____> | SamB: those shouldn't really participate in GC all the time |
| 20:27 | <smaug____> | assuming we do compartment GCs |
| 20:27 | <smaug____> | (that is something to tweak probably) |
| 20:28 | <smaug____> | for CC we certainly optimize out most of such tabs |
| 20:34 | <Hixie_> | jorendorff: another reason to fully evaluate the names to URLs in the normalize hook is that if we rely on attributes for the mapping yet do the resolving in locate, the mappings could change between the time we look up the normalised names and the time we fully resolve the URLs |
| 20:36 | <Hixie_> | jorendorff: another question. When does the ES6 loader actually evaluate the code?? I found where it compiles it (InstantiateSucceeded), but I just noticed that nothing in my flow chart _runs_ the code. |
| 20:36 | <Hixie_> | jorendorff: am I supposed to keep track of what order things are to run in, and then run it myself? |
| 20:36 | <Hixie_> | (in the HTML spec, i mean) |
| 20:42 | <jorendorff> | Hixie_: OK. In ES6, the code runs "at the last minute" before exposing the module object to user code. See EnsureEvaluated and the things that call it. |
| 20:44 | <Hixie_> | so basically i'm supposed to call EvaluateLoadedModule() when the LoadModule() promise resolves? |
| 20:49 | <jorendorff> | Hixie_: sections like EvaluateLoadedModule() are "closures" |
| 20:49 | <jorendorff> | i don't know if this is clear or not |
| 20:49 | <jorendorff> | but you can't just call EvaluateLoadedModule |
| 20:50 | <Hixie_> | er yeah sorry i meant, i call EnsureEvaluated() when the promise is resolved |
| 20:50 | <jorendorff> | yeah |
| 20:50 | <jorendorff> | yeah that's right |
| 20:50 | <Hixie_> | interesting |
| 20:50 | <jorendorff> | the system should totally do that for you though, right? |
| 20:50 | <Hixie_> | and that does the work of evaluating all the dependencies? |
| 20:50 | <Hixie_> | well, no, i'm good with doing it |
| 20:50 | <Hixie_> | in particular, i want separate control over fetching and executin |
| 20:50 | <Hixie_> | g |
| 20:50 | <jorendorff> | Hixie_: yes, it walks the dependency graph |
| 20:50 | <Hixie_> | which this provides |
| 20:53 | <Hixie_> | hmmmm |
| 20:56 | <Hixie_> | jorendorff: hmm, interesting. There doesn't seem to be any way in ES6 to map a <script type=module> to a specific Load Record. |
| 20:57 | <jorendorff> | what kind of thing are you looking for? |
| 20:59 | <Hixie_> | i want to get a promise that will resolve when a module has loaded, so that i can pass it to something else (e.g. something that will make a DOM subtree display:block) and say "you depend on this promise" |
| 20:59 | <Hixie_> | also i just noticed that my flowchart is incomplete. I missed Link(). |
| 21:00 | <SamB> | smaug____: hmm, how do you avoid touching such tabs for CC? |
| 21:01 | <SamB> | keep notes about what was found there last time? |
| 21:02 | <smaug____> | SamB: optimizing out from CC graph is rather simple many cases |
| 21:02 | <smaug____> | in this case check if the document is in an active browsing context |
| 21:03 | <smaug____> | and if scripts haven't been running in those tabs, no nodes etc would end up to possible-garbage-object-buffer |
| 21:04 | <smaug____> | (skippability and black-bit-propagation are rather nice features of CC) |
| 21:05 | <SamB> | smaug____: ah, right |
| 21:05 | <smaug____> | in other words, CC deals with possibly garbage objects , GC deals with live objects |
| 21:05 | <smaug____> | so CC tends to have smaller graphs |
| 21:05 | <SamB> | that list only gets populated with things that have had their refcounts touched in certain ways ... |
| 21:06 | <SamB> | so if they have not been touched AT ALL, they're automatically exempt |
| 21:06 | <smaug____> | right |
| 21:07 | <SamB> | so, the only thing that needs any thought is to avoid running the GC when, for example, *no* script has executed since the last GC in that arena |
| 21:07 | <smaug____> | and even if they are touched, but are in a document which is in active browsing context, they can be just removed from possible-garbage-object-buffer |
| 21:07 | <SamB> | not sure I follow that bit |
| 21:08 | <SamB> | what does "active browsing context" mean in this context? |
| 21:08 | MikeSmith | wonders what is CC |
| 21:08 | <SamB> | does it involve being in a foreground tab? |
| 21:08 | <SamB> | MikeSmith: cycle collection |
| 21:08 | <smaug____> | CC == cycle collector |
| 21:08 | <MikeSmith> | ah ok |
| 21:08 | <SamB> | or collector, as grammatical |
| 21:08 | <SamB> | same as with GC |
| 21:08 | <smaug____> | active browsing context is a spec term, or close to that |
| 21:08 | <smaug____> | basically you have a tab open |
| 21:09 | <smaug____> | it has a top level active browsing context |
| 21:10 | <smaug____> | for GC the optimization to done is to not run GC for bg tabs' compartments |
| 21:12 | <SamB> | oh, is "in a document" another spec term? |
| 21:12 | <smaug____> | node is in a document if there is parentNode chain from the node to the document |
| 21:12 | <SamB> | i.e. for DOM nodes that are clearly linked into a Document that is actually linked into the active browsing context? |
| 21:13 | <smaug____> | right |
| 21:13 | <smaug____> | not all documents are in active browsing context |
| 21:13 | <SamB> | when would would they be removed from the possibly-garbage list |
| 21:14 | <smaug____> | Gecko has forgetSkippable phase |
| 21:14 | <smaug____> | before CC |
| 21:14 | <SamB> | smaug____: yeah, because you can have documents that are just being used for computations or something |
| 21:14 | <smaug____> | which removes obviously live data from the purple buffer |
| 21:14 | <smaug____> | (purple buffer == possible garbage ) |
| 21:14 | <SamB> | yeah, I gathered it was the same list we had been talking about |
| 21:15 | <SamB> | which you keep calling a buffer so I assume it's in a flat array of some kind |
| 21:16 | <smaug____> | segmented array or some such |
| 21:29 | <pluma> | Are there any plans (distant or not so distant) for providing a low-level TCP/UDP socket API in the browser (rather than protocols like WebRTC, web sockets, etc)? |
| 21:30 | <Hixie_> | how would we do that in a safe fashion? |
| 21:31 | <pluma> | Hixie_: that's what I was wondering. So the answer is probably "no"? |
| 21:31 | <SamB> | pluma: web sockets would almost certainly not exist if that it was safe to just allow TCP/UDP sockets |
| 21:31 | <SamB> | s/that // |
| 21:31 | <Hixie_> | pluma: if we can find a way to do it safely, i'm sure it'll be mere minutes before it's available. :-) |
| 21:33 | <pluma> | Hixie_, SamB: Thanks. I thought I remembered hearing the idea being thrown around at some point, but I apparently remembered wrong. I can't see how to do it safely either (well, maybe with a permission check like the other security-critical APIs, but they'd likely not be very self-explanatory). |
| 21:33 | <pluma> | Wait, what about http://www.w3.org/TR/raw-sockets/ ? |
| 21:35 | <pluma> | Hm... looks pretty dead, though. |
| 21:36 | <Hixie_> | the existence of specs doesn't imply anyone will implement them :-) |
| 21:37 | <pluma> | Hixie_: that's what I though. Okay, thanks again ;) |
| 21:37 | <Hixie_> | (what would you want raw sockets for anyway?) |
| 21:38 | <pluma> | Hixie_: implement an <insert existing protocol here> client in the browser? |
| 21:39 | <pluma> | Hixie_: web vs native, etc |
| 21:39 | <Hixie_> | do you have a specific example? |
| 21:39 | <pluma> | I'm not saying that's a good idea. Just an idea someone could have... |
| 21:39 | pluma | shrugs |
| 21:40 | <pluma> | Torrent client? |
| 21:40 | <SamB> | pluma: it's definitely an idea that would have its uses |
| 21:40 | <SamB> | but it would also have LOTS AND LOTS of dangerous misuses |
| 21:41 | <pluma> | The reason I'm asking is because someone asked about porting a python chat client to JS for the browser and the Python code currently uses raw TCP sockets. We recommended using web sockets or some abstraction built on top of that. |
| 21:42 | <pluma> | (on ##javascript that is) |
| 21:42 | <Hixie_> | ah like an irc client? |
| 21:42 | <Hixie_> | yeah we definitely wouldn't want a random web page to be able to connect to a random irc client, just imagine the DOS attacks that would enable :-) |
| 21:43 | <Hixie_> | er, random irc server |
| 21:44 | <pluma> | Hixie_: well, it'd be fun. In the DF sense (http://dwarffortresswiki.org/index.php/Fun) |
| 21:45 | <Hixie_> | yeah... |
| 22:07 | <MikeSmith> | pluma: I think the security models for that http://www.w3.org/TR/raw-sockets/ is not the Web security model. That spec depends on an different, as-yet-undocumented off-Web security model. All the specs from the SysApps WG do |
| 22:09 | <MikeSmith> | s/security models/security model/ |
| 22:10 | <pluma> | MikeSmith: ah, so it's most likely intended for something like Firefox OS apps and such? |
| 22:10 | <MikeSmith> | yeah, that |
| 22:11 | <MikeSmith> | although I think Mozilla and Google are no longer participating actively in that WG any longer. So it seems unlikely that spec will go anywhere any time soon |
| 22:13 | <MikeSmith> | nobody's really crying out for an off-Web HTML/CSS/JS-based standard runtime |
| 22:13 | <MikeSmith> | users certainly aren't, and developers aren't |
| 22:13 | MikeSmith | ends his editorial comments |
| 22:14 | <pluma> | MikeSmith: Hm... I wished CSS would become a living standard alongside HTML. |
| 22:15 | <MikeSmith> | pluma: it is living, it's just more of a Frankenstein monster sort of life |
| 22:16 | <MikeSmith> | editor's drafts of CSS specs are living specs, it just takes a lot more work to observe it and try to keep up with it |
| 22:16 | <pluma> | MikeSmith: Sure, but CSS3 isn't fully "stable" and already browsers are chasing after CSS4, not to mention all the vendor crap. I'm really hoping for a revolution a la HTML 5. |
| 22:17 | <TabAtkins> | MikeSmith: How is it harder to observe? |
| 22:17 | <TabAtkins> | pluma: There's no such thing as CSS3 or CSS4. |
| 22:17 | <TabAtkins> | http://www.xanthir.com/b4Ko0 |
| 22:17 | <pluma> | TabAtkins: Well, there are various CSS-related specs with "3" and "4" in their name. |
| 22:17 | <TabAtkins> | Yes, those are the individual modules. |
| 22:17 | <MikeSmith> | TabAtkins: the volume/ number of the specs and the number of different editors |
| 22:18 | <TabAtkins> | MikeSmith: Sure, but actually tracking changes seems identical between the two - just watch the repos. There are even Twitter bots for each. |
| 22:19 | <MikeSmith> | TabAtkins: and also, the knowing which specs to currently take seriously, and which are known .. duds or whatever they should be called -- but that are still around and people cite them |
| 22:19 | <pluma> | TabAtkins: I understand that. But it just looks a lot hairier and messier than HTML / Web Apps look{s,ed}. |
| 22:19 | <MikeSmith> | TabAtkins: like, old GCPM |
| 22:19 | <TabAtkins> | MikeSmith: Granted on that note. |
| 22:19 | <TabAtkins> | MikeSmith: (Though dauwhe is working on GCPM now, and trying to make it realistic.) |
| 22:19 | <MikeSmith> | TabAtkins: but yeay, point taken (about watching the repos and twitter bots) |
| 22:20 | <MikeSmith> | TabAtkins: yeah astearns told me that the other day. glad to hear dauwhe is on the job |
| 22:20 | <MikeSmith> | TabAtkins: (specific context was, astearns was telling me about latest discussion on footnotes) |
| 22:21 | <pluma> | TabAtkins: Also, having selectors spread out across different version numbers is a bit more tedious to follow than to have one single selectors spec that gets continuously revised. The world in which the version numbers matter and the world for which most web code is written are two very different worlds in my experience. |
| 22:21 | <TabAtkins> | pluma: Always and only looking at the latest version is all you need. |
| 22:22 | <TabAtkins> | There are no selectors in Selectors 3 that are missing in Selectors 4, except those that were dropped because no one implemented them. |
| 22:22 | <pluma> | TabAtkins: okay, but how do I know which specs are dead and will not be updated further? |
| 22:22 | <TabAtkins> | Dead specs, *ideally*, are marked as such. We're not great about that. (I need to get off my ass and just go mark all of them.) |
| 22:23 | <TabAtkins> | This list is also very helpful and kept up-to-date: http://www.w3.org/Style/CSS/current-work.en.html |
| 22:23 | <TabAtkins> | http://www.w3.org/Style/CSS/current-work |
| 22:23 | <pluma> | TabAtkins: is there a version of the specs in which current browser support is marked as in the HTML (etc) spec? |
| 22:24 | <TabAtkins> | Some Editor's Drafts have linkages into their test suites, with support information displayed alongside each section, similar to HTML. |
| 22:24 | <TabAtkins> | But not all drafts have test suites. |
| 22:26 | <pluma> | Hrmpf. I wished someone would find a solution for that. How do the WHAT WG specs manage to do this consistently? |
| 22:27 | <boogyman> | Do you guys know if in the future the spec will call for a scenario where a "checkbox" group can have a "at least one must be checked" definition? http://codepen.io/anon/pen/IwxEh |
| 22:32 | <MikeSmith> | TabAtkins: fyi http://platform.html5.org links to http://www.w3.org/Style/CSS/current-work |
| 22:32 | <pluma> | TabAtkins: thanks for clearing up some of my misconceptions about the CSS versioning, though. However I still wished there was a nicer overview. |
| 22:33 | <TabAtkins> | pluma: HTML's data is maintained manually, whenever people care to update it. ^_^ |
| 22:33 | <TabAtkins> | boogyman: You mean <input type=checkbox required>? Oh, how I've wished for that. |
| 22:33 | <TabAtkins> | pluma: And no problem. |
| 22:33 | <MikeSmith> | TabAtkins: if/when you ahve time to look at the CSS part http://platform.html5.org please do. And either lemme know what should be changed/added/removed or just open a PR |
| 22:33 | <TabAtkins> | kk |
| 22:33 | <SamB> | TabAtkins: <input type=checkbox> can have more than one checkbox? how confusing :-( |
| 22:34 | <MikeSmith> | boogyman: there is nothing that I know of but yeah I have had cases where I'd really like to have that too |
| 22:34 | <TabAtkins> | SamB: Multiple checkboxes in a single name group. |
| 22:34 | <SamB> | TabAtkins: in one element or several? |
| 22:34 | <TabAtkins> | Several. |
| 22:34 | <TabAtkins> | Have you worked with checkboxes before? |
| 22:35 | <SamB> | okay, yes, that's what I thought... |
| 22:35 | <SamB> | TabAtkins: I may or may not ever have made any myself, but I'm sure I've poked around on pages that had them ;-) |
| 22:35 | <MikeSmith> | Hixie_: see boogyman question above. Why we have no way to define a "checkbox" group with "at least one checkbox must be checked" |
| 22:36 | <SamB> | TabAtkins: so you'd pick one to mark "required" arbitrarily? |
| 22:36 | <TabAtkins> | SamB: That's one of the questions, yeah. |
| 22:36 | <boogyman> | that's one possible implementation. |
| 22:36 | <TabAtkins> | Probably, sure. Basically if any of the checkboxes in a name group are required, it triggers the "required" beahvior for the group. |
| 22:36 | <SamB> | TabAtkins: yeah, that seems like the only even half-sane behaviour |
| 22:37 | <SamB> | because the order the checkboxes are in is not ordinarily expected to have any semantics associated with it, is it? |
| 22:38 | <SamB> | I mean, beyond what it might convey to a human |
| 22:40 | <boogyman> | SamB: The use-case here is that you have a Business / Author whom wants to impose a "must select one or more" requirement. Currently authors are required to implement a JS shim (albeit a fairly straightforward one) |
| 22:40 | <SamB> | boogyman: I understand the usecase, thanks ;-) |
| 22:40 | <SamB> | I've certainly seen it on enough paper forms |
| 22:41 | <Hixie_> | MikeSmith: not declaratively, yeah. |
| 22:41 | <Hixie_> | MikeSmith: you can give the same semantics using <select multiple required>, though. |
| 22:41 | <SamB> | obviously you'd still want to make the requirement clear in-text |
| 22:42 | <SamB> | Hixie_: isn't typically a bit more awkward UI-wise? |
| 22:42 | <SamB> | +that |
| 22:42 | <boogyman> | Hixie_: yes, but now you're tying the author to the "dropdown" cosmetics |
| 22:42 | <Hixie_> | SamB: semantically they're identical, so, in theory, it's just a UI issue. :-) |
| 22:42 | <Hixie_> | boogyman: <select multiple> doesn't have a drop-down, it has a list |
| 22:42 | <Hixie_> | in the default rendering |
| 22:42 | <Hixie_> | and in theory, you can have any rendering you like |
| 22:43 | <Hixie_> | if the theory doesn't match practice, send pitchforks to dglazkov_ :-) |
| 22:43 | <boogyman> | I am unfamiliar with CSS exposing the ability to break out that list and display as "checkbox" |
| 22:43 | <SamB> | Hixie_: I mean <select multiple> tends to be something only advanced users will actually know how to select multiple items in, doesn't it? |
| 22:43 | <Hixie_> | SamB: well, that's really up to the browser and/or author |
| 22:44 | <Hixie_> | anyway. if you really must use checkboxes and really must have one required (which is a weird UI, but whatever), then use script and setCustomValidity() |
| 22:44 | <Hixie_> | that's what it's for |
| 22:44 | <SamB> | I'm talking about the UI that the advanced users already know how to use here, which probably isn't really too negotiable at this point? |
| 22:44 | <zewt> | tired of hearing the "the special case of the ui thread has taught us that all synchronous programming is bad" nonsense |
| 22:44 | <zewt> | i seem to recall somebody saying that every time the sync-message thread comes up |
| 22:44 | <Hixie_> | SamB: as far as i can tell, it's entirely negotiable. |
| 22:45 | <SamB> | zewt: I'm already tired of it, and I'm not even *certain* I've heard it mentioned before |
| 22:45 | <SamB> | Hixie_: what, you don't think people will get confused if the shift/control click stuff stops working? |
| 22:45 | <Hixie_> | SamB: not if you replace it with just a bunch of labeled checkboxes... |
| 22:46 | <zewt> | it's nice that people are aware of the issue, but it's such an over-the-top generalization |
| 22:46 | <boogyman> | Hixie_: yes, but now you're going down the flame-wars of "JS is required", where this could be a nice addative feature for HTML to expose |
| 22:46 | <SamB> | Hixie_: they might still get frustrated by not being able to do that though |
| 22:46 | <SamB> | boogyman: you still have to validate at submit time anyway |
| 22:46 | <SamB> | boogyman: so JS is only required for the "nice-to-have" prevalidation |
| 22:46 | <Hixie_> | boogyman: there's a huge long tail of such possible new features, sure. file a bug if you want this one to enter the usual gauntlet. |
| 22:47 | <Hixie_> | boogyman: it'd need pretty compelling use cases to be worth adding instead of something else though |
| 22:47 | <SamB> | boogyman: so, make sure you say "check one or more" on the page, do the JS thing if you want, don't worry if *that* doesn't work with JS turned off |
| 22:47 | <SamB> | maybe those users are using a browser that wouldn't support the new attribute anyway |
| 22:48 | <SamB> | boogyman: you are of course aware that it's quite possible for an adversary to submit without using *your* (or any) form, yes? |
| 22:49 | <SamB> | heck, it could even be a non-adversary |
| 22:49 | <boogyman> | Hixie_: It was something asked in another channel. I remember use-cases from the past, but my solution was to just implement a simple JS script for the client-validation etc... |
| 22:50 | <boogyman> | SamB: I am well aware of the capability; I was forwarding on a request from a different channel, recalling my own past use-case(s) |
| 22:50 | <Hixie_> | boogyman: it's possible in about one line of javascript, i would imagine |
| 22:52 | <boogyman> | yup, and I reference the aforementioned "JS requirement flame-wars"... :p |
| 22:52 | <Hixie_> | i'm not sure what you're arguing against here |
| 22:53 | <zewt> | "people will complain that it requires javascript, therefore you should do it"? that would qualify among the weakest arguments that could be made. heh |
| 22:53 | <boogyman> | The intent was to ask if this was being planned for the future (forwarded request from different channel). It is not, without a ticket to undergo the typical change-request lifecycle. |
| 22:54 | <Hixie_> | boogyman: nothing is planned for the future except the things that are already in the spec :-) |
| 22:54 | <Hixie_> | boogyman: we don't really plan ahead so much |
| 22:54 | <Hixie_> | or rather, the spec is the plan ahead |
| 22:54 | <boogyman> | iterations, go figure... |
| 22:57 | <Hixie_> | i don't understand the Fetch API |
| 22:58 | <Hixie_> | what's the first argument to fetch()? |
| 22:58 | <Hixie_> | (also, window.fetch is SO going to clash) |
| 23:10 | <Hixie_> | what happens if you resolve a promise you've rejected? |
| 23:10 | <Hixie_> | because that's what fetch() does... |
| 23:12 | <TabAtkins> | Hixie_: Once a promise has been resolved in some way, any further attempts to resolve it are no-ops. |
| 23:12 | <SamB> | Hixie_: well, did you get that "shock remote victim" protocol deployed in browsers yet? |
| 23:12 | <Hixie_> | i would not support such a protocol |
| 23:13 | <Hixie_> | TabAtkins: still seems bad for a spec to do it, though... |
| 23:13 | <TabAtkins> | Hixie_: Oh, certainly; if it's happening, it's a bug. |
| 23:13 | <SamB> | well, I guess you can't use it on the spec author? |
| 23:13 | <TabAtkins> | I was just answering your question. ^_^ |
| 23:13 | <Hixie_> | SamB: more effective to file a bug :-) |
| 23:13 | <Hixie_> | TabAtkins: thanks :-) |
| 23:14 | <SamB> | of course, if it's an *accident* rather than a thoroughly bizarre API, that's different |
| 23:14 | <Hixie_> | i assume it's always an accident |
| 23:14 | <Hixie_> | so it looks like the fetch API doesn't have an object that represents an ongoing fetch |
| 23:14 | <TabAtkins> | Yeah, double-resolving a promise is always going to be an accident. |
| 23:14 | <Hixie_> | interesting |
| 23:15 | <Hixie_> | and nor does ES6, really |
| 23:15 | <Hixie_> | though they both have promises |
| 23:15 | <Hixie_> | that represent essentially the same thing... |
| 23:15 | <Hixie_> | nope, no sign of conway here, that's for sure |
| 23:15 | <SamB> | conway? |
| 23:15 | <Hixie_> | http://en.wikipedia.org/wiki/Conway's_law |
| 23:15 | <zewt> | as long as it's not "on accident" |
| 23:16 | <SamB> | zewt: you don't think 5-year-olds should be writing specs? |
| 23:16 | <TabAtkins> | Hixie_: Fetch resolves the promise with a Response as soon as it's possible to construct one, no? |
| 23:16 | <zewt> | i think the age threshold for people who say "on accident" is ~15, not so much 3 |
| 23:16 | <Hixie_> | i really don't understand why fetch() takes both a Request and a RequestInit |
| 23:16 | <SamB> | zewt: well, yes, I was just giving an example of an age at which I think it's actually acceptable |
| 23:17 | <Hixie_> | TabAtkins: well, i'm not sure how one defines "as soon as possible" here |
| 23:17 | <SamB> | I mean, when not in zombie-mode and not talking silly on purpose |
| 23:17 | <Hixie_> | TabAtkins: but if it needs a promise, presumably it's not the entire time the api is doing something |
| 23:17 | <TabAtkins> | I think as soon as the response returns and starts sending data (and redirects have been followed). |
| 23:17 | <TabAtkins> | Well, I guess you have to wait for headers to finish sending. |
| 23:18 | <TabAtkins> | But you can resolve the promise while body is still sending, since you've got a stream for that. |
| 23:18 | <SamB> | so is there a promise or not? |
| 23:18 | <TabAtkins> | SamB: ??? |
| 23:18 | <Hixie_> | my point is just that there's no object that represents the fetch |
| 23:18 | <TabAtkins> | Hixie_: In what way do you want something to "represent the fetch"? |
| 23:18 | <SamB> | Hixie_: hmm, the Response doesn't represent it well enough for you? |
| 23:19 | <TabAtkins> | (We were just discussing today that there's no way to cancel a fetch().) |
| 23:19 | <Hixie_> | TabAtkins: not saying i necessarily want anything, i'm just trying to figure out how to reconcile Fetch and Loader |
| 23:19 | <Hixie_> | SamB: well as tab just pointed out, it doesn't e.g. let you cancel a fetch |
| 23:19 | <SamB> | maybe either the promise or the Response should be acceptable as a representative of the fetch? |
| 23:19 | <TabAtkins> | Okay. Well, the Response object represents the *result* of the fetch. The promise represents the ongoing operation to produce a Response. |
| 23:20 | <Hixie_> | a promise isn't really a useful object in and of itself |
| 23:20 | <TabAtkins> | Most likely, when we figure out how promise subclassing works, fetch()'ll switch to returning a CancelablePromise or something. |
| 23:20 | <SamB> | TabAtkins: will that still be cancelable after it resolves? |
| 23:20 | <Hixie_> | subclassing promises is all kinds of trouble, since it won't chain right |
| 23:20 | <SamB> | or can't you race with the resolve? |
| 23:21 | <TabAtkins> | SamB: Dunno. Depends on semantics. |
| 23:21 | <TabAtkins> | SamB: I mean, once it resolves, you've got a Response. The question is just whether you then must cancel via the Response (to stop receiving body bytes) or whether a cancel on the promise will chain down into the Response. |
| 23:21 | <TabAtkins> | Hixie_: That's why it hasn't been done yet. It'll happen at some point, though. |
| 23:22 | <TabAtkins> | It's just an engineering problem to work around, after all. |
| 23:22 | <SamB> | what does "chain right" mean |
| 23:22 | <Hixie_> | i don't really see a sane way to do it |
| 23:22 | <SamB> | typeclasses obviously |
| 23:22 | <Hixie_> | but if it's gonna happen, i have use cases for it |
| 23:22 | <TabAtkins> | SamB: returnsASpecialPromise().then(function(x){ return "foo"; }); |
| 23:22 | <Hixie_> | in particular i need to apply backpressure to promises |
| 23:22 | <TabAtkins> | Is the promise returned by then() a special promise, or a plain one? |
| 23:22 | <SamB> | TabAtkins: that was basically my question |
| 23:22 | <TabAtkins> | Hixie_: That's for streams to do. |
| 23:23 | <TabAtkins> | SamB: Well, that's the question to answer. |
| 23:23 | <Hixie_> | TabAtkins: Promise.all() is an even bigger problem imho (or whatever it's called in ES's API) |
| 23:23 | <TabAtkins> | Hixie_: Yeah, that's definitely an... interesting aspect. |
| 23:23 | <TabAtkins> | And yeah, it's Promise.all() |
| 23:23 | <Hixie_> | TabAtkins: streams are a different issue |
| 23:23 | <Hixie_> | TabAtkins: i mean something like object A is on-demand, and depends on object B which is on-demand |
| 23:23 | <Hixie_> | one way you could do it is say that object A actually depends on object B's "ready" promise |
| 23:24 | <Hixie_> | but then you lose the back-channel for when you tell A to get on with it -- it has no way to trigger B to get on with it. |
| 23:24 | <TabAtkins> | Hixie_: Hm, I'm missing some context, since presumably B has some API to load itself as well. |
| 23:24 | <SamB> | again, are you trying to do lazy evaluation or async I/O? |
| 23:25 | <Hixie_> | TabAtkins: e.g. B is an image, A is a style sheet |
| 23:25 | <Hixie_> | TabAtkins: both are "load on demand" |
| 23:25 | <Hixie_> | TabAtkins: A depends on B |
| 23:25 | <Hixie_> | TabAtkins: at some point you say "I need A" |
| 23:25 | <TabAtkins> | Hixie_: Like, A()'s ready promise could be a Promise.all() of its internal ready promise and the ready promises of all of its dependencies. |
| 23:25 | <Hixie_> | TabAtkins: the problem is in the opposite direction |
| 23:25 | <SamB> | i.e., those aren't the same thing and trying to make promises handle both is probably a bad idea? |
| 23:25 | <TabAtkins> | But it can hold onto more API than just that promise. |
| 23:25 | <Hixie_> | TabAtkins: how does A tell B "ok, I need you now" |
| 23:25 | <TabAtkins> | Like the loader function for each of its requirements. |
| 23:25 | <Hixie_> | if all it has is a promise for a B |
| 23:26 | <Hixie_> | sure |
| 23:26 | <Hixie_> | that's how i'm going to have to do it since promises don't have subapis |
| 23:26 | <TabAtkins> | And yes, what SamB said. "Please do your work" is a separate thing from "Let me know when your work is done". |
| 23:26 | <SamB> | Hixie_: maybe the promise should be a property of some larger object? |
| 23:26 | <Hixie_> | the larger object is just B |
| 23:26 | <SamB> | okay |
| 23:27 | <TabAtkins> | Hixie_: Btw, API idiom for this stuff is a .loaded attribute, and a .load() function. |
| 23:27 | <SamB> | so don't do that thing where you throw away B and keep only the promise? |
| 23:27 | <TabAtkins> | (I expect you'll run the API by Anne/Domenic/etc, but might as well get this right from the beginning.) |
| 23:27 | <Hixie_> | TabAtkins: .loaded, .ready, whichever |
| 23:27 | <Hixie_> | TabAtkins: .loaded and .load() are bad names because they're ambiguous |
| 23:28 | <SamB> | TabAtkins: maybe fetches will need to return something more than just a promise too :-( |
| 23:28 | <Hixie_> | TabAtkins: they don't distinguish the fetch step from the execution step |
| 23:28 | <SamB> | now I'm having evil ideas involving forwarding |
| 23:28 | <SamB> | can you do forwarding in JS? |
| 23:28 | <TabAtkins> | Hixie_: Ah, sure. Those are for the loading steps. |
| 23:28 | <TabAtkins> | SamB: Yeah, there's various idioms for it. what do you want to do? |
| 23:28 | <SamB> | TabAtkins: like, fetch could return a fake promise that is actually not a promise |
| 23:29 | <SamB> | but a wrapper around a promise |
| 23:29 | <TabAtkins> | (I do some twisty stuff in Colors to make the APIs extensible more easily.) |
| 23:29 | <SamB> | which can be canceled |
| 23:29 | <Hixie_> | TabAtkins: is a module "loaded" when it's downloaded, translated, instantiated, compiled, has dependencies, evaluated...? |
| 23:29 | <TabAtkins> | SamB: Ah, no, no reason to make that happen. |
| 23:29 | <TabAtkins> | Hixie_: Shrug. ^_^ |
| 23:29 | <Hixie_> | TabAtkins: that's why i prefer terms like "ready" |
| 23:29 | <SamB> | TabAtkins: I'm sure there would be other reasons one might want to forward method calls |
| 23:29 | <Hixie_> | "ready" more clearly indicates "i'm good to go, but haven't gone" |
| 23:30 | <Hixie_> | anyway, i'm happy to let y'all bikeshed the terms |
| 23:31 | <zewt> | programmers can't even decide on what to call "null" |
| 23:31 | Hixie_ | votes for nil |
| 23:31 | <zewt> | one of python's smaller but most idiotic warts is calling null "None" |
| 23:31 | <zewt> | one of those things where: it doesn't matter which one you use, just whatever you do, don't make up something new |
| 23:32 | <TabAtkins> | Hixie_: nil is false, silly. |
| 23:33 | <zewt> | much like null |
| 23:33 | <Hixie_> | nil is the one true way |
| 23:33 | <SamB> | zewt: on the other hand, it took them forever to get around to having named truth/falsehood |
| 23:33 | <zewt> | by the way, does anyone know where the "if(x == false)" thing comes from |
| 23:33 | <SamB> | they just used 0/1 for those for ages |
| 23:33 | <Hixie_> | and it isn't type compatible with false in any sane world :-P |
| 23:33 | <zewt> | re: it's such a ridiculous lack of understanding of the whole concept of a Boolean |
| 23:33 | <SamB> | Hixie_: so you think CL is insane, not just elisp? |
| 23:33 | <zewt> | when i see "if(x == true)" i want to rewrite it to say "if(x == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == true == |
| 23:34 | <Hixie_> | all the lisps are insane but that's a whole different issue |
| 23:34 | <SamB> | zewt: there might be some cases where it is actually sane to compare against true/false |
| 23:34 | <Hixie_> | zewt: in js, if (x) and if (x == true) are not the same thing, fwiw |
| 23:34 | <zewt> | i guarantee you not in any of the cases i've seen |
| 23:35 | <SamB> | but I imagine this would mostly have to do with attempting to print them |
| 23:35 | <zewt> | pretty sure this is entirely a "i saw this somewhere and i'm doing that thing i saw" |
| 23:35 | <SamB> | like, in implementing `print' |
| 23:35 | <Hixie_> | (because == and if () coerce differently) |
| 23:35 | <jamesr__> | #define true 7 |
| 23:35 | <boogyman> | zewt: some [insert rant] languages expose *-y evaluations, where 1 == true but 1 !== true |
| 23:35 | <zewt> | mostly i see it in objc, where it's "x == YES" |
| 23:35 | <SamB> | Hixie_: what's the difference? |
| 23:35 | <Hixie_> | i forget the details |
| 23:35 | <SamB> | though actually it's not the same in C, Python, C++, etc. either |
| 23:36 | <SamB> | since e.g. 2 is truthy, but not == 1 |
| 23:36 | <TabAtkins> | zewt: null/undefined are falsey, but not == false. |
| 23:37 | <zewt> | (of course, the point wasn't the order of operations, i just wasn't going to calculate how many ('s i should stick in there when I held down shift-insert) |
| 23:37 | <SamB> | or, in python, [] or () or {} would be falsey, but not == 0 |
| 23:37 | <TabAtkins> | zewt: And use of "x == false" over "!x" is quite common when you have an API that can return false *or* a falsey value, but the latter is a valid value. Like indexOf(). |
| 23:38 | <Yuhong> | I wonder if there is any hope that iOS can stop treating application/xhtml+xml as text/html. |
| 23:38 | <SamB> | (is truthy the wrong word?) |
| 23:38 | <TabAtkins> | Or maybe that one returns -1. Anyway, cases like that occur, where 0 or "" is a valid return value, and false is a failure return value. |
| 23:38 | <TabAtkins> | SamB: Yes it is. |
| 23:38 | <zewt> | TabAtkins: err, indexOf returns -1 ... yeah |
| 23:38 | <SamB> | what's the companion to falsey, then? |
| 23:39 | <zewt> | returning true/false/null or something like that would just be a really bad API |
| 23:39 | <zewt> | and in that case i'd probably say if(x != null && x) / if(x != null && !x) |
| 23:39 | <zewt> | or something along those lines |
| 23:39 | <TabAtkins> | zewt: Shrug, it happens. Blame the lack of Except or Option monads in JS. ^_^ |
| 23:39 | <Hixie_> | jorendorff: so... if I have <script type=module dependencies=foo ...>, and at some point I call LoadModule() for that module, how do I prepopulate its dependencies?? |
| 23:39 | <gsnedders> | zewt: "yes", "no, "maybe" comes to mind as API design :) |
| 23:40 | <SamB> | TabAtkins: stupid missing typeclasses/HM typesystem ;-P |
| 23:40 | <TabAtkins> | SamB: I'd kill for a Maybe. |
| 23:40 | <TabAtkins> | Also: flatMap on Array. |
| 23:40 | <SamB> | is that concatMap |
| 23:40 | gsnedders | would kill for a decent strongly typed language with a powerful type system in place of JS |
| 23:41 | <zewt> | i wish it was any of these things in any of the times i've seen that (cough) pattern, but it's all just places returning a Simple Old Boolean |
| 23:41 | <Hixie_> | i see how to fake it for a non-JS module, but if 'instantiate' returns 'undefined' (as it would for JS), then I don't see how to inject extra dependencies |
| 23:41 | <SamB> | or is flatMap actually >>= |
| 23:41 | <Hixie_> | gsnedders: i wouldn't kill for it, but yeah, i really, really wish the web had strong types |
| 23:41 | <TabAtkins> | SamB: flatMap is >>=, yeah. |
| 23:41 | <gsnedders> | I kinda hope MSR's work on type systems for TypeScript/JS boundaries gets somewhere such that one can create a sane languge which JS maps to a subset thereof |
| 23:42 | <TabAtkins> | Wanna be able to map over an array and return 0+ elements to stitch into the result. |
| 23:42 | <zewt> | i'll take weak typing for web-like work any day |
| 23:42 | <gsnedders> | Which makes replacing JS trivial, as both input languages parse to one bytecode |
| 23:42 | <gsnedders> | Well, "easy" :) |
| 23:42 | <SamB> | I guess flatMap is actually about the most descriptive name I've heard for it |
| 23:42 | <TabAtkins> | SamB: Yeah, you map, then you flatten one level. ^_^ |
| 23:43 | <SamB> | I mean neither >>= nor bind actually desscribes it too well |
| 23:43 | <zewt> | gsnedders: call it "*cough* easy" |
| 23:43 | <TabAtkins> | It's a direct transcription of >>= implemented using only the Functor semantics. |
| 23:43 | <SamB> | TabAtkins: you can do that? |
| 23:43 | <SamB> | don't you need some kind of monoid too? |
| 23:43 | <TabAtkins> | SamB: Of course, if you ahve a flatten function as well, that'll convert a nested object into a single level. |
| 23:44 | <TabAtkins> | I don't like referring to that as a monoid, as it's not *in practice* in a language, just in the theoretical sense. |
| 23:44 | <SamB> | heh |
| 23:44 | <TabAtkins> | Yeah, you're technically combining two members of a set into a third member of the set, but really it's reaching into a nested object and generating a new one with the same data, respecting the nested sematnics. |
| 23:44 | <SamB> | my main issue with monoids is there are so darned many to choose from |
| 23:45 | <TabAtkins> | Use more complicated objects, then. |
| 23:45 | <SamB> | like, in arithmatic you've got one over (*) and one over (+) |
| 23:45 | <TabAtkins> | (That doesn't save you from every object having First/Last monoids, of course.) |
| 23:45 | <TabAtkins> | (And a bunch more.) |
| 23:45 | <zewt> | TabAtkins: don't think i've seen ever the word "functor" used outside of C++ |
| 23:45 | <SamB> | zewt: it is |
| 23:45 | <SamB> | and it means a totally different thng |
| 23:46 | <SamB> | zewt: something that has a map function, basically |
| 23:46 | <TabAtkins> | zewt: It's a category theory term, unrelated to C++. |
| 23:46 | <zewt> | i mean, it just means (to me) "something that can be called like a function", but that's just nothing special in modern languages (and python just calls that a "callable") |
| 23:46 | <TabAtkins> | In c++ it means "function", basically. |
| 23:46 | <TabAtkins> | But yeah, "Functor" is "has a .map() function, acting in the expected way". |
| 23:46 | <zewt> | yeah that's the wrong name then |
| 23:46 | <TabAtkins> | Haskell's names are stupid and dumb. |
| 23:46 | <zewt> | ah, missed the "haskell" part |
| 23:46 | <TabAtkins> | I mean, that's the term for that concept from category theory. |
| 23:46 | <SamB> | TabAtkins: in Haskell's defense, those names were not made up by the Haskell people |
| 23:47 | <TabAtkins> | No idea which one came first. |
| 23:47 | <SamB> | they were just re-used from CT |
| 23:47 | <zewt> | sure, but if you're a programming language, the meaning of terms for programming languages resolve first |
| 23:47 | <TabAtkins> | SamB: That's not a defense of Haskell, just an explanation. ^_^ Haskell is still dumb for using dumb math words. |
| 23:47 | <gsnedders> | Broadwell includes H.265 HW acceleration support; next gen video to be dominated by patent-encumbered formats again? *sighs* |
| 23:47 | <TabAtkins> | zewt: Haskell is a programming language, so it appears to have equal rights to the name as c++ |
| 23:48 | <TabAtkins> | But anyway, better name is Mappable. |
| 23:48 | <SamB> | TabAtkins: so you want Haskell people to try to make up a comprehensible term? |
| 23:48 | <TabAtkins> | Just like better name for Monoid is Joinable or something. |
| 23:48 | <zewt> | not that it matters, but i'd call c++ a higher-authority language than haskell :P |
| 23:48 | <SamB> | I don't know if Monoid has a better name; there are so darned many different ones |
| 23:49 | <SamB> | zewt: why did C++ misuse CT terms |
| 23:49 | <TabAtkins> | The concept is simple - it's something that can be combined with similar somethings to produce a third something of the same type. |
| 23:49 | <SamB> | zewt: C++ should have called those "callable" |
| 23:49 | <zewt> | (also, it's still a stupid term in C++) |
| 23:49 | <SamB> | like I always have |
| 23:51 | <SamB> | anyway, yes, Monad and Functor are bad names; Monoid isn't good but it's hard to come up with a good name for such a general structure as a monoid |
| 23:52 | <SamB> | actually, Monoid may just come from Abstract Algebra |
| 23:53 | <TabAtkins> | When I taught myself what monads are, I just read http://www.haskell.org/haskellwiki/Typeclassopedia and gradually did find+replace on terms as I figured out what they really meant. Made it *way* easier to read. |
| 23:53 | <TabAtkins> | Yeah, monad is basic abstract algebra. A bit weaker than Set. |
| 23:53 | <TabAtkins> | Ring, rather. |
| 23:53 | <TabAtkins> | (Set is way weaker, obvs.) |
| 23:53 | <SamB> | you mean monoid |
| 23:53 | <TabAtkins> | UGH, YES |
| 23:54 | <TabAtkins> | Mon(a|oi)d is stupid. |
| 23:54 | <hober> | there's an axises joke in here somewhere |
| 23:55 | <SamB> | TabAtkins: hmm, doesn't every Ring have *two* Monoids? |
| 23:55 | <SamB> | one of which ("addition") is evidently also an "abelian group" |
| 23:56 | <TabAtkins> | SamB: Hurp durp, I'm forgetting all my terms. Yes. |
| 23:56 | <TabAtkins> | *Group* is the thing right above monoid. |
| 23:56 | <SamB> | hey, I had to cheat and user Wikipedia |
| 23:56 | <SamB> | *use |
| 23:56 | <SamB> | though I did manage to extrapolate that Group must be the slightly-stronger structure |
| 23:57 | <TabAtkins> | Yeah, group is just a monoid with an identity element. |
| 23:57 | <SamB> | I can remember what a Monoid is about though |
| 23:57 | <SamB> | hmm, monoids don't have identity already? |
| 23:57 | <TabAtkins> | In programming terms, a monoid is a structure where you can take an array of them and call .reduce(), and it knows what to do automatically. |
| 23:57 | <TabAtkins> | A Group is one of those that can handle being an empty list. ^_^ |
| 23:58 | <TabAtkins> | Ugh again, Group is inverses. |
| 23:58 | <SamB> | well, if you pick *which* monoid to use for that type ;-P |
| 23:58 | <TabAtkins> | Semigroup is a monoid without identity. |
| 23:58 | <TabAtkins> | SamB: Assume strong typing, of course. |
| 23:58 | <TabAtkins> | A monoid with a .negate() is a group. |
| 23:58 | <SamB> | strong typing isn't really enough |
| 23:59 | <TabAtkins> | Sure it is. If you know you have a List[Foo], then given an empty list, you can tell that it's an empty *list of Foos*. |
| 23:59 | <SamB> | Well, I mean, if I wanted Monoids in a prover I'd make it possible to have more than one per type |
| 23:59 | <TabAtkins> | SamB: You're screwed then, because First and Last monoids exist for all types. |
| 23:59 | <TabAtkins> | At a mnimum. |
| 23:59 | <SamB> | how would I be screwed? |