/irc-logs / freenode / #whatwg / 2007-07-08 / end

Options:

  1. # Session Start: Sun Jul 08 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:03] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  4. # [00:03] * Quits: Ducki_ (n=Ducki@dialin-145-254-186-204.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
  5. # [00:06] * Quits: zcorpan_ (n=zcorpan@84-216-42-70.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  6. # [01:08] * Quits: Ducki (i=Ducki@dialin-145-254-188-106.pools.arcor-ip.net) (Client Quit)
  7. # [01:09] * Quits: weinig (i=weinig@nat/apple/x-25b264972ae92bc5)
  8. # [01:23] * Joins: wildcfo (n=wild_c_f@ool-44c1bb48.dyn.optonline.net)
  9. # [01:35] * Quits: tndH_ (i=Rob@87.102.18.111) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  10. # [01:36] * Joins: weinig (n=weinig@38.99.84.35)
  11. # [02:05] * Joins: toolskyn (i=toolskyn@amy.bdick.de)
  12. # [02:13] * Quits: weinig (n=weinig@38.99.84.35) (Read error: 110 (Connection timed out))
  13. # [02:16] * Quits: bzed (n=bzed@dslb-084-059-117-215.pools.arcor-ip.net) ("Leaving")
  14. # [02:31] * Joins: weinig (i=weinig@nat/apple/x-0d629cfa36de9e42)
  15. # [02:50] * Philip` finds another html5lib bug
  16. # [02:51] <Philip`> and I now have tests for almost every state transition in the tokeniser, only missing the ones that require non-PCDATA (which I don't handle yet)
  17. # [03:12] * Joins: malware (n=MikeSmit@eM60-254-212-195.pool.emobile.ad.jp)
  18. # [03:15] <Philip`> http://canvex.lazyilluminati.com/misc/test3.test
  19. # [03:15] * Quits: billyjack (n=MikeSmit@eM60-254-199-114.pool.emobile.ad.jp) (Read error: 110 (Connection timed out))
  20. # [03:15] <Philip`> hsivonen: I see a couple of types of test failure in your tokeniser
  21. # [03:16] <Philip`> (for "<!doctype! ?>" (too few parse errors) and "<z/0 >" (it misses the attribute), and variations of those)
  22. # [03:22] <Philip`> ((It wasn't intentional for my tests to use "<!doctype!" and "<z/0" so much - that's just what fell out of the sorting function))
  23. # [03:40] * Quits: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca) (Read error: 110 (Connection timed out))
  24. # [03:42] * Quits: webben (n=benh@82.152.177.224)
  25. # [03:47] * Quits: dev0 (i=Tobias@unaffiliated/icefox0) ("dev0 has no reason")
  26. # [04:11] * Quits: malware (n=MikeSmit@eM60-254-212-195.pool.emobile.ad.jp) (Read error: 110 (Connection timed out))
  27. # [04:18] * Joins: jruderman (n=jruderma@c-67-169-24-116.hsd1.ca.comcast.net)
  28. # [04:34] * Joins: MikeSmith (n=MikeSmit@eM60-254-212-41.pool.emobile.ad.jp)
  29. # [05:13] * Quits: wildcfo (n=wild_c_f@ool-44c1bb48.dyn.optonline.net) ("This computer has gone to sleep")
  30. # [05:30] * Quits: MikeSmith (n=MikeSmit@eM60-254-212-41.pool.emobile.ad.jp) (Read error: 110 (Connection timed out))
  31. # [07:35] * Quits: weinig (i=weinig@nat/apple/x-0d629cfa36de9e42)
  32. # [07:55] * Joins: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  33. # [07:55] * Quits: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  34. # [07:56] * Joins: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  35. # [09:26] * Quits: weinig (n=weinig@c-67-188-89-242.hsd1.ca.comcast.net)
  36. # [09:51] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  37. # [09:55] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  38. # [09:56] * othermaciej is now known as om_sleep
  39. # [10:29] * Joins: maikmerten (n=maikmert@La62d.l.pppool.de)
  40. # [10:38] <hsivonen> Philip`: thank you. I fixed bugs exposed by your test cases. One test case failure is a bug in your test cases, though: "<z/0 0" that should give 3 errors: non-permitted slash, EOF in attribute name and duplicate attribute "0".
  41. # [10:38] <hsivonen> Philip`: are you planning on contributing your tests to html5lib?
  42. # [10:40] * Joins: ROBOd (n=robod@86.34.246.154)
  43. # [10:42] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  44. # [11:28] <Hixie> http://lists.w3.org/Archives/Member/w3c-html-cg/2007JulSep/0013.html is interesting
  45. # [11:32] <hsivonen> indeed
  46. # [11:32] * Joins: Ducki (n=Ducki@dialin-145-254-187-049.pools.arcor-ip.net)
  47. # [11:32] <Hixie> the "kitchen sink" threads are also interesting
  48. # [11:33] <Hixie> in that it seems a lot of people on that mailing list don't really understand what's going on
  49. # [11:33] <Hixie> oh well
  50. # [11:37] <hsivonen> Hixie: do you mean vigorously lobbying for a detail that is already in the spec?
  51. # [11:39] <hsivonen> someone really needs to write a primer on diminishing returns, externalities and network effects for the WG, but I'm pretty sure that if someone did, (s)he'd be slammed for not being a real economist
  52. # [11:44] * Joins: MikeSmith (n=MikeSmit@eM60-254-215-109.pool.emobile.ad.jp)
  53. # [11:52] <Hixie> hsivonen: i meant like being worried that XBL2 points to HTML5 and that therefore the security thing might not be defined, etc... missing the whole point that i had to write the security thing anyway, it didn't matter which spec i put it in
  54. # [11:52] <Hixie> anyway
  55. # [11:52] <Hixie> bed time
  56. # [11:52] <Hixie> probably will be online very spottily for the next three weeks
  57. # [12:01] <hsivonen> nn
  58. # [12:02] <hsivonen> Hixie: oh you referred to public-appformats
  59. # [12:19] * Joins: zcorpan_ (n=zcorpan@84-216-40-87.sprayadsl.telenor.se)
  60. # [12:33] * Quits: MikeSmith (n=MikeSmit@eM60-254-215-109.pool.emobile.ad.jp) (Read error: 110 (Connection timed out))
  61. # [12:43] <Philip`> hsivonen: Oh, whoops, I haven't done anything about duplicate attributes
  62. # [12:43] <Philip`> (I guess html5lib hasn't either, since it passed that test)
  63. # [12:47] <Philip`> Looks a bit irritating how it says to drop the attribute value before you've actually got an attribute value at all...
  64. # [12:48] * Philip` tries to think of a nice way to handle that
  65. # [12:49] <hsivonen> Philip`: I have a boolean flag
  66. # [12:50] <hsivonen> Philip`: and I defer the actual addition of an attribute til the value is complete or know not to exist
  67. # [12:50] <hsivonen> Philip`: which was also the source of one class of test case failures you found
  68. # [12:56] <Philip`> Adding another state variable makes other things more complex (like when verifying you never have to alter an attribute unless there actually is an attribute), so it'd be nice to avoid that if possible
  69. # [13:01] <Philip`> (Well, it's fine to add a state variable into the C++/etc implementation, but preferably not into the conceptual model of the algorithm)
  70. # [13:08] * Joins: Ducki_ (i=Ducki@dialin-212-144-083-175.pools.arcor-ip.net)
  71. # [13:12] <jgraham> Philip`: So do you want html5lib commit access (hint, hint)?
  72. # [13:15] * Joins: tndH_ (i=Rob@87.102.18.111)
  73. # [13:15] * tndH_ is now known as tndH
  74. # [13:18] <hsivonen> would someone like to volunteer to check an email about bikeshedding, belling the cat and economics 101 for suitability of sending to public-html? in particular, checking whether it is offensively patronizing?
  75. # [13:19] <Philip`> jgraham: Oops, I forgot to respond to hsivonen's second comment - I expect it would be good to add these tests to html5lib (which is why I named the file test3.test already :-) )
  76. # [13:20] <Philip`> at least once I've fixed the bugs, and added manually-written tests for the other bugs I have in my code
  77. # [13:20] <jgraham> Philip`: I went ahead and gave you commit access whether you wanted it or not :)
  78. # [13:20] <Philip`> jgraham: I just saw that - thanks :-)
  79. # [13:26] * Quits: Ducki (n=Ducki@dialin-145-254-187-049.pools.arcor-ip.net) (Read error: 113 (No route to host))
  80. # [13:36] * Philip` wonders if it matters that his test cases don't have good descriptions
  81. # [13:37] <jgraham> Philip`: I think I've fixed issue 50. Your testcases would be most welcome now so I can have some confidence that I did the right thing
  82. # [13:37] <jgraham> And also because I promised them in the commit log :)
  83. # [13:38] <Philip`> Just trying to fix the duplicate-attribute issue, which hopefully won't take long :-)
  84. # [13:38] <jgraham> Descriptions are good but probably not essential - the treebuilder tests are all description free, for example
  85. # [13:38] <jgraham> But if you can add them, please do :)
  86. # [13:39] <Philip`> I have no idea what most of my test cases are doing, so I don't know how to usefully describe them
  87. # [13:40] * Joins: bzed (n=bzed@dslb-084-059-107-010.pools.arcor-ip.net)
  88. # [13:40] <Philip`> Maybe I could convince the test-generating program to work out why it's choosing those particular ones, but that seems like more effort than would be worthwhile
  89. # [13:41] <jgraham> Philip`: I guess if you keep all auto-generated tests to their own file it's fine
  90. # [13:41] * jgraham notices he changed something and forgot to run the treewalkers tests
  91. # [13:42] <hsivonen> hmm. I guess I just send the message at the risk of offending some people
  92. # [13:43] <jgraham> hsivonen: Go for it. At least then we'll get email about how offended people are rather than whether or not Anne should include all his optional tags
  93. # [13:44] <jgraham> which is probably the most boring thread ever
  94. # [13:44] <jgraham> ;)
  95. # [13:46] <hsivonen> jgraham: sent
  96. # [13:49] <hsivonen> enjoy: http://lists.w3.org/Archives/Public/public-html/2007Jul/0507.html
  97. # [14:04] <hsivonen> was I too offensive?
  98. # [14:05] <Philip`> jgraham: Committed the new tests now
  99. # [14:06] <jgraham> Philip`: Cool
  100. # [14:06] <Philip`> including one with duplicate attribute values, which html5lib fails
  101. # [14:06] <Philip`> (hsivonen's implementation passes all those tests now)
  102. # [14:07] <jgraham> hsivonen: No, I don't think so. Possibly a little terse, but if people read the links they should get the idea (I'm just reading the joel on software one which I don't think I've seen before)
  103. # [14:20] * zcorpan_ likes hsivonen's terse style
  104. # [14:21] <Philip`> Hmm, the html5lib Ruby tokeniser doesn't seem entirely happy with EOFs
  105. # [14:21] <Philip`> (resulting in various things like <"undefined method `+' for :EOF:Symbol">)
  106. # [14:30] * Quits: Ducki_ (i=Ducki@dialin-212-144-083-175.pools.arcor-ip.net) (Read error: 104 (Connection reset by peer))
  107. # [14:35] * Joins: SavageX (n=maikmert@Lbd77.l.pppool.de)
  108. # [14:51] * Quits: maikmerten (n=maikmert@La62d.l.pppool.de) (Read error: 110 (Connection timed out))
  109. # [14:53] * SavageX is now known as maikmerten
  110. # [14:59] <jgraham> Philip`: All your tests seem to pass now
  111. # [15:22] <Philip`> jgraham: That must mean more tests are needed ;-)
  112. # [15:26] * Joins: MikeSmith (n=MikeSmit@eM60-254-220-212.pool.emobile.ad.jp)
  113. # [15:52] * Joins: hasather (n=hasather@22.80-203-71.nextgentel.com)
  114. # [16:36] <Philip`> More tests says: html5lib doesn't lowercase tag/attribute names
  115. # [17:12] <jgraham> Philip`: We lowercase them at the tree construction stage (because Sam reuses the tokenizer in situations where case is important)
  116. # [17:14] <Philip`> Ah, okay
  117. # [17:14] <hsivonen> jgraham: what are those situations?
  118. # [17:15] <Philip`> How would it best to test that tokenisers do implement what the spec says (with lowercasing names), while accepting that html5lib doesn't do that at that point?
  119. # [17:16] <hsivonen> jgraham: out of curiosity, why didn't you parametrize this in the tokenizer?
  120. # [17:16] <Philip`> (And does html5lib work correctly when you do <a a=1 A=2>?)
  121. # [17:17] <hsivonen> (I think I've been a bit naïve with the way I handle lower casing per spec instead of having a readCaseFolded() method)
  122. # [17:26] * Joins: csarven (n=nevrasc@modemcable081.152-201-24.mc.videotron.ca)
  123. # [17:52] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  124. # [18:05] <Philip`> hsivonen: Your entity overflow code doesn't quite work - with input like &#x100000041; the value overflows from 0x10000000 to 0x00000000 and it's never negative so it never hits the overflow-handler
  125. # [18:06] * Philip` will upload tests for that at some point
  126. # [18:07] <hsivonen> Philip`: ouch. good point
  127. # [18:07] <gsnedders> hsivonen: Sam uses it for parsing XML
  128. # [18:07] <gsnedders> hsivonen: (the XML having failed to be processed by an XML parser)
  129. # [18:11] <hsivonen> Philip`: fix (I think) checked in
  130. # [18:11] <hsivonen> Philip`: thanks
  131. # [18:13] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  132. # [18:17] <Philip`> hsivonen: Seems to work perfectly now
  133. # [18:19] <hsivonen> looks like my code is bad enough to generate community interest after all :-)
  134. # [18:20] <Philip`> I'm always interested in breaking things ;-)
  135. # [18:22] <Philip`> I'd be interested in trying to generate stack-using code like yours, and seeing how that works in comparison with switch-statements or gotos
  136. # [18:23] <Philip`> though I'm not sure how much automatic transformation I can do to extract stackiness, and I'm too lazy to do that manually
  137. # [18:24] <hsivonen> Philip`: my expectation is that the code won't be stack-based once server HotSpot has done its thing
  138. # [18:24] <Philip`> though that reminds me that I need to collect a set of documents for performance testing...
  139. # [18:24] <hsivonen> if the expectation is incorrect, running a byte code-level optimizer would make sense
  140. # [18:27] <hsivonen> Philip`: either way, it seems to me that it is easier to convert the kind of code I have written to unconditional jumps than it would be for a switch (which, OTOH, would guarantee no worse that conditional jumps)
  141. # [18:29] <Philip`> It seems quite possible that HotSpot could give better performance for your code than for switch-based code, if it's doing lots of inlining and tail-call optimisation - it'd be interesting to see how well it works in practice
  142. # [18:29] <hsivonen> Philip`: so whether the use of methods vs. one huge switch makes sense depends on what HotSpot really does
  143. # [18:29] <Philip`> That makes sense
  144. # [18:30] <Philip`> Unfortunately C++ doesn't have the advantage of dynamic compilation, so I guess things will act totally differently there
  145. # [18:30] <Philip`> but fortunately it doesn't have dynamic compilation, so you can usually have some idea of what the compiler's actually going to do to your code :-)
  146. # [18:31] <hsivonen> Philip`: the problem is that testing which approach really performs better on HotSpot is a non-trivial task. Which is why I went with an unverified educated (hopefully :-) guess
  147. # [18:31] <hsivonen> Philip`: yeah, I'd bet on switch in the C++ case
  148. # [18:32] <Philip`> That's why I'd like to be able generate different implementation approaches from the same source data, which is still non-trivial but involves much less typing :-)
  149. # [18:33] <hsivonen> besides, for Gecko-like threading (lack thereof), on would want to have a switch-based parser with states broken down even further so that each state reads at most one character
  150. # [18:33] <hsivonen> this way, the state variable would effectively store the current continuation
  151. # [18:34] <hsivonen> and the tokenizer could be interrupted after any input character
  152. # [18:34] <hsivonen> s/on would/one would/
  153. # [18:35] <Philip`> What happens when you need to look ahead by ~6 characters at once?
  154. # [18:35] <hsivonen> Philip`: I don't.
  155. # [18:35] <hsivonen> Philip`: my max lookahead is one read()/unread()
  156. # [18:36] <hsivonen> Philip`: otherwise, I buffer pessimistically and look back
  157. # [18:36] <hsivonen> Philip`: when I start consuming a doctype, I start building a bogus comment in parallel just in case
  158. # [18:38] <hsivonen> I should learn how to dump native code disassemblies from HotSpot some day
  159. # [18:40] <Philip`> Ah, okay, so if you had "<!docty>"(network latency) then it would emit the token before running out of characters
  160. # [18:40] <hsivonen> yes
  161. # [18:53] * maikmerten is now known as maik|bath
  162. # [18:54] * Joins: weinig (i=weinig@nat/apple/x-1f3a49cad1491d2e)
  163. # [19:20] * maik|bath is now known as maikmerten
  164. # [19:28] * maikmerten is now known as maik|eat
  165. # [19:43] * om_sleep is now known as othermaciej
  166. # [19:44] * maik|eat is now known as maikmerten
  167. # [19:49] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
  168. # [19:49] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  169. # [19:54] <hsivonen> I wonder what the Wikipedia article on "HTML 5" means when it says "Elements no longer compatible with HTML 4 – a, hr, strong"
  170. # [19:57] <othermaciej> [NEEDS CITATION]
  171. # [19:58] <Philip`> Looks like they just chose a random selection of points from html4-differences
  172. # [19:58] <Philip`> and in that case, particularly the points under "These elements have new meanings in HTML 5 which are incompatible with HTML 4"
  173. # [20:00] <Philip`> (Not entirely sure what the point is in duplicating that data badly, when there's an external link to html4-differences)
  174. # [20:06] * Joins: webben (n=benh@82.152.177.224)
  175. # [20:06] * Quits: KevinMarks (n=KevinMar@c-76-102-254-252.hsd1.ca.comcast.net) ("The computer fell asleep")
  176. # [20:21] * zcorpan_ edited the wiki page: "Elements with redefined meaning which are not compatible with HTML 4 – a, hr, strong"
  177. # [20:22] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  178. # [20:31] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  179. # [20:37] * Quits: webben (n=benh@82.152.177.224) (Read error: 110 (Connection timed out))
  180. # [20:43] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  181. # [20:50] <jgraham> hsivonen: re: why case handling wasn't paramterized in the tokenizer: I don't know. I think Sam just picked a solution that did what he wanted. Is there a good reason to prefer a different approach
  182. # [20:50] <jgraham> ?
  183. # [20:51] <jgraham> Philip`: I'll change the html5lib test harness to do the same thing with attribute names as the treebuilder
  184. # [20:52] * Quits: maikmerten (n=maikmert@Lbd77.l.pppool.de) ("night/TV")
  185. # [20:55] * Joins: KevinMarks (n=KevinMar@c-76-102-254-252.hsd1.ca.comcast.net)
  186. # [20:56] <hsivonen> jgraham: reasons are running tokenizer-level tests and eliminating duplicate attributes
  187. # [20:58] <hsivonen> jgraham: going forward if we integrate SVG, a flag you can toggle in mid-tokenization might become useful
  188. # [20:58] <jgraham> hsivonen: That's a good point
  189. # [20:58] <jgraham> OK, I think I will change it to work with a flag
  190. # [20:59] <hsivonen> perhaps in the future I move case folding to one place behind a flag so that case folding writes back to the read buffer
  191. # [21:00] <hsivonen> this way I could avoid name copying whenever a name doesn't cross the read buffer boundary
  192. # [21:02] <hsivonen> the fun part would be that then one could make a legitimate claim that lower case is faster :-)
  193. # [21:17] * zcorpan_ likes <xmp> and wonders why it was deprecated way back when
  194. # [21:18] <zcorpan_> even pretending html to be sgml it's just an ordinary rcdata element, isn't it?
  195. # [21:18] <Philip`> Maybe because they couldn't work out a good way to show authors an example of how to write <xmp>...</xmp>, without the example closing itself half-way through?
  196. # [21:18] <hsivonen> zcorpan_: there's a subject for a fun public-html thread
  197. # [21:18] <Philip`> Opera's <xmp> parsing is very broken, unfortunately :-(
  198. # [21:18] <Philip`> I think it was actually mentioned on public-html some months ago
  199. # [21:18] <zcorpan_> Philip`: &lt;/xmp>
  200. # [21:19] <Philip`> zcorpan_: That won't work, except in Opera
  201. # [21:19] <Philip`> since it ought to just show the text "&lt;/xmp>"
  202. # [21:19] <zcorpan_> oh, it's a cdata element even
  203. # [21:22] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?a%3Cscript%3E%3C/script/%3Ea%0Aa%3Cstyle%3E%3C/style/%3Ea%0Aa%3Cxmp%3E%3C/xmp/%3Ea - that's rather odd in Firefox
  204. # [21:25] * Quits: weinig (i=weinig@nat/apple/x-1f3a49cad1491d2e)
  205. # [21:25] <zcorpan_> Philip`: file a bug? :)
  206. # [21:26] * Quits: MikeSmith (n=MikeSmit@eM60-254-220-212.pool.emobile.ad.jp) (Read error: 110 (Connection timed out))
  207. # [21:27] <Philip`> No need - it'll all be perfect once they've just implemented HTML5 ;-)
  208. # [21:28] * Joins: MikeSmith (n=MikeSmit@eM60-254-196-202.pool.emobile.ad.jp)
  209. # [21:34] <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ca/x%3E%3Ca/x/%3E%3Ca/x/x%3E%3Ca/x%20%3E%3Ca/x%20x%3E
  210. # [21:37] * Joins: weinig (i=weinig@nat/apple/x-c0c85f1ea37f33eb)
  211. # [21:43] <zcorpan_> <xmp><!--</xmp>--></xmp> ;)
  212. # [21:51] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  213. # [21:58] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 104 (Connection reset by peer))
  214. # [21:59] * Joins: webben (n=benh@82.152.177.224)
  215. # [22:16] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  216. # [22:30] * Quits: weinig (i=weinig@nat/apple/x-c0c85f1ea37f33eb)
  217. # [22:44] * Joins: weinig (i=weinig@nat/apple/x-12b315f07f832cd6)
  218. # [22:58] <Philip`> Looks like my OCaml implementation isn't very good - the C++ one is 150 times faster...
  219. # [23:08] * Quits: webben (n=benh@82.152.177.224) (Read error: 104 (Connection reset by peer))
  220. # [23:08] <Philip`> Oh, right, that's because I'm making it read from stdin one character at a time
  221. # [23:09] * Quits: weinig (i=weinig@nat/apple/x-12b315f07f832cd6) (Read error: 104 (Connection reset by peer))
  222. # [23:09] * Joins: webben (n=benh@82.152.177.224)
  223. # [23:09] * Joins: weinig (i=weinig@nat/apple/x-0349634b714253b6)
  224. # [23:16] * Quits: zcorpan_ (n=zcorpan@84-216-40-87.sprayadsl.telenor.se) (Read error: 110 (Connection timed out))
  225. # [23:18] <Philip`> Aha - the OCaml one is now only four times slower than the C++ one, for tokenising the HTML5 spec
  226. # [23:27] * Quits: weinig (i=weinig@nat/apple/x-0349634b714253b6)
  227. # [23:40] * Quits: ROBOd (n=robod@86.34.246.154) ("http://www.robodesign.ro")
  228. # [23:44] * Joins: h3h (n=w3rd@209.79.152.154)
  229. # [23:45] * Quits: h3h (n=w3rd@209.79.152.154) (Client Quit)
  230. # Session Close: Mon Jul 09 00:00:00 2007

The end :)