[00:50:33] Maniac is now known as _Maniac [00:50:38] _Maniac is now known as Maniac [02:52:58] ** vlado_ has joined us [06:12:43] ** vlado__ has joined us [09:58:56] jack-e|away is now known as jack-e [10:02:47] ** Maniac_ has joined us [10:29:09] hello peakers [10:50:37] hey maniac :) [13:22:42] what peakish things are we doing today ? [13:40:46] binding.Make(lambda x: None) [14:55:48] :) [14:56:24] i kinda sorta made a simple jabber bot based on peak and twisted.jabber thanks to pje and _jpl_ [14:57:20] * Maniac_ wonders if nll.libs.net.imap talks to UW-IMAP yet .... ;-) [15:02:32] Maniac: if you had success with twisted.imap4, then the chances are not bad, i refactored nll.net.mail.imap to use tw.imap as one (configurable) alternative to std-libs imap-module [15:02:53] though, there is not explicit support for namespaces yet. [15:04:28] there is a new twimap.py file in src/nll/net/mail/ [15:30:19] yeah, it was the namepaces thing that got me last time. [15:35:11] i just wish there were some more peak examples out there. what i'm doing now works but i like to emulate as much as possible. [15:35:17] * Maniac_ peers at _jpl_ [15:35:30] * Maniac_ read _jpl_'s junction idea. that looked cool [15:36:09] emulate .. what? [15:38:46] (_jpl_'s junction idea is basically the re-implementation of the agent-framework of OSE for peak, afaik) [15:44:54] i'd like to emulate other's good peak programs :) [15:46:02] there's lots of stuff in nll.apps BUT it's almost too big to grasp [15:59:12] right .. they should solve real-world problems and do not serve as examples .. otherwise the would have been contributed to the wiki or the like [15:59:56] real world problems tend to be more complex as initially thought :) [16:11:19] i want "peak for dummies" or "how to write enterprise applications for idiots" or "how to program with peak in 10 days" [16:11:57] i wouldn't sell/buy this book: "how to write enterprise applications for idiots" :)) [16:12:43] i would ! [16:13:07] ok i dont' mean the users are idiots, i mean i am :) [16:14:11] * jack-e is now going home to regenerate from the hard weekend (i did 9hrs of DJ'ing in 18hrs Party from sat 11pm - so 5pm) [16:14:27] * jack-e needs really sleep ... [16:15:21] ouch [16:15:34] .. fun .. to be more correct :) [16:16:21] the "ouch" was that we had to set down everythin on sunday 7pm :) [16:16:49] (which was about 5hrs -- we call it after-party-work :) [16:17:33] http://randomthoughts.vandorp.ca/jabberclient.py <-- my jabbercliet [16:18:08] i went out this weekend. I was too tired by 12:00 am i had to go home to bed [16:18:15] i am too old :) [16:18:20] hehe [16:18:26] almost 29 ;) [16:18:55] if you have weekends like mine about once a month, you stay young (i'm 30) [16:19:55] :) [16:20:23] jack-e is now known as jack-e|away [16:21:31] (btw. i couldn't view your jabberclient due to network timeout) .. [16:24:03] yeah, i'm trying to figure out why it's sluggish [16:24:08] try again :) [16:24:39] probably my co-workers are saturating my network with crap [16:25:00] i need a bandwidth arbitrator [17:05:31] rowr [17:05:39] all my internet is broken except irc ? [17:05:55] it's time to reboot the internet [17:09:14] ** Maniac_ has joined us [17:09:59] * Maniac_ reset the router and now all is golden !!! [18:36:08] ** _Maniac has joined us [19:26:45] ** rdmurray has joined us [19:28:19] <_jpl_> ping [19:28:45] pong [19:29:29] <_jpl_> poing [19:29:52] What was that, a net ball? [19:33:56] <_jpl_> ping/pong combination [19:34:20] Sorry, I was trying to be funny and forgot the :) :) [19:35:12] Hmm. The pyprotocol's docs don't conveniently document the full possabilities of what can be declared in an interface.... [19:35:53] <_jpl_> What are you looking to declare besides methods and attributes? [19:36:23] It's the attributes docs I can't lay my hands on. I wish the manual was one big htlm doc, so I could search it easily :) [19:36:31] html [19:37:13] <_jpl_> What are you trying to do with protocol attributes? [19:38:23] I'm just trying to define an Interface where most of the Interface consists of attributes. [19:39:14] <_jpl_> Ok, so are you using protocols.Attribute? [19:39:30] I am now that I found the docs (through google) :) [19:40:37] <_jpl_> Remember, Interface objects are essentially just documentation. You can put 'pass' as the entire body of an Interface object and it will still do its job. [19:41:03] Hmm. Good point, but I do want the docs :) [19:41:20] might as well try to do this right :) [19:41:21] <_jpl_> The important thing is that it's a separate object with a unique id (as is any other object). [19:42:06] <_jpl_> Right, interfaces don't help as documentation if they're devoid of any documenting elements. [19:42:15] Actually, I wonder if I should be using peak.model for this, since basically I'm describing the basic data structure of the package. [19:42:47] But I don't really understand peak.model or how to use it :) [19:43:50] <_jpl_> Are these objects 'model' objects? That is, are they the core object types that model the entities of the problem domain your application is meant to address? [19:44:10] Yep. [19:44:16] (I think :) [19:45:10] Actually I'm pretty sure of it. [19:48:08] I think I could figure out how to write the model classes, but I've got no idea how one is supposed to use them. [19:48:16] <_jpl_> Then peak.model is probably what you need, and you generally don't have separate interfaces for domain objects. [19:48:31] So you just adapt the model classes directly? [19:49:20] <_jpl_> No, you don't adapt model objects, as far as I know. That sort of goes against the whole idea... [19:49:29] <_jpl_> Unless you mean something else by 'adapt'... [19:49:44] I mean the pyprotocol's sense of adapt. [19:50:03] <_jpl_> You instantiate model classes, then use those instances in whatever way makes sense for your application. [19:50:41] <_jpl_> Right. Well, you *could* adapt model objects, but ... why? What are you trying to do? [19:51:05] Maybe I meant "adapt to". Like, I have data in an external representation, and I want to make the program that uses the model classes independent of the external representation. [19:51:52] <_jpl_> Ah, then you're not talking about adaptation. This is simply a question of loading data into the model objects, which is what DMs (data managers) are for. [19:51:53] So I was thinking I'd as for an adapter to get from the "load form" of my data to my "real interface", or maybe the model classes if that is what makes sense. [19:52:03] Ah, I see. [19:52:19] Did you write more of your tutorial? I haven't looked.... [19:52:33] <_jpl_> DMs shuttle data between model objects and some data storage medium. [19:52:38] <_jpl_> Not yet, unfortunately. [19:52:42] :( [19:53:03] I looked at the bulletins example, but I must admit to feeling rather lost. [19:53:08] <_jpl_> Have you looked at the "bulletins" example? It has several working model classes and DMs. [19:53:13] Not that I've spent much time on it yet. [19:53:48] ** pje has joined us [19:54:14] Hi gang. [19:54:27] You can't easily "adapt to" a model type. [19:54:33] <_jpl_> Ah. Well then, maybe start with one of the entities, like Bulletin, and learn how its used throughout the system, then move on to another, like Category, etc. [19:54:37] But, it is meaningful to adapt model types to interfaces. [19:54:50] In fact, it's likely that in a future PEAK version that'll be an AOP mechanism. [19:55:09] <_jpl_> Ah, interesting. [19:55:10] (That is, you'll adapt model types to protocols in order to get custom versions of those types.) [19:55:44] <_jpl_> Would you be adapting to another model type in that case? [19:55:55] <_jpl_> Or would the adapter not be a model object? [19:55:59] JPL: no, to a protocol representing the aspect. [19:56:24] So, let's say I have a peak.model class family representing domain behavior... [19:56:30] <_jpl_> IOW, an adapter that represents the model object in a different way? [19:56:42] And I want to define an aspect for let's say "write stuff to XML"... [19:56:43] meaning you'd get back something optimized for whatever aspect you were working with? [19:56:58] rdmurray: more or less [19:57:19] JPL: so, I write "write to XML" methods on a bunch of empty classes named the same as the model classes I want the methods added to. [19:57:40] And then declare that bunch of stuff as an "aspect adapter" for the IXMLWriter interface. [19:58:03] So then, it's really just a shortcut form of manually declaring individual adapters. [19:58:16] <_jpl_> (couldn't you just write one XML-oriented Element adapter which loops through the original objects features and does something with the data?) [19:58:18] But, really this is about adapting the *type*. [19:58:31] JPL: yeah, but now you're writing reflective code. [19:58:42] There are times that that's useful, but sometimes it isn't. [19:58:51] Here's a more specific example, one for something I actually intend to do... [19:59:01] Are you familiar with Python's "AST branch"? [19:59:38] <_jpl_> We're having to do a lot of that with our application at the moment so we can shuttle model objects to remote systems (currently using PB, but the same would apply for, say XML-RPC). [19:59:44] <_jpl_> Vaguely. [19:59:51] Take a look at http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/ast/python.asdl?rev=1.26&view=auto [20:00:11] It's very short, so just glance at it. [20:00:35] You'll notice it is basically just a very compact represenation of what is, in effect, a peak.model class family. [20:00:48] But, it doesn't provide any behavior to those data types. [20:01:24] I could write a simple generator to take that file and turn it into peak.model classes. [20:01:36] But, then to have behavior, I'd have to define adaptation to add the behavior. [20:01:46] <_jpl_> I see. [20:01:52] Reflectivity won't cut it here, though, because the behaviors are different for each class. [20:02:04] <_jpl_> Right, I get it. Nice idea. [20:02:13] <_jpl_> In fact, a really nice idea. [20:02:18] Btw, if you're wondering *why* I'd want to do this to the ASDL/AST stuff, it's to do workflow. [20:02:24] Actually, and Twisted as well. [20:02:49] <_jpl_> "Twisted as well" meaning...? [20:02:56] My idea is that if you compile Python code to AST objects like those, but they are executable, then you can suspend/resume execution. [20:03:16] Imagine if you could write something in Twisted that wasn't "inside out". [20:03:31] That is, you could call things that return deferreds, but still execute linearly? [20:03:58] <_jpl_> *boggle* [20:04:01] All the "interpreter" of these AST objects would need to do is set a callback on the deferred to resume the execution. [20:04:28] And an errback that would trigger the nearest "try" block containing the invocation point. [20:04:29] <_jpl_> So you'd automatically 'yield' or something similar? [20:04:43] No, not yield. [20:05:11] What's the DateTime thingy in bulletins/model.py? Should I cut'n'paste it into my code, or wait until I figure out why I'd want it? :) [20:05:13] Not exactly, anyway. [20:05:33] <_jpl_> I know not exactly yield... but you'd suspend execution automatically and come back to run the next line of code when a deferred returns a value. [20:05:54] rdmurray: wait until you know why you want it. :) [20:06:31] JPL: More like throwing an exception, actually. [20:07:48] <_jpl_> Oh, DateTime reminds me, if I ever get around to setting up a CVS-enable project somewhere, PEAK users could start sharing custom data types to be used in model classes. E.g. we have a 'PartitionSize' data type which converts things like '10GB' and '1000kb' to the right internal value. [20:08:21] Seems like you could just stick that on the Wiki; surely it's not that big. [20:08:30] <_jpl_> Not sure how many other people would want that, but it's potentially useful. [20:08:33] Especially if you used fmtparse. :) [20:08:47] It'd be more useful as an example of creating custom datatypes. [20:09:05] <_jpl_> I really wish I knew how to use fmtparse. There aren't any fmtparse-specific unit tests that I could find. :( [20:09:06] If I were still writing sysadmin code I'd want it. [20:09:15] So, anyway, I actually more want the interpreter thingy for workflow than for Twisted. [20:09:45] In the workflow case, it's a bit easier to envision, because you have explicit interpreter operations being called by the workflow engine. [20:10:23] <_jpl_> I was reading the fmtparse source again over the weekend, but my grasp of parsing theory is almost non-existent... [20:10:24] The things that twist my brain a bit are dealing with calling back into interpreted code from pure Python or from C. [20:11:01] Actually, it's not the calling back, it's the *returning* from calling back, if the callee gets suspended. [20:11:40] If you're explicitly calling the interpretation system, it's more sensible because you get returned a status code separate from the result of the execution. [20:11:51] <_jpl_> So by workflow you mean something like FSMs on steroids? [20:12:10] More or less. [20:12:25] But, with things like try/except blocks for timeout errors, etc. [20:12:35] <_jpl_> I could definitely use something like that. [20:12:46] And with the state being able to be stored in a database. [20:13:05] <_jpl_> It would really take all the "strangeness" out of asynchronous programming. [20:13:18] Of course, that means you can only suspend execution at points known to have no pure Python or C on the call stack. [20:13:47] Yes, that's basically the idea. [20:14:15] It's much easier to reason about a snippet of sequential Python than to try to read a bunch of state transitions. [20:14:40] Or, almost as bad, a bunch of 'def foo(): ... d.callback(foo)' blocks. [20:15:06] * pje wants good old fashioned if, while, for, and try/except/finally [20:15:26] Performance will, of course, suck. :) [20:16:08] However, it won't really matter for my workflow needs, since execution time of the business rules of the workflow will be dominated by database access. [20:16:33] <_jpl_> I just wrote a class a week or two ago which runs through a task queue asynchronously. By now I don't find the technique difficult to deal with, but what does worry me a bit is that doing this sort of thing manually makes it really possible that a particular transition falls through the cracks. [20:16:41] For Twisted, it probably won't make a difference either, because you'd only need to write suspendable routines in it. [20:17:04] JPL: yep. I hate writing FSM's by hand. [20:17:15] I don't even really care for generating them automatically from tables. [20:17:23] It's still glorified GOTO. [20:17:35] <_jpl_> FSMs considered harmful. [20:17:46] I'm not sure I'd go that far. [20:17:49] <_jpl_> :) [20:17:55] For some things, they're the *best* way to understand a thing. [20:18:08] <_jpl_> I'm just kidding. They're essential sometimes. [20:18:10] But workflow and networking protocols are *not* best understood that way. [20:18:42] Well, I guess some highly state-branchful protocols might be. [20:18:58] Even so, protocol *client* code is rarely branchful. [20:19:21] Usually, you just do things sequentially. But in Twisted, you even have to make the client an FSM. :( [20:19:40] Anyway, that's my long-term plan for dealing with workflow. [20:19:48] <_jpl_> This reminds me somewhat of the idea behind Seaside, a web application framework for Squeak. Apparently you write a web app in Seaside as you would any other app, with traditional flow control, etc. Only your Seaside app "drops out" to the web to ask the user something from time to time. [20:20:07] <_jpl_> (That's how I understand the idea, anyway. Haven't had time to run through a tutorial yet.) [20:23:05] *lightbulb* [20:23:08] Interesting. [20:23:26] But probably not worthwhile. [20:23:44] Web control flow is rarely sequential. [20:24:37] Forms and wizards are about the only places where you have a high probability of proceeding to the next step. [20:25:00] Also, the web's inherently stateless, so this forces some kind of session to save the "thread" state. [20:25:32] Ah well, for a second there it sounded really exciting. :) [20:26:19] the web is a poor man's gui, and we all know gui's have to be event driven :) [20:27:00] Plus, being stateful breaks the BACK button. [20:27:24] And as a web user I really *hate* it what that happens, as it does all to often on ecommerce sites. [20:27:58] an ecommerce site has to be stateful, but I'd like them to be able to handle my back button usage :) [20:29:05] There being stateful persistent data on a site, and there being session state are two different things. [20:29:35] * pje has got to head home now, though [20:29:43] So, I'm in a state of disarray... ;) [20:29:50] See y'all later. [20:29:59] bye [20:30:09] ** pje has left us [20:43:13] <_jpl_> Apparently Seaside deals intelligently with the back button. [20:45:00] Good trick, that. Assuming the programmer doesn't have to be aware of it. [20:45:21] <_jpl_> Apparently the programmer doesn't. [20:45:27] <_jpl_> Nor the user. :) [20:45:54] * _jpl_ spams: [20:45:55] <_jpl_> Seaside is a framework for developing sophisticated web applications in Smalltalk. [20:45:56] <_jpl_> Its most unique feature is its approach to session management: unlike servlet models which require a separate handler for each page or request, Seaside models an entire user session as a continuous piece of code, with natural, linear control flow - pages can call and return to each other like subroutines, complex sequences of forms can be managed from a single method, objects are passed by reference rather than marshalled into URLs or hidden fields - whi [20:46:17] <_jpl_> while fully supporting the backtracking and parallelism inherent to the web browser. [20:46:17] <_jpl_> Seaside also features a callback-based event model, a "transaction" system for auto-expiring pages, programmer-friendly HTML generation and designer-friendly templates, a system of reusable and embeddable UI components, and handy web-based development tools. [20:47:10] <_jpl_> I want that for Python. Maybe it would be worth porting. [20:56:46] <_jpl_> Maybe it would be *possible* to port, first... :) [21:37:28] Well, I've got a nice model built. Now to see if I can figure out how to use it :) [22:57:23] <_jpl_> What do you need to do with it? [23:12:18] Load data from files. The example uses sql... [23:13:07] pje gave me a pointer to a file example which I'll look at later. For now, it is my bedtime.