| 00:07 | <annevk> | http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0037/2008-09-17.html#topic5 |
| 00:41 | <Hixie> | i wonder where they got the idea that we dropped the repetition model |
| 00:42 | <Hixie> | i mean, we will, but i hadn't planned to do it until later |
| 00:42 | <Hixie> | i suppose i have already removed move-up and so forth |
| 00:48 | <hober> | Is anyone planning on observing any of the tag's 1.5 days of html5 discussion while @ tpac? |
| 00:55 | <Hixie> | oh these are tpac agenda items? |
| 00:55 | <Hixie> | i thought it was for their meeting next week |
| 00:55 | <hober> | oh |
| 00:55 | <hober> | yeah, didn't notice they had a separate f2f |
| 01:03 | <Hixie> | annevk: ok, made a table for you |
| 04:38 | <Hixie> | Lachy: i can't find any news about requiem for itunes 8 |
| 04:38 | <Hixie> | heard anything? |
| 05:39 | Hixie | installs freeenode just so he can see if there's an update |
| 05:39 | <Hixie> | apparently the guy is working on it |
| 06:43 | <Hixie> | wow |
| 06:43 | <Hixie> | http://www.w3.org/mid/c9e12660809172229u79084b7dv5d57e18e2834e5f6⊙mgc |
| 06:43 | <Hixie> | some people have issues |
| 06:44 | <Hixie> | and then there's this guy |
| 06:49 | weinig | boggles |
| 06:58 | <othermaciej> | Hixie: I actually replied to that - perhaps somewhat foolishly |
| 07:16 | <Hixie> | othermaciej: nice reply |
| 07:31 | <Lachy> | Hixie, no news about requiem yet, the project page on freenet says he's working on it. |
| 07:32 | <Hixie> | yeah i installed freenet to find that out |
| 07:32 | <Hixie> | :-) |
| 07:32 | <Hixie> | freenet is somewhat simpler to set up than it was four years ago |
| 07:32 | <Hixie> | but it's still a giant pain in the ass |
| 07:33 | <Hixie> | felt much faster though |
| 07:36 | <othermaciej> | what's requiem? |
| 07:36 | <Lachy> | there's a possibility that backing up the iTunes 7 key files, changing the path in the requiem source to use the backup instead and recompiling may work, however, I've been unable to test it because the free songs of the week have been iTunes Plus songs |
| 07:36 | <Lachy> | othermaciej, a utility for stripping FairPlay DRM from iTunes purchases |
| 07:37 | othermaciej | covers his ears lest hearing of such things leads him into sin |
| 07:38 | <othermaciej> | I generally avoid buying songs with DRM on them |
| 07:38 | <Lachy> | so do I, but videos aren't available with DRM yet |
| 07:38 | <othermaciej> | but the fact that non-iTunes stores can offer them now but not iTMS due to the labels being jerks kind of annoys me |
| 07:39 | <Hixie> | music isn't the problem, i'm happy to buy music at amazon |
| 07:39 | <othermaciej> | to the degree that it has reduced my level of music purchasing |
| 07:39 | <Hixie> | (though i do always check itunes first since it's so much easier) |
| 07:40 | <Hixie> | (and my girlfriend's reaction to hearing about requiem put me in a quandry -- "so... does that mean it's ok to buy songs from itunes that aren't tunes plus again?" |
| 07:40 | <Hixie> | i wasn't sure what to answer.) |
| 07:40 | <Lachy> | Hixie, another possibility is to just keep iTunes 7 on one machine, or even in a virtual machne, specifically for stripping DRM, and putting iTunes 8 on your other machines |
| 07:40 | <othermaciej> | I only check iTunes because I don't want to be party to the labels trying to blackmail it so they can reduce its market power and then reimpose DRM and add crappy pricing policies |
| 07:40 | hsivonen | notes that "international later this year" meant approximately two English-speaking countries |
| 07:40 | <hsivonen> | (for movie rentals) |
| 07:41 | <hsivonen> | I wonder if the unavailability of TV shows and movies over here is contractual stupidity or if Apple feels it couldn't sell untranslated content |
| 07:41 | <Hixie> | Lachy: right now i have a cron job that automatically decrypts videos each morning |
| 07:42 | <Lachy> | do you buy videos that frequently? |
| 07:42 | <Hixie> | Lachy: it would be way harder to do that if said job had to find encrypted data, move it to another partition, etc |
| 07:42 | <Hixie> | yes |
| 07:42 | <Hixie> | i watch stargate every week, and buy a couple of daily shows a week at laest |
| 07:43 | <Hixie> | and my girlfriend buys more for herself |
| 07:43 | <Hixie> | we have 718 tv shows on our main library |
| 07:43 | <Hixie> | and that doesn't include her latest stuf |
| 07:43 | <Hixie> | f |
| 07:43 | <Hixie> | (all bought from itunes) |
| 07:44 | <Hixie> | speaking of which i really should move her stuff to the main library |
| 07:44 | <hsivonen> | Hixie: I guess from daily show we can calculate the negative value you put on the ads of the free'online versions |
| 07:45 | <Hixie> | there are four things that make me get the (paid) itunes version over the (free) web version |
| 07:46 | <Hixie> | 1. the paid version is a standalone MPEG, and thus can be viewed offline, viewed on my ipod, viewed over a network on a remote itunes install, etc. |
| 07:46 | <Hixie> | (whereas the free version is stuck in a browser in a flash container) |
| 07:46 | <Hixie> | 2. the free version has ads. |
| 07:47 | <Hixie> | 3. the free version has unskippable content. |
| 07:48 | <Hixie> | 4. the paid version is much easier to obtain (the itunes store is easier to navigate than the web site, possibly because when i want to watch tv i'm usually already in itunes, and not looking at a web site) |
| 07:49 | <hsivonen> | #4 doesn't look good for the open web :-) |
| 07:49 | <Hixie> | if itunes had a free version with ads embedded, but otherwise was the same as now (ads skippable, no restriction on use, etc) i would probably watch that instead of the paid one |
| 07:49 | <Hixie> | 4 is not a technology issue |
| 07:49 | <Hixie> | someone could make a web version of the itunes store |
| 07:50 | <Hixie> | sadly the state of ui design on the web is generally horrific |
| 07:50 | <Lachy> | for that to happen, you would have to convince the marketing dept. that allowing users to skip ads won't reduce the number of people that pay attention to them anyway |
| 07:51 | <othermaciej> | eventually the ads will have to be embedded as an intrinsic part of the content |
| 07:51 | <othermaciej> | so that you cannot skip them even mentally |
| 07:51 | <othermaciej> | (i.e. product placement) |
| 07:51 | <othermaciej> | some of the best Apple ads are seeing flashes of brushed aluminum cases on the teevee |
| 07:52 | <hsivonen> | Lachy: you really can't miss the ads in the free version. they are so repetitive. |
| 07:52 | <Lachy> | I'm don't even know what the daily show is |
| 07:53 | <Lachy> | is this the one? http://www.thedailyshow.com/ |
| 07:53 | <hsivonen> | Lachy: yes |
| 07:54 | <Lachy> | ok, I've seen a few clips of that on youtube before |
| 07:59 | <othermaciej> | Hixie: see, I knew I shouldn't have replied |
| 07:59 | <Hixie> | the daily show is arguably the best (and one of only a few) political satire shows in the US |
| 08:00 | <othermaciej> | it's a satire? |
| 08:00 | <Hixie> | well, maybe satire is wrong |
| 08:00 | <Hixie> | colbert is satire |
| 08:00 | <Hixie> | daily show is probably just straight comedy |
| 08:01 | <Hixie> | it is very tame compared to european political comedy (e.g. have i got news for you, john bird and john fortune, etc) |
| 08:01 | <Hixie> | but sadly it's all we've got really |
| 08:01 | <Lachy> | if it's mostly political stuff, I'll avoid it. I have no interest in US politics, even though I hear about it from so many places already |
| 08:02 | <Hixie> | yeah if you don't care about US politics the daily show (and colbert) isn't for you |
| 08:03 | <Lachy> | I don't care about politics in general, regardless of what country it is. |
| 08:38 | <annevk> | colbert is awesome |
| 08:44 | <Hixie> | colbert is ok |
| 08:44 | <Hixie> | but he gets repetitive |
| 08:44 | <Hixie> | and shouts a lot |
| 08:44 | <annevk> | i haven't seen too much of him |
| 08:44 | <annevk> | mostly the white house thingy and that's great |
| 08:44 | <othermaciej> | he is personally funnier than John Stewart |
| 08:44 | <othermaciej> | but his show can be uneven |
| 08:44 | <othermaciej> | IMO |
| 08:44 | <Hixie> | annevk: i've got 22.4 horus of him in my itunes library :-) |
| 08:45 | <Hixie> | othermaciej: agreed |
| 08:45 | <Hixie> | hours |
| 08:55 | <annevk> | wow, garrett smith lost it again |
| 09:01 | <othermaciej> | annevk: I don't think he ever found it |
| 09:01 | <annevk> | hmm, is Mozilla gaining a second XHR? https://bugzilla.mozilla.org/show_bug.cgi?id=450452 :/ |
| 09:02 | annevk | wonders what happened to the days when they tried to follow standards |
| 09:17 | <hsivonen> | annevk: isn't XHR without the DOM what was the plan for workers? |
| 09:18 | <othermaciej> | we're going to do the same for workers |
| 09:18 | <othermaciej> | I think most would agree it is the right thing to do |
| 09:19 | <hsivonen> | is everyone going to call it XMLHttpRequest for compatibility, though? |
| 09:22 | <annevk> | hsivonen, Web Workers has a nicer solution for that |
| 09:23 | <hsivonen> | annevk: http://www.whatwg.org/specs/web-workers/current-work/#interface |
| 09:23 | <hsivonen> | annevk: what am I missing? |
| 09:24 | <annevk> | hmm ok, Mozilla does seem to call it XMLHttpRequest as seen from code |
| 09:24 | <annevk> | maybe I'm missing something |
| 09:25 | <annevk> | hsivonen, it seemed to me that doing what Web Workers defined was simpler than having a second XHR impl |
| 09:26 | <annevk> | lots of duplicate code now |
| 09:26 | <annevk> | which basically means you have to run the testsuite in both contexts I suppose in some way |
| 09:27 | <othermaciej> | should not be hard to make a Workers version |
| 09:28 | <hsivonen> | annevk: wasn't it the expectation that C++-based browsers would have to duplicate some code? |
| 09:28 | <annevk> | I missed that discussion I'm afraid |
| 09:32 | <annevk> | in somewhat related news, this, together with native JSON support in XHR and postMessage in due course, will kill XML even more |
| 09:34 | <hsivonen> | it seems to me that the document-oriented stuff is gravitating back towards HTML and the data oriented stuff is going to JSON |
| 09:35 | <hsivonen> | however, doing document fragments over JSON sucks |
| 09:35 | <hsivonen> | it's like RSS all over again |
| 09:35 | <aboodman> | having a DOMParser and XMLSerializer in workeres seems useful to me |
| 09:35 | <aboodman> | but everyone said it was hard |
| 09:36 | <hsivonen> | I renew my prediction that someone will create a pure-JS DOMParser and DOM for workers |
| 09:37 | <annevk> | people have already created complete DOM wrappers without workers :) |
| 09:38 | <othermaciej> | it would not be as hard if one were willing to make every single worker a separate process |
| 09:38 | <hsivonen> | annevk: has anyone written a conforming XML parser (not regexp hack) in JS yet? |
| 09:38 | <othermaciej> | but I think that is kind of expensive |
| 09:38 | <hsivonen> | othermaciej: or if one were willing to develop a second DOM impl in C++ |
| 09:39 | <othermaciej> | well but that's a lot of work |
| 09:39 | <Hixie> | i don't understand why dom implementations have to require locking to be thread safe |
| 09:39 | <othermaciej> | probably even more than making the DOM threadsafe at least at the separate document level |
| 09:39 | <Hixie> | what global state is there? |
| 09:39 | <roc> | caches |
| 09:39 | <othermaciej> | the global state is not intrinsic in the spec |
| 09:39 | <Hixie> | so long as you can never pass a dom node to another thread, what's the concern? |
| 09:39 | <othermaciej> | caches, global resource pools |
| 09:39 | <roc> | atomized strings and other objects |
| 09:39 | <othermaciej> | that kind of thing |
| 09:39 | <othermaciej> | I bet the set of things is similar in Gecko and WebKit |
| 09:40 | <Hixie> | atomised strings seem like they'd be trivial to make threadsafe, given that they're readonly |
| 09:40 | <othermaciej> | I bet furthermore that most people know the likely suspects but not all of them |
| 09:40 | <Hixie> | though i guess you need locking to create them |
| 09:40 | <othermaciej> | the hashtable used to atomize is not read-only |
| 09:40 | <othermaciej> | or are the refcounts read-only |
| 09:40 | <hsivonen> | roc: aren't nsIAtoms thread safe already? |
| 09:40 | <Hixie> | ah, if they have bound lifetimes, sure |
| 09:40 | <aboodman> | roc: how much of xhr impl is going to be shared between the worker and nonworker variants? |
| 09:40 | <Hixie> | though ref counting atoms seems like an unnecessary cost |
| 09:40 | <Hixie> | but what do i know |
| 09:41 | <othermaciej> | you'd also have to make sure the Worker DOM can never ever load external resources |
| 09:41 | <roc> | aboodman: no idea! |
| 09:41 | <othermaciej> | or you just pulled the cache in |
| 09:41 | <aboodman> | seems like an opp for bugs. |
| 09:44 | <roc> | hsivonen: I don't believe so |
| 09:45 | <roc> | you could make all the global storage for DOM optimizations thread-local. No idea what the performance hit would be |
| 09:45 | <aboodman> | we could add the x later |
| 09:45 | <aboodman> | it just seems silly to call it xhr initially, when there is no x involved :) |
| 09:45 | <hsivonen> | roc: ok. I thought they were thread safe and someone suggested making them not thread safe for perf |
| 09:45 | <aboodman> | maybe we should add the api now, and just have it throw not implemented? |
| 09:47 | <roc> | hsivonen: it looks like that suggestion was implemented last year :-) https://bugzilla.mozilla.org/show_bug.cgi?id=387445 |
| 09:47 | <annevk> | aboodman, the name is just an historical artifact |
| 09:47 | <hsivonen> | which process are Gears workers in when a Chrome WebKit process spawns one? |
| 09:47 | <aboodman> | all plugins (including gears) run in their own process |
| 09:48 | <hsivonen> | roc: ok. so my memory isn't completely broken but I'm behind the times |
| 09:48 | <aboodman> | annevk: i know, but now it is getting even sillier. |
| 09:48 | <hsivonen> | aboodman: per-plugin instance process or a shared plug-in host process? |
| 09:49 | <roc> | aboodman: is it true that V8 can only instantiate one single-thread JS runtime per process? |
| 09:49 | <annevk> | aboodman, just think of it as "URLRequest" |
| 09:49 | <aboodman> | annevk: heh, ok. |
| 09:49 | <roc> | hsivonen: I had to look it up --- my memory *is* completely broken |
| 09:49 | <roc> | well not really. It's just full. |
| 09:50 | <aboodman> | roc: not really, i mean, workers all run in threads in one process. |
| 09:50 | <aboodman> | but, the locking is rather coarse. |
| 09:50 | <aboodman> | i think they are working on making it finer. |
| 09:51 | <roc> | so no concurrent JS execution? |
| 09:51 | <aboodman> | i don't think so. i'm not super familiar with it. |
| 09:51 | <aboodman> | i believe right now it only yields at io. |
| 09:52 | <roc> | ok, that's what I heard. It seemed strange given that Workers have been on the radar for a while |
| 09:53 | <aboodman> | yeah, maybe something that just hasn't been tackled yet. |
| 09:53 | <aboodman> | i mean, workers aren't 'on the radar' for us |
| 09:53 | <aboodman> | they actually exist |
| 09:54 | roc | wonders how long it will be before JS engines are competing on scalability across stupidly-large numbers of processor cores |
| 09:54 | <roc> | yeah, exactyl |
| 09:54 | <roc> | which is why I was suprise |
| 09:54 | <roc> | d |
| 09:55 | <annevk> | it would be nice if the <canvas> API worked in a thread |
| 09:55 | <annevk> | so you can create fractals and then pass them over when they're done :) |
| 09:55 | <hsivonen> | is there a document that explains the interfaces between Gears and the host browsers and what Gears reimplments and what it reuses? |
| 09:55 | <aboodman> | freaking france. |
| 09:56 | <aboodman> | so i just did a quick test on chrome and i got concurrent js execution |
| 09:56 | <roc> | annevk: you can fill up a string with encoded values |
| 09:56 | <Philip`> | V8 does look like it supports multithreading, since it's got a load of references to the word "thread" and mutexes and things |
| 09:56 | <aboodman> | so i'm not sure, maybe they have already improved it |
| 09:56 | <aboodman> | or maybe they interleave the pumps of the message queue |
| 09:57 | <othermaciej> | last I heard, V8 only supports semi multithreading with one thread running at a time but the potential to ield around I/O |
| 09:57 | <othermaciej> | aboodman: how does Gears take over the network layer in Chrome btw? |
| 09:58 | <aboodman> | there is an extension to npapi |
| 09:58 | <aboodman> | called cpapi |
| 09:58 | <annevk> | roc, true, though having something like, canvas = new DOMCanvas(w, h) that supports the same as <canvas> might be nice |
| 09:58 | <othermaciej> | annevk: then you'd need a threadsafe way to pass over the image data |
| 09:58 | <othermaciej> | so it would have to be either full copy or copy in write |
| 09:58 | <annevk> | othermaciej, data URLs |
| 09:58 | <Philip`> | Most of the non-pointless computation-intensive worker uses (e.g. computing fractals) seem to involve quite large amounts of IO between the worker and main thread, which doesn't sound exactly great for performance |
| 09:59 | <aboodman> | hsivonen: i don't understand the question |
| 09:59 | <othermaciej> | annevk: encoding and decoding data URLs is weak sauce for large images |
| 10:00 | <roc> | aboodman: hmm, see http://groups.google.com/group/v8-users/browse_thread/thread/482575a1186e8cba/855fef2fa7de58b8?lnk=gst&q=thread#855fef2fa7de58b8 |
| 10:00 | <othermaciej> | Philip`: you just need an efficient way to transfer a large buffer when the worker is done |
| 10:00 | <othermaciej> | probably some sort of ByteArray w/ underlying threadsafe copy-on-write when transferred |
| 10:00 | <Hixie> | othermaciej: if we wanted to design for this, we could define a way for an object to be transferred, just like we do with message ports |
| 10:01 | <Hixie> | othermaciej: i don't think off-thread image construction is a critical case though |
| 10:01 | <othermaciej> | there's no good way to represent generic binary data right now anyway |
| 10:01 | <othermaciej> | something to think about as we try to add binary data to the platform |
| 10:01 | <hsivonen> | aboodman: is there a document that explains the integration to the host browser, like APIs used, etc.? |
| 10:01 | <aboodman> | roc: watching the behavior (not looking at the code), my guess is that there is a lock around every message queue dispatch on any thread. |
| 10:02 | <aboodman> | so only one thread is running at a time |
| 10:02 | <aboodman> | does not take advantage of multicore :( |
| 10:02 | <othermaciej> | JavaScriptCore can actually run JS code on multiple threads in parallel |
| 10:02 | <aboodman> | i think this will eventually improve |
| 10:02 | <othermaciej> | and our Worker implementation in WebKit will do so |
| 10:02 | <roc> | so does Spidermonkey/TM |
| 10:02 | <aboodman> | othermaciej: what can i say, you guys rox |
| 10:02 | <othermaciej> | presumably the V8 likely reimplementation will have to back that out and add locking and stuff |
| 10:03 | <aboodman> | othermaciej: why? |
| 10:03 | <hsivonen> | roc: is the name of the whole engine going to stay as spidermonkey or is tracing so big a deal that the name of the engine is changing to tracemonkey? |
| 10:03 | <roc> | no idea |
| 10:03 | <othermaciej> | aboodman: well unless V8 is able to run JS code on multiple threads concurrently for real by then |
| 10:03 | <aboodman> | hsivonen: no, sorry |
| 10:03 | <othermaciej> | though I did not get the impression that this was in any way planned |
| 10:03 | <hsivonen> | aboodman: ok. :-( |
| 10:03 | <aboodman> | hsivonen: did you have a specific question? |
| 10:04 | <roc> | Spidermonkey can actually share arbitary JS objects between threads, which as far as I can tell is pretty stupid |
| 10:04 | <othermaciej> | that is kind of stupid |
| 10:04 | <othermaciej> | JSC can't |
| 10:04 | <othermaciej> | our threading is designed for full concurrency in the shared-nothing message-passing style case |
| 10:04 | <hsivonen> | aboodman: I have two: Does Gears reuse the host JS engine. And why does Gears show up on the list of NPAPI plug-ins if it's not one (or is it)? |
| 10:04 | <aboodman> | othermaciej: can't we just add a #if USE(V8) or something that waits for a lock before pumping messages? |
| 10:04 | <aboodman> | to webcore |
| 10:04 | Philip` | uses SpiderMonkey in multiple threads but has a completely separate runtime in each |
| 10:05 | <aboodman> | it seems like a pretty minor change |
| 10:05 | <roc> | I think I heard that there are certain Spidermonkey embedders that depend on that feature :-( |
| 10:05 | <aboodman> | hsivonen: let's take this into private chat to avoid annoying people |
| 10:06 | <othermaciej> | aboodman: I do not get what you mean |
| 10:06 | <othermaciej> | what I was trying to say is that WebKit |
| 10:06 | <othermaciej> | 's workers will support execution of JS on multiple threads concurrently for real |
| 10:06 | <roc> | BTW, the best way to compute fractals I've seen is to run them on the GPU with Vlad's Canvas3D :-) |
| 10:06 | <othermaciej> | but likely not the V8 version when/if Google reimplements it using V8 |
| 10:07 | <roc> | Mandelbrot and other per-pixel iterators, anyway |
| 10:07 | <othermaciej> | since V8 can't support actually running actual code in parallel, it only does coop threads effectively |
| 10:07 | <Philip`> | roc: Only if by "best" you don't mind being incompatible with most people's GPU hardware :-) |
| 10:08 | <roc> | yeah yeah |
| 10:09 | <othermaciej> | shader languages are a good way to do it |
| 10:09 | <othermaciej> | most modern machines can support them |
| 10:09 | <othermaciej> | but |
| 10:09 | <othermaciej> | I don't think there is a safe way to expose that capability to untrusted code from the Web |
| 10:09 | <othermaciej> | (other than as canned effects) |
| 10:09 | Philip` | 's first attempt at Canvas3D code only worked on NVIDIA on Windows, and failed on OS X because the drivers lacked a GLSL bug |
| 10:10 | <aboodman> | sorry, i am at a conference and the network sucks here. |
| 10:10 | <roc> | I think in principle, untrusted shaders should be OK |
| 10:10 | <roc> | in practice, drivers probably suck and crash in exploitable ways |
| 10:11 | roc | hasn't been able to find someone with the cycles to do that testing |
| 10:11 | <Philip`> | The current Canvas3D implementation seems to basically ignore the whole exploitability protection thing |
| 10:12 | <roc> | yep |
| 10:12 | <roc> | well |
| 10:12 | <roc> | it "makes optimistic assumptions" |
| 10:12 | <Philip`> | Like it assumes the content is not hostile? :-) |
| 10:13 | <roc> | again, in principle shaders can't read or write to system memory and errors should be trapped by the driver |
| 10:13 | <Philip`> | Some of my non-hostile content ended up getting random bytes of stack data from a function call :-( |
| 10:13 | <roc> | but we sure aren't enabling it for Web content by default without a lot more analysis |
| 10:14 | <aboodman> | othermaciej: yes, workers in chrome won't support true js concurrency until v8 does. |
| 10:16 | <Philip`> | There are enough differences in shader implementations between drivers that even if it was perfectly secure, it seems a really bad idea for interoperability - I don't want sites to require NVIDIA hardware, and I don't want to write sites myself that I can only test on NVIDIA and that totally break on other hardware |
| 10:18 | <roc> | I presuppose a future where drivers are less buggy |
| 10:18 | <roc> | but maybe "shaders" are a dead end and we'll just have different kinds of "cores" to run C code on |
| 10:18 | <hsivonen> | Philip`: Apple had some OpenGL extensions that were supposed to abstract away nvidia/ati/intel difference. do those extensions really work so that the user won't notice? |
| 10:19 | <annevk_m> | Hixie, should Password allow list=""? |
| 10:19 | <roc> | GL doesn't need extensions to abstract away differences |
| 10:19 | <othermaciej> | I would guess to the extent drivers consider security, it is in terms of protecting the kernel and privileged processes from normal apps |
| 10:19 | <roc> | there's already a common shader langauge |
| 10:19 | <roc> | it's just implemented poorly |
| 10:19 | <othermaciej> | not protecting normal apps from programs they run on the GPU |
| 10:20 | <othermaciej> | that being said many drivers have bugs whereby doing certain things could take the system down |
| 10:22 | <hsivonen> | has anyone tried to come up with a canvas 3d abstraction that was in between the Opera and Mozilla levels of closeness to OpenGL? |
| 10:23 | <Philip`> | roc: Have you seen Larrabee? (which is Intel's idea of sticking a load of fast Pentium cores with 512-bit SIMD onto a chip, and then just writing graphics rendering software in C (or whatever language you want) and running it on there) |
| 10:23 | <roc> | I haven't actually seen one no |
| 10:23 | <roc> | I know about it |
| 10:24 | <roc> | hsivonen: if you want to support GPU programming then you need a language to write those programs in |
| 10:24 | <roc> | it's unclear why you'd want to create a new language rather than choose an existing one |
| 10:25 | <hsivonen> | roc: ideally, one wouldn't want a new language, but there seems to be a need for sandboxing capabilities |
| 10:25 | <roc> | there isn't really |
| 10:26 | <roc> | GLSL doesn't provide any facilities to access system memory or execute arbitrary code |
| 10:26 | <hsivonen> | though I admit I don't really know anything about modern OpenGL shaders |
| 10:26 | <hsivonen> | I haven't programmed anything with OpenGL in 6 years |
| 10:27 | <hsivonen> | would it be feasible for a browser to sanitize shaders? or are the bugs underneath too crazy? |
| 10:28 | <roc> | if the problems are all driver bugs, it's not clear how you sanitize against that |
| 10:28 | <roc> | maybe you can parse the code and re-emit it in some clean format to protect against driver parser issues |
| 10:29 | <roc> | maybe add some simple resource limits |
| 10:29 | <roc> | I dunno |
| 10:29 | <Philip`> | When you've parsed the code you can also check that e.g. all the external function calls are valid standard ones |
| 10:31 | <roc> | I guess so |
| 10:31 | <roc> | I don't know what kind of dangerous external function calls there might be |
| 10:31 | <roc> | you obviously can't call regular functions |
| 10:34 | <Philip`> | I'm just thinking about interoperability again, e.g. if someone calls the function "clamp" then complain because it shouldn't exist even if the GL driver accepts it |
| 10:35 | <roc> | good point |
| 10:36 | <Philip`> | There's also the issue that not all implementors want to use GL (because e.g. on Windows the DirectX drivers are better, and on some devices (like consoles) there isn't quite an OpenGL implementation at all) |
| 10:36 | <roc> | yeah |
| 10:36 | <Philip`> | and translating GLSL programs into HLSL is not the most desirable of things to do |
| 10:37 | <roc> | but that gets back to the issue where if you're going to have a language, what do you do? |
| 10:37 | <roc> | implementing GLSL on D3D may suck, but does it suck more than implementing a new language on every stack? |
| 10:37 | <Philip`> | (and using something unstandardised like Cg is probably not a good idea either) |
| 10:38 | <othermaciej> | OpenCL! |
| 10:38 | <Philip`> | I don't really want OpenCL in a browser :-p |
| 10:40 | <hsivonen> | is there a sound techincal reason for D3D to exist or is it just a strategy thing? |
| 10:40 | Philip` | isn't sure how to nicely do anything except not have programmable shaders, which would be quite annoying |
| 10:40 | <othermaciej> | hsivonen: OpenGL is not sufficiently technically capable of excluding Microsoft's competition |
| 10:41 | <Philip`> | hsivonen: OpenGL has too much legacy cruft and too many users who don't want it to make their 15-year-old CAD programs stop working, so it's poorly suited to modern hardware and very hard to fix |
| 10:42 | <othermaciej> | same kind of technical reasons as there are behind C#, VC-1, Managed C++, Silverlight, and other such sterling Microsoft technical initiatives |
| 10:42 | <Philip`> | or at least that's what people were saying when OpenGL 3.0 turned out to be really boring |
| 10:42 | <aaronlev> | hsivonen: have you thought about integrating validator.nu into tools like Komodo or Eclipse, for source-level error highlighting as you type? |
| 10:44 | <hsivonen> | aaronlev: It has occurred to me that it could be done, but I don't have concrete plans of doing it myself |
| 10:50 | <roc> | ah, the solution is staring us in the face |
| 10:50 | <roc> | we should write Web shaders in JS |
| 10:53 | <Hixie> | annevk2: no, but i've already fixed the spec |
| 10:54 | <Hixie> | i wonder what julian had in mind (re his latest e-mail) |
| 10:55 | <othermaciej> | I would love to have validator.nu support in the WebKit Web inspector |
| 10:55 | <othermaciej> | wonder if xenon can be convinced |
| 10:55 | <othermaciej> | but we might need error messages in a good machine-parsable format to display them nicely, if we want to do more than just send you to the results page |
| 10:57 | <hsivonen> | Hixie: resolving issues according to calendar? |
| 11:05 | <hsivonen> | othermaciej: does out=xml, out=gnu or out=json count as a good machine-parseable format? |
| 11:06 | <othermaciej> | hsivonen: dunno, have not studied any of those, but they might well be |
| 11:06 | <Philip`> | roc: I'm not entirely sure how you'd implement e.g. eval() on a GPU |
| 11:06 | <hsivonen> | the validator.nu vim integration uses out=gnu, AFAIK |
| 11:06 | <Philip`> | and I don't think we'll convince the GPU manufacturers to design a hardware implementation of a JS interpreter |
| 11:07 | <Philip`> | although it'd be pretty cool if we did |
| 11:08 | <Philip`> | It'd be the obvious evolution of the current JS performance increases |
| 11:08 | <hsivonen> | Philip`: wouldn't their HW impl have the same expected level of bugs as the current shader lang impl? |
| 11:10 | <Philip`> | hsivonen: No, since they would be designing it to be used by JS programmers (who are often incompetent or malicious), whereas current shader languages are designed to be used (indirectly) by C programmers (who are also often incompetent or malicious but already have complete user-space access to the machine so it doesn't matter if you give them a few more ways to crash) |
| 11:11 | Philip` | wants a JS engine that JITs to Verilog |
| 11:15 | <Hixie> | hsivonen: resolving how? |
| 11:16 | <hsivonen> | Hixie: forcing a decision maybe. I don't know. |
| 11:16 | Philip` | notes that someone already suggested allowing something like ctx2d.globalCompositeOperation = function (src,dest) { ... } |
| 11:20 | <Hixie> | hsivonen: if he has something that he thinks is high priority, why doesn't he just tell me what it is? |
| 11:21 | <annevk2> | seems hard for hsivonen to answer that question |
| 11:21 | <Hixie> | yeah |
| 11:21 | <Hixie> | it was mostly rhetorical |
| 11:22 | <annevk2> | as for DanC, I think he believes certain issues have been discussed in enough detail and can be closed after the WG has made a decision |
| 11:23 | <annevk2> | at least, that's the impression I get from telcons |
| 11:27 | <othermaciej> | I didn't read Chris's response to my flamage because I am worried it will piss me off more and I am close to my monthly stress quota |
| 11:27 | <othermaciej> | (about deciding things in telecons) |
| 11:31 | <Hixie> | i don't recall it being worthy of such worry |
| 11:37 | <annevk2> | ah, http://dev.chromium.org/developers/design-documents/dns-prefetching explains the <meta name=dns> feature |
| 11:39 | <annevk2> | (which was killed in http://html5.org/tools/web-apps-tracker?from=1538&to=1539 fwiw) |
| 11:39 | <Hixie> | actually the two are unrelated |
| 11:40 | <Hixie> | well, they're both caused by content teams within google lamenting the slow speed of dns |
| 11:41 | <othermaciej> | you mean "unrelated" as in they do different things, or unrelated as in you had a similar idea totally by coincidence? |
| 11:41 | <Hixie> | but the feature that was in html5 and the feature in chrome weren't developed in tandem |
| 11:41 | <Hixie> | othermaciej: so neither, in answer to your question |
| 11:42 | <Hixie> | othermaciej: the idea was had due to the same impetus, and they do similar things, but they weren't caused by each other |
| 11:42 | <othermaciej> | mmmkay |
| 11:42 | <Philip`> | Web servers should parse the HTML they're serving, and pre-resolve all the DNS names into IPs before sending it to the browser |
| 11:42 | <Hixie> | (though i did advise the chrome team on their dns prefetching feature) |
| 11:42 | <othermaciej> | I think dns prefetch will be merged to mainline WebKit at some point but the initial patch had some implementation issues |
| 11:42 | <annevk2> | the <meta> hack on that page looks terrible |
| 11:43 | <othermaciej> | in that it hooked DNS prefetch into the style system |
| 11:43 | <Hixie> | annevk2: how so? it's just doing the same thing as the http header |
| 11:44 | <Hixie> | oh wow, the example suggests you can interleave <meta> and <a>, that's crazy |
| 11:44 | <Hixie> | i wonder who came up with that |
| 11:44 | <annevk2> | Hixie, are those four separate examples or one example were the <meta> affects the preceding link? |
| 11:44 | <othermaciej> | ah, looks like it is being rewritten |
| 11:44 | <Hixie> | aboodman2: dude, we should fix that |
| 11:44 | <Hixie> | and by "we" i mean "you" :-P |
| 11:44 | <othermaciej> | <https://bugs.webkit.org/show_bug.cgi?id=20690>; for those playing along at home |
| 11:45 | <annevk2> | if we're going to have this feature can't we drop the x from the start? |
| 11:46 | <Hixie> | i told them to put the x- in so that people wouldn't think google was trying to take over http or anything |
| 11:47 | <Hixie> | i also told them they should bring it up in the httpwg |
| 11:47 | <Hixie> | dunno if they have done that yet |
| 11:47 | <zcorpan_> | hsivonen: doesn't http://c.validator.nu/all/ include http://c.validator.nu/usemap/ ? |
| 11:48 | <annevk2> | Hixie, fair enough |
| 12:05 | <hsivonen> | zcorpan_: according to code, it should. is there behavior that suggests otherwise? |
| 12:06 | <zcorpan_> | hsivonen: the about page says otherwise |
| 12:06 | <hsivonen> | zcorpan_: oops. thanks |
| 12:12 | <hsivonen> | zcorpan_: fixed. thanks |
| 12:40 | <zcorpan_> | http://www.w3.org/2007/09/19-xhtml-minutes.html#action09 |
| 12:40 | <zcorpan_> | hmm, so parsing <script> as CDATA in text/html is a bug? |
| 12:41 | <annevk2> | haha |
| 12:43 | <Lachy_> | zcorpan_, no, that doesn't appear to be what they're saying |
| 12:44 | <Lachy_> | since this mail that they're referring to is talking about XHTML http://lists.w3.org/Archives/Public/www-html-editor/2007JulSep/0031 |
| 12:44 | <zcorpan_> | Lachy_: "The example 'correct' code in sec. 4.8 does not work in either Firefox or IE" clearly means he tested text/html |
| 12:45 | <Lachy_> | yeah, but it's XHTML, so it shouldn't be using text/html, so that's irrelevant |
| 12:45 | <Lachy_> | it's correct without having to comment out the <![CDATA[ and ]]> markers |
| 12:45 | <zcorpan_> | so their reply should be "you're using text/html, the spec is talking about how to do it in xml", not "that's a bug in browsers that should be fixed and not documented in our spec" |
| 12:46 | <Lachy_> | yeah |
| 12:53 | <zcorpan_> | grddl discussion a bit up is interesting -- profile isn't good enough for xhtml2 |
| 12:55 | <hsivonen> | Validator.nu shows bad-looking all-thread locking. |
| 12:56 | hsivonen | goes investigate whether it's locking at shared IO points or something easily fixable |
| 13:04 | <annevk2> | zcorpan_, please complain when you get the reply as we consider it to be feature, not a bug |
| 13:09 | <zcorpan_> | annevk2: i don't follow |
| 13:11 | <hsivonen> | I was a bit worried about today already being the 19th until I noticed that the minutes were a year old |
| 13:16 | <annevk2> | ooh |
| 13:16 | <annevk2> | I thought that was recent minutes discussing zcorpan_'s comments |
| 13:16 | <annevk2> | doh |
| 13:24 | <zcorpan_> | hmm i thought they were recent too |
| 13:25 | <zcorpan_> | http://lists.w3.org/Archives/Public/public-xhtml2/2008Sep/0014.html |
| 13:26 | <zcorpan_> | (link at the bottom) |
| 16:30 | <zcorpan_> | setAttributeNode(document.createAttribute('aB:c')) throws in webkit |
| 16:32 | <zcorpan_> | "These methods (but not their namespaced counterparts) must compare the given argument in an ASCII case-insensitive manner when looking at HTML elements, and in a case-sensitive manner otherwise." |
| 16:33 | <zcorpan_> | hmm so getElementsByTagName('foo') should match createElementNS('http://www.w3.org/1999/xhtml','FOO';) ? |
| 16:34 | <zcorpan_> | doesn't it make more sense to lowercase the argument before checking |
| 16:34 | zcorpan_ | files a bug |
| 16:37 | <zcorpan_> | actually hmm |
| 16:39 | <zcorpan_> | webkit lowercases the argument |
| 16:39 | <zcorpan_> | which makes it impossible to look for svg camelcase elements |
| 16:40 | <zcorpan_> | i guess the specced behavior is better since it works as expected in the valid case |
| 18:26 | <gsnedders> | jgraham: No, I wasn't actually around at that moment |
| 18:33 | <jgraham> | gsnedders: I am not actually around at this moment |
| 20:48 | <gsnedders> | smedero: I can say I will be arriving in Cannes at 15:02 on the Sunday |
| 20:49 | <smedero> | gsnedders: I can say I'm still looking for help with picking up part of the tab on my flight. :-D |
| 20:50 | <gsnedders> | :P |
| 20:50 | <gsnedders> | smedero: Have you already paid for it, or not? |
| 20:50 | <smedero> | gsnedders: nope. :-/ |
| 20:50 | <smedero> | sigh. |
| 20:51 | <gsnedders> | smedero: Get a train within France. Internal flights are crazily expensive. |
| 20:51 | <smedero> | hrm, okay |
| 20:51 | <gsnedders> | Also, don't go into Paris. |
| 20:51 | <gsnedders> | Get it straight from CDG, change in Lyon. |
| 20:52 | <smedero> | hrm, I had been thinking of doing something sorta like that.... |
| 20:52 | <smedero> | I'll look into that route now though, thanks. |
| 20:54 | <gsnedders> | It'll take around 6 hours to do by train, but that isn't that much slower taking into account all the fun at airports |
| 20:55 | <gsnedders> | (I'm staying near Lyon for just over a week before) |
| 20:57 | <gsnedders> | So I'm just doing it in two goes |
| 21:21 | <gsnedders> | Can anyone help me stop worrying? |
| 22:02 | Lachy | obviously didn't check the spec well enough |
| 22:03 | <Lachy> | re target=_blank and window.opener |
| 22:05 | <Philip`> | I looked in the part that talked about target=_blank, and the part that talked about window.opener, which was not a particularly obscure thing to think to do :-p |
| 22:06 | <annevk2> | Lachy, fun video |
| 22:10 | <Lachy> | I looked there too, but I somehow missed the bit about the opener |
| 22:53 | <jgraham> | gsnedders: I doubt I can :) |
| 23:17 | <virtuelv> | this is, in every respect, somewhat depressing http://my.opera.com/operaqa/blog/2008/08/04/alexa-global-top-500-validation-research |