| 02:06 | <sid_> | Hi I wanted to know is there a simple JS method to convert HTML body node to plain string WITHOUT STRIPPING THE HTML TAGS? |
| 02:06 | <TabAtkins> | .innerHTML? |
| 02:07 | <sid_> | nono thats without the tags. |
| 02:07 | <TabAtkins> | Without which tags? |
| 02:08 | <sid_> | never mind |
| 02:08 | <sid_> | thanks |
| 02:08 | <TabAtkins> | .outerHTML includes the <body> tags, but it's not supported everywhere. |
| 02:09 | <Dashiva> | But it's part of the spec, and it's part of IE, so it should be fine to use relatively soon |
| 02:09 | <TabAtkins> | Yeah. |
| 02:12 | <sid_> | It is supported on chrome.. |
| 02:16 | <Dashiva> | Is there a version of caniuse that addresses the oldest browsers still with a relevant market share, I wonder |
| 02:17 | <Dashiva> | (That is, it doesn't help to know that IE9 supports feature X if IE<9 doesn't and still has a 40% market share) |
| 02:27 | <boblet> | Dashiva: it depends on your site’s browser breakdown, but at the top of www.caniuse.com under “other options” there’s “show conclusions”… |
| 02:28 | <boblet> | basically that’s the same as “if there’s red, don’t use” |
| 03:25 | <boblet> | ooh this is nice: http://www.germanforblack.com/articles/moving-towards-readable-w3c-specs |
| 10:10 | <micheil> | Hixie: can we introduce a websocket-version header, as chrome implements draft75, yet chromium implements draft76+ |
| 10:24 | <gsnedders> | micheil: versioning means you either are lying or end up with multiple implementations/forks within an implementation, which seems bad. I'd rather just people didn't rely upon a non-final protocol that much :P |
| 11:15 | <Hixie> | micheil: just drop chrome support |
| 11:16 | <Hixie> | micheil: anyway a new header ain't gonna do you any good for supporting already-implemented handshakes :-) |
| 11:17 | <Hixie> | and you can distinguish the handshakes unambiguously already if for some reason you really need to support obsolete experimental implementations |
| 11:17 | <micheil> | yeah, I've since relieased that only draft76+ sends sec-* headers |
| 11:26 | <micheil> | so, theoretically, I can have a dynamic switching mode to change between 75 and 76 on a per-client basis |
| 12:19 | <gsnedders> | Hmm, a pure ECMAScript templating engine... |
| 12:20 | <gsnedders> | I guess I really need some sort of tree model first. |
| 12:21 | <gsnedders> | Hmm, what would be a good tree model API in ECMAScript... |
| 12:22 | <gsnedders> | I guess I good approach would be to take the if-in-any-doubt-go-against-DOM approach |
| 12:26 | <Philip`> | gsnedders: Represent the tree as an array of triples |
| 12:28 | <gsnedders> | Philip`: How so? |
| 12:30 | <Philip`> | gsnedders: [[1, "parent", 2], [1, "parent", 3], [1, "name", "html"], [2, "child", 1], [3, "child", 1], ...] |
| 12:30 | <gsnedders> | ah, like that |
| 12:30 | <Philip`> | Then you won't even be limited to tree structures |
| 12:30 | <gsnedders> | Philip`: :) |
| 12:31 | <gsnedders> | Philip`: That doesn't address the what's a good API question, unless you intend to just expose the raw data structure |
| 12:31 | <fantasai> | Hixie: I can't find a spec for the <meta http-equiv="Link"/> behavior required by http://www.hixie.ch/tests/adhoc/css/cascade/import/002.html |
| 12:31 | <fantasai> | Hixie: don't know what you want to do about it, but thought I'd mention... |
| 12:32 | <gsnedders> | fantasai: Per HTML5 <meta http-equiv="Link"/> should have no effect |
| 12:32 | <fantasai> | gsnedders: The test passes in both Mozilla and Opera |
| 12:33 | <fantasai> | gsnedders: If it's intended to have no effect, the HTML5 spec should clarify |
| 12:33 | <fantasai> | gsnedders: I didn't find any discussion of it on the lists. |
| 12:33 | <gsnedders> | fantasai: It's specified by a whitelist of http header names |
| 12:33 | <annevk> | you could raise it on whatwg⊙wo |
| 12:33 | <fantasai> | gsnedders: That doesn't change the fact that it looks like the issue was never considered. |
| 12:34 | <annevk> | yeah indeed, same for http-equiv=set-cookie |
| 12:34 | <annevk> | (which I raised some time ago) |
| 12:34 | <gsnedders> | fantasai: I don't think the stylesheet case was, but well, yeah, it seems like it may be worthwhile raising |
| 12:35 | <fantasai> | annevk: Should I post to whatwg, public-html, or both? |
| 12:36 | fantasai | doesn't know what the conventions are for deciding, now that her messages get through to both |
| 12:36 | fantasai | only had one option before |
| 12:40 | <Philip`> | I guess that depends on whether you want no discussion then a reply in six months saying "ok, I changed the spec"/"I'm not going to change the spec", or whether you want a repeat of all the previous discussions about how the http-equiv value space is meant to be defined by HTTP not HTML |
| 12:42 | <asmodai> | mmm, anyone saw the Android 2.2 Froyo webbrowser JavaScript performance demo? |
| 12:49 | <fantasai> | Philip`: So what's the convention when you don't care and just want to file the issue and leave? |
| 12:57 | <Philip`> | fantasai: The WHATWG list is probably simplest, but it doesn't really make that much difference |
| 12:58 | <annevk> | filing a bug might be even simpler in that scenario |
| 12:58 | <Philip`> | (Also there's no guaranteed response to posts on public-html, so you'd have to use the Bugzilla instead) |
| 13:06 | <fantasai> | annevk: Ok, filed http://www.w3.org/Bugs/Public/post_bug.cgi |
| 13:06 | <fantasai> | er |
| 13:06 | <fantasai> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=9797 |
| 13:10 | <jgraham> | gsnedders: I thought you were working on Anolis 2 :p |
| 13:10 | <gsnedders> | Um, well... |
| 13:10 | <gsnedders> | I got distracted. |
| 13:10 | <jgraham> | Also, I vaugely considered writing a js templating engine a bit like genshi |
| 13:11 | <jgraham> | but without all the xml crap |
| 13:11 | <gsnedders> | jgraham: Doing it for the pure ES case will be more fun though |
| 13:11 | <jgraham> | What do you mean "pure es"? |
| 13:11 | <jgraham> | The template itself would be executable javascript? |
| 13:12 | <gsnedders> | Something that will run in a shell, without all the host objects browsers have |
| 13:12 | <gsnedders> | I.e., for this case, no XML/HTML parser, no tree model.. |
| 13:12 | <jgraham> | Yeah that was part of my design goals (given an API for reading files and so on) |
| 13:12 | <gsnedders> | It'll be a lot of work |
| 13:12 | <gsnedders> | Given that :( |
| 13:12 | <jgraham> | Yeah, writing the template parser was the first part of the project |
| 13:13 | <gsnedders> | html5lib for ES? |
| 13:13 | <jgraham> | basically I figured if you made it like XML but with much less syntax it wouldn't be that bad |
| 13:13 | <gsnedders> | I want to be able to take arbitrary HTML input, so I don't have it so easy |
| 13:13 | <jgraham> | more like XML - doctypes |
| 13:14 | <jgraham> | Why? |
| 13:14 | <gsnedders> | Because creating another language is stupid |
| 13:14 | <jgraham> | Not if it makes it achievable rather than impossible |
| 13:15 | <jgraham> | Anyway it is a pure subset of XML 1.0 |
| 13:15 | <jgraham> | so it's not really new |
| 13:15 | gsnedders | does wonder what perf would be like of a HTML5 parser in ES |
| 13:16 | <jgraham> | You can always use hsivonen's GWT one :) |
| 13:16 | <gsnedders> | Because all ES engine QAs love GWT, right? :) |
| 13:17 | <jgraham> | Yeah, well if you have a project "make a templating engine" and stage one is "write a html5 parser", it is likely that you will never get past stage one |
| 13:18 | jgraham | wonders if anyone has used pylons |
| 13:21 | <jgraham> | (in particular I have a trivial pylons + genshi project where I am trying to pass a variable to the template doing something like c.a = "b" in the controller. However c in the template always seems to have no properties) |
| 13:24 | <gsnedders> | jgraham: It wouldn't be so bad if it weren't for zcorpan and all his dammed script states |
| 13:24 | gsnedders | is still bitter about that |
| 13:25 | <gsnedders> | *damned |
| 13:26 | <gsnedders> | jgraham: I don't remember seeing anything weird when I tried Pylons before |
| 13:27 | gsnedders | wants to vary the layout of a blog at thereshouldbenored.com based upon browser bugs, but needs ideas for bugs |
| 13:31 | <jgraham> | gsnedders: With genshi? |
| 13:31 | <gsnedders> | jgraham: yeah |
| 13:32 | <jgraham> | How long ago? There seems to be a relatively new pylons and a relatively new genshi |
| 13:32 | <gsnedders> | A year or so? |
| 13:32 | <jgraham> | Hmm |
| 13:32 | <gsnedders> | I think it was just before I started at Opera, in the two weeks between my final exam and leaving for Sweden |
| 13:32 | <jgraham> | I remember using pylons for something one and it working |
| 13:33 | <jgraham> | So it shouldn't be impossible |
| 13:40 | <gsnedders> | Anyone tried out BESEN? |
| 13:50 | <jgraham> | Hmm, seems to work now. No idea what I changed apart from trying to log what was happening, of course... |
| 13:51 | <jgraham> | gsnedders: I take it you don't mean the New York based investment firm, so you might need to give more of a hint |
| 13:52 | <jgraham> | (or indeed the |
| 13:52 | <gsnedders> | http://besen.sourceforge.net/ |
| 13:53 | <gsnedders> | per the thread on es5-discuss (or maybe es-discuss), currently the only ES engine claiming full ES5 compliance |
| 13:54 | <jgraham> | gsnedders: Given how well it does on Google, I would suggest that no one has tried it (approximatley) |
| 13:59 | <gsnedders> | Would be fun to use it to try out something using strict mode |
| 14:20 | <gsnedders> | Gah. The ES spec is somewhat ridiculous. |
| 14:20 | <gsnedders> | /foobar/x is a valid syntaxual extension, new RegExp("foobar", "x") must throw SyntaxError |
| 14:21 | <micheil> | gsnedders: do you think it's wise for a server to support dynamic & automated switching between websocket versions? |
| 14:21 | <micheil> | so, allow the server to be told to use either draft75 or draft76, or auto |
| 14:21 | <gsnedders> | micheil: I'd say you run the risk of clients never moving to a newer version of the |
| 14:21 | <gsnedders> | spec and being stuck having to support it forever |
| 14:22 | <micheil> | well, the code to support the old one isn't much |
| 14:22 | <micheil> | just a different handshake |
| 14:23 | <gsnedders> | substr is non-standard!? |
| 14:24 | <gsnedders> | In the lovely app. B |
| 14:41 | <jgraham> | gsnedders: Everyone loves ECMAScript |
| 14:42 | <jgraham> | micheil: Versioning is bad in the long run. WebSockets is just a bit unstable right now |
| 14:42 | <micheil> | jgraham: yeah, although, right now, chromium supports draft76+ |
| 14:43 | <micheil> | and chrome does draft75 |
| 14:43 | <micheil> | making it utter hell for developers wanting to use them |
| 14:43 | <gsnedders> | jgraham: I'm proving how long its been sice I read the spec to be amazed a this |
| 14:44 | <micheil> | so what I'm thinking of doing is adding in an automatic upgrade/downgrade to draft75 or 76, unless the server is told to run explicitly on draft76 only. |
| 14:44 | <annevk> | micheil, well a) it's still experimental and b) the request is different so it should be as much hell as it would be with versioning |
| 14:44 | <micheil> | annevk: that's what I mean, so, I can check if the sec-* headers are sent, if they are, we assume that it's > 75 |
| 14:45 | <micheil> | otherwise, we assume it's 75. |
| 14:45 | <micheil> | (sorta like esmtp vs smtp) |
| 14:46 | <jgraham> | micheil: Yeah if you need o deploy right now, that will work |
| 14:46 | <micheil> | so, yeah |
| 14:46 | <jgraham> | But I would just support 76 and ignore 75; it will disappear soon enough |
| 14:47 | <jgraham> | 76 might disappear too... |
| 14:47 | <jgraham> | (I mean there is a push to change handshake yet again) |
| 14:47 | <jgraham> | (or two different pushes, really) |
| 14:50 | <gsnedders> | I guess having multiple different constructors for the various tokens is going to be suboptimal, because it'd mean using isinstance, which is (relatively) slow |
| 14:51 | <jgraham> | gsnedders: Just give each token an id |
| 14:51 | <jgraham> | +type |
| 14:51 | <gsnedders> | Yeah, that's what I was going to do |
| 14:51 | <jgraham> | gsnedders: What are you actually doing now? |
| 14:51 | <gsnedders> | html5lib for ES ;P |
| 14:52 | <micheil> | jgraham: you're kidding me.. ? |
| 14:52 | <jgraham> | micheil: No |
| 14:52 | <micheil> | heh heh. |
| 14:52 | <micheil> | is there any information on these two pushes? |
| 14:52 | <jgraham> | gsnedders: Ah, I hope phase two wasn't that significant then :p |
| 14:52 | <jgraham> | micheil: Sure, on the hybi mailing list |
| 14:52 | <micheil> | hmm.. |
| 14:52 | <micheil> | there's archives yes? |
| 14:53 | <gsnedders> | jgraham: I could be evil and have something like function EOFToken() { var t = new Token(); token.type = EOFToken; return token; } |
| 14:53 | <jgraham> | gsnedders: Yes you could |
| 14:53 | <jgraham> | But that would just be odd |
| 14:53 | <gsnedders> | jgraham: Also, why are both of us sitting around indoors on IRC when it's a nice sunny day? |
| 14:54 | gsnedders | keeps wondering why he is, then fails to come up with a better plan of what to do :P |
| 14:55 | <jgraham> | micheil: Basically some people think the handshake will confuse (that is, be hard to implement in) some mixed HTTP/WebSockets servers and some people think that the handshake should be done in TLS instead |
| 14:55 | <jgraham> | for security reasons |
| 14:55 | <micheil> | oh man. |
| 14:55 | <jgraham> | Yeah |
| 14:55 | <micheil> | if you require TLS you'd be adding a barrier. |
| 14:55 | <jgraham> | Indeed |
| 14:55 | <micheil> | the current awesome thing about websockets is that anyone can start a server for it |
| 14:55 | <gsnedders> | switch uses non-strict equality, right? |
| 14:56 | <jgraham> | The argument goes "everyone will just use libraries to do TLS" |
| 14:56 | <micheil> | and, thanks, but the new websocket draft76 handshake isn't hard to implement in the server level |
| 14:56 | <jgraham> | gsnedders: I think, but you aren't going to depend on that, right? :) |
| 14:56 | <gsnedders> | jgraham: It just makes it unusable for my case :) |
| 14:57 | <micheil> | yes, it required a small change to how we handled requests in node, but overall, the only difficulty is the implementation of the security headers |
| 14:57 | <micheil> | because of the various datatypes it uses |
| 14:57 | <micheil> | it's hard to implement, but not impossible / extremely hard |
| 14:57 | <micheil> | it just means a little more code. |
| 14:57 | <gsnedders> | jgraham: (I have a charsMask function that returns false at EOF, otherwise whatever does or does not match the mask, possibly "") |
| 14:58 | <jgraham> | (I don't buy the libraries argument myself; it is barely possible in the python stdlib and the puported third party alternatives are not that well known for being simple) |
| 14:59 | <jgraham> | (and the python stdlib is unusually good) |
| 15:00 | <jgraham> | micheil: If you think this would be a serious impediment to you I think you should say so on the list |
| 15:01 | <micheil> | jgraham: I'm not a technical person, I'm just a protocol implementor |
| 15:01 | <micheil> | although, really, the current spec looks rather good |
| 15:01 | <micheil> | (I have had code having it work, in plain JS, it was a bit difficult, but really, most other languages have better datatypes then js) |
| 15:02 | Philip` | notes that http://philip.html5.org/tools/parser/ exists as an HTML5 parser in JS, albeit rather incompletely and buggy and inefficient |
| 15:02 | <gsnedders> | jgraham: I'm also tempted doing this to follow hsivonen's example and make it a DFA, never rewinding the data stream |
| 15:02 | <gsnedders> | Philip`: and ld |
| 15:02 | <gsnedders> | *old |
| 15:03 | <Philip`> | Age is unimportant |
| 15:03 | <Philip`> | (Incompleteness and bugginess and inefficiency may be important, though) |
| 15:03 | <gsnedders> | Philip`: Wait, that's created from the OCaml impl, right? |
| 15:03 | <Philip`> | The _auto.js files are |
| 15:04 | <jgraham> | Philip`: In this case age directly implies "buggy" though |
| 15:04 | <jgraham> | Unless your original bugs happened to exactly match the subsequent spec changes |
| 15:04 | <jgraham> | Which would be impressive |
| 15:04 | <Philip`> | jgraham: Not directly - age plus spec changes implies buggy |
| 15:04 | <jgraham> | Yeah but we know apriori that spec changed has occurred |
| 15:05 | <gsnedders> | Someone ought to update the Python impl to match the spec |
| 15:05 | <jgraham> | I have made some changes |
| 15:05 | <gsnedders> | And the PHP one too |
| 15:05 | <jgraham> | Locally |
| 15:05 | <gsnedders> | Also, did you win? |
| 15:05 | <jgraham> | I was going to bring back the python 3 implementation this weekend but I'm not sure I will get around to it now |
| 15:05 | <jgraham> | gsnedders: hahahaha |
| 15:06 | <gsnedders> | (I'm expecting not.) |
| 15:06 | <gsnedders> | (I guess laughter confirms that.) |
| 15:10 | <micheil> | hmm.. are all the messages in the mailing list about websockets pretty much from that Simon from opera? |
| 15:10 | <gsnedders> | Most discussion nowadays is about the protocol which is mainly on the HyBi list |
| 15:11 | <micheil> | HyBi list? |
| 15:12 | <micheil> | I'm looking at: http://www.whatwg.org/mailing-list |
| 15:18 | <jgraham> | https://www.ietf.org/mailman/listinfo/hybi |
| 15:18 | <jgraham> | Notice http://www.ietf.org/mail-archive/web/hybi/current/msg01948.html |
| 15:19 | <jgraham> | and http://www.ietf.org/mail-archive/web/hybi/current/msg02003.html |
| 15:20 | <micheil> | right, well, for one, ssl will kill websockets, as ssl is fairly difficult to implement (in a good way) |
| 15:20 | gsnedders | notices where Motala is again, seeming he always forgets |
| 15:20 | <micheil> | I still have no idea whether node.js even supports ssl, which is where I'm seeing a large increase in interest of websockets |
| 15:21 | <jgraham> | I think there's plenty of interest not related to node.js |
| 15:22 | <micheil> | true, although, yeah |
| 15:23 | <micheil> | my point still standards, SSL is fairly heavy stuff; and as for implementing, well, what is it, openssl or gnutls? |
| 15:23 | <jgraham> | But I agree "just use sockets" and "just use twisted" (to reuse othermaciej's python example) are rather different uses of the word "just" |
| 15:24 | <micheil> | and, I like the idea of having wss and ws, they server a good purpose. |
| 15:25 | <micheil> | although, I don't really have any legs to stand on as far as technical chops; I can just read specs and implement them (hopefully). |
| 15:28 | <gsnedders> | So, uh, anolis 2. |
| 15:32 | <jgraham> | micheil: You seem ideally placed to answer questions like "is X too big a barrier for typical server developers" |
| 15:35 | <jgraham> | (of course it may be that the security argument wins over convenience, in which case we jsut have to suck up the fact that therewill be far less diversity of implemntation) |
| 15:38 | <micheil> | yeah |
| 15:41 | <micheil> | jgraham: I guess the other thing to note, is if you want some super strength security on your websockets, then we've already got wss |
| 15:42 | <micheil> | which is, afaik, much like https |
| 15:44 | <jgraham> | I think the point is not to protect the data being transmitted, but to protect non-websockets servers |
| 15:44 | <jgraham> | So optional wss doesn't help |
| 15:45 | <micheil> | I'm confused there, tbh. |
| 15:45 | <micheil> | a normal server should not be handling an upgrade request like an ordinary http request, should it? |
| 15:46 | <jgraham> | A normal server could be anything, not just http |
| 15:47 | <micheil> | okay, non-websocket server then |
| 15:47 | <micheil> | a non-websocket server just simply doesn't respond to a websocket upgrade request |
| 15:47 | <jgraham> | Say you could construct the websocket handshake in just such a way that a smtp server (for example) would see a commnt (smtp probably doesn't have comments but let's pretend) |
| 15:47 | <jgraham> | and then once you were connected, you would start sending smtp |
| 15:48 | <jgraham> | that would be bad |
| 15:48 | <micheil> | (that's odd, I actually know a fair bit of the smtp protocol, I was implementing that for node.js as well) |
| 15:48 | <jgraham> | I know roughly nothing about smtp |
| 15:48 | <micheil> | so, what, you mean connecting to a server, then faking a connection, like connecting via telnet |
| 15:49 | <gsnedders> | jgraham: s/ about.*// |
| 15:49 | <jgraham> | gsnedders: That is true of everyone though and is therefore a less interesting observation |
| 15:49 | <jgraham> | micheil: Yes |
| 15:50 | <micheil> | right, but that's an attack vector in.. well, pretty much every protocol, isn't it? |
| 15:50 | <micheil> | I mean, even if you do requrie tls / ssl connections, you can still do it. |
| 15:50 | gsnedders | decides to try out geotagging photos from tracks recorded on his phone |
| 15:50 | <jgraham> | micheil: I'm not an expert |
| 15:51 | <jgraham> | But yes it applies to more than just websockets |
| 15:51 | <micheil> | well, of the protocols I've seen, most are somewhat malleable through telnet or ssl telnet |
| 15:51 | <micheil> | so, by saying that websockets requires more then any other protocol seems rather odd to me. |
| 15:52 | <jgraham> | It's the other way around; you shouldn't be able to talk some other protocol using websockets |
| 15:52 | <jgraham> | just like you can't talk smtp by carefully constructing http requests |
| 15:52 | <micheil> | although, we have to remember that websockets are an extension to http. |
| 15:53 | <jgraham> | (so websockets shouldn't be like telnet which does allow you to talk random other protocols) |
| 15:53 | <micheil> | unless of course you make them not an extension on http |
| 15:53 | <jgraham> | They are not really an exension of HTTP |
| 15:53 | <micheil> | at the same instance, a websocket client probably couldn't talk to smtp |
| 15:54 | <micheil> | jgraham: well why aren't they a separate protocol from the start then? |
| 15:54 | <micheil> | eg, using a custom packet format, etc. |
| 15:55 | <jgraham> | micheil: I don't recall everything but it is likely to do with playing nice with existing infrastructure |
| 15:55 | <micheil> | right. |
| 15:55 | <micheil> | sorry, this is all a bit confusing, is it we currently have something that plays with existing infrastructure, but someone else saying that's a security flaw? |
| 15:56 | <jgraham> | No it's only a security flaw if you can abuse the protocol |
| 15:56 | <micheil> | hmm.. it just occurred to me that it may, and may only just be possible to connect to a websocket server using an xmlhttprequest |
| 15:56 | <micheil> | because you have access to the headers on a xmlhttprequest |
| 16:03 | <jgraham> | I don't think that matters |
| 16:04 | <jgraham> | The problem is using websockets to access something that isn't websockets |
| 16:06 | <micheil> | from client or server? |
| 16:06 | <jgraham> | client |
| 16:06 | <micheil> | hm... |
| 16:07 | <micheil> | I don't think that'd be possible, as the client initiates with that GET request |
| 16:07 | <micheil> | which most other protocols would not understand, would they? |
| 16:07 | <jgraham> | Yeah probably most. The trick is to make it "all" |
| 16:08 | <micheil> | well, I can't think of one off the top of my head that would understand a http request but not be a http server |
| 16:09 | <jgraham> | The argument is that "I can't think of why this won't work" isn't good enough for security |
| 16:10 | <micheil> | true |
| 16:10 | <micheil> | it sort of like saying that someone abusing an smtp client could maybe pass off as something else. |
| 16:12 | <micheil> | there's so many different protocols, that with enough time & effort, you could probably pass on off for the other |
| 17:01 | <jgraham> | micheil: With the current websockets handshake you would need to trick the server into responding with the right value computed from the random bytes and th key headers |
| 17:01 | <jgraham> | That seems challenging; the question is whether it is good enough |
| 17:15 | <gsnedders> | 7.15km, I think that counts as a reasonable walk |
| 18:21 | <jgraham> | Sigh. html5lib is crashing python |
| 18:21 | <jgraham> | Well I gues lxml is really to blame |
| 18:21 | <jgraham> | But still I have no idea why this is happening... |
| 18:21 | <jgraham> | (it works fine to run the same code in ipython) |
| 18:31 | <Dashiva> | Agh, not the list @type thing again |
| 18:32 | <Dashiva> | Unless there's a <ref> element to do automatic backreferences, it makes no sense to call it semantic |
| 18:35 | <jgraham> | http://news.ycombinator.com/item?id=1369950 -- we need a html5 parser in Haskell :) |
| 18:35 | <Dashiva> | I thought Philip` already had one |
| 18:35 | <jgraham> | That was O'Caml |
| 18:35 | <Dashiva> | Oh |
| 18:36 | <gsnedders> | jgraham: I know a bunch of Haskell fanbois who deal with HTML and related stuff... |
| 18:37 | <jgraham> | "a bunch" == 2 |
| 18:37 | <gsnedders> | True |
| 18:37 | <jgraham> | Pretty disappointing if we were talking about bananas |
| 18:37 | <gsnedders> | But we're not talking about bananas. |
| 18:38 | <jgraham> | Depends what ou think about Haskell fanbois really |
| 18:38 | <Dashiva> | I usually buy bananas in bunches of 2 |
| 18:38 | <Dashiva> | They go overripe too fast to buy more at a time |
| 18:38 | <jgraham> | I'm pretty sure that would be a pair of bananas |
| 18:39 | <Dashiva> | No, see, there's a big bunch in the store, and then I split it into two smaller bunches, one of which has two |
| 18:39 | <jgraham> | If you split it into N-1 and 1, would you describe it as a bunch of one? |
| 18:39 | <Dashiva> | No, because then there would be no bunching, just a single banana |
| 18:39 | <Dashiva> | But the bunch of two is a fully connected entity |
| 18:40 | <Dashiva> | If you split them apart, it'd be a pair of bananas |
| 18:40 | <jgraham> | Nevertheless "bunch" typically implies "large group" |
| 18:42 | <Dashiva> | But this isn't a normal-size bunch, it's a rather small bunch |
| 18:43 | <jgraham> | It depends if the critical feature of being a bunch in this case is a) banananess b) connectedness c) magnitude |
| 18:44 | <jgraham> | I guess b) is plausible |
| 20:36 | <gsnedders> | Ryanair is evil. The flight times are close to what I want. If the times of the flights on Friday and Saturday were the other way around everything would be fine... |
| 20:37 | <gsnedders> | Well, apart from the fact it's still Ryanair |
| 20:37 | <gsnedders> | But at least I could fly at the time of day I want. |
| 20:37 | <gsnedders> | (Which is about all you can wish for with Ryanair) |
| 21:01 | <Hixie> | jgraham: to a very close approximation, you can't send a handshake with websocket that looks different enough from HTTP for a cross-protocol attack to be an issue |
| 21:18 | <jgraham> | Hixie: Too many negatives combined with "approximaion" |
| 21:19 | <Hixie> | the current handshake is fine |
| 21:19 | <jgraham> | Hixie: That's what I'm hoping :) |
| 21:22 | <jgraham> | I hate OSX |
| 21:23 | <jgraham> | Could adobe please release lightroom for linux |
| 21:23 | <jgraham> | Thaen all I would need would be some decent non-apple laptop (or even an apple laptop running linux) and I could be happy |
| 21:26 | <jgraham> | (I am trying to rebuild lxml to see if the previous crash has been fixed and it doesn't compile. No one on other platforms has these issues) |
| 21:47 | <jgraham> | lxml issues fixed... finally |
| 23:52 | <boblet> | anyone like to give me some feedback on a flowchart for sectioning content (the dreaded article vs section difference etc)? |
| 23:54 | <boblet> | aaw |