[08:56:34] ** jack-e has joined us [13:15:26] ** _jpl_ has joined us [13:16:05] <_jpl_> peak.hello() [13:18:29] ** _jpl_ has left us [13:18:48] peak has a hello method [13:18:49] ? [13:19:09] oh he's gone [13:19:10] ? [13:22:29] ** _jpl_ has joined us [13:22:40] <_jpl_> damn gaim [13:24:29] ah he's back [13:24:58] <_jpl_> Who knows for how long. [13:25:04] * _jpl_ kicks gaim [13:25:26] <_jpl_> Is there a better all-in-one messaging client for Linux? [13:28:47] <_jpl_> So the sync/async thing is a little trickier than I thought, since the PEAK code would need to be running in its own thread to begin with. [13:42:21] ah [13:42:29] and no i don't know of any better all-in-ones [13:43:03] <_jpl_> Though you ought to be able to find an appropriate place to split off to another thread using reactor.callInThread [13:44:00] <_jpl_> Now we just need a blocking wrapper for deferred objects. [14:33:34] <_jpl_> Ok, I think I have a working waitForDeferred function. [15:59:10] hey jpl :) [16:10:31] hey jack-e! [16:22:16] <_jpl_> Ulrich! [16:22:35] <_jpl_> Will you buy me a beer if I come to Munich? [16:28:48] sure :)) when will you arrive ?? [16:28:58] hey maniac :-) [16:39:07] _jpl_, keep in mind jack-e likes to party! [16:39:16] _jpl_: we could then organize a peak-sprint :) [16:39:32] hehe [16:39:41] (the weekend comes closer ;-)) [16:40:24] yay a two man sprint! [17:59:21] ** aCiDBaSe has joined us [18:10:24] <_jpl_> ha! [18:10:32] <_jpl_> I dunno when, maybe March or April? [18:16:39] <_jpl_> (I'm thinking of going to Germany to hang out for a couple of weeks sometime around then) [18:24:40] ql .. [18:25:12] _jpl_, i probably won't be able to do any work on nllworkflow till my holiday starts .. [18:33:51] <_jpl_> No problem [18:35:11] it should be a pluggable option anyway .. so you could play with a "dummy-engine" and replace it with a stateful-engine later on .. [18:37:32] <_jpl_> I'm not planning on getting to message routing until v1.0 anyway, which is a ways off. [19:38:43] jack-e is now known as jack-e|away [19:52:28] so if we pack the results of a DM into a dict and transfer 'over-the-wire' via pb... if i have querylinks i could really pump alot of data [19:52:59] * _jpl_ nod [19:53:18] that would not be good [19:53:47] i must think [20:14:08] <_jpl_> Why not? [20:18:00] <_jpl_> Are you worried about many separate remote method calls? [20:54:53] one of the query links in the design i was considering eventually could have a big pile-o-data [20:55:14] since roundup will not let me keep the connectin open due to a global lock i would have to pull it all [20:55:51] because i have to close the trnasaction [21:29:52] actually doesn't look like my model has any links which would pull too much data