Hopbot log for 2007-07-20 - Helma IRC channel: #helma on irc.freenode.net

2007-07-20:

[2:24] <midnightmonster> it looks like rhino.jar is just a renamed js.jar (from Rhino project). So if I can figure out how to build the latest branch of rhino I might be able to fix it myself?
[12:07] <leobm> hi doublec: you are the bluishcoder ?
[12:07] <doublec> leobm: yes i am
[12:08] <leobm> cool. liek your work. example your javscript jetty/servlete example.I build my litte own mini webframework on it.
[12:09] <leobm> but with the new rhino 1.6 I have now problems to get work the jetty servlet with javascript. no idea why.
[12:09] <leobm> R6
[12:11] <doublec> thanks!
[12:11] <doublec> I haven't tried R6, I'll try it out
[12:11] <doublec> I believe R6 fixed a problem I was originally having with calling protected methods of a class from javascript
[12:11] <doublec> which is what the .java file in included in the distribution was for
[12:12] <doublec> If i remove that workaround it'll probably work better
[12:13] <leobm> great. wanted test this new serverside DOM emulation code.
[12:14] <leobm> but this code need R6, because it use getter and setter functionality of rhino R6
[12:14] <leobm> http://ejohn.org/blog/bringing-the-browser-to-the-server/
[12:16] <doublec> yes, I saw that article. It's a very cool idea.
[12:16] <leobm> yes. I begun a simmilar code. but this code is better :)
[12:21] <leobm> I build my mini framework on a modified version of trimjunction. for dom parsing I used e4x.. but for this the document must 100% XML complaint. I want now test this DOM emulation code for html parsing. With TagSoup as base parser
[13:46] <rjb> duh, i'm still puzzled about the trailing null bytes i get in my output from helma
[13:49] <rjb> could it be some peculiarity of my setup?
[13:51] <rjb> http://validator.w3.org/check?uri=http%3A%2F%2Fbobo.fuw.edu.pl%2Ffotw%2Fsearch%3Fkw%3Dhelma&charset=%28detect+automatically%29&doctype=Inline
[13:55] <rjb> helma is 1.5.3
[13:55] <midnightmonster> were you the one not able to run 1.6 on amd64?
[13:55] <rjb> $ java -version
[13:55] <rjb> java version "1.4.2-02"
[13:55] <rjb> Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-02)
[13:55] <rjb> Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-02, mixed mode)
[13:55] <rjb> yep that's right
[13:56] <rjb> $ uname -a
[13:56] <rjb> Linux bobo 2.6.17-10-generic #2 SMP Tue Dec 5 21:16:35 UTC 2006 x86_64 GNU/Linux
[13:57] <midnightmonster> fwiw, sun has a perfectly functional and fast Java 6u2 for amd64 linux. I upgraded to it when the gcj thing turned out to be a disaster (~50 times slower than sun)
[13:58] <midnightmonster> (bb shortly)
[14:02] <rjb> Java Plug-in, Java Web Start, and Java Control Panel are not supported on 64-bit systems.
[14:02] <rjb> http://java.sun.com/javase/6/webnotes/install/system-configurations.html#deployment-footnotes
[14:02] <rjb> doesn't really matter for server usage, i know
[14:04] <rjb> but functional does become less-than-perfectly
[14:13] <midnightmonster> you should be able to install the jdk, though. and it does work just fine. I would think you could just have both
[14:15] <rjb> right, i could install a jdk6 just for helma, that's not to worry about
[14:16] <rjb> interesting whether that would make the null bytes go away
[14:20] <midnightmonster> I'm not actually using the skins, so I'm not sure
[14:22] <midnightmonster> i can try it once I'm actually sitting down and not hopping between here and other things
[16:59] <midnightmonster> chris, do you know if the web view of the CVS is realtime?
[17:02] <zumbrunn> yes it is
[17:02] <midnightmonster> drat ;-)
[17:03] <midnightmonster> I keep hitting reload looking for a new rhino
[17:03] <zumbrunn> ;-)
[17:03] <zumbrunn> did you try with an earlier version of the jar?
[17:03] <zumbrunn> (one before the bug was introduced?)
[17:03] <midnightmonster> no, I haven't. that might work, I suppose.
[17:04] <zumbrunn> you might have other bugs then, but they probably wont bite you
[17:04] <midnightmonster> right. here's hoping
[17:05] <midnightmonster> hm. bug reported on 5/26. we've got a rhino from 5/24.
[17:07] <midnightmonster> i guess if I go back I'll need xbean.jar?
[17:08] <zumbrunn> not sure when xbean became optional
[17:08] <zumbrunn> but it will not hurt to include it
[17:08] <zumbrunn> (for now)
[17:11] <midnightmonster> same thing in 5/24
[17:11] <midnightmonster> after that have to go back to 4/4
[17:13] <midnightmonster> same bug in 4/4.
[17:14] <midnightmonster> (although there's now an additional non-critical bug in non-xbean e4x)
[17:35] <midnightmonster> 3/29 and 3/28 still broken
[17:36] <zumbrunn> in a few minutes I'll have time to try to build it for you quickly
[17:37] <midnightmonster> that'd be great
[17:37] <midnightmonster> As I'm going back and back in time, it looks like I'm backing up past important features and bug fixes.
[17:38] <midnightmonster> interestingly, at least some of e4x works without xbean as far back as 3/28 (though pretty-printing is rather broken)
[17:38] <midnightmonster> I've been trying it with and without with each build
[17:50] <midnightmonster> december is the first time E4X doesn't work at all without xbean
[17:51] <midnightmonster> and the first time that attributes *do* work with xbean!
[17:53] <typicaljoe> morning
[17:55] <midnightmonster> hey, joe. chris says he's going to try building the latest rhino for me to fix the attributes thing, but working back in time in helma cvs, I've found that the rhino.jar checked in in december can do e4x correctly if apache's xbean is in the lib/ext directory
[17:55] <typicaljoe> cool, I wonder when they will roll in the latest Rhino build
[17:56] <typicaljoe> BTW: I just now trying the e4x and getting a syntax error. stupidly I didn't copy your code form yesterday so do you have a one line example I can copy to start playing with?
[17:56] <midnightmonster> hannes said he'll build a new one and put it in the helma cvs so people can get it but won't likely release a new helma build till rhino hits its next release
[17:57] <midnightmonster> res.write(<h1>E4X works at least a little!</h1>.toXMLString())
[17:58] <zumbrunn> ls
[17:59] <midnightmonster> ?
[17:59] <zumbrunn> that's 1.6.1
[17:59] <zumbrunn> not the next relase as in 1.7
[17:59] <zumbrunn> you will not have to wait *that* long ;-)
[18:00] <zumbrunn> it makes sense not to rerelease because of this bug
[18:00] <zumbrunn> because it's no show stopper
[18:00] <midnightmonster> right... helma 1.6.1 when rhino hits 1.6r6
[18:00] <midnightmonster> yeah--I'm not really complaining
[18:00] <typicaljoe> hmm...getting the generic error: syntax error (C:\helma\helma-1.5.3\apps\degree\Root\main.hac#28)
[18:00] <typicaljoe> it no like the XML
[18:01] <typicaljoe> :-(
[18:01] <midnightmonster> which helma are you using?
[18:01] <zumbrunn> 1.5.3 doesn't do e4x
[18:01] <typicaljoe> ahh, that explains it. yeah, I just downloaded the default one from the website
[18:02] <zumbrunn> huh?
[18:02] <zumbrunn> that should be 1.6
[18:02] <midnightmonster> not if he downloaded a couple weeks ago
[18:02] <zumbrunn> (since yesterday)
[18:04] <typicaljoe> yeah, it was a few days ago. last Monday perhaps. ok, I'll download and try 1.6, another other cool adds that might be useful to know about?
[18:05] <midnightmonster> (I know it's not a show-stopper for most people, but that's b/c apparently people are even more ignorant of the awesomeness of e4x than of the awesomeness of helma. As I'm going for maximum awesomeness, and indeed have already tasted that sweetness and started architecting my app around it, it's pretty show-stop-y for me.)
[18:06] <midnightmonster> (but I don't ultimately care about the exact release schedule so long as I can find a way to get back to work)
[18:06] <zumbrunn> ok, I'll try to build it now...
[18:06] <zumbrunn> just have to apply the patch first
[18:07] <midnightmonster> I really appreciate it.
[18:07] <zumbrunn> the reason why it's not a show stopper is because it doesn't break backwards compatibility
[18:08] <midnightmonster> that makes sense, too
[18:08] <zumbrunn> (1.5 releases didn't have e4x support at all)
[18:09] <zumbrunn> don't worry, 1.x.1 releases follow usually pretty quickly after the initial release
[18:09] <zumbrunn> there is always stuff that comes up that didn't get noticed during the release candidate period
[18:10] <midnightmonster> right. I grock that. (although hannes was saying helma 1.6.1 would likely include rhino 1.6r6, and I have no concept of when that rhino release is likely to happen)
[18:11] <zumbrunn> yes, we'll see
[18:11] <typicaljoe> thanks thanks midnight, works perfect
[18:14] <midnightmonster> (silly irc question: it seems to be possible to change my handle without leaving and coming back--is that a standard irc command, or a feature of some clients?)
[18:16] <zumbrunn> that's standard
[18:16] <zumbrunn> http://helma.zumbrunn.net/downloads/anteportas/rhino.jar
[18:16] <midnightmonster> (silly question that was meant to be implicit in the last: how do I do it?)
[18:17] <zumbrunn> slash "nick" space "newnickname"
[18:18] <joshu1> hm
[18:18] <zumbrunn> hm?
[18:18] <joshu1> I guess someone else on the server is joshua
[18:19] <joshu1> 'cause that's what I tried to be
[18:19] <zumbrunn> :-)
[18:20] <jsp> there we go
[18:20] <typicaljoe> ok, one more dumb question. Lets say I have var myXML = <body><div>SomeContent</div></body>; how do I get, in javascript, to someContent and either get the content or change it after I create the XML?
[18:22] <jsp> myXML.div = 'new content'
[18:23] <jsp> myXML.div.toString() (or called implicitly by using myXML.div it in a string context) reads the content
[18:23] <typicaljoe> oh ho, thanks midnight. yeah, I really need to find a project at work to use this stuff with
[18:23] <typicaljoe> that is crazy cool
[18:24] <jsp> (you can call me jsp now--I show up that way to you, right?--I just changed it so people wouldn't have to type midnight)
[18:25] <jsp> it is crazy cool, though
[18:25] <jsp> now I need to test this new rhino jar
[18:25] <typicaljoe> ok, you do show up that way for me
[18:26] <jsp> 'course now it looks like my nick is Java Server Pages. oh well
[18:26] <zumbrunn> that's what I first thought ;-)
[18:26] <jsp> Joshua Stephen Paine
[18:37] <zumbrunn> jsp... you mentioned once that you use firebug to be able to play with e4x in the browser...
[18:37] <jsp> yeehaw! thanks, chris. works!
[18:37] <jsp> yeah
[18:37] <zumbrunn> you know you can do this also on the server-side using the shell, right?
[18:37] <jsp> well, now I can ;-)
[18:37] <zumbrunn> yes :-)
[18:38] <jsp> I haven't tried the shell yet
[18:38] <zumbrunn> you should
[18:38] <jsp> does it work in the context of my application or just a generic context?
[18:38] <zumbrunn> in the context of your app
[18:39] <jsp> that does sound pretty cool
[18:39] <zumbrunn> just like firebug works in the context of the current page
[18:40] <zumbrunn> basically, you can go dig into the running application and modify/debug as you please
[18:41] <jsp> that is so wrong (in the sense of fantastic)
[18:41] <jsp> how do I hook this up?
[18:41] <zumbrunn> you just need to include the helmaTools.zip as a repository of your app
[18:42] <zumbrunn> and then access the shell action
[18:42] <jsp> which puts itself at /shell, or I have to put it somewhere?
[18:42] <zumbrunn> you can invoke the shell action on any hopobject
[18:42] <jsp> ah!
[18:43] <zumbrunn> and "this" will refer to the current hopobject
[18:43] <jsp> swet
[18:43] <jsp> there's something deeply wrong with the world that I didn't learn of the existence of Helma till ~this year
[18:50] <jsp> complete random stupid thing about javascript I should have know already but didn't:
[18:53] <jsp> splitting most statements onto multiple lines like this:
[18:53] <jsp> myvar =
[18:53] <jsp> { a:1 };
[18:53] <jsp> or
[18:53] <jsp> myvar
[18:53] <jsp> = { a:1 };
[18:53] <jsp> works just fine. but this:
[18:53] <jsp> return
[18:53] <jsp> { a:1 };
[18:53] <jsp> returns undefined in rhino and fails to compile in spidermonkey
[18:58] <jsp> chris, something I've been wondering... can I persist object references without cloning the object? if I'm using the built-in db, is there a way to, e.g., let root have a collection of Pages as _children and also a collection of Authors as root.authors and have Page have a myAuthor property which points to one of the authors?
[19:06] <zumbrunn> yes, sure
[19:06] <jsp> how?
[19:08] <jsp> (how's that for an open-ended question?)
[19:09] <jsp> ok, say I've made Author extend User, and I log in my authors with the built-in methods. they'll show up in the session automagically, yes? (if not, I could put them there myself)
[19:09] <zumbrunn> you can attach that author object to both objects
[19:09] <zumbrunn> (or collections)
[19:09] <zumbrunn> the author object just can't have more than one parent
[19:10] <zumbrunn> so, you have to decide which one should be the parent
[19:10] <zumbrunn> (obviously the root.authors collection in this case)
[19:10] <jsp> (clearly Root.authors, since ... right)
[19:11] <jsp> so when an Author authors a page and I create it, I could just set Page.author = session.user, and *poof*?
[19:11] <zumbrunn> don't think so
[19:12] <zumbrunn> you have to add it to a collection
[19:12] <zumbrunn> but you could just set the author property to the _if of the hopobject
[19:12] <jsp> ?
[19:12] <zumbrunn> or better the author name
[19:13] <zumbrunn> or whatever unique accessname you use inside the root.authors collection
[19:13] <jsp> (that was supposed to be _id, not _if, right?) and then retrieve it later with Root.authors.get(this.author) ?
[19:13] <zumbrunn> so, this case isn't really a good example for attaching a object to multiple other objects
[19:14] <zumbrunn> _id
[19:14] <zumbrunn> right
[19:14] <jsp> so say it's tags instead of authors, and I want to keep a master collection of all tags and a collection for each page of the tags associated with it
[19:14] <jsp> I'm not duplicating tag objects when I do that
[19:15] <zumbrunn> no, you wouldn't duplicate the objects
[19:15] <zumbrunn> the same object can be attached to different parents
[19:16] <jsp> so hopobjects can only be stored in collections or mounted?
[19:16] <jsp> or maybe that's what that mysterious other option in type.properties was for!
[19:17] <jsp> ##Page/type.properties##
[19:17] <jsp> authors = object(Author)
[19:17] <jsp> tags = collection(Tag)
[19:17] <jsp> that's gotta be it
[19:17] <zumbrunn> remember that object properties are not stored in the db by default
[19:17] <jsp> a way to connect the Author directly without having a collection or a lookup by name
[19:17] <zumbrunn> objects and arrays that is...
[19:18] <zumbrunn> so you would have to serialize that yourself anyway
[19:18] <zumbrunn> afk for a few minutes
[19:19] <jsp> right... but is that true if they're marked like that in type.properties? when we were talking about this before, I was under the impression that the prop = object(Type) notation in the antville code was new to you
[19:33] <rjb> jsp: haha, that thing about newline after 'return' bit me just 2 or 3 days ago
[19:34] <rjb> it's one of the most stupid misfeatures of javascript
[19:35] <jsp> I'm guessing it's the result of the optional semicolons
[19:35] <rjb> if you want a newline in the middle of a statement, you need to make sure
[19:35] <rjb> that if you inserted a semicolon before the newline, you'd have a syntax error
[19:35] <jsp> yeah--like I was sayin' :-)
[19:36] <rjb> if the interpreter figures out that statement just can't end with the newline, cause it's syntactically wrong
[19:36] <rjb> it will keep on reading the next line
[19:37] <rjb> it's a really really dumb 'feature'
[19:37] <rjb> (awk as it too, though)
[19:38] <rjb> as=> has
[19:41] <rjb> jsp: what's your general idea of not using helma skins?
[19:44] <rjb> i mean, how would you want to build your html?
[19:52] <jsp> I'm doing it with E4X
[19:53] <rjb> and how is that a better solution?
[19:53] <jsp> which is so awesome (now that I have a patched rhino where attribute literals aren't broken) that every other method of working with xml-like documents I've ever used or seen looks clumsy and verbose by comparison
[19:55] <jsp> bb momentarily... but, btw, you've actually got the javascript semicolon parsing thing backwards. it parses first assuming that you put in all the semicolons in the right places and only goes back and tries inserting them where there are newlines if it can't make sense of your stuff. (and return on a line by itself is legit--means return undefined).
[19:56] <rjb> nope i don't believe that's correct
[19:56] <rjb> i haven't looked up the specs, but my experience is
[19:58] <rjb> that whenever you write a statement that is complete and correct up to the newline, except for the missing semicolon
[19:58] <rjb> the interpreter assumes you meant a semicolon before the newline
[19:58] <jsp> (hrm... now that I think about it, my explanation doesn't actually explain the behavior. my bad.)
[19:59] <rjb> iow, "return\n5;" will be read as "return;5;"
[20:00] <rjb> which of course is just as legal as "return 5;"
[20:01] <rjb> e4x looks pretty cool
[20:02] <rjb> it also seems even better than php for entangling logic and presentation
[20:02] <rjb> model and view, if you like
[20:02] <jsp> re: logic & pres, more in a moment
[20:05] <jsp> but re: semicolons, your explanation doesn't cover the facts either, because although "= 'something';" is not a valid statement, "var a" is. So if semicolons were inserted immediately at the end of a line if the statement were valid at that point, "var a\n= 'something'" would die on the second line.
[20:06] <jsp> it seems to be a fairly subtle bit of stupidity
[20:06] <rjb> ok, so i probably oversimplified
[20:06] <jsp> anyway, the details of that aren't terribly important
[20:06] <rjb> but i'm too lazy ot look up the spec
[20:07] <jsp> likewise. on to better things
[20:07] <rjb> i just use the rule of thumb, when inserting a newline, make sure the statement is syntactically incomplete if broken off at the newline
[20:10] <jsp> I've been using PHPTAL (which mostly duplicates python's TAL) for templates with PHP for a while. I didn't generate a single line of HTML directly with PHP but always passed variables and made filters available to my template.
[20:13] <jsp> and I've decided that, contrary to expectation, that's the real way to *tangle* logic and presentation. because when you get beyond simple cases, you end up spending an inordinate amount of code setting up information in simple variables for your template to use, and then more time writing conditionals and loops in your template language to make use of those appropriately, because the display logic for lots of pages just isn't simple
[20:14] <jsp> you get to where a third the lines of PHP make no sense unless you're holding the template next to them (and you can follow the template, which has a lot of html in between the variable references), and there's no way to write or modify a template either without holding the PHP up next to it, because there are so many arbitrary names to remember
[20:16] <jsp> Helma with its skins (e.g., if you follow the addressbook tutorial) seems to say: rendering an object in HTML is properly a method of that object. And I now agree. I just think the added indirection of splitting that rendering between two files is inefficient
[20:18] <typicaljoe> agreed
[20:19] <jsp> so my fledgling UserMgr class has a function asTable() which builds a table and inserts the results of calling asRow() on each User child.
[20:21] <jsp> these functions are 5 and 2 lines long respectively, and I can't think of any way I would benefit from complicating them by splitting each into two files
[20:23] <jsp> the other thing (and I think it's a very big thing) about e4x is that if you keep everything in XML objects until the end, escaping is handled completely for you
[20:25] <rjb> hmm yeah that is some food for thought
[20:27] <rjb> using e4x requires helma 1.6, right?
[20:28] <rjb> 'k, excuse me, gotta split now. i'll check out the logs later, when i can
[20:30] <jsp> I can (to take a too-trivial example) write a function greeting(name){ return <p>Hello, <b>{name}</b></p>; } and greeting will *always* do the right thing, no matter what I pass as name.
[20:30] <jsp> greeting("Joe") returns (the XML object) <p>Hello, <b>Joe</b></p>.
[20:30] <jsp> But if I put user input in, greeting("<a href='alert(\"XSS attack!\"'>ha</a>") returns (XML object) <p>Hello, <b>&lt;a href .... </b></p>.
[20:30] <jsp> but if I decide *I* (not a sneaky user) need some markup in user, I pass it in as an XML object like greeting(<i>Joe</i>) and e4x does the right thing again. I get <p>Hello, <b><i>Joe</i></b></p> back
[20:34] <typicaljoe> very nice, that is cool
[20:43] <jsp> helma skins are plain text, so the skin engine doesn't know what kind of escaping you need where, so you have to specify or it does nothing, which means doing the wrong thing is easier than doing the right thing. it also means it's impossible to setup your template to safely take both markup from you and text from the user.
[20:44] <jsp> PHPTAL lived in XML, so it could escape correctly by default. but neither it nor any other system I've ever seen before e4x could have done that trivial greeting example
[20:47] <jsp> I would have to make greeting(name) include the name without escaping and make sure that the code that called it did escaping when necessary (right thing hard and not transparent) or I would have had to add an extra parameter to tell greeting whether name was safe or not in which case the right thing is easier and more transparent, but still clumsy compared to e4x, especially when you consider that I'll have to add that extra paramet
[20:50] <jsp> for rjb, whenever you read the logs, yes, helma 1.6 is required, and you'll need the updated rhino.jar chris posted earlier to fix a bug with attribute literals (same smart stuff as in my greeting example, but for attributes as well as content). I've also mirrored it and am posting regularly about my helma-learnig travails at http://letterblock.com/intheopen
[22:05] <jsp> ok, I've lost the documentation page. what do you call the functions that you want to use to handle e.g., get and post if you want them to be separate functions instead of branching the hac file?
[22:26] <zumbrunn> jsp: http://helma.org/docs/guide/framework/
[22:26] <zumbrunn> "In addition to the standard '_action' suffix, which handles both GET and POST as well as HEAD requests, you can specify actions that will handle specific request methods, such as '_action_get', '_action_post', '_action_put' and '_action_delete'. See RFC 2616 section 9 for more information about standard HTTP method definitions."
[22:26] <jsp> I skimmed that page and missed it. thanks
[22:27] <jsp> new thing:
[22:27] <jsp> all the functions I define in any js files inside a prototype's directory become methods of that prototype, right?
[22:27] <zumbrunn> right
[22:28] <jsp> from my user manager I'm trying to instantiate a new User and then call a method (any method!) but they're all not founf
[22:28] <jsp> found
[22:29] <jsp> hrm and my manage application has barfed
[22:30] <jsp> ah--there's a reason for that
[22:31] <jsp> (I had changed its base uri but forgot to change it again aftewr upgrading to 1.6 final)
[22:34] <jsp> var myuser = new PTWUser;
[22:34] <jsp> var form = myuser.asForm()
[22:35] <jsp> TypeError: Cannot find function asForm. (C:\sites\preachingtheword.net\helma\UserMgr\create.hac#2)
[22:35] <jsp> but browsing the API from the manage console, it has asForm and the two other functions I've defined
[22:36] <zumbrunn> hmm...
[22:37] <zumbrunn> use the shell action to check if it's really defined
[22:37] <zumbrunn> checking with "PTWUser.prototype.asForm"
[22:38] <jsp> I was actually trying to use that originally--I was just going to .apply() it to a mini-object, but that didn't work either--couldn't call apply method of undefined
[22:44] <jsp> shell shows:
[22:44] <jsp> PTWUser.prototype
[22:44] <jsp> [HopObject prototype PTWUser]
[22:44] <jsp> but none of the expected methods exist
[22:44] <jsp> and with ps = []; for(n in PTWUser.prototype) ps.push(n); , ps is empty
[22:47] <jsp> ok, that for-in loop doesn't work on UserMgr, but I am able to access its methods through the shell
[22:47] <jsp> I wonder if it's because PTWUser extends user
[22:49] <jsp> nope
[22:52] <jsp> changed the name of it, too.
[22:57] <jsp> got it
[22:58] <jsp> there was an error in one of the files for the PTWUser, but Helma didn't display the fact anywhere till I mounted one and tried to access it
[23:16] <jsp> I think the failure to throw an error earlier had to do with the weird twilight in which E4X syntax lives (and the fact that I left off an e4x closing tag). it gets partly figured out at compile time, but some things that would seem like compile time issues don't actually show up till runtime
[23:48] <jsp> wahoo. my app finally does something
[23:57] <jsp> variables that I define outside of functions in script files inside prototypes live where? in the global scope?
[23:58] <jsp> in some kind of per-prototype scope?

 

 

In the channel now:

Logs by date: