Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-04-26:
[6:53] <hannesw> good morning[8:20] <oberhamsi> morning
[8:21] <hannesw> yet another tough stupid problem:
[8:21] <hannesw> http://github.com/ringo/ringojs/issues#issue/47
[8:22] <hannesw> simple solution seems to be to delay loading of logging module in ringo/webapp...
[9:13] <hannesw> hm, I'd like to remove addHostObject in ringo/engine in favour of global defineClass()
[9:13] <hannesw> (which comes from and is compatible to rhino shell)
[9:14] <hannesw> but of course it's a bit confiusing that it's the same name as used by Storable...
[9:14] <hannesw> robi42 you once has a proposal for renaming Storable.defineClass(), didn't you?
[9:15] <robi42> defineModel, defineDomain, define, ... xchl also had some thoughts on that.
[9:15] <robi42> defineStorable
[9:19] <hannesw> hm, maybe just define()
[9:20] <robi42> yes, `store#define` sounds just fine :)
[9:25] <hannesw> ok... will propose this for today's IRC meeting
[9:25] <hannesw> btw, let's not forget :)
[9:27] <hannesw> http://ringojs.org/wiki/IRC_Meeting/
[9:30] <robi42> :)
[9:40] <robi42> oh, we're on the front page of http://metalab.at/ by now
[10:16] <robi42> liamMT: just curious, still working on your mongodb adapter, originally, for helma-ng?
[14:39] <liamMT> robi42: no, I haven't touched that for a while, and it was not much more than a thin layer around their existing java driver
[14:41] <robi42> liamMT: thanks for info. would be really interesting to have a ringo store mongodb impl
[14:41] <liamMT> agreed - both are pretty nice pieces of software :)
[14:41] <robi42> :)
[14:43] <robi42> btw, code of your native java driver wrapper's still available online somewhere?
[14:44] <liamMT> um, I think I took it down, unfortunately. but I'm not sure it would really have gotten you that far, anyway.
[14:45] <robi42> ok, thanks
[17:35] <gmosx_> hi
[17:36] <gmosx_> any1 here?
[17:37] <waddler> some1
[17:37] <oberhamsi> hi
[17:38] <gmosx_> ok...
[17:40] * oberhamsi will be back later
[17:55] <robi42> hi
[17:56] <hannesw_> hi there
[17:56] <hannesw_> gi gmosx_ this symlink stuff is weird
[17:57] <hannesw_> just tried and symlinks do in fact work
[17:58] <gmosx_> hey
[17:58] <hannesw_> so, no idea what's going on here
[17:58] <gmosx_> strange...
[17:58] <hannesw_> you get no error message?
[17:58] <gmosx_> and this is a showstopper for me...
[17:58] <gmosx_> I get file not found or permission denied...
[17:59] <gmosx_> let me have a look...
[17:59] <hannesw_> hm, can you post that error message or stack trace here? http://ringojs.pastebin.com/
[17:59] <gmosx_> ok..
[18:00] <gmosx_> another question
[18:00] <gmosx_> when I pull the latest git repo
[18:00] <gmosx_> I should run ant jar again
[18:00] <gmosx_> should I copy run.jar to WEB-INF/lib/ringo.jar ?
[18:01] <hannesw_> no, ringo.jar should be the same as lib/ringo.jar
[18:01] <hannesw_> run.jar is just a tiny starter jar that sets up class path etc
[18:01] <hannesw_> not needed for app engine
[18:01] <gmosx_> ah ok
[18:01] <gmosx_> brb
[18:02] <hannesw_> ok, i'm ready to meet
[18:02] <hannesw_> ping earl robertgg robi42 waddler zumbrunn
[18:03] * robi42 equipped with a plate of noodles :)
[18:03] <hannesw_> ha... nice :)
[18:03] <hannesw_> we had one very large fish tonight... :)
[18:04] <robi42> which you also caught yourself? :)
[18:04] <hannesw_> nope. somebody else did that for us
[18:05] <robi42> :)
[18:05] <gmosx_> http://ringojs.pastebin.com/bkkG2tHg
[18:05] <gmosx_> hannesw_, this is the stacktrace
[18:05] <gmosx_> I use:
[18:05] <hannesw_> gmosx_ thanks
[18:05] <gmosx_> myapp/WEB-INF/packages/appengine -> symlink
[18:05] <gmosx_> if I use cp -R insteas of ln -s it works...
[18:08] <hannesw> can you find out what require.paths.join("\n") looks like?
[18:08] <gmosx> wait a bit...
[18:10] <gmosx> /home/gmosx/Temp/ringojs/apps/lala/WEB-INF/app/
[18:10] <gmosx> hmm...
[18:10] <gmosx> the require() is in config.js
[18:11] <gmosx> maybe the packages dir is not scanned in this stage?
[18:11] <hannesw> it should be
[18:11] <hannesw> hm, there's also no modules...
[18:11] <hannesw> did you create the app with ringo-admin create?
[18:11] <gmosx> yeap..
[18:11] <gmosx> ringo-admin create -a
[18:12] <gmosx> btw is the file main.js used my the ae-servlet?
[18:13] <hannesw> no, i don't think so
[18:13] <gmosx> oops wait a bit...
[18:14] <gmosx> the correct require.paths is
[18:14] <gmosx> /home/gmosx/Temp/ringojs/apps/lala/WEB-INF/app/
[18:14] <gmosx> /home/gmosx/Temp/ringojs/apps/lala/WEB-INF/modules/
[18:14] <gmosx> /home/gmosx/Temp/ringojs/apps/lala/WEB-INF/packages/narwhal-lib/lib/
[18:15] <gmosx> narwhal-lib is copied in packages (cp -R)
[18:15] <gmosx> appengine is symlinked and it is not shown in require.paths
[18:16] * earl waves hello
[18:16] <gmosx> earl, hey
[18:17] <robi42> g'evening, earl
[18:17] <hannesw> hi earl
[18:18] <hannesw> gmosx I'll try to replicate your setup tomorrow
[18:18] <gmosx> ok, thanks
[18:18] <hannesw> i'm sure we'll find what's going on
[18:18] <hannesw> well thanks for keeping on trying :)
[18:19] <gmosx> I am lured by the speed of ringojs (esp. on reloading)
[18:19] <earl> gmosx: would you mind posting a `find myapp/ -printf '%p %l\n'` as well?
[18:19] <gmosx> wait a bit...
[18:21] <gmosx> http://ringojs.pastebin.com/uZkzLLGj
[18:21] <earl> great, thanks
[18:21] <earl> /home/gmosx/Code/appengine is what?
[18:22] <gmosx> thats the target of the symlink
[18:22] <earl> yeah, what's in there?
[18:22] <earl> appenginejs?
[18:22] <gmosx> contains the appenginejs
[18:22] <gmosx> package
[18:22] <earl> so there's a /home/gmosx/Code/appengine/package.json?
[18:22] <gmosx> yeap
[18:23] <earl> k
[18:23] <hannesw> ok, should we get started with the meeting or continue debugging?
[18:23] <gmosx> :)
[18:24] <hannesw> i just tried appengine package with lib symlinked, and it 's on require.paths
[18:24] <gmosx> ok, lets start the meeting, i will create a new app from scratch and try again...
[18:24] <robi42> and package.json's similar to following one, right? http://github.com/gmosx/appengine/blob/master/package.json
[18:25] <gmosx> yes
[18:25] <earl> well, looks all very strange
[18:25] <earl> perhaps starting over with a app created from scratch is really the best option :)
[18:25] <robi42> :)
[18:25] <gmosx> have a look at the experimental branch of appenginejs for the actual code...
[18:25] <gmosx> ok...
[18:25] <gmosx> lets start the meeting and I will investigate this further privately...
[18:26] <gmosx> thanks for the help...
[18:27] <hannesw> ok
[18:27] <hannesw> so it looks like we only have a few renaming issues on the agenda today
[18:27] <hannesw> http://ringojs.org/wiki/IRC_Meeting/
[18:28] <hannesw> i think another interesting issue woud be things we want to get done for 0.5
[18:28] <robi42> yep
[18:30] <hannesw> should i ping everybody once more?
[18:31] <oberhams> pong :)
[18:31] <hannesw> ok first issue: renaming stuff
[18:31] <hannesw> i think now (before release) is again a good opportunity to try get some naming issues sorted out
[18:32] <hannesw> first one is Storable.defineClass()
[18:32] <robi42> +1 for `store#defineC lass` -> `#define` from my side :)
[18:32] <hannesw> xchl disliked the term "class" i think
[18:32] <hannesw> ok. isn't define() to generic?
[18:33] <robi42> well, not sure about the alternatives
[18:33] <earl> it's namespaced within storables anyway, no?
[18:33] <robi42> yep
[18:33] <hannesw> yep
[18:33] <earl> then no, not too generic :)
[18:33] <hannesw> ok. because the somehow related issue is:
[18:33] <robi42> `defineModel`, `defineDomain`, `defineStorable`, ...
[18:33] <earl> Domain: yuck
[18:33] <hannesw> rhino's global function for adding host objects (written in java) is also "defineClass()"
[18:33] <robi42> :)
[18:33] <earl> rest is fine with me :)
[18:34] <hannesw> defineEntity()?
[18:34] <earl> what we call addHostObject?
[18:34] <robi42> so it kind of conflicts to be used inside storage impls, right?
[18:34] <hannesw> yes. first, there was addHostObject() in ringo/engine
[18:34] <hannesw> actually, the implementation is the same
[18:34] <earl> ok
[18:35] <earl> defineEntity is nice, yes
[18:35] <hannesw> but i'd like to go with defineClass() for host objects because it's rhino kind of standard
[18:35] <robi42> sounds good
[18:35] <hannesw> the less stuff in ringo/engine the better IMO
[18:36] <hannesw> if ringo looks like a rhino shell, we have good starting point for interop (even though its globals)
[18:36] <hannesw> well what do you think?
[18:37] <robi42> i'd actually prefer defineEntity over plain define in that case, and +1 for ditching addHostObject in favour of defineClass
[18:38] <hannesw> ok
[18:39] <hannesw> earl? oberhams? anybody else?
[18:39] <earl> i also prefer defineEntity
[18:39] <earl> and getting rid of functionality duplicated in ringo over plain rhino is always nice :)
[18:40] <oberhams> i haven looked much at those. dont yet know what defineDomain does for example
[18:40] <oberhams> so what you decide :)
[18:41] <oberhams> but i agree defineEntity > defineClass
[18:42] <hannesw> ok, let's go with defineEntity() then
[18:43] <hannesw> so the second issue is also solved - go with rhino "standard" defineClass() , right?
[18:43] <robi42> +1
[18:46] <hannesw> ok next issue:
[18:46] <hannesw> skin vs. template
[18:46] <hannesw> i think this one will stir up some emotions... :)
[18:47] <hannesw> my drive behind this is simply because i'm afraid people don't get what skins are, and skip over them
[18:47] <robi42> wellll, i definitely like skins naming... :)
[18:49] <robi42> but i can see the benefits of calling them templates probably outweighing that, yes
[18:49] <earl> well, i though a bit about this one, and i think it's mostly a marketing issue
[18:49] <hannesw> i'm not sure. maybe it doesn't matter, or we just need to market the feature better
[18:49] <robi42> maybe
[18:50] <earl> if we want to promote our own templating engine even beyond ringo, i think keeping a distinct name would actually be a boon
[18:50] <hannesw> ok, very plausible
[18:50] <earl> but otherwise, just going with "ringo template" certainly eases discoverability
[18:50] <hannesw> you think we should do that? (unbundle etc)?
[18:51] <robi42> and in the end skins are still "skinning" views in one way or another :)
[18:51] <earl> i think we _could_ do that eventually
[18:51] <earl> i don't think that we should do it at the moment
[18:51] <hannesw> btw, the whole storage thing is a candidate for unbundling, too
[18:52] <oberhams> i like skins, the way we do templates is just different from a lot of other solutions
[18:52] <hannesw> ok i think the consensus is to stick with skins
[18:52] <oberhams> no if, different kind of loops, macros filters
[18:53] <oberhams> ok
[18:53] <hannesw> and just do some better marketing
[18:53] <hannesw> or documentation
[18:53] <earl> i probably wouldn't do anything about skins at the moment, as plainly, i don't think renaming is worth the effort
[18:53] <robi42> agreed
[18:53] <earl> and we can always revisit that decision later on
[18:53] <hannesw> ok, cool
[18:53] <earl> i.e. the next time skins get some love :)
[18:53] <hannesw> i still plan to rewrite the skin parser, btw
[18:54] <robi42> in pure js?
[18:54] <hannesw> the current setup is a bit weird and complex
[18:54] <hannesw> robi42: yes.
[18:54] <earl> i still plan to eventually revisit the builtin macros
[18:54] <hannesw> earl: that would be very welcome, they definitely need some love
[18:55] <robi42> is there a real reason why it's currently not pure js (performance-related)?
[18:55] <hannesw> robi42 when i wrote them we didn't have binary or io modules
[18:55] <robi42> i see
[18:56] <hannesw> and i did much more than like there's alomst a full json parser in there, which isn't needed really
[18:56] <robi42> ok
[18:56] <hannesw> it just doesn't make sense to put json into macro tags
[18:57] <robi42> do you think performance could become an issue in comparison to a skins parser in java?
[18:57] <hannesw> well we'll see. I'll have a try, if it doesn't work we'll stick with what we have
[18:58] <robi42> alright, sounds good :)
[19:00] <robi42> ah, new sub bullet point on agenda: what's missing to make ringo_hibernate "production ready"? :)
[19:00] <hannesw> yeah, i put that on :)
[19:00] <robi42> hehe
[19:00] <robi42> so
[19:01] <hannesw> because i think ringo-hibernate is going to be a huge force for us
[19:01] <robi42> basically, i (at least) try to manage current progress and issues via github by now
[19:01] <robi42> http://github.com/robi42/ringo-hibernate/issues
[19:02] <robi42> to make it production-ready what's needed primarily is convenient object reference / collection relation handling, i guess
[19:03] <hannesw> ok
[19:03] <hannesw> do you need help with this?
[19:03] <robi42> support's always appreciated :)
[19:03] <earl> btw, as someone mostly ignorant about our storage stuff, do we have something akin to helma's cache already?
[19:03] <hannesw> i can have a look
[19:03] <robi42> you can use ehcache with hibernate
[19:03] <hannesw> will also help me better understand r-hib
[19:04] <hannesw> can?
[19:04] <robi42> it allows for pretty sophisticated config
[19:04] <earl> yeah, i think caching for hibernate specifically is not the issue
[19:04] <robi42> well, actually it's there by default and one can further config it
[19:04] <earl> (i remember having a pretty awesome experience with swarmcache)
[19:05] <earl> would having a generic id-based cache a'la helma make any sense with our storage backends?
[19:05] <robi42> (hib-related example ehcache-config: http://github.com/ringo/ringowiki/blob/hibernate/config/ehcache.xml )
[19:06] <hannesw> is that config picked up automatically?
[19:06] <robi42> yep
[19:06] <hannesw> cool
[19:06] <robi42> taken from classpath
[19:07] <hannesw> robi42 could you still use subprocess support for running mysql scripts or whatever?
[19:07] <robi42> sure
[19:07] <hannesw> i merged the staging branch today
[19:07] <robi42> saw that, yes
[19:07] <hannesw> so there's semi-working encodings and subprocess modules
[19:07] <hannesw> i plan to do more work on them tomorrow
[19:08] <robi42> could provide according code in hib tests (commented out)
[19:08] <robi42> to possibly also make it even more convenient to test with mysql
[19:08] <robi42> btw, current test suite passes with bundled hsqldb as well as mysql
[19:09] <hannesw> tres cool
[19:10] <robi42> so next important step there would really be references/relations :)
[19:10] <hannesw> yes, think so too.
[19:11] <robi42> also have to think about how best to model it api-wise
[19:11] <robi42> via second arg to Storable and so on
[19:11] <hannesw> ok. maybe a good thing to sort out on wednesday
[19:11] <robi42> yep
[19:11] <hannesw> so anything else we _must_ get ready for 0.5?
[19:12] <robi42> cassandra! (just kidding) :)
[19:12] <gmosx> update jsgi to 0.3? ;-)
[19:12] <hannesw> ah, perfect!
[19:12] <gmosx> (no async, just the keys in env)
[19:12] <hannesw> thanks gmosx i actually thought about that
[19:12] <hannesw> well we do have async working already.
[19:12] <gmosx> ok then...
[19:13] <gmosx> just rename the env keys then ;-)
[19:13] <hannesw> but updating jsgi to 0.3 is a great idea because it'll make things simpler for us
[19:13] <hannesw> yes
[19:13] <hannesw> i think we won't have to wrap the env anymore, because our req object is already largely compatible to jsgi 0.3
[19:13] <hannesw> (not actually sure about that)
[19:15] <gmosx> yeap... the env in 0.3 is almost a request object...
[19:15] <gmosx> the only thing missing is a qs parser
[19:15] <gmosx> is a .params() function or something in env...
[19:15] <robi42> (btw, what would also be really nice for 0.5 is enhanced `ringo-admin install`? updating/deps etc.)
[19:17] <hannesw> also will add my promise implementation, which makes async jsgi much nicer:
[19:17] <hannesw> http://gist.github.com/379761
[19:17] <hannesw> regarding parameter parsing, another question:
[19:17] <hannesw> should we do something like request.GET/request.POST for request parameters?
[19:18] <hannesw> right now we only have request.params i think..
[19:18] <oberhams> jsgi 0.3 .. well the 'draft' assumes promises, is that still debated?
[19:18] <hannesw> robi42: yes, ringo-admin install with deps/updates is a must have, too
[19:18] <gmosx> I like request.GET, request.POST
[19:19] <robi42> i like that, too
[19:19] <earl> when do we want to release 0.5?
[19:19] <robi42> may 12th?
[19:19] <gmosx> I think it was useful in several occations in the past
[19:21] <gmosx> me sighs
[19:21] * gmosx sighs
[19:22] <hannesw> hey xchl!
[19:22] <xchl> good evening (europeans)!
[19:22] <gmosx> (i got the symlink to appengine to work, but now I have a problem with another package, drives me crazy)
[19:22] <gmosx> hey...
[19:22] <robi42> g'evening xchl :)
[19:23] <earl> hannesw: sync is a rhino builtin?
[19:23] <xchl> interrogating le bot
[19:23] <hannesw> earl: yes
[19:23] <hannesw> originally it always sync'd on the this-object, but upon oberhams' request it now takes an optional second argument to sync on
[19:24] <hannesw> gmosx :(
[19:24] <oberhams> if we work with promises in jsgi we should check if narwahl promises work in ringo
[19:25] <hannesw> well they should
[19:25] <oberhams> ok good for us :)
[19:25] <hannesw> but i think there's two kinds of promises in narwhal...
[19:27] <hannesw> i added a 0.5-proposed label to http://github.com/ringo/ringojs/issues
[19:30] <robi42> btw, would it suffice for updating packages to simply `rm -rf pkg; ringo-admin install pkg`, so to speak (at least as a first sketch)?
[19:31] <xchl> robi42: yes, most definitely
[19:32] <hannesw> it isn't hard
[19:32] <hannesw> you probably would want to make sure you can install the new version before vaporizing the old one
[19:32] <xchl> true
[19:33] <xchl> should we think about a way to install specific versions?
[19:33] <robi42> having a temp copy around, right?
[19:34] <xchl> (specific version support would probably require a catalogue app, though ... so ... that's for 0.6+)
[19:34] <robi42> would make sense also in connection with deps handling, i guess
[19:35] <xchl> from my pov, the one missing thing to make ringo "as useful as helma" is a fully functional orm, i.e. refs/collections in ringo-hibernate
[19:35] <robi42> ok, got it :)
[19:36] <hannesw> xchl yeah :)
[19:36] <xchl> but if I interpret the log correctly, everyone agrees on the awesomeness and importance of r-hib ;-)
[19:37] <robi42> what i'd really love to see in ringo is a "fully supported ng db", btw ;)
[19:37] <robi42> cassandra & co. ftw
[19:37] <xchl> oh yes
[19:38] <xchl> after hannesw's cassandrastore I spent a day looking at cassandra
[19:38] <xchl> and it looks fantastic, even for single-node storage
[19:39] <hannesw> xchl tres cool
[19:39] <hannesw> i was under the same impression
[19:39] <xchl> coupled with something like enki's tragedy (for python), i.e. a true cassandrastore ? la berkeleystore ... that'd be a killer combination
[19:40] <hannesw> unfortunately i updated berkeleystore to make some comparisons, and now i'm kind of in love with that :)
[19:40] <xchl> hehehe :)
[19:40] <xchl> the store-ier, the merrier!
[19:40] <hannesw> well they're very different obviously
[19:40] <robi42> only possible drawback i see with cassandra is devs having to care in advance about which queries they'd like to have later on
[19:40] <xchl> yup
[19:41] <xchl> although that's mostly an issue of maintenance tools
[19:41] <robi42> true
[19:41] <xchl> well, I certainly want to experiment further w/ cassandra
[19:42] <xchl> hannesw, where do you see the main differences between cassandra & bdb?
[19:43] <xchl> bdb has secondary indices, which seem to be used to great effect in berkeleystore, right?
[19:43] <robi42> (ah btw, xchl, cause it just came to my mind, any ideas/plans how to perhaps make ringo-processing draw to html5 canvas?)
[19:43] <xchl> robi42: I'd just use processing.js for that
[19:43] <robi42> ok
[19:44] <xchl> ringo-processing is most useful for generating (static) images, imo
[19:44] <xchl> and for people who prefer javascript over java under practically all circumstances, i.e. me ;-)
[19:44] <robi42> while processing.js lacking all the nice libs coming from java-land, of course
[19:45] <xchl> yeah ...
[19:45] <oberhams> robi42: i have gamejs which draws on canvas but doesnt have much to do with ringo so far
[19:45] <xchl> but how would you use html5 canvas w/ a server-side java lib?
[19:46] <xchl> you could do some wicked comet-ish stuff
[19:46] <robi42> that'd be awesome :)
[19:46] <oberhams> once clientside integration is better we get closer to that :)
[19:47] <xchl> the processing.js folks are working on a 3d renderer based on webgl, btw
[19:47] <robi42> interesting
[19:47] <xchl> I hereby predict that one day processing.js will be the "canonical" implementation ;-)
[19:48] <xchl> mozilla is sponsoring some recent p.js work, too; especially a web-based ide (bespin-based, afaik)
[19:48] <oberhams> what i dont like about processingjs is that they went 100% java with synax and API. though it works great and is stable..
[19:48] <xchl> yeah, that's kinda crazy, imo
[19:49] <robi42> i'd also prefer plain modern js
[19:49] <xchl> but one day soon, they'll see the error of their ways ;-)
[19:49] <robi42> :)
[19:49] <oberhams> mh, processing.js is getting bigger than processing java? :)
[19:49] <xchl> the reasoning behind was to re-use all the books, tutorials, samples ...
[19:49] <oberhams> good reasoning
[19:50] <robi42> and the fun of implementing it, i guess :)
[19:50] <xchl> especially as many people interested in processing aren't professional programmers, and keeping a model of _two_ languages _and_ a mapping between them in their heads seemed unreasonable to expect, I guess
[19:50] <oberhams> yes, i'
[19:51] <oberhams> m surprised p.js is so big, didn't follow that for a while
[19:52] <robi42> let's get back to agenda? ;)
[19:53] <hannesw> ok
[19:53] <xchl> ok!
[19:53] <hannesw> :)
[19:53] <oberhams> :)
[19:53] <hannesw> last item? cool demo for vienna.js
[19:54] <gmosx> gotta go, bye every1...
[19:54] <robi42> twissandra port sounds sweet
[19:54] <robi42> bye gmosx!
[19:54] <hannesw> by gmosx thanks for the hanging on :)
[19:54] <xchl> bye gmosx!
[19:54] * oberhams gotta run too... cu latest wednesday :)
[19:54] <hannesw> well twissandra port was an idea of mine
[19:55] <hannesw> maybe simplify a bit
[19:55] <hannesw> question is: should we use time on wednesday afternoon to work on something like that
[19:55] <robi42> is it, basically, possible already with current cassandra client?
[19:56] <robi42> well, i guess, we've got a fair bit of time there :)
[19:56] <hannesw> well, still got 1 1/2 days left to improve cassandrastore :)
[19:57] <hannesw> or we might do it with berkelelystore
[19:57] <hannesw> zero setup also makes for good demos
[19:57] <robi42> bdb-backed would be fine as well, yep
[19:58] <hannesw> well maybe we should just look what cool stuff we can come up with
[19:58] <hannesw> btw, who's coming? :=
[19:58] <hannesw> :)
[19:58] <xchl> I am!
[19:58] <robi42> me too :)
[19:58] <hannesw> cool!
[19:59] <hannesw> we already have critical mass then :)
[19:59] <robi42> hehe
[19:59] <xchl> oberhamsi too I think
[19:59] <hannesw> i hope oberhams can come too
[19:59] <hannesw> what about earl?
[19:59] <hannesw> zumbrunn?
[20:00] <xchl> zumbrunn mentioned he can't make it
[20:00] <robi42> yes, unfortunately
[20:00] <hannesw> well i understand that, given the distance
[20:00] <xchl> that wasn't the problem
[20:00] <xchl> just the specific date
[20:02] <robi42> anyone knows something if knallgraus are interested/coming, btw? :)
[20:03] <robi42> anyway, let's send some reminder via ml/twitter tomorrow (just in case)?
[20:03] <xchl> some of the ol' helmatics have still to taste the sweet kool-aid of ringojs ...
[20:05] <hannesw> yes :)
[20:05] <robi42> could also send a msg. on helma-ml :)
[20:08] <hannesw> yes, i might
[20:09] <hannesw> hm while you're all here:
[20:09] <xchl> yes, a reminder on all channels would be good
[20:10] <hannesw> feedback on the subprocess module? (naming, api, etc)
[20:10] <hannesw> http://github.com/ringo/ringojs/blob/master/modules/ringo/subprocess.js
[20:10] <hannesw> implementation is unfinished/buggy
[20:11] <robi42> hm
[20:12] <xchl> personally I think the convenience layer should do the tokenization, shouldn't it?
[20:13] <xchl> and I'd like a function that gives me both out- and err-stream
[20:13] <xchl> var {out, err} = foo("curl ...")
[20:15] <xchl> _and_ a function that waitFors and gives me {status, errorAsString, outputAsString}
[20:17] <robi42> maybe it could be refactored to a single function which one can take from what one's interested in via destructuring assignment {out, err, outStr, errStr, status}
[20:17] <xchl> hm, I think two variants are needed at least - one that waitFors and one that doesn't
[20:18] <robi42> right
[20:18] <xchl> i.e. stream vs. string
[20:18] <xchl> btw, any pointers wrt/ the "promises" I keep hearing about?
[20:19] <robi42> -> `execute`, `executeStreaming` ..?
[20:20] <xchl> good question ... maybe there is posix-y prior naming art?
[20:21] <xchl> functionality-wise, python's subprocess is ... well, comprehensive: http://docs.python.org/library/subprocess.html
[20:21] <xchl> but I only ever use it through convenience layers ;-)
[20:24] <robi42> :) "spawn" sounds good naming-wise
[20:25] <robi42> btw, commonjs take on promises: http://wiki.commonjs.org/wiki/Promises
[20:27] <robi42> gotta leave. good night everyone!
[20:27] <xchl> spawn and execute sound good to me
[20:28] <xchl> thanks robi42 and bye bye!
[20:28] <xchl> should we add a springo topics wishlist to the wiki?
[20:38] <earl> why not :)
[20:40] <xchl> maybe everyone is wunschlos gl?cklich ;-)
[20:42] <xchl> I'd love to hear about storage design & implementation
[20:50] <hannesw> xchl + robi42 thanks for the feedback
[20:51] <hannesw> xchl early promise code is here: http://gist.github.com/375799
[20:51] <hannesw> actually i've worked a bit on it since, and it's actually ready
[20:53] <earl> do you still explicitly sync(..., this) as in the gist piece?
[20:53] <earl> because with my renewed understanding of this, that might actually not be what you want
[20:53] <hannesw> yes, but i use setTimeout(function() {}, 0) to call the callbacks
[20:57] <hannesw> i updated the gist to the current code
[20:58] <earl> thanks
[20:58] <hannesw> scales pretty well ~ 2000 reqs/second on my laptop
[20:58] <hannesw> i tweaked ringo/scheduler.setTimeout() a bit
[20:59] <hannesw> while for delayed timeouts it only allocates 4 threads max
[20:59] <hannesw> for timouts with delay === 0 it directly allocates threads as needed
[20:59] <earl> wouldn't sync(..., value) suffice?
[20:59] <earl> or something similar
[20:59] <earl> maybe i get the intentions wrong, but the "this" you are syncing is the module scope of promise.js
[20:59] <hannesw> no, because value may not be set when either function is called
[21:00] <hannesw> oh wait, yes, this is infact wrong
[21:00] <earl> great
[21:00] <hannesw> it should be the deferred, the return value
[21:00] <hannesw> some object that is unique to this invocation and doesn't change
[21:00] <earl> yeah, or any local object
[21:00] <earl> exactly
[21:01] <hannesw> ok thanks for telling me :)
[21:01] <earl> var lock = {}; should probably do
[21:03] <earl> are timeouts executed in strictly serial order?
[21:05] <earl> (i guess they are)
[21:06] <earl> (but if not, that's a possible race which needs additional synchronisation to prevent)
[21:06] <earl> finally, i think two convenience wrappers for resolve would be nice: fail and fulfill (or fail and succeed)
[21:07] <hannesw> no, timeouts are not executed serially.
[21:07] <hannesw> why is that a problem?
[21:08] <earl> ok, maybe it is not
[21:09] <earl> if i add the same callback to two promises
[21:09] <earl> i'd probably expect the callback getting called in the same temporal order the promises where resolved
[21:10] <earl> w/o serial timeout execution, that's not guaranteed
[21:10] <hannesw> you want an event loop
[21:11] <earl> i don't think so
[21:11] <earl> but the expectation is a pretty strong one, it seems reasonable for it not to hold :)
[21:14] <earl> setTimeout(,0) is just a hack to not tie a function to the thread of the caller
[21:14] <earl> right?
[21:14] <hannesw> yes
[21:14] <earl> yeah, then forget what i said
[21:15] <hannesw> it's a way to run a function in another thread, but without the thread creation overhead
[21:15] <hannesw> maybe we should find a better name for it
[21:16] <earl> so basically you _want_ callbacks executed indeterministically :)
[21:16] <earl> i.e. not in the same thread the resolve is called
[21:18] <hannesw> yes, mostly to avoid deadlocks
[21:22] <earl> i guess it's just that i'm used to a different notion of promises :)
[21:22] <hannesw> well, speak up
[21:22] <earl> nothing really to speak up
[21:23] <earl> i'm just not sure what the extra callback buys us :)
[21:23] <earl> compared to a more traditional force/wait primitive, for example
[21:23] <hannesw> what's the extra callback?
[21:24] <earl> the "listener" that gets called on resolve
[21:24] <hannesw> you mean the "tailed" promise?
[21:24] <hannesw> well i think we should implement a wait().
[21:25] <earl> i'm not sure if it's really the "tail" itself
[21:26] <earl> i understand the value of pipelined/transparently forwarde promises
[21:26] <earl> but it may be the conflation of pipelining and how to ultimately obtain a result
[21:27] <xchl> hannesw, what's the === in `var isError = state === FAILED;` good for?
[21:27] <xchl> === doesn't do much w/ numbers, does it?
[21:27] <hannesw> you mean why === and not ==?
[21:27] <xchl> yeah ...
[21:27] <hannesw> don't know... :)
[21:28] <hannesw> well there is a toNumber() in js which you avoid this way
[21:28] <hannesw> but it doesn#t matter really
[21:28] <xchl> ah! ok
[21:28] <earl> i sometimes wonder if === is not the better default to use when hacking away code :)
[21:28] <hannesw> i don't think it has any practical effect
[21:29] <xchl> I usually use === or !== only in very specific situations
[21:29] <earl> as .state should be hidden anyway, it probably won't matter much in this case :)
[21:30] <xchl> e.g. when the default value in an options object is false, i.e. absence of a value should be interpreted as kinda-true ;-)
[21:30] <xchl> earl: yeah, just wondering
[21:31] <earl> and right you are :)
[21:31] <xchl> for enums, objects might work quite well
[21:32] <earl> was just wondering about that earlier
[21:32] <xchl> >> [SUCCESS, FAILED] = [{}, {}]; SUCCESS == FAILED
[21:32] <xchl> false
[21:32] <earl> is {} guaranteed to be shorthand for (new Object())?
[21:33] <xchl> we'd need to ask The Russian
[21:33] <earl> hehe
[21:33] <earl> clumsy question, but i think for (new Object()) we can safely assume that no pooling is allowed :)
[21:34] <xchl> I'd hope so ...
[21:34] <earl> me too :)
[21:34] <earl> but who knows!
[21:34] <earl> maybe there is a nifty copy-on-write clause hidden somewhere in js
[21:35] <earl> which allows for temporal pooling of structurally-identical objects :)
[21:35] <hannesw> {} is always a new object
[21:35] <earl> temporary*
[21:35] <hannesw> what would promise.wait() do in case of failure?
[21:35] <hannesw> rethrow the error
[21:35] <hannesw> ?
[21:35] <earl> _re_throw?
[21:35] <hannesw> or just throw?
[21:36] <earl> throw, maybe :)
[21:37] <earl> yes, i'd throw the value
[21:40] <hannesw> so now i fixed the lock thing and implemented promise.wait()
[21:40] <hannesw> http://gist.github.com/375799
[21:40] <earl> lovely
[21:41] <earl> var lock = {}; doesn't do?
[21:41] <hannesw> we need java.lang.Object to use wait() and notifyAll()
[21:41] <earl> heck!
[21:43] <xchl> hannesw: very cool
[21:44] <hannesw> so, for example, JSGI implementations that don't support async can simply wait for the response
[21:44] <earl> do you currently use the then() for anything?
[21:44] <hannesw> yes, in the ringo/jsgi handler
[21:45] <hannesw> jetty response gets actually suspended, without a thread
[21:45] <hannesw> so you can use this to do long polling and it will scale to the moon :)
[21:45] <earl> so you need a fresh thread to write to it?
[21:46] <hannesw> a pooled one :)
[21:48] <earl> ah, i think i get it
[21:48] <earl> you don't want threads lingering around wait()ing
[21:49] <hannesw> right
[21:49] <earl> so to overcome this, you just register a lot of callbacks via then()
[21:50] <earl> and once promises are resolve()d you create new threads to run the callbacks in
[21:50] <earl> (actually, re-use pooled ones, but that's a detail i'll ignore)
[21:52] <hannesw> well you could do a comparison of using then() vs. using wait() in jsgi handler
[21:53] <hannesw> i bet wait() will look really bad for lots of long waiting requests
[21:53] <xchl> that'd be super-interesting, actually
[21:53] <earl> well, the intuition would be that threads are far more expensive then the state you keep in then()
[21:54] <earl> xchl: i agree :)
[21:55] <earl> even more interesting would be a comparison to using java's bordmittel for that purpose
[21:56] <hannesw> bord-what?
[21:56] <earl> denglisch! :)
[21:56] <earl> java's highly tuned stuff in java.util.concurrent
[21:58] <hannesw> i don't think there is anything that could help there
[21:58] <hannesw> we're already using a java.uitl.concurrent threadpool for setTimeout()
[21:59] <hannesw> which obviously helps a lot
[21:59] <earl> Future?
[22:00] * xchl is trying to figure out the differences between promises and futures
[22:00] <hannesw> hmmm setTimeout does return futures
[22:00] <earl> xchl: not much to figure out in general, the terms are mostly used interchangably or conflictingly
[22:01] <xchl> so promises add some more functionality over futures, e.g. chaining?
[22:02] <hannesw> setTimeout(..., 0) does basically this: file:///usr/share/doc/openjdk-6-jre/api/java/util/concurrent/ExecutorService.html#submit(java.lang.Runnable)
[22:02] <earl> :)
[22:02] <hannesw> oops, file url :)
[22:02] <hannesw> hehe
[22:02] <hannesw> sorry
[22:03] <earl> http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ExecutorService.html
[22:03] <hannesw> right
[22:03] <xchl> yeah
[22:03] <hannesw> so with java future, you only have the wait option
[22:03] <xchl> although I have to say that `submit` is clearer than `setTimeout(..., 0)` ;-)
[22:04] <hannesw> yep
[22:04] <earl> submit only makes sense in context of an executorservice
[22:04] <hannesw> or maybe execute
[22:04] <xchl> later ;-)
[22:04] <xchl> earl: yes
[22:05] <hannesw> gotta go too
[22:05] <earl> if setTimeout(,0) is supposed to be a thread-launching idiom, it should probaly be thread.start() or spawn()
[22:05] <hannesw> yes, true
[22:05] <hannesw> we already discussed spawn for processes, i think
[22:05] <earl> of course, those more general names would not really hint at the fact that it's not a real thread that is spawned
[22:05] <earl> but a thread from a pool reused
[22:05] <xchl> isn't spawn in rhino already?
[22:06] <hannesw> might be
[22:06] <hannesw> it is
[22:06] <earl> it's in ringo, in any case :)
[22:06] <earl> and it seems to spawn a fresh thread :)
[22:06] <xchl> it's the thread-launching shorthand in rhino, iirc
[22:06] <hannesw> funny :)
[22:07] <hannesw> ok
[22:07] <hannesw> if we keep that we should use a thread pool for that, and use it
[22:07] <hannesw> instead of setTimeout()
[22:07] <earl> well, maybe we should add another pooled primitive
[22:08] <xchl> splash!
[22:08] <earl> :)
[22:08] <xchl> ok, time to call it quits for today, I think ;-)
[22:08] <hannesw> yap met too
[22:09] <hannesw> good night!
[22:09] <xchl> byebye, hannes!
[22:09] <xchl> see you on wednesday
