| 01:30 | <MikeSmith> | SimonSapin: as far as In other words, it should be possible to catch this case just using a conforming tokenizer, without needing a parser. |
| 01:30 | <MikeSmith> | oops |
| 01:30 | <MikeSmith> | copy pasta |
| 01:31 | <MikeSmith> | SimonSapin: meant to say, as far as "User agents are encouraged to expose parse errors somehow.", Firefox's View Source also uses that |
| 01:32 | <SimonSapin> | MikeSmith: for URL parse errors? |
| 01:32 | <MikeSmith> | SimonSapin: no, in the case of the similar parse-error stuff in the HTML parsing algorithm |
| 01:33 | <MikeSmith> | SimonSapin: for URL parse errors, galimatias (a general-purpose URL parsing library) at least does expose the parse errors |
| 01:35 | <MikeSmith> | SimonSapin: there might be non-browser cases other than validators where people would like to have access parse errors, but I don't know of specific ones |
| 01:38 | <SimonSapin> | ok, apparently you can give galimatias a custom error handler that will receive errors and can do whatever |
| 01:38 | <SimonSapin> | a closure (callback) should do |
| 01:39 | <MikeSmith> | SimonSapin: what you need this for? |
| 01:40 | <SimonSapin> | MikeSmith: I’m implementing http://url.spec.whatwg.org/ in Rust |
| 01:40 | <SimonSapin> | trying to figure out what to do with non-fatal parse errors |
| 01:42 | <MikeSmith> | SimonSapin: ah ok |
| 01:43 | <MikeSmith> | SimonSapin: well at the very least having an error-reporting URL parser in Rust would mean somebody could eventually use that parser as part of a validator written in Rust, which is worth something |
| 10:34 | <zcorpan_> | mathiasbynens: is http://dev.opera.com/articles/showmodaldialog/ still up to date? was the removal delayed another version maybe? (also the demo's popup says 404) |
| 12:52 | <MikeSmith> | Ms2ger: I see you heard back from the W3C systeam by now but yeah there was scheduled network outage at MIT that made IRC and everything else inaccessible for a while |
| 12:53 | <Ms2ger> | Yep, thanks :) |
| 23:38 | <daurnimator> | I return, yet again lamenting the lack of some sort of GC callback in JS :( |
| 23:40 | <SamB> | daurnimator: for what? |
| 23:40 | <daurnimator> | SamB: interop/other languages running on top of JS |
| 23:40 | <daurnimator> | trying to know when js is done with some object/callback/etc |
| 23:41 | <caitp> | frankly, having a standard way to run specific code when an object is finalized is very useful, and we are all poorer for not having it |
| 23:41 | <daurnimator> | I'm now sitting here contemplating writing a js parser to analyse functions to decorate them as leaky or not |
| 23:42 | <SamB> | we could use it for useful things, like putting the object in a list of dead objects! |
| 23:43 | <Hixie> | SamB: or to force all browsers to have the same GC model and kill all innovation in that space! |
| 23:43 | <daurnimator> | SamB: e.g. I want to run lua in the browser: x=js.new(window.XHR);x:open("GET", "google.com", true); function x:onreadystatechange() print("I get leaked") end; x:send(); |
| 23:43 | <daurnimator> | Hixie: having an 'oncollected' callback does not dictate the GC model |
| 23:43 | <caitp> | SamB: like closing file handles, for instance |
| 23:44 | <SamB> | caitp: I know what such things are used for in the real world, yes |
| 23:44 | <caitp> | just checking =] |
| 23:44 | <SamB> | but here on the web, our file handles aren't even open in the first place ;-) |
| 23:44 | <Hixie> | daurnimator: actually it does, because people will end up depending on in what order things get GCed |
| 23:44 | <caitp> | javascript doesn't strictly live on the web though |
| 23:44 | <daurnimator> | Hixie: why? they don't in other languages |
| 23:45 | <caitp> | all kinds of things use v8, from databases to web servers |
| 23:45 | <caitp> | rhino too |
| 23:45 | <SamB> | daurnimator: outside of the web, the people who screw stuff up in the first place get most of the complaints |
| 23:46 | <SamB> | not the ones who changed what was meant as an implementation detail |
| 23:46 | <SamB> | or, well, outside of networking really |
| 23:47 | <SamB> | now *I* would think this was easily solved by having an unintelligable order in the first place, but evidently it isn't so |
| 23:49 | <Hixie> | daurnimator: the web is an oddly unusual case in that there's orders of magnitude more code, the code isn't maintained but is still compiled by newer compilers every time they come out, and the users are HIGHLY sensitive to breakage and change compilers on a whim so there's a lot of pressure to not break things |
| 23:49 | <daurnimator> | that sounds like a documentation issue, but to prevent people relying on *BROWSER'S* behaviour, just add (excuse the psuedo code): function gc_sweep() shuffle(this.marked_objects); this.marked_objects.forEach(function(o) if o.oncollect then o:oncollect() end free(o) end); |
| 23:50 | <daurnimator> | that is, if you're scared of people relying on order. randomise order |
| 23:51 | <Hixie> | that still exposes order |
| 23:51 | <Hixie> | it's not just per-cycle order that matters |
| 23:51 | <Hixie> | it's also which cycle |
| 23:51 | <daurnimator> | should make it unreliable enough that people don't rely on it? |
| 23:51 | <Hixie> | not if the list is one item long each time |
| 23:52 | <daurnimator> | Hixie: true. |
| 23:52 | <Hixie> | the problem is some browsers want to optimise for memory pressure, so they'll GC aggressively, and others want to optimise for speed, so they'll aggressively wait for idle cycles to do incremental GC |
| 23:52 | <Hixie> | and these two have _radically_ different behaviours |
| 23:52 | <Hixie> | behaviours that can't just be papered over |
| 23:52 | <daurnimator> | anyway, I'd really like to see some sort of oncollect callback. even if it's only on ES6 proxies for e.g. |
| 23:53 | <Hixie> | i wouldn't hold your breath :-) |
| 23:54 | daurnimator | goes back to theorising a JS parser in JS and then writing a GC on top of JS |
| 23:54 | <SamB> | anyway, it turns out that releasing things like file handles only when something is GC'd naturally can have bad results sometimes ... |
| 23:54 | <daurnimator> | SamB: yep. 'sometimes'. in the (rare) cases it's not, you still have ob:close() |
| 23:54 | <caitp> | a GC on top of JS? lol |
| 23:55 | <daurnimator> | caitp: somefunc.toString() ==> parse ==> what happens to arg#2? ==> does it get assigned somewhere? ==> add it to 'leaked' list |
| 23:55 | <caitp> | SamB there's a distinction between "finalized" and "collected" |
| 23:55 | <caitp> | I think what he's really talking about is finalization |
| 23:56 | <caitp> | once there are no live references to an object, he'd probably want to close those file handles |
| 23:56 | <SamB> | so, maybe the real solution is to run finalizers after a random delay regardless |
| 23:56 | <daurnimator> | I'd also be happy with that solution |
| 23:57 | <daurnimator> | I just don't want to keep leaking via callbacks (e.g. setTimeout, xhr.onreadystatechange, etc) |
| 23:57 | <daurnimator> | makes writing long running web apps impossible |
| 23:57 | <Hixie> | why would you leak via callbacks? |
| 23:57 | <daurnimator> | Hixie: 23:43:25 < daurnimator> SamB: e.g. I want to run lua in the browser: x=js.new(window.XHR);x:open("GET", "google.com", true); function x:onreadystatechange() print("I get leaked") end; x:send(); |
| 23:58 | <daurnimator> | the lua function gets a proxy constructed in JS |
| 23:58 | <caitp> | now it gets interesting :> |
| 23:58 | <daurnimator> | which is set as the onreadystatechange callback |
| 23:58 | <Hixie> | ok well step one, don't run lua... |
| 23:58 | <SamB> | what browser is this? |
| 23:58 | <daurnimator> | this is applicable to running anything on top of JS |
| 23:58 | <daurnimator> | SamB: all of them |
| 23:59 | <SamB> | most of my browsers don't offer to run lua |
| 23:59 | <daurnimator> | SamB: https://daurnimator.github.io/lua.vm.js/repl.html |
| 23:59 | <Hixie> | why would you run a language on top of JS |
| 23:59 | <caitp> | i expect you could probably build the lua runtime with emscripten, heh |
| 23:59 | <caitp> | guessing it's something like that |
| 23:59 | <daurnimator> | caitp: that one there is |
| 23:59 | <SamB> | ah, right, crazy |
| 23:59 | <daurnimator> | SamB: it works except for the fact it leaks proxys >.< |