| 00:44 | <wanderview> | Domenic: does streams API spec anything related to cross-global stuff? like ReadableStream created in one global, then added as body of Response with a different glkobal, and then put into Cache with a third global? which global would the ReadableStream callbacks fire in when Cache starts draining the stream? |
| 00:44 | <wanderview> | I assume its the ReadableStream global? |
| 00:56 | <wanderview> | or what if a script in another global does the read() directly |
| 03:36 | <Domenic> | wanderview: what does "callbacks fire in" mean? |
| 04:04 | <MikeSmith> | Domenic: TabAtkins about https://github.com/whatwg/html-build/issues/113 (Add built-time syntax highlighting) for now when I can make time I can figure out how to make wattsi take the contents of each pre and shell out to send those to whatever external script to run them on, and get the results back into the wattsi DOM(ish) thing |
| 04:05 | <TabAtkins> | MikeSmith: Cool. I've got the code almost completely written to take some JSON-HTML in and spit highlighted JSON-HTML out. |
| 04:05 | <MikeSmith> | super |
| 04:07 | <MikeSmith> | well in the mean time even if that’s not completely ready yet I could just first write the wattsi shell-out stuff, and just test it with some simple script that returns whatever I feed to it |
| 04:08 | <MikeSmith> | anyway I reckon I would not be able to make the time til the weekend, so couldn’t have any thing to try to beginning of next week regardless |
| 04:09 | <MikeSmith> | unless I surprise myself with finding out that part ends up being simple to do in wattsi |
| 08:54 | <benjamingr_> | Hey, is there anything in the Timers spec that deals with values over Int32? https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html# |
| 09:32 | <annevk> | benjamingr_: IDL |
| 09:32 | <annevk> | benjamingr_: https://heycam.github.io/webidl/#es-long in particular |
| 09:34 | <benjamingr_> | @annevk got it, thanks! |
| 10:30 | <jgraham> | annevk: Thanks! |
| 10:31 | <jgraham> | Now if only the tree would reopen :) |
| 12:04 | <annevk> | Domenic: I prefer landing WPT first to make sure there's no gotcha there |
| 12:23 | <Domenic> | annevk: hmm ok, well as long as they both land around the same time, I guess it's fine |
| 12:24 | <annevk> | Domenic: in this case the spec was ready but I wasn't sure whether the tests were ready |
| 12:24 | <annevk> | Domenic: yeah, I guess they mostly just need to land around the same time and have pointers to each other |
| 17:06 | <TabAtkins> | MikeSmith: Interestingly, the thing that's slowing me down is the idl highlighter. I can get pigments to feed me a good text format I can transform into HTML, but I'm having to trick widlparser into doing the same. |
| 17:07 | <TabAtkins> | (Abusing some pua characters to turn the "HTML" it emits into a de facto stack-based text format.) |
| 17:09 | <MikeSmith> | why I am not suprised to see “the thing that's slowing me down” and “idl” in teh same sentence |
| 17:12 | <MikeSmith> | TabAtkins: from my side I find the shell/process interaction stuff for Free Pascal is well documented, so no problem there. The thing that I still have no clue about with wattsi yet is how to serialize out from its DOM or get sometihng back into/replace in its DOM |
| 17:12 | <MikeSmith> | that may turn out to be easy, I dunno. JUst have never needed to do it for anything yet |
| 17:13 | <TabAtkins> | Serialize out should be a relatively simple walk over the structure, building json as you go. Getting something back in has to exist, Wattsi generates HTML in some of its processes, but don't how easy it would be. |
| 17:15 | <MikeSmith> | yeah |
| 18:41 | <wanderview> | Domenic: I think "callbacks fires in" means what global self is and maybe permissions associated with the global... |
| 18:42 | <Domenic> | Yeah, I got an email I should respond to... unsure why it's an email not an issue though. |
| 18:46 | <wanderview> | Domenic: from baku or bz?> |
| 18:46 | <Domenic> | baku |
| 18:48 | <wanderview> | Domenic: yea, I think sorting out how we should handle this might be one of the last issues before we can r+ all the streams patches (on the DOM side anyway) |
| 18:48 | <Domenic> | I guess, seems like a tiny thing to hold up over |
| 18:49 | <wanderview> | Domenic: since we have script globals with super power privs I think it can be a security problem if we get it wrong |
| 18:49 | <Domenic> | Hmm I see |
| 18:50 | <wanderview> | Domenic: we probably don't need to block on getting it landed in spec, but at least make sure we're on the same page as to where we want to be |
| 18:50 | <Domenic> | I unfortunately don't know myself; both ECMAScript and Streams suffer from not doing incumbent/entry correctly |
| 18:50 | <Domenic> | Solving that is pretty hard |
| 18:51 | <wanderview> | Domenic: IMO it seems it should just be bound to whatever global was present when the function passed to ReadableStream() constructor... it shouldn't change based on who it reading from the stream |
| 18:52 | <wanderview> | Domenic: not sure what that means in spec language, though... maybe we need to loop bz into the email if he isn't already |
| 18:52 | <Domenic> | He is yeah; maybe I should have +ed you in |
| 18:52 | <Domenic> | Again, email = :(, GitHub issues = :) |
| 18:52 | <wanderview> | yea |
| 18:52 | <wanderview> | technically I am on PTO and shouldn't be worrying about this |
| 18:52 | <Domenic> | Ah I see :) |
| 18:53 | <wanderview> | but trying to get streams through this month before baku goes on PTO |
| 19:39 | <weinig> | Domenic: I have a dumb question for you. Since DOMException is defined as a terminal in the grammar, is the new DOMException definition https://heycam.github.io/webidl/#idl-DOMException valid WebIDL (e.g. is it ok for a terminal symbol to be an identifier here)? |
| 19:40 | <Domenic> | weinig: haha probably not. It should have been removed from the grammar. |
| 19:40 | <weinig> | Domenic: ok, cool, I’m not going crazy then |
| 19:40 | <weinig> | phew |
| 19:40 | <weinig> | I’ll file an issue |
| 19:40 | <Domenic> | Cool, I'll file a PR :) |