Options:
- # Session Start: Mon Apr 28 00:00:00 2008
- # Session Ident: #whatwg
- # [00:00] <hsivonen> indeed it appears that the tokenizer's main loop never gets compiled
- # [00:00] <hsivonen> that's dumb!
- # [00:00] <hsivonen> leaving the most important thing uncompiled
- # [00:00] <hsivonen> wtf?
- # [00:01] <Philip`> It's strange that even the server VM doesn't do that
- # [00:02] * Philip` likes languages with predictable performance :-)
- # [00:03] <hsivonen> I'd love to have some radically traditional compilation right now
- # [00:03] <Philip`> GCJ!
- # [00:05] <Philip`> Or use a series of sed scripts to convert the tokeniser into a JNI C++ component
- # [00:05] <hsivonen> Philip`: not an entirely bad idea
- # [00:06] <Philip`> Uh oh
- # [00:06] <Philip`> (Which of the ideas do you mean?)
- # [00:07] <Philip`> (not that it would affect my reaction much)
- # [00:07] * jgraham predicts it's not the sed option
- # [00:07] <hsivonen> sed to C++
- # [00:07] * Quits: qwert666 (n=qwert666@acau177.neoplus.adsl.tpnet.pl) ("Leaving")
- # [00:08] * jgraham needs to polish his crystal ball
- # [00:19] * Quits: weinig (n=weinig@adsl-75-36-185-28.dsl.pltn13.sbcglobal.net)
- # [00:25] <hsivonen> but seriously, how can it be a good idea to leave the largest methods uncompiled
- # [00:25] <hsivonen> those are almost sure to be parser code
- # [00:25] <hsivonen> or generated code
- # [00:25] <hsivonen> i.e. stuff that should be Fast
- # [00:50] <annevk> http://www.p01.org/releases/DHTML_contests/files/20lines_twinkle/ is cool
- # [00:51] <annevk> i should put that on a slide calling it "the new <marquee>
- # [00:51] <annevk> "
- # [00:53] <Philip`> annevk: That's an excellent idea - <marquee><canvas/></marquee>
- # [00:53] <Philip`> Works quite nicely on that 20lines_twinkle page
- # [00:55] <hsivonen> now I need a tool that shows me the bytecode sizes of my methods
- # [00:55] <annevk> Philip`, hehe, that makes it toaly crazy :)
- # [00:55] <annevk> (I quite like the edit source function of Opera)
- # [00:57] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
- # [00:57] <Philip`> hsivonen: javap -c ClassName
- # [00:57] <Philip`> shows disassembly, including instruction numbering
- # [00:58] * Quits: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu) (Read error: 104 (Connection reset by peer))
- # [00:58] * Joins: jacobolus1 (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
- # [01:01] <hsivonen> Philip`: it doesn't show the method I'm looking for
- # [01:02] <Philip`> Add -private ?
- # [01:03] <hsivonen> yeah. thanks
- # [01:04] * Joins: tndH_ (i=Rob@83.100.253.115)
- # [01:04] * tndH_ is now known as tndH
- # [01:05] <hsivonen> I need to spilt out NCR value handling
- # [01:08] * htmlfivedotnet suggests http://www.sun.com/software/vmware/getit.jsp
- # [01:10] <hsivonen> Philip`: so each instruction number corresponds to one byte op and one byte arg, right?
- # [01:10] <hsivonen> so the size in roughly number of instructions times two?
- # [01:16] <hsivonen> nope. times one
- # [01:17] <Philip`> hsivonen: javap shows the byte offset of each instruction, so you should be able to just look at the last one in the method
- # [01:17] <Philip`> (Instructions are variable length; I've got no idea what a sensible average is)
- # [01:18] <hsivonen> now I got the big method to compile
- # [01:18] <hsivonen> much better but still sucks
- # [01:19] * Quits: jgraham (n=james@81-86-210-188.dsl.pipex.com) ("I get eaten by the worms")
- # [01:24] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [01:38] * Quits: tndH (i=Rob@83.100.253.115) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
- # [01:44] * Quits: shepazu (n=schepers@218.246.74.90)
- # [01:50] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) (Read error: 104 (Connection reset by peer))
- # [01:52] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
- # [01:56] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 110 (Connection timed out))
- # [02:13] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
- # [02:31] <Hixie> annevk: yt?
- # [02:31] <Hixie> On Fri, 11 Apr 2008, Anne van Kesteren wrote:
- # [02:31] <Hixie> >
- # [02:31] <Hixie> > Euhm, setItem() takes two strings. Therefore I'd expect null, undefined,
- # [02:31] <Hixie> > etc. to be stringified.
- # [02:31] <Hixie> i don't understand what that means
- # [02:35] <Dashiva> null => 'null'
- # [02:45] * jacobolus1 is now known as jacobolus
- # [02:47] <Hixie> but why?
- # [02:54] * Joins: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [02:54] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [03:07] * Joins: aroben (n=adamrobe@76.111.160.14)
- # [03:18] * Quits: Camaban (n=alee@85-211-181-63.dyn.gotadsl.co.uk) ("Ex-Chat")
- # [03:39] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
- # [04:16] <othermaciej_> what is setItem?
- # [04:16] * othermaciej_ is now known as othermaciej
- # [04:17] <othermaciej> DOM APIs are pretty inconsistent about whether null is treated same as empty string, or same as 'null', when they take a string
- # [04:19] <Hixie> Storage.setItem()
- # [04:19] <Hixie> i guess we'll have to get heycam to decide the default, and then give us a flag thingy for the cases where it's the other way around
- # [04:21] <heycam> Hixie, currently null gets passed as null to DOMString arguments unless the [NoNull] extended attribute appears on it
- # [04:21] <heycam> then it'll always get stringified
- # [04:21] <Hixie> to what?
- # [04:21] <heycam> to 'null'
- # [04:21] <Hixie> oh
- # [04:21] <Hixie> is that ever what we want?
- # [04:21] <Hixie> i'd have expect it to be null or ''
- # [04:22] <heycam> i think i remember some things actually stringifying the parameter, resulting in 'null'
- # [04:22] <heycam> was it .textContent? dunno now.
- # [04:34] * Joins: Camaban (n=alee@85-211-181-63.dyn.gotadsl.co.uk)
- # [04:40] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
- # [04:46] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [05:05] * Quits: Camaban (n=alee@85-211-181-63.dyn.gotadsl.co.uk) ("Ex-Chat")
- # [05:24] * Quits: roc (n=roc@202.0.36.64)
- # [05:25] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [05:38] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [06:16] * Joins: weinig (n=weinig@adsl-75-36-185-28.dsl.pltn13.sbcglobal.net)
- # [06:28] * Joins: othermaciej_ (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [06:28] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [06:35] * othermaciej_ is now known as othermaciej
- # [06:41] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
- # [06:45] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
- # [06:59] * Quits: weinig (n=weinig@adsl-75-36-185-28.dsl.pltn13.sbcglobal.net)
- # [07:00] * Joins: weinig (n=weinig@adsl-75-36-185-28.dsl.pltn13.sbcglobal.net)
- # [07:03] * Joins: tantek (n=tantek@c-76-126-35-151.hsd1.ca.comcast.net)
- # [07:19] * Joins: MikeSmith (n=MikeSmit@EM117-55-20-253.pool.e-mobile.ne.jp)
- # [07:21] * Quits: weinig (n=weinig@adsl-75-36-185-28.dsl.pltn13.sbcglobal.net)
- # [07:46] * Quits: tantek (n=tantek@c-76-126-35-151.hsd1.ca.comcast.net)
- # [07:46] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
- # [07:51] * Joins: jgraham (n=james@81-86-210-188.dsl.pipex.com)
- # [07:57] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
- # [08:00] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [08:01] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [08:11] * Quits: jgraham (n=james@81-86-210-188.dsl.pipex.com) ("I get eaten by the worms")
- # [08:21] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [08:22] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [08:25] <jacobolus> hmm. this question had no response in #webkit, so i'll try here. does anyone know what the proper behavior is for rendering a table where the tbody has a specific height set in css?
- # [08:25] <jacobolus> webkit ignores the height, ff2 makes it take up that much space, but leaves rows rendering as they had, ff3 expands rows until they fill up the specified height
- # [08:25] <jacobolus> this doesn't seem to really be covered by http://www.w3.org/TR/CSS21/tables.html
- # [08:26] <jacobolus> example: http://cs179-spring-2008.seas.harvard.edu/wheatmuffin/prototype/index_2008.04.27-3.html
- # [08:26] <jacobolus> here, ff2 does what I want it to, while the other two don't
- # [08:26] <jacobolus> if this is unspecified, is there some better way of achieving the same effect?
- # [08:26] * Joins: tndH_ (i=Rob@83.100.253.115)
- # [08:26] * tndH_ is now known as tndH
- # [08:28] <jacobolus> opera also seems to ignore it
- # [08:29] <Hixie> jacobolus: see css
- # [08:29] <Hixie> iirc 'height' doesn't apply to table sections
- # [08:30] <jacobolus> all elements but non-replaced inline elements, table columns, and column groups
- # [08:30] <jacobolus> which would seem to imply it should apply to row groups
- # [08:31] <jacobolus> the behavior difference between ff2 and ff3 is also puzzling though
- # [08:32] * Joins: heycam (n=cam@203-217-88-240.dyn.iinet.net.au)
- # [08:34] <jacobolus> Hixie: in general, what happens to heights in tables seems rather underspecified
- # [08:35] <Hixie> yeah
- # [08:35] <Hixie> indeed
- # [08:35] <Hixie> let the wg know
- # [08:36] <jacobolus> what's the best way to do that?
- # [08:37] <jruderman> http://landfill.bugzilla.org/complaints/show_bug.cgi?id=22
- # [08:38] <jacobolus> jruderman: there are no steps to reproduce there
- # [08:38] <jruderman> jacobolus: if you think of good ones, you should add them
- # [08:39] <jacobolus> jruderman: also, no expected behavior vs. actual behavior
- # [08:39] <jruderman> otoh, it's a complaint system, so not everything needs steps to reproduce
- # [08:39] <jacobolus> :p
- # [08:39] <jruderman> for example, http://landfill.bugzilla.org/complaints/show_bug.cgi?id=21 does fine without them
- # [08:40] <jacobolus> Hixie: wait, is the css 3 tables spec really password protected?
- # [08:41] <jacobolus> (it's a working draft, according to http://www.w3.org/Style/CSS/current-work)
- # [08:41] <jacobolus> or does that just mean they don't have anything yet?
- # [08:44] <Hixie> don't ask me, i gave up on the csswg a year or more ago
- # [08:44] <jacobolus> heh. fair enough
- # [08:45] <jacobolus> well, any suggestions for how to get a scrollable tbody with a fixed thead, without setting the height of the tbody and setting its overflow-y to scroll?
- # [08:45] <jacobolus> (I suppose that's a bit off topic for this channel; not sure where else I'd ask)
- # [08:46] <othermaciej> css wg is planning more openess
- # [08:46] <othermaciej> that process is moving at a gradual place
- # [08:48] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [08:50] <Hixie> i'd have used another g word
- # [08:50] <Hixie> "glacial"
- # [08:53] <Hixie> but to each his own
- # [08:58] * Quits: aroben (n=adamrobe@unaffiliated/aroben)
- # [09:02] <annevk> Hixie, for quite a few things null becomes 'null'
- # [09:02] <annevk> iirc
- # [09:02] <annevk> for IE compat
- # [09:02] <Hixie> k
- # [09:03] <Hixie> someone should let me know what they are so i can pepper [NoNull]s around the spec
- # [09:03] <Hixie> :-)
- # [09:06] * Quits: MikeSmith (n=MikeSmit@EM117-55-20-253.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
- # [09:11] <annevk> Hixie, "<span>browsing content</span>"
- # [09:13] <Dashiva> othermaciej: Does refusing IRC logging make up part of that process? ;)
- # [09:13] <othermaciej> Dashiva: they just want the logging done in a carefully considered, measured, slow way
- # [09:18] * Dashiva avoids further comment
- # [09:18] * Quits: sverrej__ (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
- # [09:19] <jacobolus> Dashiva: someone might prevent you from running for world leader 20 years from now, if they see what you wrote in some technical IRC channel!
- # [09:20] <Dashiva> That reminds me of the conspiracy of light mail when Hyatt became editor
- # [09:23] <jacobolus> Dashiva: and you see, because of IRC logs (http://krijnhoetmer.nl/irc-logs/html-wg/20070423#l-55) now zcorpan is implicated too.
- # [09:23] <Dashiva> That's okay, he was part of the vast browser wing conspiracy already
- # [09:24] <annevk> and also proud member of the secret WHATWG cabal
- # [09:25] <Hixie> not gonna be secret for long if y'all keep talking about it in public!!!
- # [09:26] <othermaciej> I thinkt it was top secret that the secret cabal is secret
- # [09:26] <othermaciej> how can you just openly admit that it is secret like that?
- # [09:27] * annevk is not sure what to say
- # [09:27] <Dashiva> One of these days I'm actually going to join #whatwg-secret-treehouse
- # [09:27] * annevk blames krijn for logging
- # [09:27] * jacobolus hears nothing
- # [09:30] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
- # [09:36] <jacobolus> Hixie: do people *really* want modal dialogs in html5? modal dialogs suck :/
- # [09:37] <jacobolus> can't you just ignore them and hope they go away? :)
- # [09:37] <Hixie> both mozilla and safari were forced to implement showModalDialog()
- # [09:37] <Dashiva> If you don't give them modal dialogs, they create them with CSS and ruin your page
- # [09:37] <Hixie> apparently if you don't give them modal dialogs, they don't support our browser
- # [09:37] <Dashiva> (or that)
- # [09:46] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
- # [09:46] <annevk> should there be a way to do in page modal dialogs? like limit all interactivity to a given DOM element and descendents
- # [09:48] <annevk> so you can implement your own menus and such in case the native ones are not good enough
- # [09:50] <jacobolus> annevk: you mean instead of dumping a gigantic invisible un-clickable element over the whole page, then putting the new element w/ a higher z-index?
- # [09:51] <jacobolus> that seems to work reasonably well in my experience
- # [09:51] <jacobolus> but maybe isn't super clean (requires javascript)
- # [09:51] <jacobolus> annevk: doesn't seem like enough of a use case to add as a feature though
- # [09:52] <jacobolus> also, encouraging people to use modal dialogs is bad :)
- # [09:53] <jgraham__> annevk: "should there be a way [...] to do modal dialogs" is already "no but we have to sped the existing method. I don't think we need authors to have more ways to annoy their users :)
- # [09:53] <jgraham__> s/sped/spec/
- # [09:53] <annevk> I was mostly thinking about contextmmenus and normal menus
- # [09:53] <annevk> and similar uses
- # [09:53] <annevk> which are modal in some way too
- # [09:54] <annevk> though they're arguably not dialogs so I messed that up
- # [09:55] <jgraham__> Well I guess if you can enforce the "click anywhere off the menu and normal operations are restored" behaviour then it wouldn't be so bad
- # [09:55] <Hixie> we have a solution for menus already
- # [10:01] <krijn> -_-
- # [10:03] * Quits: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) (Read error: 110 (Connection timed out))
- # [10:05] * Joins: zcorpan_ (n=zcorpan@pat-tdc.opera.com)
- # [10:14] * Joins: itpastorn (n=itpastor@ne.keryx.se)
- # [10:15] * Joins: itpastor1 (n=itpastor@ne.keryx.se)
- # [10:26] * Joins: itpastor2 (n=itpastor@ne.keryx.se)
- # [10:26] * Parts: itpastor2 (n=itpastor@ne.keryx.se)
- # [10:27] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Remote closed the connection)
- # [10:28] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
- # [10:32] * Joins: itpastor3 (n=itpastor@ne.keryx.se)
- # [10:33] <hsivonen> it's a bit silly that there should be two parse errors in '<!DOCTYPE html SYS'EOF
- # [10:33] * Quits: itpastor3 (n=itpastor@ne.keryx.se) (Client Quit)
- # [10:35] <Hixie> you only have to report one :-)
- # [10:35] <Philip`> It's a bit silly that '<!DOCTYPE' has more parse errors than either '<!DOCTYP' or '<!DOCTYPE '
- # [10:35] <hsivonen> Hixie: the test cases want two
- # [10:35] * Quits: itpastorn (n=itpastor@ne.keryx.se) (Read error: 110 (Connection timed out))
- # [10:35] <Hixie> the test cases are fascist
- # [10:36] <hsivonen> but then they want only one for '<!DOCTYPE html PUBLIC'EOF
- # [10:36] <hsivonen> that's painful
- # [10:36] * Joins: qwert666 (n=qwert666@acaq114.neoplus.adsl.tpnet.pl)
- # [10:38] <hsivonen> Philip`: I'm back to reasonable perf by keeping the tokenization loop just under 8000 bytes
- # [10:39] <Philip`> hsivonen: Hopefully future versions HotSpot (and other people's JVMs) won't have a smaller limit than that - seems a little dodgy but I'm not sure what else you could do :-/
- # [10:41] <hsivonen> Philip`: tweaking things for HotSpot are painful and silly enough. I'm not going to worry too much about IBM or BEA or whatever JVMs at this point
- # [10:42] <hsivonen> Philip`: anyway, any conclusions yesterday about switch itself are wrong
- # [10:42] <hsivonen> the thing that makes switch "death slow" is that making a huge switch easily makes the method too large
- # [10:44] * Quits: gavin (n=gavin@firefox/developer/gavin)
- # [10:44] * Quits: itpastor1 (n=itpastor@ne.keryx.se) (Read error: 110 (Connection timed out))
- # [10:45] <hsivonen> now I have to add a couple of states for [CDATA[ it'll be interesting to see if doing so breaks the limit again
- # [10:46] <hsivonen> also, I wonder if object fields and spilled locals make a perf difference
- # [10:46] <hsivonen> and how many locals fit it registers on x86_64?
- # [10:47] * Joins: gavin (n=gavin@firefox/developer/gavin)
- # [10:50] <annevk> you're going to add math support?
- # [10:50] * Quits: Lachy (n=Lachlan@85.196.122.246) (Read error: 110 (Connection timed out))
- # [10:50] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
- # [10:50] <Hixie> anyone got a pool going on how long it'll take for the svgwg to get back to us, btw?
- # [10:51] <annevk> given that Doug is on holiday I guess it will take a while
- # [10:52] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
- # [10:54] <Hixie> i guess we'll wait until after webforms2 is dealt with
- # [10:56] <annevk> eternity+1
- # [10:56] <Philip`> Interacting with other WGs is fun
- # [10:56] <Hixie> actually the dealine for wf2 is rapidly approaching
- # [10:57] <Hixie> june? july? something like that?
- # [10:57] <annevk> true
- # [10:57] * annevk looks
- # [10:57] <annevk> July 2008 per http://www.w3.org/2007/10/forms-tf/charter-proposal
- # [10:57] <annevk> (and some e-mail that states the charter has been approved by the TF by implicit consent)
- # [10:58] <hsivonen> annevk: yes, I'm going to add math support
- # [10:58] <hsivonen> but I think I should prepare XTech slides first
- # [11:03] <annevk> hmm, XTech slides...
- # [11:05] * Joins: webben (n=benh@nat/yahoo/x-20346b6ead3423c5)
- # [11:07] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
- # [11:13] * Joins: ROBOd (n=robod@89.122.216.38)
- # [11:43] * hsivonen finds -XX:-DontCompileHugeMethods
- # [11:49] <hsivonen> it's particularly Not Nice that the option isn't documented in the usual HotSpot documentation
- # [11:53] <Philip`> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6453531 - "The VM is tuned for compiling for the common programming paradigm, which includes generally small methods." - it would be nice if it was merely tuning, rather than order-of-magnitude differences
- # [11:59] <hsivonen> I'd be interested to know when compiling a > 8000-byte method actually hurts
- # [12:00] <Philip`> It would hurt when the compiler is O(n^2)
- # [12:01] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
- # [12:01] <hsivonen> perhaps, but the 8000 sucks big time for parsers and generated code
- # [12:02] <hsivonen> it's quite reasonble to compile a program written in a non-Java language into one huge Java method with a lot of goto
- # [12:04] * Joins: webben_ (n=benh@nat/yahoo/x-04d1d3040a73c5d7)
- # [12:11] <Philip`> Maybe it's a problem of trying to optimise the JVM for benchmarks and for common applications, since that's how people try to measure performance, and any code that does something significantly different will lose out
- # [12:13] <hsivonen> well, yeah, but it's not like tokenizer state machines (generated or hand-written) or dynamic or functional languages compiled to Java are rare and bizarre these days
- # [12:16] <hsivonen> it seems that other people who've hit this problem are doing something as enterprisey as JSP!
- # [12:16] * Quits: webben (n=benh@nat/yahoo/x-20346b6ead3423c5) (Read error: 110 (Connection timed out))
- # [12:16] * Joins: shepazu (n=schepers@218.246.74.90)
- # [12:27] <Philip`> hsivonen: Enterprisey people can just buy a 16-core CPU to replace their old server, and that'll make up for the loss of performance between Java 1.5 and 1.6
- # [12:30] <Philip`> Hmm, I wonder who's making 16-core CPUs
- # [12:30] <Philip`> Oh! Sun is - how convenient
- # [12:47] * Joins: webben (n=benh@nat/yahoo/x-7a33d54a595382d3)
- # [13:03] * Quits: webben_ (n=benh@nat/yahoo/x-04d1d3040a73c5d7) (Read error: 113 (No route to host))
- # [13:05] * Quits: webben (n=benh@nat/yahoo/x-7a33d54a595382d3)
- # [13:08] * Joins: webben (n=benh@nat/yahoo/x-f4817272b1b0afc3)
- # [13:16] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
- # [13:22] * Quits: webben (n=benh@nat/yahoo/x-f4817272b1b0afc3)
- # [13:43] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
- # [14:33] * Quits: heycam (n=cam@203-217-88-240.dyn.iinet.net.au) ("bye")
- # [14:35] * Quits: qwert666 (n=qwert666@acaq114.neoplus.adsl.tpnet.pl) ("Leaving")
- # [14:35] * Joins: qwert666 (n=qwert666@acaq114.neoplus.adsl.tpnet.pl)
- # [14:37] * Joins: webben (n=benh@nat/yahoo/x-2f02c789275f5bf3)
- # [15:01] * Joins: aaronlev (n=chatzill@nat/ibm/x-d7dac1d6cd3fe2ee)
- # [15:05] * Joins: Camaban (n=alee@85-211-181-63.dyn.gotadsl.co.uk)
- # [15:13] * Joins: qwert666_ (n=qwert666@acaq114.neoplus.adsl.tpnet.pl)
- # [15:15] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
- # [15:22] * Joins: phsiao (n=shawn@c-71-233-78-251.hsd1.ma.comcast.net)
- # [15:25] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
- # [15:30] * Quits: phsiao (n=shawn@c-71-233-78-251.hsd1.ma.comcast.net)
- # [15:32] * Quits: qwert666 (n=qwert666@acaq114.neoplus.adsl.tpnet.pl) (Connection timed out)
- # [15:40] * Quits: aaronlev (n=chatzill@nat/ibm/x-d7dac1d6cd3fe2ee) (Read error: 104 (Connection reset by peer))
- # [15:42] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
- # [15:59] * Joins: inimino1 (n=inimino@atekomi.inimino.org)
- # [16:02] * Quits: inimino (n=inimino@c-75-70-128-190.hsd1.co.comcast.net) ("WeeChat 0.2.6")
- # [16:02] * inimino1 is now known as inimino
- # [16:11] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
- # [16:24] * Joins: billmason (n=billmaso@ip227.unival.com)
- # [16:32] * Quits: zcorpan_ (n=zcorpan@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
- # [16:37] * Joins: aroben (n=adamrobe@unaffiliated/aroben)
- # [16:38] * Joins: aroben_ (n=adamrobe@c-71-58-57-150.hsd1.pa.comcast.net)
- # [16:39] * Quits: aroben_ (n=adamrobe@unaffiliated/aroben) (Client Quit)
- # [16:39] * Joins: aroben_ (n=aroben@c-71-58-57-150.hsd1.pa.comcast.net)
- # [16:47] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
- # [16:47] * qwert666_ is now known as qwert666
- # [16:51] * Joins: qwert666_ (n=qwert666@acap154.neoplus.adsl.tpnet.pl)
- # [16:57] <htmlfivedotnet> Philip: Of course they are. And they cost how much? 10K Euros?
- # [16:57] * Quits: billmason (n=billmaso@ip227.unival.com) (".")
- # [16:58] * Quits: aroben (n=adamrobe@unaffiliated/aroben) (Read error: 110 (Connection timed out))
- # [17:01] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
- # [17:02] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
- # [17:02] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
- # [17:05] <Philip`> htmlfivedotnet: The 16-core CPUs? I have no idea how much they are likely to be, but I'd have to guess they're not cheap :-)
- # [17:05] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Client Quit)
- # [17:09] <gsnedders> Philip`: Sun aren't making 16-core CPUs. They only make 8-core ones (which can run 64 threads concurrently).
- # [17:09] * Quits: qwert666 (n=qwert666@acaq114.neoplus.adsl.tpnet.pl) (Connection timed out)
- # [17:09] * aroben_ is now known as aroben
- # [17:12] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
- # [17:13] <Philip`> gsnedders: 8 cores wouldn't be enough to make up for an order of magnitude performance loss, so I was thinking of the not-quite-released Rock processors which Wikipedia says has 16 cores :-p
- # [17:13] <gsnedders> ah, Rock. That isn't released! That doesn't count :P
- # [17:15] * Joins: Lachy (n=Lachlan@85.196.122.246)
- # [17:16] <Philip`> gsnedders: I never said Sun was actually shipping 16-core processors, only that they were making them
- # [17:16] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
- # [17:16] <Philip`> and http://blogs.sun.com/jonathan/entry/rock_arrived indicates that they have made at least one
- # [17:24] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
- # [17:25] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [17:26] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [17:49] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
- # [17:50] * Joins: RCanine (n=RCanine@cpe-76-168-1-38.socal.res.rr.com)
- # [17:56] * Quits: Camaban (n=alee@85-211-181-63.dyn.gotadsl.co.uk) ("Ex-Chat")
- # [18:03] <htmlfivedotnet> Has anyone else heard here about MS plans to throw CSS3 under the bus?
- # [18:04] <htmlfivedotnet> oh god. nevermind. please don't listen to me. i just read an april fools joke that spanned across two sites. i hate april 1st.
- # [18:22] * Joins: KevinMarks (n=KevinMar@nat/google/x-baafe412eb207292)
- # [18:26] <gsnedders> htmlfivedotnet: They already support some CSS3 modules (such as almost all of selectors) in IE7 :P
- # [18:31] * Quits: aroben (n=aroben@unaffiliated/aroben)
- # [18:31] * Joins: aroben (n=aroben@unaffiliated/aroben)
- # [18:34] <htmlfivedotnet> gsnedders: Yeah. I knew that too. I just woke up, haven't had my coffee, and wasn't thinking straight. Oh well.
- # [18:41] <htmlfivedotnet> I have a question, and please let me know if this isn't a good place to ask, and i'll keep them out of here, but there are pages, like the google cache page, that use frames. With the html5 spec, would the only way to be able to display the page in a similar manner be to use scripting? And if so, doesn't it seem inefficient to remove functionality from the html spec? It seems like the client-side and server-side would have to d
- # [18:42] <takkaria> htmlfivedotnet: your comment was cut off at "would have to d"
- # [18:42] <htmlfivedotnet> do more work in a case like this
- # [18:43] * Joins: jgraham_ (n=james@81-86-210-188.dsl.pipex.com)
- # [18:44] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
- # [18:45] <Philip`> htmlfivedotnet: Google cache has never used frames, as far as I've seen - it just adds some code into the top of the page to create its ugly box with information
- # [18:45] <Philip`> Might you be thinking of Google Image search results instead?
- # [18:46] <htmlfivedotnet> yes. i'm sorry, i do mean google image search.
- # [18:46] <Philip`> I suppose that could be implemented using <iframe> instead
- # [18:47] <Philip`> Don't know if there would be any problems with that approach
- # [18:47] <htmlfivedotnet> well, there would be the backwards compatibility issue
- # [18:47] <Philip`> <iframe> is backwards-compatible
- # [18:48] <htmlfivedotnet> i know recent browsers don't behave the same with an iframe in all cases, at least as far as setting it to the page width, and positioning (which i guess is a css-issue moreso)
- # [18:48] <htmlfivedotnet> which is i guess where the major part of the scripting would come in, and window resizing.
- # [18:49] <Philip`> Ah, okay
- # [18:50] <hsivonen> hmm. Image Report shows that I've written bad alt text in 2003
- # [18:50] * Philip` isn't quite sure of what problems there are
- # [18:51] * Quits: KevinMarks (n=KevinMar@nat/google/x-baafe412eb207292) ("The computer fell asleep")
- # [18:52] <htmlfivedotnet> accessibility is a major one, from what i've heard, as well as search engine crawling: they determine it to be a separate page (which may or may not be the intended result... i'm not sure)
- # [18:53] <Philip`> htmlfivedotnet: Perhaps it's reasonable to say that browsers will have improved in the years before everyone should start using HTML 5, and so iframe CSS bugs won't matter much by then
- # [18:53] <Philip`> and people like Google can still use <frameset> if they want to be more compatible with really old browsers, because they don't care whether their code validates or not
- # [18:55] <htmlfivedotnet> philip: good point. i guess i don't see the *ahem* "sense of logic" in ditching frames, but keeping something that doesn't have any practical use like the "font" element... unless its specifically there because wysiwyg editors currently like it
- # [18:56] <Philip`> htmlfivedotnet: It seems very likely that <font> will be removed from the spec, since everyone hates it, and Hixie just hasn't got around to editing that section yet
- # [18:57] <Philip`> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#the-font - "This entire section will probably be dropped."
- # [18:59] <htmlfivedotnet> philip: Well that sets my mind at ease. Haven't read that part in a while. Just wanted to say my piece, thank you :-)
- # [19:00] * gsnedders notes that WYSIWYG editors will just move over to span/div instead :P
- # [19:00] <Philip`> gsnedders: Is that a bad thing?
- # [19:00] <gsnedders> Philip`: It's no better than the status quo.
- # [19:01] <gsnedders> But there again, due to the very nature of WYSIWYG editors they will always output presentational HTML
- # [19:01] <Philip`> Hixie said the <font style> thing was an attempt to attach the stigma of 'font' onto 'style' (to discourage people from using 'style'), but it seems to have just attached the stigma to the HTML5 spec instead,
- # [19:01] <Philip`> s/,$//
- # [19:01] * Quits: jgraham_ (n=james@81-86-210-188.dsl.pipex.com) ("I get eaten by the worms")
- # [19:02] <htmlfivedotnet> i just assumed that it was to allow legacy WYS editors to have an easier transition to new specs
- # [19:03] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
- # [19:04] * Joins: KevinMarks (n=KevinMar@nat/google/x-d248d460624dafc8)
- # [19:04] <Philip`> htmlfivedotnet: In the current spec, the only attribute allowed on font is style, and the style attribute is not allowed on any other element; so I think that makes it harder for existing WYSIWYG editors to transition, since they either use <font face size color> or they use <span style>
- # [19:04] <Philip`> *they currently use either ...
- # [19:07] <htmlfivedotnet> ah. well, i haven't used one in a long while. well cool. thanks for clearing that up
- # [19:07] * Joins: phsiao (n=shawn@nat/ibm/x-77f96780d29b2830)
- # [19:08] * Joins: andersca (n=andersca@nat/apple/x-e3de6591b867d32f)
- # [19:08] <Philip`> gsnedders: Is the status quo a bad thing?
- # [19:08] <gsnedders> Philip`: No, it just seems change for no reason.
- # [19:10] <Philip`> gsnedders: Uh, isn't the point of the status quo that it's *not* a change?
- # [19:10] <gsnedders> Philip`: I said it's no better than the status quo, not that it is the status quo
- # [19:11] <Philip`> gsnedders: Oh, then what is the status quo if it's not using span/div?
- # [19:11] <gsnedders> Philip`: That is the status quo. I meant font@style is no better.
- # [19:12] <Philip`> gsnedders: Ah, I didn't gather that meaning from your statements :-p
- # [19:13] * gsnedders hopes he's less confusing in real life
- # [19:14] <htmlfivedotnet> haha
- # [19:14] <Philip`> gsnedders: When you said "It's no better than the status quo.", I didn't realise that the antecedent of "it" was from half a dozen lines earlier :-)
- # [19:14] <htmlfivedotnet> who's on first gsnedders?
- # [19:15] <gsnedders> htmlfivedotnet: huh?
- # [19:16] * Quits: RCanine (n=RCanine@cpe-76-168-1-38.socal.res.rr.com)
- # [19:16] <htmlfivedotnet> gnsedders: http://www.phoenix5.org/humor/WhoOnFirst.html
- # [19:17] <gsnedders> heh.
- # [19:19] * Joins: jgraham_ (n=james@81-86-210-188.dsl.pipex.com)
- # [19:21] * Quits: jgraham_ (n=james@81-86-210-188.dsl.pipex.com) (Client Quit)
- # [19:23] * Joins: jgraham_ (n=james@81-86-210-188.dsl.pipex.com)
- # [19:24] * Quits: jgraham_ (n=james@81-86-210-188.dsl.pipex.com) (Client Quit)
- # [19:29] * Joins: Camaban (n=alee@77-103-78-94.cable.ubr08.hawk.blueyonder.co.uk)
- # [19:32] * Joins: jwalden (n=waldo@STRATTON-SEVEN-TWENTY-ONE.MIT.EDU)
- # [19:34] * Joins: [CitationNeeded] (i=refugee@elvis.mu.org)
- # [19:35] * Parts: [CitationNeeded] (i=refugee@elvis.mu.org)
- # [19:37] * Joins: blooberry (n=brian@c-76-126-194-196.hsd1.ca.comcast.net)
- # [19:37] * Joins: sverrej (n=sverrej@89.10.27.86)
- # [19:44] <gsnedders> Hmm, if you believe some of my photos' metadata, I've been taking photos on 6th August 2099.
- # [19:45] * Joins: othermaciej (n=mjs@17.203.15.181)
- # [19:45] <Philip`> gsnedders: That metadata would make an excellent basis for the semantic web
- # [19:47] <gsnedders> I think the dates are totally wrong though, I don't think it's even August. I wasn't on Maderia then.
- # [19:48] * Quits: KevinMarks (n=KevinMar@nat/google/x-d248d460624dafc8) ("The computer fell asleep")
- # [19:49] <Philip`> gsnedders: I think you may be missing a more obvious discrepancy in the dates
- # [19:49] <gsnedders> Philip`: I mean discounting the year :)
- # [19:49] <gsnedders> So none of it is right whatsoever :)
- # [19:49] <Dashiva> What about the time zone? :)
- # [19:50] <Philip`> gsnedders: If that's what you meant then you should have said that :-p
- # [19:50] <gsnedders> Dashiva: That isn't given :P
- # [19:50] <gsnedders> Lesson learnt from this: don't take photos of the Firth of Forth. It screws with your camera :P
- # [19:50] <Dashiva> But if it was wrong, you'd have pictures taken at 6 am and stuff
- # [19:50] <gsnedders> (or is that the conclusion?)
- # [19:51] <Philip`> gsnedders: You need to do a more extensive investigation
- # [19:52] <gsnedders> The photos were taken sometime between 23 July 2003 and 22 January 2005.
- # [19:52] <Philip`> I suggest taking photos in the same place with somebody else's camera, and then see whether the ill effects affect you or the camera's owner
- # [19:52] <gsnedders> And I don't remember being on Maderia in that time
- # [19:52] <gsnedders> Philip`: I'll try taking a photo from the train on the way to Cambridge :P
- # [19:53] <Philip`> (Do you mean Madeira, as in Madeira cake?)
- # [19:54] <gsnedders> (I mean Maderia as in the island in the Atlantic Ocean where the Maderia cake originates from)
- # [19:54] * Joins: maikmerten (n=maikmert@Lbfe6.l.pppool.de)
- # [19:55] <Philip`> (Okay, so you do mean Madeira, not Maderia)
- # [19:55] * maikmerten wonders if Hixie is active right now
- # [19:55] <gsnedders> Philip`: Stop picking on the kid with dyspraxia! :P
- # [19:55] <gsnedders> (But yes)
- # [19:56] <gsnedders> (and the cake is spelt the same way)
- # [19:56] <gsnedders> Actually, I can narrow the date down further. It's after 24 July 2003.
- # [19:56] <Philip`> (I was just checking it wasn't some obscure place that I had never heard of and that sounded like somewhere more familiar :-) )
- # [19:56] <gsnedders> (It's a common spelling mistake, actually)
- # [19:57] <Philip`> (Google says only about 1% get it wrong, which is hugely better than the number of people who misspell colour)
- # [19:58] * Quits: othermaciej (n=mjs@17.203.15.181)
- # [19:58] <gsnedders> Moving swiftly on, http://twitter.com/gsnedders/statuses/798868533
- # [20:00] <gsnedders> (There is a story behind that)
- # [20:01] <jwalden> Philip`: color :-P
- # [20:01] <jwalden> </snark>
- # [20:07] * Joins: othermaciej (n=mjs@17.255.92.67)
- # [20:13] * Joins: jgraham_ (n=james@81-86-210-188.dsl.pipex.com)
- # [20:14] * Joins: weinig (n=weinig@17.203.15.172)
- # [20:24] <hsivonen> othermaciej: you may have noticed from the logs that I refactored the Validator.nu parser to use switch instead of methods
- # [20:25] <othermaciej> hsivonen: I didn't
- # [20:25] <othermaciej> hsivonen: use switch instead of methods for what?
- # [20:25] <hsivonen> othermaciej: re: our perf speculation last summer, data now shows that I wasn't nuts to use one method per state
- # [20:25] <hsivonen> othermaciej: tokenizer states
- # [20:26] <hsivonen> switch has other nice qualities, but perf in Java doesn't appear to be one of them
- # [20:31] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Remote closed the connection)
- # [20:33] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
- # [20:34] * Joins: eseidel (n=eseidel@nat/google/x-8c1c8ec49311f4bb)
- # [20:35] * Joins: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com)
- # [20:36] <othermaciej> hsivonen: how did you do your method lookup before?
- # [20:37] <hsivonen> othermaciej: switching to states was method calls. switching to data state was return. there were additional loops around comments and attributes so it wasn't recursive
- # [20:38] <othermaciej> hsivonen: I see
- # [20:39] <othermaciej> if I were coding it in C++, I'd probably use an array of function pointers per state, but a switch statement might indeed be faster
- # [20:39] <othermaciej> (right now our tokenizer is much simpler and more ad-hoc)
- # [20:47] <jwalden> there's a tableswitch JVM instruction that probably sufficiently optimizes things
- # [20:47] * Philip` 's tokeniser spends all its time copying characters between buffers and allocating memory, and no time on the actual switch :-(
- # [20:48] <hsivonen> jwalden: sufficiently, yes, but methods aren't madly worse in Java
- # [20:49] <jwalden> sure
- # [20:49] <jwalden> I wouldn't assert substantial differences between the two
- # [20:49] <hsivonen> in fact, on the client VM in short runs, methods are a bit better
- # [20:49] <hsivonen> I have to rerun my long server VM tests
- # [20:50] <hsivonen> I'm going to keep switch, though, because it enables other nice things
- # [20:50] <jwalden> switch does allow commoning of a case with another case sharing its tail, tho
- # [20:50] <jwalden> without jumping to a different method and having call setup costs
- # [20:51] <Philip`> Methods + inlining would work the same
- # [20:51] <hsivonen> (the other nice things are: 1) full suspendability at any point, 2) app owning the IO loop, 3) document.write() and 4) line-by-line porting to C, C++ or Objective-C)
- # [20:52] <Philip`> (I want a port to JavaScript)
- # [20:52] <jwalden> sure, if you can do it; that's getting into tricky territory in terms of implementation, tho
- # [20:52] <jwalden> which is what matters, this all being theoretically equal
- # [20:52] <hsivonen> Philip`: you should check if GWT can compile the Validator.nu HTML parser into JS
- # [20:53] <Philip`> hsivonen: Compiling Java into JS sounds like more evil than I could bear
- # [20:53] * Quits: jruderman (n=jruderma@c-67-180-174-213.hsd1.ca.comcast.net)
- # [20:53] * Quits: othermaciej (n=mjs@17.255.92.67)
- # [20:53] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
- # [21:02] * Joins: othermaciej (n=mjs@17.203.15.181)
- # [21:02] <jgraham__> More evil than Philip`can bear? Isn't that some theoretical upper bound on evilness? :)
- # [21:02] <hsivonen> Philip`: re: copying buffers: that's one area where the Validator.nu HTML parser isn't optimized
- # [21:03] <hsivonen> it always copies element and attribute names, comment contents and attribute values into auxiliary buffers
- # [21:04] <hsivonen> this could be changed to happen only when the input buffer can't be used as the backing store of those buffers
- # [21:04] * Philip` wonders if he should make his parser use UTF-8 everywhere, and just blindly pass char* encoded strings through the tokeniser
- # [21:05] <jgraham__> Philip`: Which parser is this?
- # [21:05] <hsivonen> well, I use UTF-16 everywhere
- # [21:05] <Philip`> jgraham__: The C++ instantiation of my language-independent one
- # [21:05] * jgraham__ was planning to make chtml5lib do that but hasn't actually worked on chtml5lib
- # [21:06] <jgraham__> (where by "that" I mean "use utf-8 everywhere")
- # [21:06] <Philip`> hsivonen: I imagine you don't have much choice in string representation when you're using Java :-)
- # [21:06] <hsivonen> jgraham__: is chtml5lib a line-by-line port of the Python code?
- # [21:06] <jgraham__> hsivonen: chtml5lib is not even vapourware :)
- # [21:06] <jgraham__> But the idea was to follow the python code closely
- # [21:06] <hsivonen> Philip`: I mean, whatever comes before the tokenizer is responsible for not passing lone surrogates to the tokenizer
- # [21:06] <Philip`> Does the spec still say that <table>errôr</table> ought to give a parse error for each character?
- # [21:07] <jgraham__> not necessarily line-by-line
- # [21:07] <hsivonen> jgraham__: you might get better perf in other ways
- # [21:07] <jgraham__> hsivonen: This is true
- # [21:07] <hsivonen> I think both my code and Philip`'s code are likely to lead to more performant C than the html5lib code
- # [21:08] <Philip`> hsivonen: About UTF-16: Ah, right
- # [21:08] <Philip`> What would make an html5lib port non-performant?
- # [21:09] <hsivonen> Philip`: it has more recursion and polymorphism that you'd expect to see in C code
- # [21:09] * Philip` currently just has a big dumb switch and lots of if statements, since his attempts at optimisation had no measurable effect so he took them out again
- # [21:10] <Philip`> hsivonen: Ah, makes sense
- # [21:10] <hsivonen> all my optimizations that make the tokenizer loop over or under 8000 bytes have a very measurable effect :-)
- # [21:10] <jgraham__> It may well have more recursion than python code that aims to be performant
- # [21:11] <Philip`> I solve that by using a language without such arbitrary limits :-)
- # [21:11] <jgraham__> But optimum performance is not a stated design goal (fortunately)
- # [21:11] <Philip`> (Well, I suppose I've occasionally written C++ methods large enough that the compiler simply rejected my program)
- # [21:11] <jgraham__> (although it is obviously nice to be faster)
- # [21:11] <Philip`> jgraham__: There's already a correct implementation of html5lib, in Python, so isn't the whole purpose of chtml5lib to be fast?
- # [21:12] <hsivonen> jgraham__: I thought the goal of chtml5lib was to make Python fast by using C under the hood
- # [21:13] * Quits: othermaciej (n=mjs@17.203.15.181)
- # [21:15] * Joins: othermaciej (n=mjs@17.203.15.181)
- # [21:16] <jgraham__> I mean the design goal of html5lib-in-python
- # [21:16] <jgraham__> Using C is obviously supposed to help perf :)
- # [21:16] <Philip`> Ah, right
- # [21:17] * weinig is now known as weinig|away
- # [21:18] <jgraham__> Although I'm not even clear that the project is worth doing now (globally, it may be for me personally) since Philip`and takkaria and hsivonen may all produce C based html5 parsers which I could write python bindings for
- # [21:18] <jgraham__> "the project" being chtml5lib
- # [21:18] <Philip`> My parser is mostly a toy/experiment so hopefully someone will make a good one instead :-)
- # [21:18] <htmlfivedotnet> is failing 1600 of the 7400 tests a normal behavior, or am i missing libs? (html5lib)
- # [21:19] <jgraham__> htmlfivedotnet: It's not normal but it shouldn't test libs that you don't have either
- # [21:20] <Philip`> htmlfivedotnet: Which version of html5lib?
- # [21:20] <htmlfivedotnet> trunk
- # [21:20] <Philip`> Ran 7650 tests in 23.214s
- # [21:20] <Philip`> FAILED (failures=46, errors=3)
- # [21:20] <Philip`> is what I get on trunk
- # [21:21] <htmlfivedotnet> FAILED (failures=4, errors=1630)
- # [21:21] <jgraham__> Do you have any/all of lxml, BeautifulSoup, pyxdom, chardet?
- # [21:21] <Philip`> (for Python, not Ruby)
- # [21:21] <jgraham__> (and probaly some others I forget)
- # [21:21] * htmlfivedotnet doublechecks lxml
- # [21:22] <htmlfivedotnet> jgraham__: i know i don't have the others
- # [21:23] <jgraham__> Can you tell from the error messages what is failing? (or throw some of the output online and I'll have a look)
- # [21:23] <jgraham__> FAILED (failures=4)
- # [21:23] <jgraham__> is what I get
- # [21:23] * Philip` tries installing chardet
- # [21:23] <jgraham__> My tree seems to have some patches in though :)
- # [21:24] <htmlfivedotnet> test_title_body_mismatched_close, test_title_body_named_charref, test_script, test_script_src
- # [21:24] <Philip`> Ran 7651 tests, failures=46, errors=3
- # [21:24] <htmlfivedotnet> installing lxml gives the same result, but a few different run-time outputs
- # [21:24] * Quits: jgraham_ (n=james@81-86-210-188.dsl.pipex.com) ("I get eaten by the worms")
- # [21:24] <jgraham__> htmlfivedotnet: Those are sanitizer tests. How hard would it be to dump some of the output to a file and put it online somewhere
- # [21:25] <jgraham__> ?
- # [21:25] * Philip` goes home
- # [21:25] <htmlfivedotnet> jgraham__: no problem. one sec
- # [21:25] <htmlfivedotnet> http://pastebin.ca/1000764
- # [21:26] <hsivonen> jgraham__: It would be nice to have automated Java to C, C++ and Objective-C translation for the Validator.nu HTML parser tokenizer and abstract tree builder
- # [21:26] <Philip`> hsivonen: Why not start from an abstract language that avoids the complexities of Java, and convert from that into Java and C and C++ etc?
- # [21:27] <jgraham__> htmlfivedotnet: Those are the same failures I get. What are the errors?
- # [21:27] <hsivonen> Philip`: because I already have a Java impl and C, C++ and Objective-C are structurally similar
- # [21:27] <hsivonen> nn
- # [21:27] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
- # [21:27] <htmlfivedotnet> all 1630 of them? for some reason python runtests.py > text.txt isn't putting them to a text file, and my console doesn't have 8000 lines of buffer
- # [21:27] * Joins: jgraham_ (n=james@81-86-210-188.dsl.pipex.com)
- # [21:28] <htmlfivedotnet> jgraham__: you know what... looks like i have json problems. let me try to fix that.
- # [21:28] <Philip`> htmlfivedotnet: python runtests.py 2>&1 >text.txt
- # [21:28] <jgraham__> htmlfivedotnet: Nah, I think just a few should be enough to wok out what's going on.
- # [21:28] * Quits: jgraham_ (n=james@81-86-210-188.dsl.pipex.com) (Client Quit)
- # [21:29] <htmlfivedotnet> i keep getting "AttributeError: class simplejson has no attribute 'loads'".
- # [21:29] <Philip`> (to redirect stderr onto stdout, then to save both in the .txt file)
- # [21:29] <htmlfivedotnet> so i think my json is broken.
- # [21:29] <jgraham__> htmlfivedotnet: You need to install simplejson
- # [21:29] <htmlfivedotnet> Philip`: Thanks. I'll remember that
- # [21:29] <jgraham__> That would explain a lot :)
- # [21:30] <jgraham__> We should make a better error message there :)
- # [21:30] <jgraham__> Philip`: I'm also curious what faliures you are getting?
- # [21:31] <Philip`> jgraham__: Maybe support.py should just die when simplejson is missing, instead of trying (and failing) to implement it itself
- # [21:32] <Philip`> jgraham__: I'll tell you in ~40 minutes :-)
- # [21:32] * jwalden wishes everybody could just get along and use a single mailing list for spec discussion
- # [21:32] <htmlfivedotnet> 3 errors, 4 fails (same failures): http://pastebin.ca/1000774
- # [21:32] <jgraham__> Philip`: Yes. It should. That was a hack that someone (Sam?) added and I forgot to take out when it stopped working
- # [21:33] <jgraham__> htmlfivedotnet: I think I have fixes for those errors in my tree (it's an issue with the test harness iirc)
- # [21:33] <jgraham__> So it's working as well for you as for anyone else
- # [21:33] <jgraham__> I need to fix the other issues
- # [21:34] * jgraham__ will have a look later this evening
- # [21:34] <htmlfivedotnet> seems to be. i figured something was wrong on my end...
- # [21:35] <jgraham__> jwalden: Either one of those things seems pretty unlikely on it's own, so them both happening seems very improbable :)
- # [21:35] <jwalden> I know, I'm just feeling grouchy
- # [21:49] * Joins: maikmerten_ (n=maikmert@Laea1.l.pppool.de)
- # [21:49] * Quits: maikmerten (n=maikmert@Lbfe6.l.pppool.de) (Read error: 104 (Connection reset by peer))
- # [21:51] * Joins: andersca_ (n=andersca@17.255.111.81)
- # [21:52] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
- # [21:52] * Quits: aroben (n=aroben@unaffiliated/aroben) ("Leaving")
- # [21:53] * Joins: aroben (n=aroben@c-71-58-57-150.hsd1.pa.comcast.net)
- # [22:00] * Quits: othermaciej (n=mjs@17.203.15.181) (Read error: 110 (Connection timed out))
- # [22:02] * Joins: othermaciej (n=mjs@17.255.111.204)
- # [22:02] * Quits: maikmerten_ (n=maikmert@Laea1.l.pppool.de) ("Leaving")
- # [22:03] * weinig|away is now known as weinig
- # [22:05] * Joins: aaronlev (n=chatzill@pD9E4E109.dip.t-dialin.net)
- # [22:07] * Quits: andersca (n=andersca@nat/apple/x-e3de6591b867d32f) (Read error: 110 (Connection timed out))
- # [22:12] <Philip`> jgraham__: Oops, those failures existed because I have another file of tree-construction tests in testdata
- # [22:12] <Philip`> If I remove that file, I only get 4 failures, 3 errors
- # [22:12] <jgraham__> Philip`: That sounds like the expected behaviour
- # [22:13] <Philip`> I don't know which of my uncommitted tests are still legitimate given the changes to the spec, so I'll ignore them until I get around to checking parser things again in the future
- # [22:13] * Joins: KevinMarks (n=KevinMar@nat/google/x-19c95ca46184b197)
- # [22:16] <Hixie> man, addressing the needs of bloggers was a stroke of genius
- # [22:17] <Hixie> every time a blogger looks at html5, they're all like "sweet, this makes blog way better"
- # [22:17] <Hixie> and then they like html5
- # [22:17] * Joins: jgraham_ (n=james@81-86-210-188.dsl.pipex.com)
- # [22:18] * Joins: othermaciej_ (n=mjs@17.203.15.181)
- # [22:19] <jgraham__> Hixie: presumably that method of optimisation would lead to specs that mainly address the needs of other specs (since the main people who read specs are people writing other specs)
- # [22:19] <Hixie> well it wasn't intentionally optimised that way
- # [22:20] <jgraham__> I'm not suggesting it was :) But it provides a model of why some specs end up so divorced from reality
- # [22:20] <jgraham__> or at lkeast from the needs of real users
- # [22:20] <Hixie> oh for sure
- # [22:21] <Hixie> annevk: i put to you a challenge: get the XHR2 spec agreed to by everyone before the F2F, so i don't have to go :-)
- # [22:21] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
- # [22:21] <jgraham__> Hixie: Impossible things take longer
- # [22:21] <jgraham__> :)
- # [22:21] <Hixie> shouldn't be that impossible
- # [22:21] <Hixie> just need to get sicking to tell us what he wants
- # [22:22] * jgraham__ actually has no idea what the status of XHR2 is
- # [22:23] <jgraham__> I thought it was just AC that was an issue for Mozilla? Or is the AC dependency the only remaining XHR2 issue?
- # [22:25] <Hixie> ac/xhr2, same thing
- # [22:26] <jgraham__> Oh OK
- # [22:26] <jgraham__> Philip`: If you svn update html5lib it shouldn't have the three test errors now, assuming I checked the right code in
- # [22:27] <othermaciej_> I think Mozilla's issue was cookies
- # [22:27] <othermaciej_> I owe some writing on security issues related to cookies
- # [22:27] <othermaciej_> in particular I am pretty convinced now that *not* sending them is a security risk
- # [22:27] * Quits: othermaciej (n=mjs@17.255.111.204) (Nick collision from services.)
- # [22:28] * othermaciej_ is now known as othermaciej
- # [22:28] <Philip`> jgraham__: "FAILED (failures=4)" - looks like success
- # [22:28] <othermaciej> (sadly meetings all day today)
- # [22:28] <jgraham__> Philip`: Thanks
- # [22:32] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
- # [22:33] * Quits: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
- # [22:47] * Joins: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
- # [22:52] * Joins: andersca (n=andersca@nat/apple/x-02e2ee7dbdb73799)
- # [22:59] * Quits: webben (n=benh@nat/yahoo/x-2f02c789275f5bf3) (Read error: 110 (Connection timed out))
- # [23:02] * Quits: jgraham_ (n=james@81-86-210-188.dsl.pipex.com) ("I get eaten by the worms")
- # [23:05] * Joins: fantasai (i=fantasai@connectionreset.info)
- # [23:07] * Quits: andersca_ (n=andersca@17.255.111.81) (Read error: 110 (Connection timed out))
- # [23:11] * Joins: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
- # [23:19] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
- # [23:21] * Joins: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
- # [23:23] * Joins: tantek_ (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
- # [23:37] * Joins: roc (n=roc@202.0.36.64)
- # [23:38] * Quits: KevinMarks (n=KevinMar@nat/google/x-19c95ca46184b197) ("The computer fell asleep")
- # [23:40] * Quits: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
- # [23:49] <Hixie> annevk: do you know if you have yet defined same-origin security policies for CSSOM?
- # [23:50] <Hixie> in particular, that a script shouldn't be able to mutate a StyleSheet object from another origin
- # [23:51] * Joins: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
- # [23:58] * Quits: phsiao (n=shawn@nat/ibm/x-77f96780d29b2830)
- # [23:58] * Quits: aaronlev (n=chatzill@pD9E4E109.dip.t-dialin.net) (Read error: 110 (Connection timed out))
- # [23:59] * Quits: jruderman (n=jruderma@guest-226.mountainview.mozilla.com)
- # Session Close: Tue Apr 29 00:00:00 2008
The end :)