| 02:12 | <Philip`> | jacobolus: http://krijnhoetmer.nl/irc-logs/whatwg/20080702#l-282 |
| 02:15 | <jacobolus> | Philip`: that may be, but that limits what you can do |
| 02:16 | <jacobolus> | Philip`: it's quite useful to draw a bit, then transform, then draw a bit more (in the same path) |
| 02:17 | <jacobolus> | Philip`: that spec wording you pasted in that chat seems about right to me, and is sufficiently explicit. cool. |
| 02:17 | <Philip`> | jacobolus: Only Opera prevents you from doing that, and nobody uses Opera so you could ignore it ;-) |
| 02:18 | <jacobolus> | yep |
| 02:18 | <jacobolus> | that's the plan |
| 02:18 | Philip` | uses Opera :-( |
| 02:18 | <jacobolus> | Philip`: so my little test thing at http://www.orbited.org/wiki/CanvasShapes won’t work for you then |
| 02:19 | <jacobolus> | or rather, it will only draw circles |
| 02:20 | <Philip`> | jacobolus: That's what happens in Opera, though I can trivially switch to Firefox to see it properly :-) |
| 02:23 | <Philip`> | jacobolus: The arc() call for drawing circles should probably use false (clockwise) instead of true, else (according to the spec) it might (if Math.PI > π) draw nothing instead of a circle |
| 02:23 | <jacobolus> | okay |
| 02:24 | <Philip`> | (because of the way angles get wrapped, depending on the clockwisity and the angles) |
| 02:24 | <jacobolus> | Philip`: I would expect one of arc(x, y, radius, 0, 0, false) and arc(x, y, radius, 0, 0, true) to draw a whole circle |
| 02:24 | <jacobolus> | but both just do nothing |
| 02:24 | <Philip`> | (Hmm, maybe "clockwisdom" is a better term) |
| 02:24 | <jacobolus> | hehe |
| 02:26 | <Philip`> | arc() is a bit weird and unintuitive |
| 02:27 | <Philip`> | but it's implemented interoperably in Firefox and WebKit, so I guess there'd need to be strong justification for changing the spec to not match those implementations |
| 02:36 | <jacobolus> | Philip`: hmm, if I use a bit more than 2π for the second angle, it draws most of a circle whether I use true or false |
| 02:44 | <Philip`> | jacobolus: Argh |
| 02:44 | <Philip`> | You are entirely right, and that is the expected behaviour |
| 02:44 | <Philip`> | I just get this all mixed up every time I look at arc() :-/ |
| 02:44 | <Philip`> | I remember not enough to be correct, but enough to be dangerous |
| 02:45 | <jacobolus> | Philip`: is there a mathy explanation of how arc is supposed to work? |
| 02:45 | <Philip`> | jacobolus: What do you consider "mathy"? |
| 02:45 | <Philip`> | (particularly compared to what's in the spec already) |
| 02:45 | <jacobolus> | just unambiguous. I haven't read what the spec says about arc :) |
| 02:48 | <Philip`> | If start->end is clockwise (i.e. end > start), and anticlockwise=false, then it draws all the way from start to end and possibly goes all the way around the circle (though at most once); and if anticlockwise=true, then the angles are wrapped modulo 2pi and the shortest anticlockwise arc from start to end is drawn |
| 02:48 | <Philip`> | and same if you swap all mentions of 'clockwise' and 'anticlockwise' |
| 02:48 | <Philip`> | or at least I think that's what it is |
| 02:51 | <Philip`> | Oh, maybe the problem is if Math.PI < π, because drawing anticlockwise from 0 to 2π-ε would draw an ε-long line instead of a circle |
| 02:51 | <Philip`> | But I could still be wrong, so I'll just give up and go to bed :-) |
| 02:53 | <jacobolus> | Philip`: yes, that is true |
| 02:54 | <jacobolus> | Philip`: if you have Math.PI < π then arc(x, y, radius, 0, 2*Math.PI, true) draws nothing |
| 02:54 | <jacobolus> | so you’re right, to draw a circle I should use false |
| 02:56 | <Philip`> | Drawing circles is quite irritatingly complex |
| 02:56 | <Philip`> | Anyway, good night for now |
| 02:57 | <jacobolus> | 'night |
| 02:57 | <jacobolus> | thanks |
| 08:51 | <gDashiva> | "Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature." |
| 08:51 | <gDashiva> | Are these text/plain web servers related to hsivonen's transcoding proxies? |
| 09:11 | <Hixie> | hsivonen: the most common errors i get are (1) mistyping the start tag (e.g. missing the leading <), and (2) getting hte wrong end tag. |
| 09:11 | <Hixie> | these two errors both cause an inordinate number of errors to be reported and none of them really say what the actual mistake was. |
| 09:12 | <Hixie> | e.g. <p> foo var title="">x</vsr> </p> and <p> <a href="">x</span> </p> |
| 09:12 | <othermaciej> | I had a similar experience with the validator |
| 09:13 | <othermaciej> | although the mistake was missing close " |
| 09:14 | <Hixie> | the wrong end tag for an inline element in particular cascades into an error for almost every block-level element in the tree from the point of the error on. |
| 09:14 | <Hixie> | which is exciting when the error is half way down the html5 spec |
| 09:18 | <Hixie> | first draft of Web Sockets has now been completely defined |
| 09:19 | <jacobolus> | Hixie: that sounds great. I'll take a look tomorrow morning |
| 09:21 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#network |
| 09:30 | <Hixie> | Lachy_: just listend to the podcast on the web, and i think you did great! |
| 09:32 | <hsivonen> | Hixie: recorded http://bugzilla.validator.nu/show_bug.cgi?id=258 |
| 09:32 | <Hixie> | cool |
| 09:34 | <Lachy> | Hixie, really? I couldn't listen to it all. The sound of my own voice is irritating. |
| 09:41 | <Hixie> | heh |
| 09:41 | <Hixie> | it was fine as far as i could tell :-) |
| 09:41 | <Hixie> | one's own voice is often found to irritate one |
| 09:42 | <Lachy> | I tend to say um and ah far too often, at least at the beginning |
| 09:42 | <Lachy> | I need to practice more |
| 09:42 | <Hixie> | eh, everyone does :-) |
| 09:42 | <Hixie> | you should hear my talks, i'm terrible |
| 09:42 | <Lachy> | have you got any recorded? |
| 09:46 | <Hixie> | not publicly :-) |
| 09:48 | <Hixie> | right bed time |
| 09:48 | <Hixie> | nn |
| 09:51 | <hsivonen> | Lachy: It's a bit hard to comment, since I already know the topic, so I can't comment what it souded like to someone who doesn't. |
| 09:51 | <hsivonen> | Lachy: you did go a bit easy (non-controversially) on the XHTML vs. HTML question |
| 09:52 | <Hixie> | (wow, julian was fast at sending that complaint about the Web Socket Protocol) |
| 09:58 | <Lachy> | hsivonen, of course I did. If I said anything bad about XHTML, think of the complaints I'd be getting from certain people |
| 09:59 | <Lachy> | gotta go, bbl |
| 10:03 | <othermaciej> | Hixie: specifying the bytes is not really helpful to implementors (I don't think anyone will put an array of hex values in their code instead of a string) |
| 10:03 | <hsivonen> | othermaciej: for another part of the spec I did and later regretted |
| 10:04 | <hsivonen> | (not an array actually, but individual numbers) |
| 10:05 | <othermaciej> | yikes |
| 10:06 | <othermaciej> | I don't understand also why validating the response depends on details that are irrelevant from the HTTP point of view |
| 10:07 | <othermaciej> | that makes it harder to make a module for an existing web server that would implement this on the same port as the normal connection |
| 10:08 | <othermaciej> | seems like gratuitous draconianism (but maybe I am missing the motivation) |
| 10:09 | <othermaciej> | also the fact that it defaults to a weird port and doesn't rely on same-origin security at all partly misses the point of making it look like HTTP |
| 10:11 | <othermaciej> | I guess I can send email tomorrow |
| 10:38 | <mcarter> | good evening |
| 13:59 | <Windstoss> | What is the browser supposed to do, when an author sets contenteditable for <title></title>? |
| 14:00 | <annevk> | Hixie, "their originating server" seems false, as it clearly allows cross-origin |
| 14:01 | <annevk> | Windstoss, make it editable? |
| 14:02 | <zcorpan> | Windstoss: same as any other element i guess |
| 14:11 | <zcorpan> | Philip`: is there an easy way to sort the canvas results table so that tests that fail across the board are at the top, tests with 1 pass next, 2 passes next, and so forth? |
| 14:22 | <Philip`> | zcorpan: The easy way is to just write a script that sorts them based on the class names, I would expect |
| 14:23 | <zcorpan> | Philip`: ok |
| 14:25 | <Philip`> | zcorpan: probably something like http://philip.html5.org/misc/canvas-table-sort.txt but less rubbish |
| 14:29 | <zcorpan> | Philip`: thanks, you're faster than me :) |
| 14:31 | <Philip`> | JS needs an operator like Perl's <=> and cmp |
| 14:36 | <Philip`> | zcorpan: (Updated the script to give nicer output now) |
| 14:42 | <zcorpan> | Philip`: thanks |
| 14:43 | <zcorpan> | http://simon.html5.org/dump/canvas-results-sorted.html |
| 14:44 | <zcorpan> | i think i'll go through the top ones and see if it makes sense to change the spec |
| 14:45 | <Philip`> | It'd probably be sensible to ignore the Excanvas column |
| 14:46 | <zcorpan> | yeah but it's mostly fail anyway :) |
| 14:47 | <zcorpan> | is it defined somewhere what should happen in general with too few or too many arguments? |
| 14:48 | <Philip`> | zcorpan: http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#common |
| 14:54 | <zcorpan> | wonder if it would be useful to have a standard exception for not enough arguments |
| 14:54 | <zcorpan> | that is different from NOT_SUPPORTED_ERR |
| 14:56 | <annevk> | if the use case is testing, no :) |
| 14:56 | <gDashiva> | WRONG_ARITY_ERR |
| 14:57 | <zcorpan> | well debugging for authors |
| 14:58 | <zcorpan> | "not enough arguments" is more helpful than "NOT_SUPPORTED_ERR" when the author looks in the error console to figure out why it doesn't work |
| 14:58 | <annevk> | usually exceptions have some message that could be more detailed |
| 14:58 | <zcorpan> | oh that's true |
| 14:58 | <zcorpan> | ok |
| 15:15 | <zcorpan> | hmm, is the imageData stuff not implemented yet? |
| 15:17 | <annevk> | it is |
| 15:17 | <annevk> | though in varying degree |
| 15:28 | <zcorpan> | now i wonder, should i post my notes to whatwg, public-html or file a bug? |
| 15:29 | zcorpan | posts to whatwg |
| 15:31 | <Philip`> | zcorpan: Nobody implements it all, as far as I'm aware |
| 16:10 | <annevk> | Hixie, yt? any idea whether we postponed the meeting to 10AM again? |
| 16:23 | <annevk> | guess i'll be there at nine |
| 17:16 | <annevk> | seems I was wrong, nobody here :/ |
| 18:35 | <gsnedders> | Hixie: What's the justification for not just using full HTTP/1.1 for WebSockets? |
| 18:37 | <takkaria> | it's the requirement to write a websockets server in only a few lines of code |
| 18:37 | <takkaria> | I believe, anyway |
| 18:38 | <annevk> | indeed |
| 18:38 | <Hixie> | right |
| 18:39 | <gsnedders> | peh. we already have perfectly good HTTP servers. |
| 18:39 | <Hixie> | i'm not writing a whole web server just to do a chat client |
| 18:39 | <Hixie> | the "perfectly good HTTP servers" don't do full duplex. |
| 18:39 | <Hixie> | cos HTTP isn't full duplex. |
| 18:42 | <gsnedders> | hmm, looking through the diff of spec-gen v. the CSS WG's postprocessor, a heckuva lot is just the difference between actually parsing it and serializing it v. rewriting parts of the document |
| 18:42 | <gsnedders> | brb (again) |
| 18:43 | <gsnedders> | (back) |
| 18:51 | <Hixie> | othermaciej: the reason for having an exact hex dump is to make absolutely sure that the remote end really is a WebSocket server and isn't being tricked into pretending to be one |
| 18:51 | <gsnedders> | Why claim to be an HTTP server? |
| 18:52 | <gsnedders> | (i.e., get off ma lawn!) |
| 18:52 | <Hixie> | so that you can reuse the same port |
| 18:52 | <othermaciej> | Hixie: it seems like the most likely thing to trick would be a generic web server that doesn't actually support WebSocket at all |
| 18:53 | <othermaciej> | in which case, requiring a particular header order does not seem like a strong defense |
| 18:54 | <othermaciej> | but it may well make it more of a pain in the ass to implement it integrated into normal web servers |
| 18:54 | <Hixie> | well there's no way that a random HTTP server is going to be saying "Upgrade: WebSocket". |
| 18:56 | <othermaciej> | it seems unlikely that anything else could be made to produce something that looks like an http response with the right status code and response headers, but only with the headers in a different order |
| 18:56 | <john_fallows> | Hixie, looks you are making very good progress with the WebSocket section :) |
| 18:58 | <Hixie> | john_fallows: it's basically done :-) |
| 18:58 | <john_fallows> | i have a question about the step 11 in the handshake |
| 18:59 | <Philip`> | ...except for the implementations and tests and feedback and tutorials and ... |
| 18:59 | <john_fallows> | why use GET rather than OPTIONS? |
| 19:00 | <Philip`> | (Note to self: Hash tables don't work well when you have ten thousand items and the hash function always returns 0) |
| 19:02 | gsnedders | is looking over an htmldiff of the real spec-gen's output and his own |
| 19:02 | <gsnedders> | no breakage that I've seen yet |
| 19:02 | <Hixie> | othermaciej: i don't think it's that unlikely. we'd still have to define error handling to a lot of detail, too, so it seems better to make that as simple as possible |
| 19:02 | <Hixie> | Philip`: i just meant the text in the spec :-) |
| 19:03 | <gsnedders> | (well, breakages due to one or two things not being supported yet) |
| 19:03 | <Hixie> | john_fallows: OPTIONS means "tell me about this resource", GET means "give me this resource" |
| 19:03 | <Hixie> | john_fallows: we don't want to know if it's possible, we just want to connect :-) |
| 19:05 | <john_fallows> | don't we need to wait for the 101 Switching Protocols to know if it's possible? |
| 19:10 | <john_fallows> | Hixie: sorry, did not prefix my last comment with your id |
| 19:11 | <Hixie> | well, it's like with a normal GET request right? You don't know if the URL exists before you call it. |
| 19:21 | <john_fallows> | Hixie: yes, that applies to many different HTTP methods with request paths, such as GET, POST, PUT, DELETE, HEAD, OPTIONS, so it doesn't seem to imply the use of GET |
| 19:31 | <john_fallows> | Hixie: OPTIONS implies we are negotiating capabilities of the conversation, which IMHO seems like the best fit for the WebSocket handshake |
| 19:32 | <Hixie> | OPTIONS isn't negotiation, it's asking for information |
| 19:33 | <gsnedders> | Now, I need help with a non-recursive algorithm |
| 19:34 | <john_fallows> | Hixie: you are right, OPTIONS is asking for meta-information about a resource, not the resource itself - that's why OPTIONS is a better fit over GET |
| 19:35 | <Hixie> | we want a resource here, not meta information |
| 19:35 | <gsnedders> | Namely, http://pastebin.com/m2f04a2a |
| 19:36 | <john_fallows> | if we wanted to return the actual resource, wouldn't that be a 200 OK or similar with a request body? |
| 19:37 | <Hixie> | it is |
| 19:37 | <annevk> | gsnedders, hey, how far is your specgen? |
| 19:37 | <Hixie> | well |
| 19:37 | <Hixie> | it's a 101 |
| 19:37 | <Hixie> | but 101 just means "i'm moving to another protocol to give you the 200 OK" |
| 19:37 | <gsnedders> | annevk: xref is more or less perfect, I just need to build the TOC from the internal structure and add section numbers |
| 19:38 | <gsnedders> | and that'll probably do for 1.0 (well, with some bugfixes) |
| 19:38 | <annevk> | is it available as web service already? |
| 19:38 | <gsnedders> | nope |
| 19:42 | <john_fallows> | Hixie: we do want meta-information about the resource, namely whether or not it supports Upgrade: WebSocket |
| 19:43 | <Hixie> | john_fallows: no, we want it to actually upgrade |
| 19:44 | <Hixie> | it's like saying when you go to ikea to buy a cupboard, you're looking for the instructions to build the cupboard, not the cupboard itself |
| 19:48 | <john_fallows> | looking at the TLS Upgrade scenario in RFC2817 - http://www.ietf.org/rfc/rfc2817.txt |
| 19:49 | <john_fallows> | they specify Optional Upgrade using GET and Mandatory Upgrade using OPTIONS |
| 19:49 | <gsnedders> | Hixie: I want the pieces to build the cupboard from too, when I go to IKEA |
| 19:50 | <john_fallows> | the WebSocket upgrade is mandatory, which seems to imply using OPTIONS rather than GET |
| 19:58 | <Hixie> | 2817 is on crack |
| 19:58 | <Hixie> | note how nobody implements it |
| 20:00 | gsnedders | passes Hixie some crack so he can be on it too |
| 20:00 | <Hixie> | no thanks :-) |
| 20:02 | <gsnedders> | 0.714s to xref HTML 5 |
| 20:03 | <Hixie> | how long to parse? :-) |
| 20:03 | <gsnedders> | Far too long :) |
| 20:04 | <gsnedders> | 13.106s |
| 20:06 | <Hixie> | d'oh |
| 20:21 | <john_fallows> | if the handshake is forced to either Upgrade or fail, and can never return a non-upgraded response, i don't see how we can justify using GET over OPTIONS |
| 20:21 | <Hixie> | i don't see how we can justify using OPTIONS |
| 20:22 | <john_fallows> | sorry Hixie, don't mean to bug you on this, just trying to better understand the "is on crack" response earlier :) |
| 20:22 | <Hixie> | rfc2817 is just fundamentally not a sane spec |
| 20:22 | <Hixie> | and is not likely to convince me as an appeal to authority :-) |
| 20:23 | <john_fallows> | maybe if i understood why you think that, it would be easier for me to reach your perspective |
| 20:26 | <Hixie> | it makes fundamental mistakes like not having a way for pages to say that following a link must happen over an encrypted channel |
| 20:27 | <john_fallows> | is that relevant to the optional upgrade=GET, mandatory upgrade=OPTIONS? |
| 20:27 | <Hixie> | well, that's just another example of something i don't think is sane in that spec :-) |
| 20:28 | <Hixie> | i'm just saying that RFC2817 being a proponent of something or not isn't a useful technical argument |
| 20:28 | <Philip`> | Hixie: If you made the encoded length value be big-endian instead of little-endian, then it'd be compatible with Perl's "pack 'w'", which might be nice |
| 20:28 | <john_fallows> | ok, understood |
| 20:28 | <john_fallows> | well, we're not even delivering a pseudo 200 OK after the 101, because after the protocol switch we are both sending and receiving bytes on the wire, it is no longer about resource retrieval |
| 20:30 | <Hixie> | john_fallows: once it's upgraded, it is implied that it is OK :-) |
| 20:30 | <Hixie> | Philip`: hm, interesting |
| 20:31 | <john_fallows> | yeah, but you didn't actually retrieve any resource when it upgraded, you just changed the rules on how to communicate with that resource |
| 20:34 | <Hixie> | well, the full duplex socket is the resource |
| 20:34 | <john_fallows> | identified by the request URI |
| 20:36 | <Hixie> | right |
| 20:40 | <john_fallows> | so what are you saying? GET makes sense to you because you are "GET"ing the full duplex socket resource? |
| 20:46 | <Hixie> | right |
| 20:46 | <Hixie> | Philip`: i have switched to big endian |
| 20:50 | <john_fallows> | those semantics are not consistent with HTTP specification's definition of the GET method, to transfer an entity identified by request URI |
| 20:51 | <Philip`> | Hixie: It should multiply 'length' by 128 in each iteration, not by 'multiple' |
| 21:38 | <Hixie> | Philip`: oops |
| 21:44 | <gsnedders> | Does anyone want to bitch about how bad http://pastebin.com/m3f6dd4f4 is? |
| 21:45 | <gsnedders> | That's my first attempt at a non-recursive implementation of that (due to the need to be able to cope with infinitely deep nested sections) |
| 21:45 | <gsnedders> | (which jgraham's online viewer will hit the recursion limit with) |
| 21:54 | <hsivonen> | Hixie: in the binary math, shifting left may be more intuitive that multiplication |
| 22:00 | <Hixie> | true |
| 22:00 | <Hixie> | too busy to change it right now |
| 22:08 | <Philip`> | Nobody's going to implement it correctly - they'll all wrap at 2^31 or 2^32 or 2^64 or something |
| 22:09 | <Hixie> | probably |
| 22:09 | <Philip`> | so maybe it should be defined so that a straightforward 32-bit implementation will work correctly, because nobody has a legitimate reason to send 4GB messages |
| 22:09 | <Hixie> | today |
| 22:09 | <roc> | 4GB ought to be enough for anyone |
| 22:09 | <gsnedders> | Hmm, my HD is bigger than that. |
| 22:09 | Hixie | already deals with terabyte files |
| 22:10 | <Philip`> | You can split the data up into multiple messages |
| 22:10 | <takkaria> | Hixie: yes, but will you really want to send those files over a WebSocket? |
| 22:10 | <annevk> | couple of MB was enough for anyone at some point in the past |
| 22:10 | <jgraham> | gsnedders: Why re you using a deque? |
| 22:10 | <annevk> | even a couple of KB... |
| 22:11 | <gsnedders> | jgraham: Well, it probably doesn't make much difference on such a small outline (even as big as HTML 5) |
| 22:11 | <Philip`> | You don't really want to transmit 4.0GB of your 4.1GB file and then have the connection drop and have to resend the entire thing, so you'd always split it up and build some higher-level file transfer protocol on top of it |
| 22:11 | <takkaria> | if you're dealing with 4GB of data transfer at one point, you're better using BitTorrent or something else |
| 22:11 | <takkaria> | I thought WebSocket was there for chat applications and remote train control, not sending files |
| 22:11 | <Hixie> | we can certainly define a limit after which the client should abort the connection |
| 22:11 | <Hixie> | that's what i tried doing on the last checkin |
| 22:11 | <Philip`> | gsnedders: Replace deque with list, and replace extendleft with push, and replace popleft with pop |
| 22:12 | <Philip`> | s/push/append/ or whatever |
| 22:12 | <jgraham> | gsnedders: what Philip` said |
| 22:12 | <Philip`> | gsnedders: Also have a single list of (section, indent) tuples, instead of two lists |
| 22:12 | <gsnedders> | Hey, I'm not a CS student! |
| 22:12 | <jgraham> | gsnedders: Me neither :) |
| 22:13 | <Philip`> | gsnedders: (unless that'd make the implementation ugly, but I don't see obvious problems) |
| 22:13 | <gsnedders> | Philip`: Well, extend not push |
| 22:13 | jgraham | was going to write you an implementation which just walked the tree iteratively |
| 22:13 | <Philip`> | gsnedders: Oh, right, I meant s/push/extend/ |
| 22:14 | <jgraham> | But that's only really easier if you have parent pointers and I don't know if you do |
| 22:14 | <gsnedders> | lxml has _Element.parent |
| 22:15 | <Philip`> | takkaria: I'd be pretty worried if I was a passenger on a train that was being controlled by Web Sockets :-( |
| 22:15 | <jgraham> | gsnedders: But a section is not an lxml element, right? |
| 22:15 | <gsnedders> | jgraham: right |
| 22:15 | <gsnedders> | jgraham: It's a subclass of list, and has section.header and section.parent |
| 22:16 | <gsnedders> | You need to be able to get the parent to implement the algorithm anyway |
| 22:18 | <gsnedders> | Philip`: How can I do something like l18? |
| 22:18 | <takkaria> | Philip`: not if you were a fly. :) |
| 22:19 | <gsnedders> | Philip`: All I can think to do is a loop over section and append a truple for each |
| 22:20 | <Philip`> | gsnedders: section_and_indents_list.extend((s, indent+2) for s in sections) perhaps |
| 22:20 | <jgraham> | gsnedders sections.extend((sec, indent+2) for sec on section) |
| 22:20 | <gsnedders> | ah, I don't often think of that, and not with truples |
| 22:20 | <Philip`> | s/sections/section/ |
| 22:20 | <jgraham> | s/on/in/ of course |
| 22:22 | <gsnedders> | I've done something wrong. |
| 22:22 | <Hixie> | q+ |
| 22:22 | <Hixie> | er |
| 22:22 | <Hixie> | wc |
| 22:28 | <gsnedders> | That just looks messy. |
| 22:28 | <gsnedders> | http://pastebin.com/m7d7fc0a1 |
| 22:30 | <gsnedders> | 22*C here tomorrow. |
| 22:30 | <Hixie> | http://languagelog.ldc.upenn.edu/myl/TranslateServerError.jpg |
| 22:30 | <Hixie> | ... |
| 22:31 | <hsivonen> | Hixie: that's awesome |
| 22:31 | <gsnedders> | I think that's a bug. |
| 22:31 | <roc> | owah |
| 22:32 | <roc> | could it be photoshopped? |
| 22:32 | <Hixie> | could be |
| 22:32 | <Hixie> | wouldn't surprise me if it was real |
| 22:33 | <gsnedders> | http://xkcd.com/331/ |
| 22:33 | <roc> | it could be real, but a *lot* of Chinese people know English these days, especially ones involved in the Olympics I guess |
| 22:34 | <roc> | so it would have to be a monumental stuff-up |
| 22:34 | <roc> | which is of course entirely possible |
| 22:34 | <gsnedders> | Like, committing code that breaks everything thinking it's a tiny fix and can't possibly break anything? |
| 22:35 | <jgraham> | gsnedders: You should do something like item = sections.pop(); section, indent = item |
| 22:35 | <takkaria> | there's a massive screen in Manchester, UK, right in the middle of town, which every now and again has Windows error boxes about media types not being supported |
| 22:35 | <gsnedders> | jgraham: or just section, indent = sections.pop() |
| 22:35 | <jgraham> | Yeah, or just that :) |
| 22:35 | <gsnedders> | jgraham: Myself coding half asleep isn't good :) |
| 22:36 | <gsnedders> | Actually building the TOC, inevitably, is more complex. |
| 22:39 | <gsnedders> | I also need to deal with no-toc |
| 22:41 | <gsnedders> | How come I need reversed() like this, but not with the non-recursive algorithm? |
| 22:42 | <jgraham> | Do you mean not with the recursive algorithm? |
| 22:42 | <gsnedders> | yeah |
| 22:43 | <gsnedders> | I _am_ half asleep, remember :P |
| 22:43 | <jgraham> | Because at each stage you want to pick the first child of the current section to serialize next which means that it has to go on the far right of the array so it is popped off next |
| 22:44 | <gsnedders> | duh. |
| 22:44 | <jgraham> | Alternatively, if there are no children, you want the next sibling of the current node, so that has to be one to the left of the current node in the array |
| 22:44 | <gsnedders> | Because I push and not pop now. |
| 22:45 | gsnedders | is really proving how silly his is when tired |
| 22:45 | gsnedders | heads off to sleep |
| 22:45 | <jgraham> | His what is ? ;) |
| 22:45 | <gsnedders> | :) |
| 22:45 | <gsnedders> | s/his/he/ |
| 22:46 | <jgraham> | Did anyone mention http://www.toolness.com/wp/?p=52 already? |
| 23:09 | <Philip`> | jgraham: So I could run Python code that's compiled into Python bytecode, executed by an interpreter that's written in C and compiled to LLVM IR then converted to opcodes for a virtual machine written in ActionScript, ... |
| 23:09 | <Philip`> | which is compiled to ABC bytecode, which runs in an interpreter written in Forth, which gets JITted to x86 machine code, which is translated into micro-ops which get executed on the hardware |
| 23:09 | <Philip`> | Abstraction is great |
| 23:13 | <roc> | it's amazing anything ever works at all |
| 23:14 | <othermaciej> | I wonder why the LLVM IR needs to be interpreted rather than translated to ABC directly |
| 23:16 | <othermaciej> | I imagine you could give LLVM an ABC back end, but maybe writing a back end is more complex than I thought |
| 23:19 | <roc> | maybe the poster is just confused |
| 23:20 | <roc> | if you delete the "in" before "Actionscript" in step 2 I think it would make more sense :-) |
| 23:23 | <othermaciej> | presumably we'd have to ask someone who has seen the presentation |
| 23:24 | <roc> | I don't think it really matters, we can all see the ways it could work |
| 23:24 | <Philip`> | and all those ways are similarly crazy |
| 23:24 | <roc> | the only crazy thing is the prospect of JS as the universal compiler intermediate language |
| 23:25 | <othermaciej> | translating LLVM to a custom bytecode which is then interpreted by a VM written in ActionScript is certainly possible |
| 23:25 | <othermaciej> | though it does seem like needless extra steps compared to translating LLVM to ABC bytecode |
| 23:25 | <othermaciej> | or translating LLVM IR to ActionScript directly |
| 23:25 | <othermaciej> | rather than to a different bytecode interpreted by ActionScript |
| 23:26 | othermaciej | shrugs |
| 23:26 | <Philip`> | It would be fun to try debugging a performance problem in your Python code and having to traverse down a dozen levels to find the cause |
| 23:26 | <Philip`> | s/levels/levels of abstraction/ |
