| 00:40 | <gsnedders> | aklein: also note that when that public-script-coord email was written [[SetPrototypeOf]] did not yet exist, IIRC |
| 00:43 | <rniwa> | Domenic: yt? |
| 01:27 | <TabAtkins> | tobie: Yeah, people really want 64-bit ints, for obvious reasons. |
| 05:38 | <annevk> | aklein: I think that might have been for simplicity reasons |
| 05:39 | <annevk> | aklein: to just align Location and WindowProxy in as many ways as possible |
| 06:05 | <felixjet> | hiya everyone |
| 06:06 | <felixjet> | i was checking the whatwg FAQ for feedback and i'm more confuse now |
| 06:07 | <felixjet> | should i use <dl> and <dt> <dd> for FAQs? |
| 06:07 | <felixjet> | where <dt> is question and <dd> answer |
| 06:07 | <felixjet> | it seems like make sense, but an answer is not a definition of a question, at all |
| 06:07 | <felixjet> | the whatwg FAQ page is hosted on a wikimedia script so... that forces the page to use <h3> for questions and <p> for answers |
| 06:08 | <felixjet> | not a good example to clear my doubt i think |
| 06:19 | <felixjet> | and also if someone can confirm me if this thread (https://github.com/whatwg/html/issues/1937) is resolved as being able to use <div> to group definitions would be nice, because i've read most of the messages and i'm not 100% sure |
| 07:34 | <annevk> | felixjet: as defined in the HTML Standard <dl> is no longer a definition list |
| 07:35 | <annevk> | felixjet: also, as you can see at https://html.spec.whatwg.org/multipage/semantics.html#the-dl-element it allows either <div> children or <dt>/<dd> groupings |
| 07:36 | <felixjet> | and <dt>/<dd> inside <div> ? |
| 07:36 | <felixjet> | <dl><div><dt><dd></div></dl> ? |
| 07:39 | <annevk> | felixjet: yes |
| 07:44 | <felixjet> | thanks! |
| 08:28 | <tobie> | Am I reading the ES to IDL long long conversion algorithm properly? (https://heycam.github.io/webidl/#es-unsigned-long-long) |
| 08:28 | <tobie> | Are the [EnforceRange] and [Clamp] extended attributes using much lower bounds than those supported by the number for the reasons Domenic exposed yesterday? |
| 08:28 | <tobie> | If so, is this just completely unintuitive to me because I'm new to thinking about these issues? |
| 08:29 | <tobie> | Or is this unintuitive to all? |
| 08:35 | <annevk> | tobie: a number is 2^53-1 in ECMAScript |
| 08:36 | <annevk> | tobie: integer anyway |
| 08:37 | <tobie> | annevk: I think I'm starting to figure out the different pieces, but I'm still putting them together all wrong. |
| 08:40 | <tobie> | annevk: you can still have numbers bigger, right? But then they loose precision. |
| 08:43 | <annevk> | tobie: I don't think so |
| 08:43 | <annevk> | tobie: https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type has some of the details |
| 08:43 | <annevk> | tobie: I'm not overly familiar with IEEE Standard for Binary Floating-Point Arithmetic though |
| 08:43 | <annevk> | tobie: or at all, hah |
| 08:44 | <tobie> | In the console: |
| 08:44 | <tobie> | Math.pow(2, 53) // 9007199254740992 |
| 08:44 | <tobie> | Math.pow(2, 55) // 36028797018963970 |
| 08:54 | <annevk> | tobie: Math.pow() is implementation-dependent |
| 08:54 | <annevk> | tobie: "Note that all the positive and negative integers whose magnitude is no greater than 2^53 are representable in the Number type (indeed, the integer 0 has two representations, +0 and -0)." |
| 08:54 | <tobie> | 36028797018963970 |
| 08:55 | <tobie> | oops sorry, wrong console. :) |
| 08:57 | <tobie> | annevk: so what about those numbers that are bigger in long long that are neither clamped nor whose range is enforced? |
| 08:59 | <annevk> | tobie: long long is always bigger, no? |
| 08:59 | <annevk> | tobie: which is arguably a problem |
| 08:59 | <annevk> | tobie: it doesn't make much sense for IDL to accept and return bigger numbers than JavaScript can handle reliably |
| 09:00 | <tobie> | annevk: if you look at unsigned long long, we use modulo 2^64, not modulo 2^53 |
| 09:00 | <annevk> | tobie: I saw that, presumably since long long is a 64-bit signifier |
| 09:02 | <tobie> | annevk: I don't understand. :( |
| 09:03 | <annevk> | tobie: as I said, I'm not great at the JavaScript numbers game either |
| 09:04 | <tobie> | annevk: I'll wait for the prof. TabAtkins to show up. |
| 09:05 | <annevk> | tobie: I think the problem with numbers larger than 2^53 is what happens when you start adding or subtracting |
| 09:06 | <annevk> | tobie: e.g., if you subtract 1 from 2^55 in your example you still get the same result |
| 09:06 | <annevk> | tobie: if you subtract 4, 6 is subtracted |
| 09:07 | <tobie> | annevk: yes, I'm aware of this. But then why is this an issue for clamped numbers and not for non-clamped ones. |
| 09:07 | <annevk> | tobie: https://mail.mozilla.org/pipermail/es-discuss/2013-August/032991.html |
| 09:08 | <annevk> | tobie: I think [Clamp] is typically not used for long long, but smaller values |
| 09:09 | <annevk> | tobie: and it's kinda recommended against |
| 09:09 | <annevk> | from what I remember anyway |
| 09:11 | <annevk> | zcorpan: hey, can you convert html-differences to Bikeshed? |
| 09:12 | <tobie> | annevk: I see no such warning in the spec |
| 09:12 | <tobie> | annevk: anyway, thanks for the help |
| 09:13 | <zcorpan> | annevk: i suppose. is it a problem? |
| 09:16 | <annevk> | zcorpan: not huge, but with Bikeshed we can do commit snapshots and I'm going to stop maintaining the xref repo |
| 09:18 | <zcorpan> | annevk: ok. i filed an issue |
| 09:19 | <annevk> | zcorpan: the other thing I guess is that we only have mimesniff/xhr/html-differences left and I'm converting mimesniff at the moment and xhr is halfway done |
| 09:20 | <annevk> | zcorpan: so nobody having to install and deal with Anolis anymore is also a win of sorts |
| 09:20 | <zcorpan> | yeah, agreed |
| 09:29 | <tobie> | when you need booleans in abstract operations, do you just "set |foo|" and then do "if |foo| is set"? |
| 09:34 | <tobie> | is calling those flags suggested? |
| 09:40 | <annevk> | tobie: in abstract operations you would use actual booleans and no flags |
| 09:40 | <annevk> | tobie: and copy the language from ECMAScript |
| 09:40 | <tobie> | annevk: are you and domenic working on a guide for this |
| 09:40 | <tobie> | ? |
| 09:42 | <annevk> | tobie: we're in the process of figuring out guidance around algorithms, but we're not sure yet what to suggest |
| 09:42 | <tobie> | annevk: heh |
| 09:42 | <annevk> | tobie: I'd personally be okay with going abstract-op everywhere, but it seems there's quite a few people that are okay with preserving named algorithms and such |
| 09:42 | <annevk> | tobie: including Domenic! |
| 09:43 | <tobie> | annevk: yeah, would have thought? :) |
| 09:43 | <annevk> | tobie: so for now we'll have things that "return" terminates the algorithm and "throw" rethrows unless caught with prose, etc. |
| 09:44 | <tobie> | annevk: is this happening in a repo anywhere? |
| 09:44 | <annevk> | tobie: yeah, needs to be made public soonish, I'll show you |
| 09:45 | <tobie> | cool |
| 09:45 | <MikeSmith> | is Domenic being OK with preserving named algorithms is maybe because he sees that way as being more understandable/approachable Web/JS developers? |
| 09:45 | <annevk> | (if anyone else is interested let me know, it's not public yet since we need to figure out some more details) |
| 09:45 | <MikeSmith> | or is that totally unrelated in this context? |
| 09:46 | <annevk> | MikeSmith: I don't really want to speak for him, but he's argued that it has worked well thus far |
| 09:46 | <annevk> | MikeSmith: and I think indeed also that people have said that ECMAScript is less readable |
| 09:48 | <MikeSmith> | well not sure how useful a data point this is, but personally I find the ECMAScript spec way extremely difficult/unfamiliar as far as readability |
| 09:48 | <annevk> | I wonder to what extent that is because it describes a programming language |
| 09:48 | <MikeSmith> | maybe that is just because it is so very different from the specs for Web APIs that I am more familiar with |
| 09:49 | <annevk> | But folks have also said this of Streams |
| 09:49 | <MikeSmith> | yeah, that, I think |
| 09:49 | <annevk> | Which describes a set of objects |
| 09:51 | <MikeSmith> | well I am pretty sure I have never actually read any other spec for a programming language. So for all I know it could be that the way to ECMAScript defines this is very like specs for other programming languages and looks familiar for anybody who has implemented a programming-language runtime, and for people who actually work in V8 and SpiderMonkey (or whatever the current name is) and JSC |
| 09:52 | <annevk> | When ECMAScript still had ReturnIfAbrubt there was a lot of complaining |
| 10:02 | <gsnedders> | MikeSmith: it's a kinda odd way to do it, but not unreasonable compared with others (which mostly rely on some separate section defining what happens with abrupt completion in various places) |
| 12:45 | <tobie> | MikeSmith: I actually find it very useful to identify algorithms as such, with input values, output values, etc. I find the Algo(args) style very expicit and that's something I like about it. I think developers in general find that easier to grok ("oh, here's a call to a function! this I understand!") |
| 12:46 | <tobie> | MikeSmith: the reason the ES spec is super hard to read, imho, is because it defines things that are super hard to understand, does so very precisely, and does so in a style that is reminiscent of the language it describes |
| 12:48 | <tobie> | MikeSmith: It's like meta-programming. Once you get in the right mindset, it's actually pretty straightforward, until you do, it makes your head explode. |
| 14:48 | <annevk> | tobie: if that were to happen, it would be hard to continue |
| 14:50 | <tobie> | Yes. Poor metaphor. I agree. |
| 14:51 | <annevk> | But I think I agree |
| 14:52 | <annevk> | Although I do think stuff like IDL can help a lot in understanding, if you're used to that kind of notation |
| 14:52 | <annevk> | It neatly summarizes a whole bunch about an interface/class |
| 14:54 | <jgraham> | FWIW I made the WebDriver spec use Result types rather than exceptions |
| 14:54 | <jgraham> | Although I did then add a "try" macro to it so… |
| 16:42 | <smaug> | jgraham: do you know where the test for web animations live? |
| 16:42 | <smaug> | in github |
| 16:43 | <smaug> | aha, https://github.com/w3c/web-platform-tests/blob/master/web-animations/interfaces/AnimationEffectTiming/endDelay.html |
| 16:47 | <smaug> | how do I in github UI go to the log of the file in its previous location ? |
| 16:47 | <smaug> | that particular file was moved |
| 16:48 | <smaug> | oh, perhaps blame works anyhow |
| 18:44 | <TabAtkins> | tobie, annevk: You can absolutely have numbers larger than 2^53 in JS. Numbers go all the way up to 10^308. You just, as Tobie says, lose precision - between 2^53 and 2^54, you can only represent even numbers, between 2^54 and 2^55, only numbers divisible by 4, etc. |
| 18:46 | <tobie> | TabAtkins: can you explain why the clamp / enforce range works on 2^53 then, but not the modulo? |
| 18:47 | <tobie> | s/works on/uses/ |
| 18:47 | <TabAtkins> | Are the details of this in WebIDL for me to read? |
| 18:47 | <tobie> | Yes. Just a sec. |
| 18:48 | <tobie> | TabAtkins: https://heycam.github.io/webidl/#es-long-long |
| 18:49 | <tobie> | In particular steps 2.3, 3.1 and 6. |
| 18:49 | <tobie> | TabAtkins: ^ |
| 18:51 | <tobie> | TabAtkins: it feels like the semantics of clamp/enforce range are different here. And I don't understand the reasoning. |
| 18:52 | <TabAtkins> | Yeah, that's weird. I'm guessing it's because long long was intended to be the i64 type that Java and other langs expose, so the initial definition was written with that behavior, while [Clamp] and [EnforceRange] were added later and more explicitly coupled to JS' |
| 18:52 | <TabAtkins> | s representation. |
| 19:49 | <tobie> | TabAtkins: thanks. Filed https://github.com/heycam/webidl/issues/237 |