| 00:27 | <zewt_> | some aws stuff is designed around expecting low ttl always (on the order of ~60s) |
| 00:27 | <zewt> | it's a bit bizarre that apparently firefox still ignores TTL, even though it breaks anything hosted on amazon ELB |
| 00:33 | <caitp> | sounds like good material for a bug |
| 00:34 | <zewt> | https://bugzilla.mozilla.org/show_bug.cgi?id=151929 filed 12 years ago |
| 00:34 | <caitp> | nice |
| 00:36 | <caitp> | well, 12 years and no attachments shows some commitment :s |
| 00:36 | <zewt> | certainly a bigger bug today than it was then |
| 01:58 | <Hixie> | how do other browsers honour ttl if the OS doesn't expose it? |
| 02:08 | <zewt> | the OS DNS does handle ttl, but iirc firefox has its own caching layer that doesn't |
| 02:08 | <zewt> | if they're using the OS to do the underlying DNS and it doesn't expose TTL, then they either need to 1: not use the OS resolver at all to get the info or 2: lose the extra caching layer |
| 02:10 | <SamB> | zewt: might not be *totally* insane to cache for, say, a minute despite not knowing TTL |
| 02:11 | <zewt> | afaik they're caching for longer than that (five minutes or something) |
| 02:12 | <zewt> | amazon ELB instances have a ttl of around 45-60 seconds |
| 06:10 | <dbpokorny> | what's with all of the asm.js hate? |
| 06:11 | <dbpokorny> | why did everybody decide to put their head in the ground at exactly the same time? |
| 06:12 | <dbpokorny> | Why can't I put my MacDraw picture in the cloud? |
| 06:12 | <dbpokorny> | Why can't I put my HyperCard stack in the cloud? |
| 06:15 | <SamB> | dbpokorny: asm.js hate? |
| 06:15 | <SamB> | and what's this about not being able to store those files in the cloud ... ? |
| 06:18 | <dbpokorny> | For example "assembly is inherently incompatible with the web". This is the ultimate source of what is and is not web. |
| 06:18 | <SamB> | asm.js is probably not what they think |
| 06:19 | <dbpokorny> | I bring up MacDraw and HyperCard because they currently require pce.js to run, which requires asm.js. |
| 06:52 | <dbpokorny> | *sigh* so stuff like this "image decoding *can't* be done efficiently in script" |
| 06:52 | <dbpokorny> | I mean, it is being done in script. That train has left |
| 06:53 | <dbpokorny> | Are compiler writers so scarce that people simply believe language translation is not possible? |
| 06:53 | <SamB> | it is better if you can let the browser do it rather than insisting on wasting memory in every ... single ... tab |
| 06:54 | <dbpokorny> | I agree |
| 06:54 | <SamB> | okay, so no lecture about sharing code pages necessary then ;-) |
| 06:56 | <dbpokorny> | sharing code pages is very apt to this discussion |
| 06:57 | <SamB> | yes, but *you* already know about it so *I* don't need to bore you with the details that you already know |
| 06:57 | <dbpokorny> | Basically, I want to run libhfs.c in my browser |
| 07:01 | <dbpokorny> | The whole, "it hasn't been invented yet, it will never be invented" attitude is just...so early 90s |
| 07:01 | <dbpokorny> | "(People have been trying unsuccessfully to do that since day one of MMX, so it's irrelevant until the day it actually happens.)" |
| 07:02 | <SamB> | what, only since then? |
| 07:02 | <SamB> | and I thought MMX was late 90s ;-P |
| 07:02 | <dbpokorny> | lol you're right |
| 07:16 | <dbpokorny> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296960.html |
| 07:17 | <dbpokorny> | "platform-independent code with performance competitive with native SIMD assembly is a thing of myth" |
| 07:19 | <SamB> | it does sound kind of grail-ish |
| 07:20 | <dbpokorny> | yeah, but if you just turn over the coin, you see that all you have to do is define the algorithm namespace, check which algorithms/libraries you want, and hand the thing over to a compiler from 2050 |
| 07:20 | <dbpokorny> | everyone implements the same algorithms on new SIMD hardware |
| 07:21 | <dbpokorny> | unless, you know, you're IBM Almaden |
| 07:21 | <SamB> | the compiler from 2050 still has good sheduling support for the hardware of 2014 ? |
| 07:25 | <dbpokorny> | I don't follow. The image compression issue is latency-oriented |
| 07:40 | <dbpokorny> | but the greater issue is that there are only so many ways to design different scheduling schemes for hardware. With the web, it will be easier to share them, and then design compilers for historical SIMD hardware the same way we ask students to come up with proofs that every nonempty perfect complete metric space is uncountable |
| 12:30 | <gsnedders> | jgraham: I would like opinions from you on the Jython PR for html5lib. |
| 15:14 | <bkardell__> | slightlyoff: you around? |
| 15:20 | <slightlyoff> | Ish. In a cab. Whaddup? |
| 19:54 | <Ms2ger> | Domenic, you realize that breach.cc is basically Firefox, right? |
| 19:54 | <Domenic> | Ms2ger: Firefox has a Node.js core? |
| 19:54 | <Domenic> | The UI being in HTML/JS is not the interesting part |
| 19:55 | <Ms2ger> | The core is Chromium, afaict |
| 19:56 | <Domenic> | see "layer 3" and http://breach.cc/hack/ |
| 19:59 | <SamB> | what, firefox UI is in HTML now? |
| 20:00 | <Ms2ger> | XUL and bits of HTML |
| 20:11 | <zewt> | it's sort of neat how FF's view for directly viewing an image is just a built-in html page, I was able to attach a greasemonkey script to it to add better zooming support |
| 20:17 | <gsnedders> | zewt: doesn't everyone do that nowadays? |
| 20:18 | <SamB> | gsnedders: hasn't mozilla been doing that since before most of the other engines were even born? |
| 21:26 | <Hixie> | jorendorff: yt? |
| 21:26 | <Hixie> | jorendorff: any idea why the sticky headers on http://people.mozilla.org/~jorendorff/es6-draft.html no longer appear on chrome? |
| 21:27 | <Hixie> | maybe chrome dropped position:sticky? |
| 21:29 | <Ms2ger> | I think that may be correct |
| 21:29 | <jorendorff> | Hixie: Does it work for you here? http://html5-demos.appspot.com/static/css/sticky.html |
| 21:29 | <Ms2ger> | <insert wit about mobile performance> |
| 21:30 | <Hixie> | jorendorff: it does not |
| 21:30 | <Hixie> | jorendorff: you didn't use to use js or anything i take it |
| 21:30 | <jorendorff> | Hixie: no, just position:sticky |
| 21:31 | <jorendorff> | it says here "Support: Chromium 23.0.1247.0 with the --enable-experimental-webkit-features flag enabled via about:flags." |
| 21:32 | <Hixie> | ah maybe that's it |
| 22:26 | <zewt> | gsnedders: chrome's can't be affected by user scripts, as far as i could tell |
| 22:26 | <zewt> | though chrome basically removed support for user scripts (which forced me back to firefox) |
| 22:29 | <jamesr__> | Hixie, jorendorff: the experimental sticky support in chrome was ripped out recently |
| 22:30 | <Hixie> | ah |
| 22:30 | <Hixie> | k |
| 22:30 | <jamesr__> | it'll be added back when somebody (1) writes down what it is supposed to do and then (2) writes code that does that |
| 22:30 | <jamesr__> | (1)'s never really happened so it's pretty hard to have good code around |
| 22:30 | Hixie | nods |
| 22:31 | <jamesr__> | i think a mozilla intern was starting on it but didn't make it all the way. it's a worthwhile thing in a very long list of worthwhile things to pursue |