B ... the span gets broken into an inline part, an anonymous block part, and an inline part [13:26:03.0000] Yeah, this is all fun times. [13:26:04.0000] you can think of that as a grotesque form of line breaking I suppose [13:27:00.0000] but it means your boxes don't even all have the same type [13:27:01.0000] OK, I think I'm done :-) [13:27:02.0000] astearns: yes [13:28:00.0000] regions are worse than multicol [13:28:01.0000] All of which suggests that I'm wasting my time trying to find corner cases where browsers disagree on exactly how to apply transforms, because it's shooting fish in a barrel and is just going to require zillions of special cases. [13:28:02.0000] astearns: in multicol, at least each column box has the same parent. with regions that doesn't hold [13:28:03.0000] It would be more worthwhile for me to finish up a basic transform test suite for both 2D and 3D, help work out any remaining kinks, and move on to something more productive than CSS until it's rewritten from scratch. [13:29:00.0000] nonono, your bug-filing on the transforms spec is super useful [13:29:01.0000] and the test suite work too [13:29:02.0000] AryehGregor: I think our goal here is to have enough interop and tests to progress to CR [13:29:03.0000] AryehGregor: No, edge-cases are far more important in layout-land than DOM-land. [13:29:04.0000] the Web badly needs that [13:29:05.0000] hober, I know, but only up to a point . . . [13:29:06.0000] roc, well, who decides how many tests are needed for CR? [13:29:07.0000] s/for/to exit/ [13:29:08.0000] I'm willing to let you decide :-) [13:30:00.0000] obviously, only you can choose how to spend your time, but personally I'm very happy that you're making tests and filing bugs wrt transforms [13:30:01.0000] astearns: the current example I'm harping on is where you have an element that has 'opacity' and needs to get rendered as a single unit. It flows into two regions, and one of the regions is inside an element with its own 'opacity' [13:31:00.0000] roc, I spent the last two days or so finding more corner cases. [13:31:01.0000] astearns: how do you render that? The first element needs to be rendered as a single unit, but it can't be [13:31:02.0000] Some are just silly bugs, like Gecko and WebKit mangling transformed file inputs in some cases. [13:31:03.0000] roc: do two renders of the element with opacity and slice? [13:31:04.0000] But some are bugs that arise from the ambiguity of CSS. [13:31:05.0000] this can't happen with columns since two column boxes can't have different ancestor chains [13:31:06.0000] roc: thanks - I don't think we have that as an issue, so I'll add it [13:31:07.0000] I grant that the stuff I've done so far remains useful. [13:31:08.0000] (Bear in mind for CR the main aim is to prove that the whole spec can implemented) [13:31:09.0000] I've brought it up on the www-style list multiple times [13:32:00.0000] But does anyone really want me to file a bug on how browsers behave when a position: fixed element is repeated across multiple pages with different sizes and you transform it? [13:32:01.0000] That far doesn't seem very useful to me. [13:34:00.0000] astearns: forgive me if I come across as a self-righteous prat in the following ... but this is a pattern that I've seen repeated too many times [13:34:01.0000] I'd actually be really interested to see how hard it is to start writing a unified CSS spec. Start with just block and inline elements in normal flow with margin/border/padding, that kind of thing. [13:34:02.0000] I imagine no one will be willing to pay me to do that, though. :) [13:35:00.0000] Well that is an interesting and testable question [13:35:01.0000] Is nyone prepared to pay AryehGregor enough to rewrite CSS [13:36:00.0000] astearns: a) vendor(s) rush to implement a feature and "get it out there" (probably prefixed) b) lots of corner cases are ignored c) the Web starts to depend on the (prefixed) feature c) later spec writers and/or other implementors try to implement, discover feature makes no sense d) those people get to clean up the mess while implementors a) move on to the next feature [13:36:01.0000] Well, I don't have time to fully rewrite it just yet, only to do a very basic start. [13:36:02.0000] So it wouldn't be of much use to anyone. [13:36:03.0000] I hope someone will be willing to pay me to do it someday, if no one else beats me to it. [13:36:04.0000] /me starts a kikstarter project [13:36:05.0000] kickstarter even [13:37:00.0000] Well they would have to pay you enough that you were prepared to keep working on it rather than do whatever else you had in mind [13:37:01.0000] :) [13:37:02.0000] The problem is, my desire for money is finite relative to the other things I want to do. So you'd just encourage me to work fewer hours if you paid me more per hour. [13:37:03.0000] roc: no worries, I agree with you. I want to get all the corner cases considered (and get implementation feedback from mozilla and opera) [13:41:00.0000] hober: that might work [13:41:01.0000] for opacity [13:42:00.0000] in fact, duplicating the rendering might work in general [13:43:00.0000] but it's hard to be sure [13:46:00.0000] In unrelated news, developing webaps seems to kind of suck. I mean there is lots of - what seems to be - accidential complexity. If you want to do something "simple" like sync the state of some controls with a server using ajax it isn't really obvious what the right choices are for storing the data, or for organising the code. [13:47:00.0000] its why people use frameworks [13:47:01.0000] Well yes [13:48:00.0000] But there is a major paradox of choice issue there [13:48:01.0000] yeah :( [13:48:02.0000] and it's not really clear what works with what other things [13:49:00.0000] yeah true enough, we have a surfeit of frameworks and not enough understanding of what does what and when [13:53:00.0000] The only thing that everyone seems to use is jQuery. Which is better than DOM I guess, but it does make me feel a bit... unclean, perhaps. Because everything seems to be based on magic and string manipulation. And having all these things that are sometimes wrapped in magic jQuery stuff and sometimes have the underlying implementation leak through [13:53:01.0000] roc: bug stub at https://www.w3.org/Bugs/Public/show_bug.cgi?id=15835 (with your latest list comment) [13:53:02.0000] actually I think Vincent Hardy just responded to my email by filing his own bug :-) [13:54:00.0000] I guess my perspective on that is very unusual though since I know DOM rather well and jQuery rather poorly whilst most webdevs are the exact opposite [13:54:01.0000] bah [13:55:00.0000] jgraham: ha true. but jQuery is hardly enough for these webapps [13:55:01.0000] yes, it's always good to check the latest messages on the mailing list before going off on a rant :-) [13:57:00.0000] actually, they might be separate bugs. Vincent's is about stacking contexts, which could be specified without addressing opacity/filters directly [13:57:01.0000] ok [14:07:00.0000] divya: Right. That is tidying up the platform. The next level where there are relatively high-level primitives for writing complex applications seems to be missing [14:08:00.0000] This is not a new observation, obviously [14:08:01.0000] yeah everyone seems to have their own idea of what that would look like :( [14:08:02.0000] hence the fragmentation 2012-02-02 [16:56:00.0000] hm, no abarth [16:56:01.0000] aha, he's in #webkit [23:16:00.0000] Hixie: http://www.whatwg.org/issues/data.html looks borked [23:17:00.0000] oh [08:00:00.0000] Anyone around that understands __proto__ in SM? [08:10:00.0000] Basically, anyone know what Object.prototype.__proto__ does? [08:11:00.0000] I'm confused looking over the thread in es-discuss. [08:59:00.0000] Mmm [08:59:01.0000] I wonder why Opera mobile does not allow fingerpress on URL to have a copy URL popup option. [09:12:00.0000] asmodai: What OS? [09:13:00.0000] Android 3 [09:13:01.0000] Only got a Save As and Copy Text option when long pressing an URL leading to an apk (nightly firefox in this case) [09:16:00.0000] Oh, you mean on a link? [09:17:00.0000] Aye [09:18:00.0000] Many cases where you might want to drop an URL into an evernote note or something like that [09:34:00.0000] Argh, Transforms are *so* messed up. [09:34:01.0000] I suspect largely because nobody ever finished the spec, but everyone implemented anyway. [09:35:00.0000] Sounds like something to blame Apple for [09:35:01.0000] TabAtkins_, :) [09:36:00.0000] TabAtkins_, on the other hand, it might get interesting if you resolved ems for computed value but not percentages . . . [09:36:01.0000] /me tries to think of an interesting case [09:36:02.0000] It's a corner case anyway, since there's no reason for anyone to specify transform: inherit, ever. [09:37:00.0000] We could probably change it so ems are resolved and no one would notice. [09:41:00.0000] AryehGregor, I think a well-written css3-box would be really nice, fwiw [09:42:00.0000] /me has never looked at css3-box [09:42:01.0000] Hey, it doesn't have a warning [09:42:02.0000] TabAtkins? [09:44:00.0000] w3c reminds me idef more and more [09:49:00.0000] back [09:49:01.0000] jetlagged [09:49:02.0000] Ms2ger: Yes? [09:50:00.0000] Oh, I see. [09:50:01.0000] Huh, I wonder how that escaped my warning crusade. [09:50:02.0000] annevk: welcome back! [09:51:00.0000] inbox >4000 [09:51:01.0000] annevk, multipage HTML is broken [09:51:02.0000] yeah, I read about that [09:51:03.0000] is foolip away too? [09:51:04.0000] or just didn't have the time [09:58:00.0000] AryehGregor: Changing it to resolve ems would be great, yes. [10:05:00.0000] MikeSmith: resolved bugs still don't go to www-dom I think [10:05:01.0000] MikeSmith: the timeout given in my email (backed up by Art) has long since passed [10:05:02.0000] MikeSmith: so I think we can go ahead with that now [10:11:00.0000] Velmont: hey, have you ever played with gzip and XHR? [10:12:00.0000] Velmont: should work fine no? [10:12:01.0000] Ms2ger or some Mozilla person: do reftests detect differences that aren't painted onto the screen? Like, they're outside the initial viewport? [10:12:02.0000] Don't think so [10:13:00.0000] I just found a reftest that seems to want to say matrix3d(1,0,0,0, 0,2,0,0, 0,0,3,0, 4,5,6,1) is the same as scale3d(1,2,3) translate3d(4px,5px,6px), which of course it's not, but the transformed div has no background and the text is off-screen, so I guess it's not surprising that it passes anyway. [10:13:01.0000] "Responses must have the content-encodings automatically decoded." [10:13:02.0000] so that should work fine [10:16:00.0000] . . . also, I just found a test that's precisely identical to its ref. [10:16:01.0000] <3 [10:16:02.0000] I guess I should file bugs. [10:16:03.0000] Checked for silly things like BOMs? [10:17:00.0000] diff -u returned nothing. [10:17:01.0000] A bug it is, then, I guess [10:17:02.0000] diff -u layout/reftests/transform-3d/overflow-hidden-1{a,-ref}.html [10:17:03.0000] /me reports [10:17:04.0000] Hah [10:51:00.0000] Ms2ger, if I'm filing a bug that was introduced by another bug, the new bug I file should depend on the old bug, right? Not block it? [10:52:00.0000] /me always gets them confused [10:52:01.0000] MikeSmith: wfm now [10:52:02.0000] AryehGregor, block [10:52:03.0000] Okay. [10:55:00.0000] anyone have IE handy? [10:55:01.0000] Hixie, yes. [10:55:02.0000] /me is using Windows 8 Developer Preview in VirtualBox with IE10 [10:56:00.0000] No need for licensing fees. [10:56:01.0000] can you load http://software.hixie.ch/utilities/js/live-dom-viewer/ and hit the download link [10:56:02.0000] Then what? [10:56:03.0000] and then hit set 0, check that option 0 is selected, then hit set 1, check that option 1 is selected, and then hit set null, and see what happens? [10:57:00.0000] When I hit "set 0", option 0 is selected. Then when I hit "set 1", option 1 is selected. Then when I hit "set null", option 0 is selected again. [10:57:01.0000] In IE10 Developer Preview. [10:57:02.0000] awesome, thanks [10:57:03.0000] and nothing is selected for set 2, right? [10:57:04.0000] Right. [10:57:05.0000] ok so the guy reporting this bug was just wrong, cool [10:57:06.0000] thanks [10:58:00.0000] it's so cool the way these days the specs all line up and actually describe obscure edge cases interoperably [10:59:00.0000] Well, the HTML/DOM type of specs, at least . . . CSS not so much, as I'm finding. [10:59:01.0000] :-( [11:02:00.0000] Dude, you're explicitly dealing with specs that are shitty because they got dropped. [11:02:01.0000] Stop generalizing, please. >_< [11:02:02.0000] good morning, Whatwg! [11:02:03.0000] TabAtkins_, no, I definitely mean all CSS specs. At least all the ones to do with layout. Parsing and the cascade seems fine. But layout is horribly vague. It needs to be redefined algorithmically using precise hyperlinked definitions. [11:03:00.0000] We were just talking about how terms like "the element's box" are ambiguous in tons of cases. [11:03:01.0000] oh hey Hixie, until when are you around? [11:03:02.0000] Mm, that's true. [11:03:03.0000] woot, anne has returned! [11:04:00.0000] annevk: i'm at home with some virus or something [11:04:01.0000] Hixie: planning on looking into that multipage issue, but food is getting near [11:04:02.0000] annevk: so on and off depending on when i'm feeling better and when i'm out cold in bed [11:04:03.0000] A big problem there is that no one has written Box yet, and 2.1 is still overly vague. [11:04:04.0000] Hixie: oh, good luck with that [11:04:05.0000] i'll be fine [11:04:06.0000] Hixie: will take a look a little later (still going through email) and ping you again [11:04:07.0000] A big problem is that tons of different people are all writing different specs to bolt on features in different places and there's very little thought given to how they interact, because nothing is being done in a unified fashion. [11:04:08.0000] annevk: cool [11:05:00.0000] annevk: it looks like your end isn't fetching the spec [11:05:01.0000] annevk: at least, i don't get any hits for the spec when i ping your end [11:05:02.0000] I use svn update [11:05:03.0000] oh [11:05:04.0000] hm [11:05:05.0000] might be my fault then [11:05:06.0000] maybe i'm no longer updating something [11:05:07.0000] let me check [11:06:00.0000] nope, looks like the repo is up to date [11:06:01.0000] both complete.html and index (though tehy're identical now of course) [11:07:00.0000] man, i really need to add a mail filter to send anything matching (to:public-webapps subject:charter) to trash [11:08:00.0000] hmm a week out of date [11:12:00.0000] oh, dreamhost was hacked, had to reset my password [11:12:01.0000] they were hacked jan 21... spec stopped updating jan 24 [11:12:02.0000] hmm [11:15:00.0000] yeah i don't think the password change would have any effect [11:19:00.0000] and I'm in [11:22:00.0000] Hixie: fixed [11:23:00.0000] what was wrong? [11:23:01.0000] Hixie: same problem as last time, svn cleanup was required [11:23:02.0000] weird [11:23:03.0000] I put it in the cgi script now [11:23:04.0000] heh [11:23:05.0000] not sure if that'll help [11:25:00.0000] annevk: any idea what's causing svn cleanup to be needed? [11:26:00.0000] svn being locked while checking out maybe? not sure if that's possible, but it complaints about locking [11:26:01.0000] weird [11:31:00.0000] This is actually what *specs* do? [11:31:01.0000] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12539#c11 is still not fixed [11:31:02.0000] any idea jgraham ? [11:32:00.0000] Apparently the web wants isSameNode :( [11:32:01.0000] And GWT in particular [11:33:00.0000] annevk, ^ [11:34:00.0000] aah [11:34:01.0000] sad [12:03:00.0000] IE is shipping BlobBuilder? [12:03:01.0000] I thought we were going to kill that? :( [12:05:00.0000] WTF -- transform-origin parses differently in standards and quirks mode? [12:05:01.0000] Interoperably? [12:07:00.0000] transform-origin: 100 100 is interpreted as transform-origin: 100px 100px in quirks mode, but not standards mode . . . [12:07:01.0000] Is this an across-the-board difference in CSS parsing? If so, is it specced somewhere? [12:07:02.0000] TabAtkins, ^^ [12:07:03.0000] https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior ? [12:07:04.0000] ("The CSS parser interprets unitless numbers as px") [12:08:00.0000] (Oh, I misread "specced" as "documented") [12:08:01.0000] Seems interoperable. [12:09:00.0000] This should probably be in Values and Units. [12:09:01.0000] Oh, and I think we parse color: 000000 in quirks [12:09:02.0000] Quirks mode doesn't exist in CSS, though [12:10:00.0000] So it's only for styles that are inline in an HTML document? [12:10:01.0000] css compressors will be happy to hear this [12:11:00.0000] Ms2ger and color: fff too? [12:11:01.0000] Dunno [12:11:02.0000] AryehGregor, is it? I'm not sure [12:11:03.0000] /me also doesn't [12:13:00.0000] data:text/html,

displays a green box in IE/Chrome/Opera, but not Firefox. [12:14:00.0000] Hmm, attributes may go through another path [12:15:00.0000] Awesome. [12:21:00.0000] I think they should all go through the same path [12:21:01.0000] and I think we should define it [12:24:00.0000] /me just sent mail to www-style [12:28:00.0000] Hmm, ParseStyleAttribute does seem to check for quirks mode [12:30:00.0000] Seems like this should work... [12:32:00.0000] Aha [12:33:00.0000] AryehGregor, doesn't work for compound properties; color and background-color work [12:33:01.0000] Nice. [12:34:00.0000] Ah, and bz beat me to it [12:49:00.0000] so data URL rules when fetching data URLs through an HTTP API [12:49:01.0000] what would be the best place? [12:49:02.0000] XMLHttpRequest for now? [13:10:00.0000] gwt users blame Ms2ger that he deleted isSameNode [13:12:00.0000] I wonder why GWT uses isSameNode [13:34:00.0000] so what's HTTP/2.0? [13:34:01.0000] is it intended to be the new name for SPDY? [13:52:00.0000] I presume HTTP/2.0 will be where they take SPDY, make some backward-incompatible changes, and leave browsers with 3 protocols to implement [13:57:00.0000] reminiscent of Kafka [14:00:00.0000] <2400 [14:00:01.0000] (there was a lot of spam :( ) [14:04:00.0000] jgraham: sounds familiar... [14:10:00.0000] jgraham: I'm not sure SPDY has any legacy which prevents it from being dropped, though. [14:10:01.0000] why is http://tools.ietf.org/html/draft-ietf-websec-origin not linked to http://tools.ietf.org/html/draft-abarth-origin ? [14:11:00.0000] jgraham: Also Firefox already supports at least four already: HTTP, FTP, SPDY, and Gopher. [14:11:01.0000] annevk: and both should really point to http://tools.ietf.org/html/rfc6454 [14:11:02.0000] annevk: dunno. I think we'd need to ask someone at the IETF to add the links [14:12:00.0000] hober: yeah, the former does, but I found the latter via Google :/ [14:12:01.0000] annevk abarth: of course the ietf have always been so good about this sort of thing [14:13:00.0000] annevk: I can update the draft with a link if all else fails [14:15:00.0000] abarth: I guess I'll ask Julian if I remember [14:20:00.0000] gsnedders: I don't think that FTP or Gopher are functionally equivalent to HTTP. I mean Opera support SMTP but it's hardly comparable [14:23:00.0000] oh, by donating you become an EFF member? [14:24:00.0000] I wonder if I could have avoided that somehow [14:26:00.0000] should we add something to http://wiki.whatwg.org/wiki/MetaExtensions about emailing whatwg⊙wo for community review? [14:26:01.0000] as optional step of course [14:35:00.0000] only two sleeping spammers on the wiki since I left [14:35:01.0000] good times [14:35:02.0000] Oh hey, it's anne! [14:40:00.0000] "Obsolescence notices on old specifications, again" ooh [14:48:00.0000] ooh, there's a subthread on www-archive with the same name [14:48:01.0000] and no popcorn available [14:56:00.0000] does anyone know what the right way is to unpack a javascript float? i.e. to figure out the exact bits of the internal number? [14:56:01.0000] *internal representation [14:56:02.0000] You mean get at the actual repr of it? [14:56:03.0000] right [14:57:00.0000] Um, there's no built-in way to do so. [14:57:01.0000] sure. I'm just wondering what the best arithmetic to do is that won't introduce rounding errors or w/e [14:57:02.0000] You can probably achieve it through Typed Arrays, actually. [14:57:03.0000] gsnedders: yeah, but that doesn't help me in old browsers :) [14:57:04.0000] Then it's less easy :) [14:58:00.0000] gsnedders: and one thing I'm trying to do is test out the PRNGs behind Math.random(), just for my own edification [14:59:00.0000] I guess you just need to calculate the needed exponent and mantissa yourself. [15:00:00.0000] yeah. so in theory, if I have a number 0 < x < 1, repeatedly multiplying by 2 and sometimes subtracting 1 should avoid rounding problems, right? [15:01:00.0000] I'm nowhere near awake enough to think in that level of detail :) [15:01:01.0000] heh. boo [15:02:00.0000] :) [15:02:01.0000] Well, the exponent is such that you take log2, round-down. [15:03:00.0000] IEEE754 means you need to deal with the exponent bias. [15:03:01.0000] But then you should just be able to subtract Math.pow(2, exponent) from your value to get the mantissa, no? [15:04:00.0000] that's what I would expect [15:05:00.0000] but once I have the mantissa, that's still as a float. I should be able to pull out the bits w/ repeated [multiply by 2], [if > 1 then subtract 1] steps, right? [15:05:01.0000] And both the exponent and mantissa can be expressed exactly (both are less than 2^53), and Math.pow(2, exponent) is guaranteed to have a representation possible. [15:05:02.0000] jacobolus: Just x.toString(2) [15:06:00.0000] gsnedders: oh! didn't realize that one. [15:07:00.0000] gsnedders: I can just use x.toString(2) in general then [15:08:00.0000] jacobolus: Doesn't get you the actual repr of the float, though [15:08:01.0000] but it gives the exponent & mantissa [15:09:00.0000] jacobolus: It shouldn't. [15:09:01.0000] > (Math.pow(2, 51)+1.5).toString(2) [15:09:02.0000] "1000000000000000000000000000000000000000000000000001.1" [15:09:03.0000] For example [15:10:00.0000] that looks correct...? [15:10:01.0000] It's not the exponent and mantissa, though [15:10:02.0000] well, the exponent is however far the . is to the right [15:11:00.0000] and the mantissa is the value if we remove the . and strip leading 0s [15:11:01.0000] and if I read the ieee 754 spec I could figure out precisely how the bits of that are arranged [15:11:02.0000] jacobolus: That's not going to be in IEEE754 double format, though [15:12:00.0000] what do you mean? [15:12:01.0000] (where the mantissa has an implicit leading 1, effectively making it normalized) [15:12:02.0000] sure [15:12:03.0000] Or am I being stupid and half-asleep? [15:12:04.0000] (This seems quite plausible) [15:12:05.0000] (Seeming I am, in fact, half asleep) [15:12:06.0000] gsnedders: what I'm saying is I can deterministically figure out the representation from that, I think [15:12:07.0000] Right. [15:13:00.0000] but in any event, it's good enough for my purposes here [15:13:01.0000] gsnedders: interestingly, v8's Math.random() seems to only do 32 random bits? [15:13:02.0000] jacobolus: No idea. [15:13:03.0000] safari as well [15:14:00.0000] in theory they could do 53 random bits, right? [15:14:01.0000] for a number in (0, 1) [15:14:02.0000] (0, 1] [15:15:00.0000] [0, 1) [15:15:01.0000] is it (0, 1]? I was under the impression that they'd never produce 1. [15:15:02.0000] No, I'm just getting my brackets the wrong way around. [15:15:03.0000] gotcha [15:15:04.0000] What Philip` said. [15:15:05.0000] 0 <= x < 1, if you want the not incredibly confusing notation [15:15:06.0000] :) [15:16:00.0000] the notation is plenty readable to former math students :) [15:16:01.0000] gsnedders: thanks for the toString(2) lead. I for whatever reason thought that only worked for integers [15:19:00.0000] I believe at least SpiderMonkey uses an RNG equivalent to lrand48(), which returns 31 bits, but then it gets two random ints and shifts and adds to get a random double [15:20:00.0000] I think one difficulty with Math.random() is that if you change it to a higher quality RNG, you lose on critical-for-marketing benchmarks [15:20:01.0000] boo [15:20:02.0000] prngs like MWC are pretty fast though [15:21:00.0000] integrate randomness quality into the benchmarks? heh [15:21:01.0000] Philip`: but it's hard to imagine a case where actual calls to random() is the bottleneck. adding just a couple noop function calls seem to dramatically slow things down relative to calling random() bare [15:22:00.0000] as long as you're not doing anything stupid (like touching /dev/random) [15:22:01.0000] i.e. hard to imagine such cases in real code [15:22:02.0000] jacobolus: Never underestimate the ability of benchmark writers to write benchmarks whose bottleneck is nowhere like where they intended :-) [15:22:03.0000] heh. fair enough [15:23:00.0000] (especially since the bottlenecks change after the benchmarks are written) [15:23:01.0000] I guess what I mean is, doing `for (var i = 0, r = Math.random; i < 1e6; i++) { r(); };` seems like a relatively rare sort of occurrence [15:24:00.0000] if there's a benchmark along those lines, maybe it should be scrapped :) [15:24:01.0000] jacobolus: of course, a smart JIT would notice that Math.random() has no side-effects, and elide the whole damn thing :P [15:24:02.0000] A lot of Peacekeeper comes down to little more than that. [15:25:00.0000] c/c++ compilers definitely do that sort of thing [15:26:00.0000] (no clue if JS engines do) [15:26:01.0000] (guess it'd be easy enough to find out) [15:27:00.0000] I *think* V8 and SM should, but in V8's case it needs to be detected as hot-code to get the optimization done! [15:27:01.0000] chrome production doesn't, anyway [15:27:02.0000] well, not when pasting into the console [15:27:03.0000] gsnedders: of course, that's another problem with benchmarking JS :P [15:27:04.0000] was: re: stating the obvious [15:28:00.0000] zewt: It's optimization for hot-code should, at least. The problem is you have to run the non-optimized code first. :P [15:28:01.0000] zewt: Well, it's a problem with any JITing language. [15:28:02.0000] sticking it in a function and calling it a few times and it doesn't change, at least [15:28:03.0000] gsnedders: well, I'm blaming the naive benchmarks, not JS [15:28:04.0000] Try a few hundred :P [15:28:05.0000] gsnedders: is commented peacekeeper code easily accessible someplace? [15:28:06.0000] jacobolus: No. [15:28:07.0000] their site is kind of a mess [15:29:00.0000] shouldn't have to run an expensive function a few hundred times to get it to optimize :P not when calling the function takes over a second [15:29:01.0000] (increased to 1e7 so I could see the runtime clearly) [15:29:02.0000] jacobolus: The test frame just loads the same URL over and over again, and changes based on cookies :P [15:30:00.0000] how can people take a 21st century benchmark seriously that doesn't clearly show & explain what it's doing? [15:30:01.0000] Marketing. [15:31:00.0000] The perceived quality of a benchmark is entirely dependent on how pretty its graphs are [15:31:01.0000] (That's how I judge them, at least) [15:31:02.0000] Philip`: well are there any good benchmarks with shitty graphs that need help? [15:32:00.0000] I bet with a couple days effort it would be possible to make some damn pretty graphs [15:32:01.0000] use canvas or SVG, and if they aren't supported, just "sorry, your browser is so obsolete we can't even show you results" [15:33:00.0000] Kraken for example tests CSE quite heavily. [15:35:00.0000] (for var i = 0; i < 1000; i++) { foo[i] = Math.abs(foo[i] >> 1); bar[i] = foo[i] >> 1; } [15:35:01.0000] /me knows too little to know of any good benchmarks [15:35:02.0000] Is what you need to be quick on to be good on Kraken. [15:36:00.0000] gsnedders: "CSE"? [15:36:01.0000] jacobolus: common subexpression elimination [15:37:00.0000] ah, I see [15:37:01.0000] Also you need to be able to tell Math.abs is loop-invariant [15:37:02.0000] gsnedders: with the idea there being that foo[i] >> 1 can't be eliminated because foo[i] changes after the first time? [15:38:00.0000] jacobolus: Gah! No, switch the two statements in the block around. [15:38:01.0000] understanding const functions is a pretty fundamental optimization anyway, i'd expect [15:38:02.0000] (which means you have to be able to tell that Math.abs is the built-in pure one, and that foo[i] and bar[i] are data properties for all i) [15:39:00.0000] (because if they are accessor properties for any i then they could have side-effects and mutate Math.abs) [15:39:01.0000] sure [15:39:02.0000] i'd expect engines to optimize for functions like that not being mutated, and have an exception path if anything ever does ("fuck, throw everything jitted away and give up because someone did something horrible") [15:41:00.0000] Also if any are {valueOf:function(){return 1;}} because obv. you can do whatever in that function [15:41:01.0000] are there any "how fast can the jit do when we throw horrible stuff" tests? those would be fun to write [15:41:02.0000] and if someone creates benchmarks for performance when people do horrible things that break optimizations, they get shot in the head [15:41:03.0000] zewt: Ah, but the point is you don't want the branch for the exception path in the hot code. [15:41:04.0000] Oh, you mean just throwing out all generated code if something mutates such a thing? [15:41:05.0000] gsnedders: the branch would happen on assignment, not on access [15:42:00.0000] (putting aside how to do *that* efficiently) [15:42:01.0000] right [15:42:02.0000] zewt: That could be fun with OSR. [15:42:03.0000] with who? [15:42:04.0000] on-stack replacement [15:43:00.0000] Imagine you have generated code that assumes a built-in is a built-in, and then you change the built-in. [15:43:01.0000] right [15:43:02.0000] Everything higher up on the stack has to cope with this change. [15:43:03.0000] i'd think that would be an important assumption to be able to make [15:43:04.0000]