| 00:30 | <KiChjang> | i don't understand step 7 of this spec https://fetch.spec.whatwg.org/#concept-main-fetch |
| 00:31 | <KiChjang> | when it says run the remaining steps in parallel, does it mean each and every subsequent steps should be ran in a separate thread? |
| 00:51 | <KiChjang> | anyone? |
| 00:53 | <caitp-> | it's hard to make heads or tails out of it, but it doesn't seem to mean what "in parallel" normally means |
| 00:54 | <caitp-> | https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel << pretty clearly is not saying "new thread for each subsequent step" though |
| 00:56 | <KiChjang> | caitp-: yes that's why i was confused |
| 00:57 | <caitp-> | yes, probably worth filing a bug on the language used =p |
| 00:57 | <KiChjang> | what's the link for reporting bugs? |
| 00:58 | <caitp-> | you should see one if you fling the mouse around the spec, it pops up at the top or bottom |
| 00:59 | <caitp-> | oh, you don't even have to fling the cursor around, it's just floating at the bottom |
| 01:01 | <caitp-> | TabAtkins, just because we don't all have high S2N ratios doesn't mean we're trolls, I'm sure L2L or whatever his name is means well |
| 01:01 | <KiChjang> | ok i found it |
| 01:02 | <roc> | without judging L2L specifically --- sufficiently advanced incompetence is indistinguishable from malice |
| 01:04 | <caitp-> | this is about asking for labeled block statements in ecmascript |
| 01:04 | <caitp-> | which is a perfectly fine thing to propose when talking about language design |
| 01:14 | <TabAtkins> | caitp-: Nah, L2L's s/n ratio is basically zero. I flipped the bozo bit on him when he was doing stuff in www-style. |
| 01:14 | <TabAtkins> | You don't need a *high* ratio, just one distinguishable from gibberish. |
| 01:15 | TabAtkins | is about to take off. |
| 01:16 | <caitp-> | if it was anyone else asking for goto in js would you still be talking about banning them |
| 01:18 | <caitp-> | you don't have to explain why vms don't really want to have to implement it, or why most authors don't want to read or write it, but it's certainly not off the table for discussion on language design |
| 03:04 | <roc> | my laptop just crashed |
| 03:04 | <roc> | oos |
| 05:48 | <ek_> | hello |
| 05:48 | <ek_> | i have a question |
| 05:48 | <ek_> | In HTML5 spec it talks about stable state (in http://www.w3.org/TR/html5/single-page.html#await-a-stable-state). Can you explain what is a stable state and what does it exactly mean to await a stable state? I can not get the explanation in the spec. A simple example will be helpful |
| 09:57 | <hsivonen> | hmm. annevk isn't here. |
| 09:57 | <hsivonen> | Does anyone have test cases for the Big5 decoder as defined in the Encoding Standard? |
| 10:23 | <SimonSapin> | Hixie: What is a "globally unique identifier" in https://html.spec.whatwg.org/multipage/browsers.html#origin ? Is it the same as "opaque identifier" ? |
| 10:25 | <Ms2ger> | Yeah |
| 10:28 | <SimonSapin> | Shouldn’t that be defined in the spec? |
| 10:34 | <Ms2ger> | I guess it should say "globally unique opaque identifier" |
| 11:19 | <philipj> | hsivonen: It's possible that libicu would have test cases, jshin⊙co has done some work. I kind of doubt there's a from-scratch implementation based on the spec algorithm with test cases for its specific way of doing error handling, however. |
| 11:20 | <hsivonen> | philipj: thanks |
| 11:20 | <Ms2ger> | SimonSapin, ^ |
| 11:20 | <hsivonen> | philipj: I guess I'll do some manual math to at least get a couple of smoke tests written |
| 11:21 | <hsivonen> | but first, it turns out that I should replace my placeholder for a data table with an actual data table! |
| 11:21 | <philipj> | hsivonen: I really hope the new Big5 bits work out, I put quite a lot of research into some of the tiny details :) |
| 11:21 | <philipj> | but if it doesn't, we'll learn something from the failure at least |
| 11:22 | <hsivonen> | philipj: first thing I've learned: the lowest valid pointer in the index does not exist according to the OpenJDK notion of "Big5", so I probably shouldn't check my test cases against the JDK decoder |
| 11:23 | <philipj> | hsivonen: I think on average the Big5-HKSCS decoder from other implementations would be the closest to the spec |
| 11:23 | <philipj> | not sure if the low indexes are where Big5-HKSCS has its additions though |
| 11:24 | <hsivonen> | philipj: makes sense |
| 11:28 | <hsivonen> | does Python have syntactic sugar for a flavor of xrange that takes a pair of integers instead of two integer arguments? |
| 11:28 | <hsivonen> | I guess I'll just have to take the integers out of the pair myself :-( |
| 11:29 | <hsivonen> | except I already did so. doh |
| 11:29 | <Ms2ger> | range(*(2, 3)) |
| 11:31 | <hsivonen> | Ms2ger: thanks |
| 11:31 | <Ms2ger> | Np |
| 11:31 | hsivonen | writes Python to generate Java with the plan to then repurpose the Python program to generate C++ |
| 11:32 | <hsivonen> | (because it makes no sense to write either directly) |
| 11:33 | <Ms2ger> | hsivonen, btw, Kannan was looking for someone to ask about nsScriptLoader; I believe he said he'd send you email |
| 11:35 | <hsivonen> | Ms2ger: I've replied, but by then smaug had already replied more usefully |
| 11:35 | <Ms2ger> | Alright, great :) |
| 11:39 | <hsivonen> | aargh. I keep doing things that collide with magic limits of either the Java class format or HotSpot |
| 11:40 | <hsivonen> | this time, I tried to pack data in a string literal that's too long for the class file format |
| 11:51 | <SimonSapin> | 16 bit length? |
| 11:56 | <hsivonen> | SimonSapin: yes |
| 11:56 | <hsivonen> | SimonSapin: counted on Java-modiefied UTF-8 bytes |
| 11:57 | <hsivonen> | apparently |
| 12:13 | <Ms2ger> | "Postel tarpit (n.) - A system that has tried so hard to accept all possible input that any change becomes backwards-incompatible" |
| 12:28 | <hsivonen> | hooray. my Big5 decoder isn't obviously broken |
| 12:29 | <hsivonen> | (unobvious test cases are harder, of course) |
| 12:38 | <hsivonen> | oh, great. the error reporting design of the Java NIO decoding API is more broken than I thought |
| 12:40 | <hsivonen> | hmm... |
| 12:41 | <hsivonen> | and even more broken than I thought |
| 12:41 | <hsivonen> | quite sad really |
| 12:46 | <hsivonen> | so assume you have a big5 input buffer that ends with 0xFE. then your next input buffer starts with 0x39. |
| 12:48 | <hsivonen> | I don't see how the Java API allows the decoder to signal the error to the caller such that the caller constructs U+FFFD followed by U+0039 and not just U+FFFD |
| 12:48 | <hsivonen> | boo |
| 12:49 | <hsivonen> | if there is a way, it sure is an undocumented abuse of the API |
| 12:49 | <hsivonen> | let's see if my caller-side code that I wrote years ago has an answer to how the JDK decoders deal |
| 12:50 | <hsivonen> | kids, don't try to design a streaming decoder API that allows the caller simultaneously to learn which bytes turn into U+FFFD and to continue decoding |
| 12:50 | <hsivonen> | seems to be too hard a problem even for profession drivers on closed road |
| 12:52 | <hsivonen> | OK, my old calling code, for which I blackbox reverse engineered how the API actually works, shows how the undocumented part works |
| 12:53 | <hsivonen> | you claim you need more input but you leave some input unconsumed |
| 12:53 | <hsivonen> | and the caller in, undocumentedly, supposed to copy the unconsumed bytes to the start of the next buffer |
| 12:54 | <hsivonen> | sucks to be the caller if the unconsumed bytes are more numerous that the size of your buffer |
| 12:54 | <hsivonen> | boo boo boo |
| 12:59 | <hsivonen> | except how does what I just said work if 0xFE is the last byte before EOF? |
| 12:59 | <hsivonen> | aargh |
| 13:16 | <hsivonen> | wow. this API design sucks |
| 13:17 | <MikeSmith> | hsivonen: you writing this in Python? |
| 13:17 | <MikeSmith> | which API |
| 13:21 | <hsivonen> | MikeSmith: I'm writing the code generation in Python |
| 13:21 | <hsivonen> | MikeSmith: the actual code is Java (C++ inthe future) |
| 13:22 | <hsivonen> | MikeSmith: the bad API is java.nio.charset.CharsetDecoder |
| 13:22 | <MikeSmith> | aha |
| 13:24 | <hsivonen> | fun fact, if your input buffer is one byte long (edge case that's not prohibited!), the API doesn't work on the REPORT mode |
| 13:25 | <hsivonen> | i.e. if you try to feed the decoder one byte at a time |
| 13:25 | <hsivonen> | I guess if I had unlimited time, I could write a blog post about how even the API that's supposed to be right is wrong |
| 13:29 | <MikeSmith> | hsivonen: good thing it's not very widely used :-) |
| 13:29 | <hsivonen> | MikeSmith: few people need to use the API directly |
| 13:29 | <hsivonen> | from either side |
| 13:30 | <hsivonen> | anyway, if anyone wants to review: https://hg.mozilla.org/projects/htmlparser/rev/b426b2e8f47a |
| 13:30 | <hsivonen> | oh, and I just noticed that implFlush is wrong |
| 13:33 | <hsivonen> | for those who are interested, search for "undocumented" in the above changeset |
| 13:48 | MikeSmith | looks now |
| 13:51 | <MikeSmith> | I think a good rule if you're reading hsivonen code and there's a commment that's any longer than two lines, it's most likely there to point out something that's broken |