[02:21:12] ** gpciceri has joined us [07:05:15] vlado|away is now known as vlado [07:30:37] ** Gurra_ has joined us [07:31:15] * Gurra_ greetz all the peak'ers from chiang mai in thailand .. i just found Mirc on this computer and couldn [07:31:24] 't resist to post this :-)) [07:31:34] err .. [07:31:46] hmm [07:32:01] i'm still online from home .. hmmmmm [07:32:06] mompl [07:32:08] ** Gurra_ has left us [07:41:44] ahhh [07:42:18] so again greetings from thailand .. i'll now let even my irc-proxy take a little rest for the next couple of weeks [07:42:59] * jack-e waves [08:20:46] ** gpciceri has joined us [09:04:50] ** _jpl_ has joined us [11:56:04] vlado is now known as vlado|away [13:13:26] i guess jack-e went on holidays [13:14:08] ooo he's in tailand [13:46:40] ** _jpl_ has joined us [15:37:16] ** hazmat has joined us [16:14:38] <_jpl_> Hi #peak [16:40:04] * Maniac was spying on _jpl_ in #python [16:40:15] <_jpl_> ha [16:40:35] that guy is behind #supbot [16:40:45] er the principal developer of [16:43:04] <_jpl_> I've heard of it, but I'm not familiar with it. [16:44:10] <_jpl_> Is it l33t? [16:44:21] i guess. [16:44:33] the most featurefull python irc bot that i'm aware of [16:46:33] <_jpl_> So when is your PEAK-based bot going to kick its butt? [16:46:37] ha! [16:46:55] there's like 1/2 a dozen active developers of supybot they have more code-power [16:47:20] <_jpl_> Come on, we need a good, generally useful PEAK app to help get people hooked. [16:47:51] oh, ok [16:48:03] * Maniac writes it in his spare time [16:48:12] is an IRC bot generally useful? [16:48:33] and my PEAK-based bot is jabber so far [16:48:46] (which i am writing corporate 'plugins' for as we speak) [16:49:15] http://www.openp2p.com/pub/a/p2p/2002/01/11/jabber_bots.html [16:49:29] it's the commandline of the future DJ Adams says so [16:56:24] oh and we call 'bots' V-People now [17:14:05] * Maniac watches debate on #python [17:15:38] <_jpl_> What debate... [17:15:50] <_jpl_> That guy has fascist tendencies, I tell you. [17:16:47] they love to indulge in those arguments [17:16:55] they being #twisted sorts [17:17:03] and you seem to be on his hit list [17:17:13] <_jpl_> Apparently. Not sure how I got there, though. [17:17:15] moshez was really bad until he found a job [17:17:31] <_jpl_> He's booted me from #python once before for simply making one off-topic remark. [17:17:49] exarkun doesnt' have a job other than code Quotient (afaik) [17:18:17] <_jpl_> At the time others were in some off-topic discussion which he had gotten tired of. I came in late and added one comment to the off-topic topic and he booted me. [17:18:18] twisted folk claim dominance of that channel [17:19:16] <_jpl_> dash booted me once for answering someone's question with a link to the appropriate docs on python.org. [17:19:20] eh? [17:19:29] how's that a bootable offense? [17:19:40] <_jpl_> dash considered the question *wrong*, so even entertaining it was wrong. [17:19:48] <_jpl_> Actually, he didn't boot me, he silenced me. [17:19:55] <_jpl_> Which is even more annoying. [17:19:55] meh [17:20:58] <_jpl_> The question was about diamond pattern inheritance, to which dash kept saying "don't do that". I simply pointed the questioner to the doc on python.org which describes how it already works in Python. [17:21:20] <_jpl_> I was apparently helping the person do something very stupid. [17:28:40] they are quite agressive, i dont' know why [17:28:56] i can understand slapping the people who obviously can't think for themselves at all [17:32:00] almost time to go home :0 [17:34:12] ** rdmurray has joined us [17:36:27] <_jpl_> Come to think of it, the Twisted person with whom I had an argument about synchronous vs. asynchronous programming a few months ago must have been exarkun. [17:37:20] writing models and DM's is a little grueling at first. no immediate feedback until you get everything setup and wired together [17:37:25] <_jpl_> He used similar arguments then, too, e.g. that asynchronous programming is objectively better (and thus the only solution), that this was logically provable, etc. [17:37:42] yup [17:38:51] it's unfortunate because as a networking framework twisted is good [17:39:57] ** gpciceri has joined us [17:40:11] * Maniac heads home [18:17:18] <_jpl_> Maniac: I'm sure Quotient would really benefit from PEAK (what large Python app wouldn't?), but those twisted fellows seem to have a real aversion (if not outright hostility) to PEAK, for no apparent reason that I know of. [18:21:10] <_jpl_> I think exarkun called PEAK "scary". [18:29:22] Maybe that's code for "I don't understand it", and can be solved by more docs.... [18:39:08] <_jpl_> A lot of it seems to be related to "not invented here" syndrome. [18:48:22] imho twisted has series NIH [18:48:29] serious even [18:48:37] but python != twisted [18:48:48] and python == good == peak :) [18:49:06] yeah, they kind of started out that way, and then kept trying to invent everything "better" :) [18:49:26] Which is not a bad thing if you don't blind yourself. [18:50:17] btw hi rdmurray long time no irc [18:50:27] Yeah, been busy with non programming stuff. [18:50:54] Today, I'm trying to get amavisd/spamassassin/clamav working ;) [18:51:23] i got spamassassin but i dont' even know what amavisd and clamav are ! [18:51:25] <_jpl_> They ought to adopt PyProtocols in Twisted, it's a lot more powerful than what they have. [18:51:36] _jpl_, they looked at it and..... NIIH [18:51:46] NIH <--- /me slaps his fingers [18:52:03] Zoep should adopt pyprotocols, too, but I don't think they will either. [18:52:06] Zope even [18:52:39] Well, as long as everyone works towards interoperability (which I think they are) I don't really care :) [18:52:43] <_jpl_> Yeah, come to think of it I've had discussions on #twisted about PyProtocols, probably with exarkun once again, but whoever it was had never really looked much at it but was already pretty convinced that that was not much point in doing so. [18:53:02] <_jpl_> I thought Zope3 already was moving to PyProtocols? [18:53:12] Maybe they are, I'm a bit out of touch there. [18:53:42] <_jpl_> pje at least said something to that effect not too long ago, maybe here rather than on the mailing list. [18:54:28] <_jpl_> I couldn't find any references in the Z3 mailing list, but there is a "geddon" coming up related to interfaces/protocols, I think. [18:54:36] geddon? [18:54:39] That would be cool. I bumped into a message where they were talking about having I(someobj) return an adapter to someobj, which doesn't sound very PEPish. [18:55:00] And something about "multi-parameter" adapters or somesuch. [18:55:25] As in armegeddon. Blast away the existing code and replace it with something better :) [18:55:26] <_jpl_> rdmurry: Ugh, that's how Twisted does it. [18:55:39] <_jpl_> i.e. ISomething(obj) [18:56:09] <_jpl_> Oh yes, it's called "adaptergeddon" IIRC [18:56:15] jpl, is that an NIH, or do you have a reason for disliking it :) [18:56:24] <_jpl_> right [18:57:10] <_jpl_> I have reasons. :) [18:57:40] maniac: amavisd is an efficient framework for calling spamassasin and virus scanners on incomming email. clamav is an open source virus scanner. [18:57:54] <_jpl_> As you pointed out it ignores the adaptation PEP. I also don't see why you need to load the adaptation logic into the protocol classes themselves. [18:58:07] Hmm. Good point. [18:59:26] <_jpl_> It also means you can't adapt to or from anything but an interface, and a very specific interface type at that. [18:59:37] * rdmurray . o O (Cool, amavisd is working. Now to see if I can get clamd running) [19:00:12] Well, but if it's an optional feature and not a required feature that isn't so bad. [19:00:19] <_jpl_> With PyProtocols you can adapt to/from Python types, you can say that a specific instance of something provides a particular interface, etc. [19:00:22] clamav hmmm. [19:00:42] <_jpl_> rdmurray: Which feature? [19:00:55] getting the adapter from the interface. [19:01:11] wow cool. i need to set that up @ work [19:01:20] Less confusing to be consistent about it, though. [19:01:27] (ie, just use adapt) [19:01:46] IMO, of course :) [19:02:56] <_jpl_> Yes, it's better to be consistent, and it avoids needing to put adapt() functionality in the interface class itself. [19:03:02] amavis.org? [19:03:18] Actually, I'm using amavisd-net [19:03:22] er -new [19:03:37] http://ftp.cfu.net/pub/amavisd-new [19:04:26] Between freebsd ports and good docs, this install has been slick, so far. [19:05:28] any pointers to settting up with postfix/clamav/amavisd-new on linux? [19:06:18] Should be pretty simple. I'm using postfix on freebsd, and the postfix hookup is real easy. [19:06:54] The INSTALL/README files for amavisd take you through the steps you'd need for a linux install. [19:07:07] i've got procmail calling spamassasin [19:07:22] so that should be fine too [19:07:22] The biggest pain there will be making sure you have all the aux programs (the PERL modules and unarchivers) [19:07:53] Fortunately for me, the ports system made sure I had everything installed for me. :) [19:08:30] amavisd-new does spam blocking as well? [19:08:57] Using spamassasin, yes. [19:08:57] we get approx 200 email a day of which 70-80 are blocked via a dns-rbl [19:09:41] amavisd-new is the framework for calling the content scanners, and then handles disposition based on the results of calling those scanners. [19:09:54] It doesn't do any content scanning itself. [19:10:20] installing these are definately getting added to my TODO list [19:10:28] thanks for the pointer rdmurray [19:10:28] :) [19:10:30] My own mailbox gets about double that :( [19:10:33] welcome [19:11:26] Heh, if you need any consulting help on it, I'm a free-agent consultant these days :) [19:12:45] rdmurray, um, sorry that's what i get paid for :) [19:13:02] well, not really.... it's what i do on weekends for free :( [19:13:08] :) [19:13:20] but i'm a sucker for working too many unpaid hours [19:13:42] <_jpl_> Maniac: There seems to be an amavis ebuild for Gentoo. [19:13:55] _jpl_, my only non gentoo server is my mail server :) [19:14:05] <_jpl_> d'oh [19:14:05] redhat 6.1 or something [19:14:14] <_jpl_> :o [19:14:26] with an uptime of like 600 days (minus power outages) [19:14:57] one day it'll get debian'd probably (vs gentoo) [19:15:13] Doesn't that kind of uptime imply you have kernel bugs? [19:15:20] rdmurray, eh? [19:15:26] yes. [19:15:30] does it matter? [19:15:36] no local access for anyone but me. [19:15:44] so exploits are moot [19:15:44] Well, only if someone cracks an account, I suppose. [19:15:56] firewalled to the moon [19:16:07] * Maniac goes to eat dinner [19:16:10] I just believe in defense in depth, so I try to keep even my inside kernels patched. [19:25:55] * _jpl_ hacks into Maniac's mail server while he's at dinner. [19:36:31] * Maniac hacks into _jpl_ [19:38:44] _jpl_, have at it here's the ip: 131.107.3.124 [20:27:56] <_jpl_> Hmm, new addition to PEAK just now: 'First draft of 'peak.ddt', a "Document-Driven Testing" framework.' [20:28:39] Sounds cool. I was thinking about that kind of thing last week :) [20:44:33] ** rdmurray has joined us [21:01:34] ** pje has joined us [21:01:50] Hola. [21:10:22] 'lo [21:11:13] * pje has been exceedingly busy with "real work" lately [21:11:22] * _jpl_ waves [21:11:25] <_jpl_> I know the feeling. [21:11:42] <_jpl_> Just found a minor bug, Phillip, was about to send e-mail. [21:11:58] On the plus side, it means lots of cool tech spinoffs. :) [21:12:04] What'd you find, JP? [21:13:16] <_jpl_> peak.events.twisted_support needs a "from interfaces import *" at the beginning. [21:13:59] <_jpl_> Otherwise line 141 dies not knowing what IEventSource is. [21:14:10] Ah. [21:14:24] I'm surprised it works even with that fix. :) [21:14:33] Because it's just a draft, there are no unit tests for it at all. [21:14:49] <_jpl_> :) [21:14:53] Are you saying it works otherwise? That'd be cool. :) [21:14:54] <_jpl_> So far so good. [21:16:31] <_jpl_> It seems to be automagically using twisted_support somehow, and after adding that line I know at least that exiting via IMainLoop.exitWith() works. [21:16:55] The automagicness comes from 'events.ifTwisted()' stuff in peak.ini [21:16:56] <_jpl_> Don't know about other event sources. [21:17:07] <_jpl_> Ah, cool. [21:17:25] See peak.ini [Component Factories]... if you depend on ITwistedReactor, it slams the whole service area into "twisted mode". [21:18:12] And that makes it use all the twisted_support versions of scheduler, event loop, selector, etc. [21:18:23] * _jpl_ nods. [21:18:36] <_jpl_> Well it seems to be working. :) [21:19:00] Excellent. The real test will be using the peak.events interfaces with 'em. [21:19:35] e.g., can you make an events.Thread() that yields to eventLoop.readable(someSocket), with an eventLoop.alarm() running. [21:19:48] Not that I expect you to write the tests for me or anything. :) [21:20:19] I'm thinking it would be really cool to create some Spread services using peak.events. [21:20:32] <_jpl_> I'm not even doing any socket-level stuff with Twisted anyway, though I do use deferreds all over the place. [21:20:37] <_jpl_> YES [21:20:38] Like a distributed locking service, for example. That one's been on my mind a while. [21:20:47] <_jpl_> That's partly what Junction is supposed to do. [21:20:59] <_jpl_> Eventually. [21:21:03] Spread objects have a fileno() attribute, so they should be usable with eventLoop.readable(). [21:21:27] I'm not sure they support nonblocking sockets, though. [21:23:00] <_jpl_> Oh, I see DeferredAsEventSource made it into twisted_support. The last we talked about it there was one little glitch left relating to exceptions -- someone somewhere was printing the text of the exception. Did you notice that and fix it? [21:24:45] Um, I think so. Feel free to check and see. :) [21:25:17] <_jpl_> I didn't feel like digging up the old code to be able to do a diff. :) [21:25:37] You can click on the 3D glasses in RecentChanges on the Wiki. [21:26:01] It shows the last change(s) I made. [21:26:08] <_jpl_> I've been wrestling with some really ugly deferred-oriented code all day. I was thinking of turning it into an events.Thread, but didn't think the deferred adapter was there yet. I will now hapilly do so. [21:27:14] <_jpl_> This chunk of code will be a really great test case for adoption of peak.events. [21:27:26] * pje just checked in the interface import fix [21:28:28] <_jpl_> Great, thanks. [21:34:29] ** hazmat has joined us [21:34:54] <_jpl_> Actually, this code would need to be multi-threaded to use peak.events... [21:35:42] peak.events doesn't support "real threads" anywhere yet. Notably, the scheduler and similar items aren't threadsafe. [21:35:57] PEAK components in general aren't threadsafe, actually. [21:36:23] But there are some specific bits of peak.events that *should* be, eventually, like scheduling something. [21:37:57] <_jpl_> This code periodically gets a schell script to be run (from something at the other end of a PB connection), so it needs to be able to handle potentially multiple jobs at once. The single while loop approach wouldn't work. [21:38:16] Um, why does that need threads? [21:38:34] You can spawn processes using peak.running.process, and communicate with them. [21:38:45] Or do you need to support an OS without fork()? [21:38:54] <_jpl_> How would I handle the callbacks? [21:38:59] <_jpl_> Or events, rather. [21:39:12] What events do you mean? [21:39:24] <_jpl_> I'm actually using Twisted's spawnProcess (which works under Win32 with the right reactor) [21:39:32] Ah. [21:39:53] But then, doesn't it treat the processes as protocols? I'm still not following how the threads come into it. [21:40:22] <_jpl_> Oh wait. I could just use multiple microthreads, one for each running job. [21:40:46] <_jpl_> The main thread would just be there to continually ask for work. [21:40:55] If you say so. :) [21:41:14] <_jpl_> Main microthread, I mean. [21:41:36] I'm not clear on what you're doing with the processes, so I'm unclear on whether it will work. :) [21:43:10] <_jpl_> Each separate process will be forked by spawnProcess. I need a way to wait for the resulting deferred object, process the results or errors, and send the results of the job back to the server. [21:43:32] Ah. Okay. [21:43:38] <_jpl_> So I think rather than needing real threads, I can have the first microthread spawn off a new microthread for each incoming "job". [21:43:48] Yeah, just spawn an events.Thread for each outstanding request. [21:44:07] <_jpl_> The secondary microthread would do the waiting, reacting, and reporting. [21:44:22] Yep. [21:44:45] You realize of course that you're committing a mortal sin of some sort by doing it so easily. ;) [21:44:57] (PEAK - it's sinfully good) :) [21:45:03] <_jpl_> This ought to be alot easier to read and maintain than the current version which has 4 or 5 separate methods. [21:45:26] Yeah, I've been rewriting huge amounts of callback-based stuff in PEAK lately. [21:45:28] <_jpl_> I think I'm already an outcast amongst the Twisted crowd anyway. [21:46:07] I keep having the experience of gradually refactoring some twisted (no pun intended) set of methods, and then it ends up as like two or three lines of peak.events stuff. [21:46:22] And then I go, "oh, is that all that was doing? Duh." [21:46:24] <_jpl_> Did you know that you only ever (*ever*) want mutable objects in Python programs? Exarkun says so, and I'm an idiot for saying otherwise. [21:46:48] Ah, well, he won't like PEAK then. :) [21:47:16] PEAK mostly believes in the superiority of *immutable* objects. :) [21:47:19] <_jpl_> Ha, yes, the asynch approach often ends up being really messy. [21:47:35] <_jpl_> See, there you go. We must both be total idiots. [21:48:06] <_jpl_> All I said on #python was that it's sometimes appropriate to use immutables and exarkun climbed all over me. Shrug. [21:51:51] Well, I have enough politics to deal with in my day job, so I won't dwell on such matters here. :) [21:53:44] the twisted folks on python tend to be very opinionated. [21:53:48] <_jpl_> So simply creating an events.Thread(generator()) is enough to get it going? [21:53:57] Yep. [21:54:18] And if 'generator' is a method, you can use 'method = events.threaded(method)' [21:54:21] <_jpl_> Not just opinionated. If you dare disagree with them you're an idiot. "Objectively" [21:54:29] Then just calling 'self.method()' will start the thread. [21:54:36] Guys, please... [21:54:50] Like I said, I have enough of that sort of thing to deal with in real life. [21:54:57] <_jpl_> That's if you can set it up as a property, you mean. [21:55:09] JPL: no. It works for methods too. [21:56:00] See peak.events.tests.test_events [21:56:37] <_jpl_> Right, I get it, I just can't use that approach for this piece of code since I need multiple threads. [21:56:51] Um, no. [21:57:06] Try 'peak help events.Threaded'. :) [21:57:42] <_jpl_> "help: Can't find help on 'events.Threaded'" [21:57:55] Oops. lower case 't'... [21:58:00] 'peak help events.threaded' [21:58:14] It's advice, like staticmethod or classmethod. [21:58:38] So my convention for those is to follow the python all-lowercase naming pattern. [21:58:52] <_jpl_> Right, I've seen that. I could use it for the main thread, but not for the individual threads. [21:58:57] Aagh. [21:59:08] Maybe I need to rewrite the doc. [21:59:17] Each time you call the method, it returns a thread. [21:59:37] So if the method takes arguments, each time you call it with different arguments, you get a different thread, running with those arguments. [21:59:44] <_jpl_> Ah! [21:59:50] <_jpl_> That's not clear from the documentation. [21:59:52] I thought that was obvious from the doc, but I guess it isn't. [22:00:06] <_jpl_> That's exactly what I want, then. :) [22:00:10] Yes. [22:00:14] That's what it's for. [22:00:30] It's just that since it's callable, it can *also* be used for binding.Make, as the doc says. [22:00:42] At least, if the method has no arguments. [22:00:46] <_jpl_> It doesn't say anything about what happens to parameters, so I got the feeling it only worked for simple things. [22:01:01] There wouldn't be any point to having parameters if you could only ever call it once. [22:01:39] <_jpl_> It would still be useful for simple "worker" threads which to the main bit of work for a component. [22:01:40] Anyway, so events.threaded(method) makes method return a thread for each invocation. [22:02:00] Yeah, but in that case you'd wrap them with binding.Make() so they're only called once. [22:04:06] <_jpl_> With twisted_support there now, if I do an Obtain on IScheduler will I get a TwistedSchduler? [22:04:23] Yep. [22:04:32] See peak.ini [Component Factories] [22:04:47] <_jpl_> Sorry, just RTFS'd and saw it. :) [22:04:47] peak.events.interfaces.IScheduler = [22:04:47] events.ifTwisted(targetObj,twisted_support,events).Scheduler [22:17:13] <_jpl_> Does one still need reactor.callLater to run something in the future, or is there an equivalent in peak.events? [22:17:34] Well, ordinarily, one doesn't callLater in peak.events. [22:17:58] There's still some transitional code in peak that does things like that, but it's mostly for reactor compatibility. [22:18:21] Normally, you either alarm() (raise an error on timeout) or wait for a sleep() or until() or timeout() object. [22:18:33] See events.IScheduler's methods. [22:18:55] <_jpl_> Ok. This bit of code needs to shutdown the application at some point, but I want it to wait a few seconds first. [22:18:57] If you want a callback though you can always eventLoop.sleep(n).addCallback(lambda src,evt: whatever) [22:19:30] So... yield eventLoop.sleep(aFewSeconds); events.resume() [22:19:34] <_jpl_> So just "yield scheduler.sleep(x); events.resume()" then call mainLoop.exitWith. [22:19:37] And then do whatever's next. [22:19:43] Yep, you got it. [22:20:07] <_jpl_> Great, I can finally imagine a time when there will be no reactor calls in my code. :) [22:21:50] They're beginning to get scarce in PEAK, too. [22:27:17] hazmat is now known as haz|away [22:29:06] <_jpl_> Oops, think I found another bug. [22:29:44] <_jpl_> File "/usr/lib/python2.3/site-packages/peak/events/twisted_support.py", line 98, in _callAt [22:29:44] <_jpl_> self.isEmpty.set(False) [22:29:44] <_jpl_> exceptions.AttributeError: 'Scheduler' object has no attribute 'isEmpty' [22:31:31] <_jpl_> Make that line 97 with latest copy from CVS. [22:32:34] Hm. [22:33:16] Ah, subclass isn't doing base class init. [22:33:59] Add ' isEmpty = binding.Make(lambda: events.Condition(True)) [22:33:59] ' [22:35:11] <_jpl_> Ok, so far so good. [22:37:09] <_jpl_> Hmm, other than the exitWith code, the rest seems to work. [22:37:23] <_jpl_> And is actually *readable*. [22:37:57] What's wrong with exitWith? [22:39:51] <_jpl_> Nothing I'm sure, my piece of code didn't seem to call it as far as I can tell. [22:40:32] Ah. [22:42:26] <_jpl_> Oh. It seems that ignoring a deferred gums up the works. [22:42:38] Ignoring? [22:43:35] <_jpl_> Running something which returns a deferred without actually doing anything with the return result. [22:44:44] Is that a Twisted issue, or a peak.events issue? [22:44:51] I mean, what's breaking. [22:45:49] <_jpl_> I can't tell. I just yielded the deferred and it still doesn't go to the next line of code after the events.resume(). [22:46:00] <_jpl_> I'll stare at it some more. [22:46:42] <_jpl_> Oh! Stupid mistake. [22:46:50] Eh? [22:47:09] <_jpl_> The next line of code must be generating an exception, which is quietly ignored. [22:48:03] <_jpl_> Er, it's in a try/except, but the exception handler must be broken, too. [22:48:28] <_jpl_> It was. Cut and paste strikes again. [22:49:18] Ah. [22:50:28] <_jpl_> Success [22:53:07] success is good [22:53:12] hi pje [22:53:19] Hey. [22:53:41] <_jpl_> The peak.events version isn't dramatically smaller, but it's dramatically easier on the brain. [22:55:03] it takes a while for a peak app to get off the ground [22:55:05] Yeeha! DDT does extra rows, annotations, and expected vs. actual... [22:55:11] Get off the ground? [22:55:31] it takes some setup and confiuration before i see gratification [22:55:40] configuration even [22:55:40] Ah. [22:55:49] <_jpl_> I can really use peak.ddt myself. I have a kludgy little test script I'm using now. [22:56:21] It's not quite ready for prime time yet, JPL. Maybe tomorrow, though. :) [22:56:35] I'm *really* surprised at how easy it's been so far. [22:56:57] .... that was just an idle comment, as i was grinding out a DM today :) [22:57:01] or some DM's [22:57:27] DDT has a DM that reads and writes HTML. :) [22:57:40] So, you can perhaps understand why I wasn't expecting it to go quickly. :) [22:57:55] <_jpl_> oooh [22:58:20] Don't get too excited there, JP. It's not a general HTML parser. It just matches table/tr/td stuff. [22:58:31] And it only edits table/tr/td tags. [22:59:23] <_jpl_> Even so, it'll make for interesting reading. [23:01:06] <_jpl_> That's more what I was ooohing about. :) [23:01:22] Ah. [23:03:28] <_jpl_> Oh, with twisted_support working I can now write some DMs using Junction calls. [23:05:48] Yeehaa... now it's got exception/traceback formatting. [23:06:56] _jpl_, that would be interesting to see (DMs using Junction calls) [23:06:56] Alright, that's it for the parsing and formatting support. It's a complete HTML DM for this data model. [23:07:11] JPL: DMs aren't asynchronous. [23:07:25] they have to be made syncronous [23:07:34] we discussed this some days ago :) [23:07:41] i dont' know how :) [23:07:50] Of course, all you need is a nested IEventLoop. [23:08:02] By nested, I mean an independent one from your main event loop, if you have one. [23:08:15] If the main program is synchronous, it only needs one event loop to use async code within it. [23:08:56] In either case, you use eventLoop.runUntil(condition) in synchronous code to run an async loop until 'condition' fires. [23:09:02] <_jpl_> DMs aren't asynchronous, but getting data from a PB connection is. [23:09:16] * _jpl_ is slow [23:09:20] * _jpl_ catches up [23:09:56] Find any other issues in twisted_support, JP? I'm about to check in that other fix (isEmpty) [23:10:03] <_jpl_> So you'd use an EventLoop within a DM's _load method, perhaps? [23:10:16] <_jpl_> So far no more problems. [23:10:19] Yeah... e.g.: [23:10:41] self.eventLoop.runUntil(self.someThreadedMethod(parameter).isFinished) [23:11:48] I'm thinking about maybe having threads themselves be event sources that output the last value yielded by the last generator in the thread. [23:12:21] So, if you ended a thread with 'yield someValue' it would fire any callbacks on the thread. Almost like a deferred. [23:12:28] Except no error-backs. [23:13:15] It would be mainly useful for runUntil() operations, though. [23:17:33] * pje checks in the new peak.ddt with full formatting abilities [23:17:52] Now, I just hope that adding the fixture classes will go as smoothly tomorrow. [23:19:26] And then it'll be time to make some database-specific fixture classes. [23:19:52] I have a project that calls for intensive testing of some stored procedures ported from Sybase to Oracle. [23:20:10] So, I'll be making fixtures that let me create a table of expected outputs given a set of inputs... [23:20:19] And other fixtures to verify the contents of tables before and after. [23:21:01] The table stuff should be generic enough to put into PEAK for other sorts of DB testing. [23:21:41] * _jpl_ wonders what piton is(was). [23:21:55] It's a previous name for ddt. [23:22:04] PEAK Integrated Test Oracle Notation. :) [23:22:44] I was going over some details of how we would use it with Ty this evening, and at one point he just used the phrase "document-driven testing".. [23:23:04] And once I realized the abbreviation was DDT, I said, "we gotta change the name." :) [23:23:06] <_jpl_> And because DDT is such a catchy acronym... :) [23:23:17] And it' [23:23:26] s much more obvious what the hell it does and why. :) [23:23:27] isn't ddt a wrestling move? [23:23:44] <_jpl_> But yeah, considering what the real DDT is for and what this is for, it makes sense in a slightly perverted sort of way. :) [23:23:48] Maniac: you're joking, right? [23:24:06] DDT is an insecticide. [23:24:10] = debugger. :) [23:24:26] <_jpl_> It's also a humanicide. [23:24:40] http://www.chem.ox.ac.uk/mom/ddt/ddt.html [23:24:43] Well, yes, but that's not what it was intended for. :) [23:24:59] <_jpl_> Hopefully peak.ddt won't be *quite* so strong. :) [23:25:42] Heh. [23:25:57] For an idea of what it'll be like when it's done, check out http://fit.c2.com/ [23:26:11] That site is very hard to follow, considering how simple the idea is. [23:26:21] oh and DDT is really a wrestling move :) [23:27:05] fit.c2.com was too complicated and i browsed on [23:27:07] is it a wiki? [23:27:15] Yes. [23:27:18] Try http://fit.c2.com/wiki.cgi?SimpleExample [23:27:22] * pje grins. [23:27:43] Then click on the "Run:" link near the bottom of the page, and look at the pretty colors. :) [23:28:13] It redisplays the page, annotated with the results of running the test that's embedded in the page. [23:28:13] <_jpl_> Nice. [23:28:56] http://fit.c2.com/wiki.cgi?MusicExampleWithErrors is a bit more advanced, showing how errors are rendered. [23:29:04] <_jpl_> Is there an easy way to run it automatically and send out e-mail in case of errors? I suppose you'd have to parse the resulting HTML. [23:30:11] I don't know about theirs, but ddt has a Document object with a 'score' that tracks the good/bad/ugly counts. [23:30:30] So, your top-level Command would be able to do something with it. [23:32:20] I don't expect to have a web-based runner like theirs at first. [23:32:31] It'll just be a command-line filterish tool. [23:32:56] But you can always run it on a webserver using cron and stick the results in a file. [23:33:03] <_jpl_> Ah, ok, then doing interesting things with it will probably be a lot more obvious. [23:33:37] * _jpl_ nods. [23:34:11] Thing is, for any "interesting" application you're going to have to do a bit of glue code to wrap your app. [23:34:22] Ran 522 tests in 10.643s [23:34:22] OK [23:34:22] Segmentation fault [23:34:25] what does that mean? [23:34:29] But you can write the test documents *before* you even write any app code. [23:34:32] (running peak tests) [23:34:47] Dunno, Maniac. It looks like you were fine until exit. What version of Python? [23:34:58] 2.3.2 [23:35:23] IIRC, wasn't 2.3.3 released to fix a problem w/core dumps during GC on exit from Python? [23:35:46] mmm [23:35:58] * Maniac checks for 2.3.3 in gentoo [23:36:51] Looks like I'm right... see http://www.python.org/2.3.3/NEWS.html [23:37:17] Two critical bugfixes relating to GC, weakrefs, and new-style objects. [23:37:42] I don't know if they affect 2.2 or not. [23:37:42] * Maniac is emerginhg [23:37:49] emerging :) [23:39:38] Well, I better get going if I want to get some sleep before I start in on test fixtures. [23:40:01] nite! [23:40:08] * pje waves [23:40:13] ** pje has left us [23:52:04] ja python2.3.3 fixed it :)