Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-05-31:
[7:48] <hannesw> good morning[7:49] <hannesw> wondering if we should do a 0.5.1 release soon
[7:49] <hannesw> because of the changes in httpserver which came immediately after 0.5.0
[7:49] <hannesw> that was pretty bad timing
[7:57] <hannesw> oberhamsi read your message regarding array.unique etc from two days ago
[7:57] <hannesw> i agree. i think I'll start throwing out obscure stuff from core/array and core/string and whatever
[7:58] <hannesw> and we need to think about a story for making core extension optional.
[8:09] <oberhamsi> my biggest concern with core extensions is that it makes apps less portable to other commonjs frameworks
[8:09] <hannesw> right
[8:09] <oberhamsi> which could easily be fixed by making them an extra lib
[8:10] <hannesw> if ringo core still depends on it that wouldn't make much of a difference
[8:10] <oberhamsi> right
[8:11] <hannesw> we should investigate what it would look and feel like to have core/* as ordinary modules
[8:16] <robi42> i think we could put quite some of the core prototype extension methods into corresponding "utils" modules
[8:16] <robi42> or get rid of altogether in some cases
[8:18] <hannesw> +1
[8:18] <robi42> plus, in some cases it may make most sense to introduce new types
[8:18] <robi42> like, e.g., some kind of set type for `array#unique`
[8:18] <hannesw> yes
[8:19] <hannesw> we could make better use of java collections, although they're easy enough to use as is
[8:19] <robi42> true
[8:19] <hannesw> maybe we can make it simpler, and not force people to leave ringo api
[8:19] <robi42> personally, i like the way python's collection apis work
[8:20] <robi42> interface-wise
[8:20] <hannesw> what's special about it?
[8:21] <robi42> well, nothing really special. just convenient to use (don't need 5 locs just to init a map/dict)
[8:22] <hannesw> hm, of course operator overloading is also nice
[8:22] <hannesw> like set < other
[8:22] <robi42> right
[8:22] <robi42> so maybe we could wrap java's collections a little into that direction
[8:36] <robi42> btw, it's also pretty straight-forward to extend collection types in python; see, e.g.: http://docs.python.org/library/collections.html#abcs-abstract-base-classes
[8:38] <hannesw> interesting, thanks
[14:59] <gmosx> hey
[15:00] <hannesw> h gmosx
[15:00] <hannesw> i
[15:01] <gmosx> is there a ringo-meeting scheduled for tonight?
[15:01] <hannesw> don't know
[15:01] <hannesw> i'm a bit out of the loop, semi holydays so to speak
[15:02] <hannesw> we used to irc-meet every monday, but became a bit lazy
[15:02] <hannesw> but yes, i think we should have one
[15:02] <gmosx> ok...
[15:02] <gmosx> btw...
[15:02] <oberhamsi> i usually check the schedule and when it's empty i don't expect many attendents
[15:02] <oberhamsi> :) today +1
[15:03] <gmosx> appenginejs.org is 'slashdotted' by hacker news: http://news.ycombinator.com/item?id=1392197
[15:03] <gmosx> please vote ;-)
[15:03] <hannesw> yeah, saw that already. great!
[15:03] <gmosx> thanks...
[15:04] <gmosx> hannesw: commonjs has ratified a proposal for tests
[15:05] <gmosx> is ringo/test compatible?
[15:05] <gmosx> can we move it to a toplevel namespace since this is a commonjs proposal?
[15:05] <hannesw> no, unfortunately not
[15:05] <gmosx> hmm...
[15:05] <hannesw> there's an open issue for that
[15:06] <gmosx> how about just 'stealing' the test code from narwhal-lib?
[15:06] <hannesw> not sure how to resolve this (keep both, build one on top of the other, use impl from narwhal...)
[15:06] <hannesw> yes, it's a possibility
[15:06] <gmosx> just use the narwhal version...
[15:06] <hannesw> i think there are really good features in ringo/unittest
[15:06] <gmosx> hmm...
[15:06] <hannesw> so i wouldn't discard that
[15:07] <gmosx> but commonjs comaptibility isn't more important?
[15:07] <gmosx> for example I would like to port my test suite from narwhal to ringojs
[15:07] <gmosx> at least use the same names for the common functionality
[15:07] <hannesw> yes, talking about starting from ringo/unittest and making it commonjs compliant
[15:07] <gmosx> ok
[15:08] <gmosx> I any case
[15:08] <gmosx> I use very small subset of the features...
[17:59] <hannesw> irc meeting anyone?
[18:03] <earl> i'd be around (but don't have interesting things to talk about)
[18:09] <hannesw> i'm here but kids are still up, so not likely i get to work
[18:13] <robi42> am around now as well (yet, not really with hot topics and actually busy otherwise)
[18:25] <gmosx> I am here too...
[18:26] <gmosx> I would like to discuss the unittesting/commonjs compatibility issue...
[18:26] <hannesw> ok
[18:27] <hannesw> we usually put our meeting agenda up here:
[18:27] <hannesw> http://ringojs.org/wiki/IRC_Meeting/
[18:28] <hannesw> i added unittesting/comonjs compat
[18:28] <gmosx> thanks...
[18:28] <robi42> my 2 cents: i really like `ringo/unittest` and would rather keep and extend/adapt it
[18:28] <hannesw> adding extending core objects
[18:29] <hannesw> sorry, away for 5 minutes
[18:29] <gmosx> robi42: but it should be commonjs compatible, come on!
[18:29] <robi42> sure, commonjs compatibility is preferable :)
[18:31] <robi42> yet, afaik `ringo/unittest`'s actually merely a superset of commonjs' one (at least in some respects)
[18:31] <gmosx> ok, let's make sure that it is a superset...
[18:31] <gmosx> ant move it to the top level namespace
[18:31] <gmosx> and
[18:32] <robi42> +1 for checking commonjs compliance, not sure about moving top-level scope, tho
[18:32] <robi42> moving to*
[18:33] <earl> http://wiki.commonjs.org/wiki/Unit_Testing/1.0
[18:34] <earl> ^^ is this the spec we are talking about?
[18:34] <robi42> guess so? :)
[18:36] <gmosx> i guess so too...
[18:36] <gmosx> btw, ot:
[18:36] <gmosx> hannesw, etc: congrats for ..Lena ;-)
[18:37] <gmosx> (even though I preferred the Denmark song)
[18:37] <earl> totally ot, and wrong ...
[18:37] <earl> because germany != austria
[18:37] <gmosx> (I was listening eurovision songs at the moment)
[18:37] <gmosx> ah, I though you were germans... sorry ;-)
[18:38] <gmosx> my mistake...
[18:38] <gmosx> was a lame song anw ;-) ;-)
[18:38] <earl> :)
[18:38] <robi42> omg, even #ringojs is being spam med by #esc now ;)
[18:38] <gmosx> what is #esc ?
[18:38] <earl> the eurovision song contest
[18:39] <robi42> and its twitter hash tag
[18:39] <gmosx> ah
[18:40] <earl> back to testing
[18:40] <robi42> i think ringo/unittest's assertEqual equals commonjs deepEqual
[18:41] <earl> i think it should be possible to impl ringo/unittest on top of commonjs assert
[18:42] <robi42> think so too, yes
[18:43] <earl> not sure if it's worth the effort, at the moment
[18:43] <earl> but patches would certainly be accepted :)
[18:45] <robi42> btw, ringo's not on http://en.wikipedia.org/wiki/Server-side_JavaScript
[18:45] <robi42> let's add?
[18:47] <earl> sure :)
[18:52] <robi42> ok, done so :)
[19:00] <gmosx> OK, perhaps I can work on the testing thing...
[19:00] <gmosx> will have a look tomorrow...
[19:02] <robi42> great
[19:04] <gmosx> btw I have another idea...
[19:04] <gmosx> it seems to me that commonjs is stalled...
[19:05] <gmosx> and all the action happens with nodejs
[19:05] <hannesw> i'm back
[19:05] <gmosx> perhaps we should copy some apis from nodejs (NOT the async stuff though)
[19:06] <gmosx> ie, make ringojs more compatible with nodejs (NOT 100% compatible)
[19:06] <gmosx> what do you think?
[19:06] <earl> well, that's pretty abstract, i fear :)
[19:06] <earl> there's good reason nodejs does not care much for commonjs in many areas
[19:07] <earl> (afaiu, nodejs decidedly wants to be non-blocking as much as possible)
[19:08] <hannesw> well, nodejs things that operates on strings etc should work in ringo
[19:08] <gmosx> ok...
[19:08] <hannesw> i'm fine with copying good stuff - not because it's in node.js, but because it's good
[19:08] <earl> but wherever a node api makes sense on ringo as well, why not
[19:08] <hannesw> any significant level of compatibiltiy will be hard
[19:09] <gmosx> I meant copying names, etc...
[19:09] <hannesw> well node doesn't use a proper namespace for its own modules
[19:09] <earl> any specific things you are thinking about?
[19:09] <gmosx> ie, keep nodejs apis in mind when naming things...
[19:09] <hannesw> i think that might be fine for things like url-parsing utilities etc (haven't looked at node api recently)
[19:09] <gmosx> ehm, perhaps using a sys module instead of system, using process instead of subprocess, stuff like that...
[19:10] <gmosx> the url-parsing utilities, is a nice example too...
[19:10] <earl> system is commonjs, so i guess we'll keep that :)
[19:10] <hannesw> well system is commonjs, i woudn't depart from that
[19:10] <gmosx> earl: yeah ;)
[19:10] <hannesw> node.js is very overhyped
[19:10] <hannesw> things will calm down
[19:10] <gmosx> hannesw: agreed ;-)
[19:10] <earl> well, it's ok for a certain class of things
[19:11] <gmosx> dunno, rails was overhyped too, but things never slowed down...
[19:11] <hannesw> node will, i'm sure
[19:11] <hannesw> first, full async won't work well for local dbs
[19:12] <gmosx> hannesw: don't underestimate the effect of hype...
[19:12] <hannesw> second, jvm beats v8 in many ways
[19:12] <gmosx> and don't try to rationalize with technical arguments...
[19:12] <earl> re process: that's a pretty good example of an api we decidedly won't mimic in ringo
[19:12] <hannesw> well, i know
[19:12] <gmosx> one problem of Ringo is Rhino... looks like a stalled project...
[19:13] <earl> that's FUD
[19:13] <gmosx> JVM is good, but Rhino needs some marketing... is there any progress with Rhino?
[19:13] <earl> http://github.com/earl/rhino-mirror/commits/master
[19:13] <gmosx> is there a changelog somewhere?
[19:13] <hannesw> rhino is fine.
[19:14] <earl> rhino is stable and battle-proven, and way ahead of v8 language-wise
[19:14] <oberhamsi> well rhino already has modern js ... lots of other engiens dont. what is stalled?
[19:14] <robi42> rhino's on the forefront of es5-compliant engines :)
[19:16] <hannesw> and it won't crash on you
[19:16] <hannesw> randomly
[19:16] <hannesw> http://transloadit.com/blog/2010/04/to-launch-or-not
[19:17] <hannesw> and i also read this today:
[19:17] <hannesw> http://debuggable.com/blog
[19:17] <earl> well, that's only spreading counter-fud :)
[19:17] <hannesw> raw node upload performance is 16-20 mb/s
[19:17] <hannesw> ringo's is 35 mb/s (on my laptop)
[19:18] <hannesw> and the 500 mb/sec is in-memory, without http protocol
[19:18] <gmosx> nice to now that rhino development is active...
[19:18] <hannesw> so there's a lot of bs and good marketing there...
[19:19] <gmosx> perhaps you should add a page about Rhino (including a link to the changelog) in the RingoJS homepage
[19:20] <hannesw> well maybe we should write more about ringo
[19:20] <hannesw> i mean off-ringojs.org
[19:21] <hannesw> i know i'm really bad at this
[19:21] <robi42> well, at least there's a little ringolog out there ;)
[19:21] <earl> :)
[19:22] * hannesw cheers to robi42 for ringolog
[19:23] <robi42> thanks, but i could put more effort into directly promoting ringo there, i guess
[19:23] <hannesw> no, you're doing fine
[19:24] <robi42> ok, actually can't stand (over-)hyping myself :)
[19:24] <hannesw> i think what we're missing something like a common effort, i think
[19:24] <robi42> yep
[19:25] <earl> well, at the moment an apples-to-apples comparison of our multipart parsing would be nice :)
[19:26] <robi42> but generally interest is rising as far as i can tell
[19:26] <gmosx> what is ringolog ?
[19:26] <earl> a weblogging app written using ringo
[19:26] <gmosx> ah
[19:26] <robi42> log.robert42.com
[19:26] <earl> http://github.com/robi42/ringolog
[19:26] <earl> running at what robi said :)
[19:26] <robi42> :)
[19:27] <gmosx> http://www.gmosx.com/blog
[19:27] <earl> actually a nice show-off of a whole bunch of features
[19:27] <gmosx> another webloging app using ringo: http://www.gmosx.com/blog
[19:27] <robi42> cool
[19:27] <gmosx> ringo + appenginejs that is ;-)
[19:27] <robi42> that's great
[19:28] <gmosx> ringo is great ;-)
[19:28] <gmosx> and this is why I switched from narwhal:
[19:28] <gmosx> No, I meant what I said. We use narwhal-jsc 95% of the time. Rhino is this unfortunate thing we keep around for compatibilities sake.
[19:28] <gmosx> !!!!
[19:28] <gmosx> from one of the 280North guys...
[19:28] <gmosx> what a pitty...
[19:28] <gmosx> pity
[19:29] <hannesw> well narhwal-rhino is a real hack
[19:29] <gmosx> finally they admitted they are not interested in narwhal-rhino
[19:29] <earl> narwhal's multi-engine stuff is a story of a failed attempt, so far
[19:29] <earl> (at least to me :)
[19:30] <gmosx> narwhal was great until for some reason Tom and Kris seemed to lose interest...
[19:30] <gmosx> for different reasons each of them...
[19:30] <hannesw> who said that, francisco tomalsky?
[19:30] <gmosx> boucher
[19:31] <hannesw> ok
[19:31] <gmosx> what a pity, I really admire Tom's and especially Kris' work...
[19:31] <earl> (now where-the-f has ringostarr gone ...)
[19:31] <hannesw> yes, they're both great
[19:31] <gmosx> (I mean Kris is nothing sort of a genius)
[19:32] <gmosx> and Tom looked like a great leader for an OSS project...
[19:32] <hannesw> kris has followed the crowd to node, and i guess tom is busy with other things
[19:32] <gmosx> what a pity :(
[19:32] <gmosx> nah, Kris is more interested on CommonJS, and the standards process...
[19:32] <gmosx> anw gotta go, bbl
[19:33] <hannesw> cu
[19:33] * earl pats ringostarr on the back
[19:33] <robi42> cu gm osx
[19:34] <earl> what a pity that ringostarr's log missed the last 10 hours
[19:34] <hannesw> where is ringostarr's log=
[19:34] <earl> totally hidden and secret :)
[19:35] <earl> http://ringojs.at/bot/
[19:35] <hannesw> oh noes! another ringojs
[19:35] <earl> well, only until i get around to deploy it on ringojs.org
[19:35] <hannesw> :)
[19:35] <robi42> :)
[19:36] <earl> but as you can see, it's almost done :)
[19:36] <earl> fully integrated into the ringojs.org app, that is
[19:36] <hannesw> it looks good
[19:36] <robi42> it does
[19:37] <hannesw> what's stopping you from deployment on ringojs.org?
[19:37] <earl> deployment itself
[19:37] <hannesw> :) ok, good reason
[19:38] <earl> ringojs.at is also a testbed for alternative deployment strategies for me
[19:38] <robi42> as in "run.sh"?
[19:38] <earl> yeah
[19:39] <earl> but it's now managed using daemontools
[19:39] <robi42> ah nice
[19:39] <earl> and makes for a very nice deployment, where all of the bits and pieces are kept together, instead of spread around wildly across the fs
[19:39] <hannesw> ah yes, earl i hear you have doubts about debian packages being best way to deploy (on debian)?
[19:39] <earl> yes, i do :)
[19:40] <hannesw> what does your strategy look like?
[19:40] <earl> but that's mostly got to do with ringo's rapid progress
[19:41] <earl> if you want to deploy from released ringo versions, the debian packages are fine
[19:42] <earl> http://bin.strain.at/paste/LaGllk.html
[19:42] <earl> crap :)
[19:43] <earl> that's an overview comparing the directory layout of ringojs.org and ringojs.at deployments
[19:43] <hannesw> ok, interesting
[19:43] <hannesw> the dirty dirs are my fault of course :)
[19:43] <earl> yeah, np :)
[19:44] <hannesw> ha, ringojs.at is a full clone of ringojs.org?!
[19:44] <earl> sure :)
[19:44] <hannesw> ok
[19:44] <earl> i sync ringojs.org data over :)
[19:45] <hannesw> wow, would be nice to join irc via web interface in that irc tab
[19:45] <earl> yes, that's still missing
[19:45] <hannesw> maybe a use case for some async/comet/jabber whatever package we have :)
[19:46] <earl> well, i'll simply rip off what zumbrunn is using :)
[19:46] <earl> http://ringojs.com/bot/join
[19:46] <hannesw> oh ok
[19:46] <earl> until we have our own chat, that is :)
[19:47] <earl> would be an awesome place for a ringo-written irc web client, or something
[19:47] <robi42> totally :)
[19:47] <earl> well, the point about ringojs.at deployment is that the whole app is self-contained in a single directory structure
[19:47] <hannesw> maybe updae irc channel in web via async ajax
[19:48] <robi42> that would be sweet, yes
[19:48] <earl> http://github.com/earl/ringobot
[19:48] <hannesw> +1 for updating ringojs.org soon
[19:48] <earl> that's the irc webapp :)
[19:50] <robi42> yep, we need some node-like chat stuff on ringojs.org :)
[19:50] <earl> yeah :)
[19:50] <earl> would be awesome to have it IRC-backed, though
[19:51] <hannesw> yep
[19:51] <robi42> +1
[19:51] <earl> but i think we may hit connection restrictions or something similar
[19:51] <robi42> possibly, yes
[19:51] <earl> needs some investigation
[19:51] <robi42> so let's give it a spin :)
[19:52] <hannesw> +1!
[19:54] <robi42> btw and a bit ot, what i, among other things, enjoy most about coding things with ringo is how few legible code's generally necessary to build something valuable
[19:55] <robi42> and the fewer code, the fewer bugs potential, the better :)
[19:55] <hannesw> yes, think so too
[19:56] <hannesw> not sure if you saw this:
[19:56] <hannesw> http://groups.google.com/group/bespin/browse_frm/thread/6de8c718d64232a0#
[19:57] <hannesw> bespin server roadmap - kevin dangoor announced they're rewriting their python server in js, probably node.js
[19:57] <earl> heh, i guess that means they'll be dropping use of my beanstalkc lib as well :)
[19:57] <hannesw> somebody in the thread asks for ringojs compat
[19:58] <hannesw> i'm not sure, but maybe we can make them see how ringojs helps them get to shipping project earlier
[19:59] <robi42> would be awesome
[19:59] <hannesw> and it's in that context that i thought about extending core orbjects - because i think that potentially scares many potential savvy users
[19:59] <robi42> do you know how much they're node-biased already?
[19:59] <hannesw> i know chl was kind of shocked when he learned we're doing this :)
[19:59] <hannesw> i think it's just a general follow-the-crowd sentiment
[19:59] <robi42> i see
[19:59] <hannesw> their current python app would map to ringo nicely
[19:59] <robi42> so let's at least try to get ringo in there as well
[20:00] <hannesw> and i'm truly convinced it would be completely wrong for them to choose node
[20:00] <robi42> so let's convince them then :)
[20:00] <hannesw> yes.
[20:00] <hannesw> just: i think we need to get a better compatibility story
[20:01] <robi42> agreed
[20:01] <hannesw> which is why i think we shoudl consider dropping extending core objects
[20:01] <earl> well, why not
[20:01] <earl> will lead to slightly more verbose code in some cases
[20:01] <earl> but i guess that's a cost worth paying
[20:02] <hannesw> if we do that and use destructuring require in our own code, i think we have a pretty good compat story
[20:02] <robi42> yes, as mentioned before, most stuff would be fine in some kind of "utils" modules, i think
[20:02] <hannesw> i think we should try it and look at the code and then decide
[20:02] <robi42> +1
[20:02] <hannesw> i guess i can do a branch
[20:05] <robi42> earl, is there something like beanstalkr? :)
[20:06] <earl> i guess there are java libs :)
[20:06] <earl> a branch is a good idea
[20:07] <robi42> (with r as in ringo, a ringo client for beanstalkd, that is :) )
[20:08] <oberhamsi> compat plan sounds good
[20:10] <earl> btw, a completely unrelated q
[20:10] <earl> it seems that ringo webapps don't need the config/ subdirectory at all
[20:12] <oberhamsi> i think it would read the one from modules
[20:12] <earl> would it make sense to drop creating it in ringo-admin create?
[20:16] <robi42> i guess most users would be fine with simply using defaults from ringo's home installation
[20:17] <gmosx> +1000 with droping extensions in core objects
[20:17] <gmosx> +1000000 for droping include()
[20:18] <gmosx> btw, nodejs and narwjaljs use the same require("assert");
[20:19] <gmosx> i think just moving assert.js from narwhal-lib into ringojs/modules would be a good first step
[20:20] <robi42> i'd like to keep include() (really useful, e.g., in repl sessions) but wouldn't use it in modules code as far as possible/reasonable
[20:22] <gmosx> robi42: makes sense
[20:22] <hannesw> yes, i think the thing about include is just we shouldn#t use it in our code
[20:22] <earl> yep
[20:22] <earl> include absolutely rocks in the shell
[20:22] <earl> maybe we should simply move it to ringo/shell :)
[20:22] <gmosx> another q: i am browsing ringo/unittest.js
[20:22] <gmosx> and see code like
[20:22] <hannesw> earl: maybe so
[20:23] <gmosx> this.functionname = function () {}
[20:23] <robi42> earl: +1
[20:23] <gmosx> is this === exports ?
[20:23] <gmosx> in ringo?
[20:23] <earl> nope
[20:23] <hannesw> gmosx: no
[20:24] <gmosx> I see this with no identation...
[20:26] <earl> i think the top-level `this` stuff in ringo/unittest is mostly superfluous by now
[20:27] <robi42> yes
[20:27] <hannesw> don't know, haven't looked at it
[20:28] <robi42> doesn't hurt, tho (how it's currently written)
[20:29] <earl> unittest predates our the whole commonjs modules stuff, if i'm not mistaken
[20:29] <hannesw> well it's from the early days
[20:29] <robi42> it is
[20:31] <robi42> btw, while speaking of unittest: a `fail(msg)` would come in handy, imho
[20:31] <hannesw> yes, totally
[20:32] <hannesw> shout we add (a) ticket(s) for that?
[20:32] <robi42> +1
[20:32] <earl> == system.stderr.print(msg) + exit?
[20:33] <hannesw> throw AssertError(msg) i guess
[20:33] <robi42> calling fail would expect an Error to have taken place, yes
[20:33] <hannesw> ah, we have that!
[20:33] <hannesw> i think it's called throws() or so
[20:33] <robi42> do we? :)
[20:33] <earl> :)
[20:34] <hannesw> but fail() in my book would be to throw an error and say "we failed"
[20:34] <hannesw> i.e. "test failed"
[20:34] <hannesw> not sure, but this might be in commonjs api also
[20:34] <earl> ok
[20:35] <hannesw> i think both are needed
[20:35] <robi42> yes, we'd need both
[20:36] <robi42> so assertThrows() covers the first case, right?
[20:36] <earl> yes
[20:38] <earl> fail(msg) == throw new ringo.unittest.AssertionException(msg)
[20:38] <earl> (or new assert.AssertionError({message: msg}), with cjs testing)
[20:38] <earl> currently ringo/unittest does not export the AssertionException, though
[20:38] <earl> not a problem if we add fail in ringo/unittest :)
[20:39] <robi42> +1 for adding fail like that :)
[20:40] <robi42> plus, something like "[before|after]TestModule" would be nice, i guess
[20:41] <hannesw> yes... i fought hard with setup/teardown in httpclient tests
[20:41] <earl> is setup/teardown run once per test?
[20:41] <hannesw> for each test function
[20:41] <robi42> yep, once per test function
[20:41] <earl> ok
[20:41] <hannesw> so for each httpclient a new server is started
[20:42] <hannesw> that caused some problems with binding, so i had to add a sleep(1000) to get it run consistently on my machine
[20:45] * robi42 gotta leave now, bye guys
[20:45] <hannesw> bye
[20:45] <hannesw> one last thing from me
[20:45] <hannesw> i've started working again on making ringojs securable
[20:45] <hannesw> so i can set up some ride demo
[20:46] <hannesw> i still think that could do many good things for ringojs
[20:46] <hannesw> http://github.com/hns/ride
[20:46] <earl> robi42: you still around?
[20:46] <hannesw> even just as a simple demo site
[20:46] <earl> robi42: well nvm, can wait for another day :)
[20:47] <robi42> couldn't leave when ride topic came up now :)
[20:47] <earl> go away! :)
[20:47] <robi42> can't! :)
[20:47] <hannesw> oh, i'm already finished with ride
[20:48] <robi42> anyway, see you tomorrow ;)
[20:48] <earl> heh, you're even using submodules
[20:48] <earl> who'd have thought!
[20:48] <hannesw> :) not much more to say (or show)
[20:48] <hannesw> cu
[20:48] <hannesw> i love submodules!
[20:48] <hannesw> (not)
[20:48] <earl> hehehe :)
[20:49] <earl> ride certainly is a nice demo
