[00:09:15] --> _jpl_ has joined #peak [00:10:48] --> jolby has joined #peak [00:11:13] --> _jpl_ has joined #peak [04:33:21] <_Maniac> jolby: is it you doing jabber or _jpl_? [04:38:42] --> itamar has joined #peak [04:38:49] no pje [04:38:58] oh well [04:39:00] <-- itamar has quit #peak [04:44:28] Maniac: I'm doing some jabber-server stuff in twisted, and jack-e is doing some jabber stuff for the client side. [04:46:35] <_Maniac> ok, well dizzyd on #twisted is doing jabber-twisted.. http://www.jabberstudio.org/projects/hemp [04:46:38] <_Maniac> FYI [04:47:56] <_Maniac> he walked me through a *very* simple client today [04:47:58] _Mainiac: Ahhh-- I knew that (dizzyd) name looked familiar. I was looking at hemp last night (from your link you posted) [04:48:17] <_Maniac> ok [04:48:41] <_Maniac> there is no server yet, but he does xpath stuff which is quite different from jabberpy [04:51:52] _Maniac: Yah-- that was pretty cool I thought. I'm just using the jabberpy event-dispatch code, along w/ some awful hacks to not make it stream based so it hooks up w/ twisted's reactor. [04:56:02] <_Maniac> if you look in jabber.py there's a client class. [04:59:14] _Maniac: in the hemp code you mean? [04:59:26] <_Maniac> jolby: yes, sorry in hemp [05:02:03] _Maniac: Damn-- I kind of stirred up a hornet's nest on #twisted! [05:02:27] <_Maniac> :) [05:04:58] --- _Maniac is now known as Maniac [05:05:15] jolby: NIH syndrome :) [05:07:25] Maniac: hehe-- well to be fair, I see NIH a lot in python frameworks. I think PEAK has some of it as well. :-) [05:52:24] {global notice} Good morning everyone, we need to do some rehubbing in the us. I appologize for the inconvenience, any further messages will be given in wallops, 2500 users will be effected. Thank you for using freenode! [05:55:41] --> jolby has joined #peak [05:56:48] --> _jpl_ has joined #peak [09:59:00] --> jack-e has joined #peak [10:40:08] --> aloisius has joined #peak [10:40:16] hi radek :) [10:40:44] hi Ulrich! [10:40:58] how are things going ? [10:43:49] I had to teach new colleagues. My idea was that they start work with new system (based on peak) but things go very slowly. [10:46:13] As our team grows we need more rigid methodology for developers. [10:50:08] have you followed the mailinglist and the (now used) DevWiki ? [10:50:47] Und wie gehet's du? [10:51:27] I haven't any time to follows news :-( [10:52:07] :) .. fine so far .. i've a zope2 consulting job right now, that needs to be finished soon .. so i've not that much time for peak-development as i would like .. [10:53:41] It is a paradox. I must finish system that reduce development time but i have no time for working on it. [10:54:02] :) [10:56:03] I haven't worked with zope. Only some experiments. [10:58:40] We love vim,cvs,apache,fastcgi and of course python :-) [11:04:58] with peak.web i could jump on this train as well ;-) [11:05:08] except that i like emacs ;-) [11:14:23] I loved emacs too but it was too huge for my poor computer in 90's. And vim knows now how to play hanoi too :-) [11:14:58] :) [11:16:45] if you use python+fastcgi+apache you should really look into the new examples (trivial_web, trivial_cgi) in peak .. [11:17:26] they use fastcgi to make peak-applications available with security, traversal and soon templates [12:12:45] * Maniac uses xemacs [12:18:21] hey maniac [12:36:20] --- jack-e is now known as jack-e|shopping [12:42:15] --> _Maniac has joined #peak [13:09:53] <_Maniac> http://twistedmatrix.com/~moshez/haifux.html <--- [13:31:03] <_Maniac> jolby started a firestorm on #twisted last night [13:31:15] <_Maniac> here's one summary from twisted hacker moshez [13:31:32] <_Maniac> ok, so let me summarize PEAK [13:31:33] <_Maniac> * Intefaces -- looks good, a bit harder to use but more functional than Twisted's [13:31:33] <_Maniac> * Persistency -- completely undocumented, no idea [13:31:33] <_Maniac> * DB -- ditto [13:31:33] <_Maniac> * Binding -- a way to do mostly useless things [13:31:33] <_Maniac> [but cool things nonetheless] [13:31:35] <_Maniac> Does web and/or woven and/or guard have a debug mode where I can find out why it's not finding a child or suchlike? [13:31:38] <_Maniac> hrm, the "Hello world" example in t.web takes one less line than PEAK [13:31:40] <_Maniac> and it has to actually run a server, too. [13:31:42] <_Maniac> without peak, the same functionality can be accomplished with [13:31:44] <_Maniac> #!/usr/bin/python [13:31:46] <_Maniac> print 'hello world' [13:31:48] <_Maniac> Also note that 'peak.web' uses packages from Zope X3, so you need to [13:31:50] <_Maniac> have the Zope X3 milestone 3 release installed in site-packages, or on [13:31:52] <_Maniac> the PYTHONPATH as well. [13:31:54] <_Maniac> so you need to install Zope X3 to do that too... :) [13:31:56] <_Maniac> well, gotta run [13:32:00] <_Maniac> see y'alls [13:32:02] * _Maniac notes ignore the holocaine comment :) [13:32:14] --- _Maniac is now known as Maniac_ [13:37:00] * jack-e|shopping is gone (3:37PM): .. autoaway .. [15:17:29] * Maniac_ looks around [15:17:46] * Maniac_ contemplates using PEAK to take over the world.... [17:00:32] --> yarcat has joined #peak [17:04:10] --> als has joined #peak [17:04:15] <-- aloisius has quit #peak [17:05:00] hello [17:16:27] <_jpl_> 'Morning all [17:19:51] <_jpl_> So I now have an app working with binding, configuration, modeling, and storage. A little bit of protocols, with a fair amount of adaptation to come. So far not much with naming. [17:19:56] --- jack-e|shopping is now known as jack-e [17:25:14] hey john [17:25:30] <_jpl_> Hi Ulrich [17:26:25] <_jpl_> I might be able to release some source code soon for you to look at, which should make it easier to see how we could integrate our work. [17:26:47] jpl: that would be great :) [17:28:07] <_jpl_> Getting my first data manager to work the other day was pretty exciting. I trimmed down my SQL enough so that the same object loads/save from either SQLite or PG. [17:28:48] yeah .. simple tasks are again exciting ;-) [17:29:55] <_jpl_> Also complex tasks are exciting, rather than daunting. [17:30:06] right [17:45:14] helo [17:46:57] <_jpl_> Hi Maniac [17:48:32] _jpl_: Hey-- that's great. I'll be needing to check out the storage area myself fairly soon, so I may bug you for tips! [17:50:07] <_jpl_> It's pretty simple, actually. The bulletins example was enough to get me started. [17:51:22] <_jpl_> Though I had to take a slightly different approach than pje to get my DM to work effectively with Postgres. Phillip is taking advantage of SQLite's wonderful 'insert or replace' functionality, so I had to split that up into separate inserts and updates. [17:52:37] oh. I see. So did you just do that for both your backend adaptors, so it works the same across both postgres and sqlite backends? [17:53:16] <_jpl_> There's actually only one DM which works fine with both backends, and presumably others. [17:53:31] Ahh. Got it. Very cool. [17:54:05] <_jpl_> If you write your SQL generically enough it's theoretically possible to switch out the backend, though there'll probably always be exception cases that pop up. [17:55:42] <_jpl_> I was originally using some Postgres-specific features like table inheritance and IP/MAC addr field types, but the former can be managed manually (not pleasant, but the portability is probably worth it), and the latter (in the form of data validation) can be moved to the domain logic. [17:56:33] right. I imagine you can do basic CRUD stuff pretty generically, and then any sort of fancy reporting etc... you can do in lovingly handcrafted SQL that deals w/ the idosyncracies for the db you're in. [17:57:52] <_jpl_> One of the realy nice aspects of the PEAK approach is that you can simply supply a different database URL to get everything talking to a completely different backend. [17:59:00] <_jpl_> Yep, that's my expectation. I'm just doing really basic SQL at the moment, but any exceptional coding that needs done gets put in only one place: the data manager. Everything else remains blissfully unaware of how or even where the data is stored. [18:00:35] i think one of the jobs, a peak.storage.SQLConnection has is type-conversion as well .. so you don't need to care how to get your timestamp converted into a datetime object, no matter what rdbms you use .. [18:01:43] Oh, I didn't know that. I thought it was just a thin wrapper that blindly passed data back and forth from the db w/ no munging. That's cool. [18:02:34] nope .. it does return a SQLResult that behaves like a list/iterator but cares about memory-usage (e.g. yields .fetchone() [18:03:04] <_jpl_> It's a generator, in fact. We like generators. [18:03:06] and it does type-conversion on all columns (conversion can be configured within an .ini-style file) [18:03:19] jpl: right [18:03:20] <_jpl_> Nice, I didn't know about the type conversion either. [18:03:55] look at peak/storage/SQL.py SQLCursor.__call__ i think is the place where it happens [18:04:41] no SQLCursor.__iter__ [18:09:51] wow-- so much cool stuff to check out!. I need to get finished with my time generator so I can have 72hr days to explore all this stuff! [18:10:38] jobly: hey .. anotherone developing a timemachine :-)))) .. we should probably join forces for this project first ... [18:10:47] <_jpl_> I hope you release that time generator open source. We could probably all it. :) [18:11:09] <_jpl_> er, s/all it/all use it/ [18:13:44] _jpl_: Hehe-- yeah, I think it will be LGPL. [18:14:36] jolby: ;-) [18:19:50] Oh, ok. I see in peak.storage.SQL.py he's using a type map facility. very nice. [18:21:01] yup .. when you write a new Connection-Class for peak, you once care about type conversion and get back sensible python-values when using it [18:21:20] cool. [18:22:51] if you use ANSI-SQL (most commonly understood featured) in your Datamanagers they should be fairly cross-rdbms .. that's what i wanted to reach with nll.database.sqldm (it generates simple sql for object<->table persistence) [18:23:02] s/featured/features [18:24:22] * jack-e i fighting with win32com, ADSI and ADODB [18:24:34] s/i/is .. [18:25:06] and cannot use python2.2 features :(((((( [18:32:35] jack-e: yech! [19:15:57] <_jpl_> Hmm, how to store timestamps in an RDBMS-neutral way... [19:16:27] <_jpl_> It seems there's no date/time datatype in peak.model. [19:18:03] <_jpl_> Though there's support in storage/SQL.py... hmm. [19:26:00] * jack-e is gone (9:26PM): .. autoaway .. [19:29:26] jpl: i think it should be done with pyhton datetime objects .. [19:30:11] look at the bulletin example .. this is one of the things, pje realized while writing the example [19:32:40] <_jpl_> You mean mxDateTime? [19:33:21] nope .. python2.3 will ship with a datetime module [19:33:30] i think pje included it into the peak-distro [19:33:43] (for python2.2 installs) [19:34:35] <_jpl_> Ah, ok. Luckily I have "What's New in Python 2.3" printed out and on my desk. [19:34:44] :) [19:37:38] <_jpl_> How do I access the datetime class(es) from PEAK? [19:38:09] there is no implementation yet afaik. [19:38:33] you could just (temporarily) copy the DateTime class from bulletins-model to your app .. [19:39:03] you can allways define your very own datatypes [19:39:16] <_jpl_> True [19:39:19] and then referencedType = 'myType' [19:39:34] or without '' [19:39:46] depends on if you want it to be looked up or not ;-) [19:40:35] <_jpl_> Looked up where/how? At the DM level? [19:41:17] a component-class also has a context .. it's logical parent is the module that it contains [19:41:33] so if you say referencedType = 'model/String' [19:41:43] you advise the machinery to lookup an attribute model [19:41:52] then traverse to String [19:42:09] in a common module you say from peak.api import * [19:42:21] there you have you attribute model from that will be traversed [19:42:37] it also helps, if you don't want to order stuff in a certain way e.g. [19:42:46] class Blub(Attribute): [19:42:56] referencedType = 'someTypeDefinedBelow' [19:43:07] class SomeTypeDefinedBelow(String): pass [19:43:25] if you don't use the '' then you need to define the Type before you use it [19:43:40] <_jpl_> nod [19:43:47] and don't worry about performance .. the string is only looked up once [19:44:52] <_jpl_> I'm not sure I understand the 'model/String' functionality. Here 'model' refers to your own model.py, or peak.model? [19:45:15] to peak.model that you imported with from peak.api import * [19:45:29] it's available as *name* in your module [19:45:47] 'model/String' is a path [19:46:01] <_jpl_> So in referencedType you can include 'model/String', 'model/Integer', etc... [19:46:35] yes, as long as you do a "from peak.api import *" (or from peak.api import model at least) [19:46:59] if it's a string, it will be looked up, otherwise it needs to be a type [19:47:19] <_jpl_> (BTW, it looks as though when you install PEAK you get 'datetime' installed too at the top level. i.e. 'from datetime import datetime, timedelta') [19:48:08] yep .. that's what i thought [19:48:41] this is the python-type .. you need to define a peak-type for it, as done in bulletins-model that uses datetime to convert and represent the value [19:49:08] <_jpl_> Right, I'm looking at that. [19:49:13] <_jpl_> Looks pretty straightforward. [20:15:20] jack-e: i've been playing a little with hemp http://www.jabberstudio.org/projects/hemp [20:15:36] there's a jabber client class there that uses the twisted event loop [20:16:18] Maniac: ql .. go for integrating it with peak :) (and don't tell anybody ;-) [20:19:02] ql? [20:19:07] cool [20:19:10] ah [20:19:23] well if it is already using a proper event loop it should be easier no? [20:19:58] is it implemented as protocol ? [20:21:23] i guess [20:21:26] looks like it is implemented as protocol [20:21:28] yes [20:21:37] http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/hemp/hemp/jabber.py?rev=1.9&content-type=text/vnd.viewcvs-markup [20:21:39] so you'ld have to copy the twistedpeak stuff [20:21:47] i'm looking at it at the moment [20:21:53] :) [20:27:28] maniac: it is a protocol but i have no clue how to use it :-P [20:27:43] heh [20:28:02] basically the same as the EchoProtocol for the things you need on the peak-side .. but what else is needed .. i don't know [20:31:41] how do you mean what else is needed? [20:32:39] how you could do anything usefull with that jabber-protocol then ... [20:33:01] oh [20:33:04] or setup you components in a way that i would make sense [20:33:06] i know that :) [20:33:12] now setup components i dont' know [20:33:27] ql .. post an example (or mail me) [20:33:47] ok you mean how would you use that at all, say in a client? [20:33:53] right [20:34:05] very rough: [20:34:31] one sec [20:34:46] don't bother now .. i'm coding anyway [20:34:51] ok [20:34:56] it's not hard [20:35:00] send my an email with an example how you got it working [20:35:06] ok [20:41:04] sent [20:41:11] take it with a grain of salt :) [20:43:07] btw: hemp appears to be a project by: http://conferences.oreillynet.com/cs/os2003/view/e_spkr/1603 [20:46:11] if so .. he probably knows what he's doing ;-) [20:46:15] i might be wrong who it is tho [20:46:19] i just googled [20:46:58] no, it's him alright [20:48:48] he has not yet responded to any of the twisted-jabber mails on jdev .. [20:50:06] btw: got you mail .. thanks .. will look into it probably 2morrow [20:51:11] :) [21:11:09] i guess pje is not happy with some spillage into twisted [21:12:14] what does spillage mean ? [21:16:00] the discussions about peak at #twisted ?? [21:24:17] jack-e: yes [21:24:34] based on his meail [21:24:40] er email [21:25:28] i actually think it was accidental [21:25:50] and i don't think there's evangelicism going on other than very *loose* discussions in this channel [21:27:20] i partially agree with him .. allthough a larger community would help to strenghen the concepts and the amount of available information/documentation [21:27:26] i see the same for zope3 [21:27:54] there is an irc-channel where everybody who wants to get a problem solved joins and some of them stay [21:28:39] there is little documentation yet .. but some people have started demo-projects where they contribute their experiences back [21:29:03] this helps the core developers from zope3 to refine and check their concepts [21:29:50] a major plus for zope3 is, that they have sprints (developer-meetings of about 2-5 days which are a mix of tutorial, pair-programming and socializing) [21:30:27] having an active irc-community, a sensible mailinglist and sprints is a good thing to get people up to speed .. [21:31:00] docs are necessary .. but unless the alpha-phase has been finished, so many things are still a matter of change, that it's hard to have updtodate documentation [21:31:03] . [21:31:19] i dont' disagree with him at all [21:31:42] I think a sprint (In a few months after its baked a bit more) would be really fun. [21:32:03] yeah :)) i'll be there - no matter where it'll be located .. [21:32:04] jolby: have you read his latest mailing list message? [21:32:26] his == pje [21:34:01] Maniac_: ya- I read and replied off-line. I think everything is cool. I can understand his desire to not want a whole rabble of folks involved yet. [21:34:25] I don't really think there's any hard feelings. [21:36:34] that's good [21:37:01] I dont' think it was intentional to stir up interest just a question [21:37:22] I'm still working on some twisted+PEAK experiments tho' :-) I'll just be quieter about them for the time being... [21:38:16] No-- and I don't think pje thinks it was intentional either. [21:39:44] jolby: you can talk about your experiments in here - without any potential trouble ;-) [21:40:15] I think he's just worried that premature exposure will lead to a flock of end-user newbies expecting to see a finished, documented,tested, fully working framework, and when they try it out and get stuck flood the maillist with messages like: "Dude-- your framwork docs suX0rs!" [21:40:53] and he's probably right [21:41:58] jack-e: Ya-- I'll continue discussing here. I'm working right now on the twisted-web stuff. Hopefully I'll have a web-admin frontend to administer the echoserver in a couple hours. [21:42:10] :) [21:43:56] jack-e: Ya-- after going back and forth on the #twisted list yesterday, I began to see the problems it could cause as well. [21:44:19] joelby: what are you using for creating pages/parsing forms ?? [21:44:57] l8tr guys [21:45:00] cu [21:45:02] <-- Maniac_ has quit #peak [21:45:03] I'm going to play around with the twisted.web.woven stuff. Have you checked it out? [21:45:37] nope .. i've read through some intro .. but to grok it i'ld have needed more time [21:45:55] i think you could do a very similar thing as i did for the ZPT Adapter [21:47:58] jack-e: I may not even have to do that much. Right now, I'm thinking that I can just add another listener on another port for the webmin stuff. I *think* it would just be straight twisted at that point. [21:48:27] that's another option [21:48:40] but what from peak.web are you playing with then ?? [21:49:32] err .. i read peak.web instead of twisted-web .. [21:49:50] jack-e: Oh, not really anything. To integrate those two, I'd need delve deeper. [21:50:38] don't mind .. i was misslead by reading text that wasn't there .. [21:50:39] I *could* still access components/services/utilities from w/in the twisted-web-woven templates, I think. [21:50:58] would be another interesting direction to explore [21:51:53] Ya-- that's what's so cool about python and these frameworks. The time to spike a little test is minimal (especially compared to java) [21:52:23] i have no (or short and bad) experience with java .. [21:54:20] some of it can be pretty fun. There's certainly some cool stuff in there, but its sooooo *heavy* compared to python. I'm glad I know how to program in java, but I hope I never have to again... :-) [21:55:54] jolby: i think that's why i didn't really find my way into it .. you can't start small .. i wanted to build a java-applet with swing long time ago .. i never figured out, how to configure/package all that, to be able to execute this applet from a [21:56:15] browser .. but that's long time ago .. and i never really touched java again since then [21:56:15] The j2ee stuff is pretty life-crushing. I'd been doing that for a few years, and I realized "programming isn't fun anymore". Its just too heavyweight. Simple things took forever to code. took forever to compile, and forever to deploy. [21:56:21] jack-e: exactly [21:56:41] jack-e: It just got worse after you stopped playing w/ it. [21:56:57] good to hear ;-) [21:57:07] (at least for me) [21:57:48] a very good friend of mine is a java-code with j2ee/etc stuff involved .. he's still fascinated from what can be done with it .. [21:57:57] i haven't yet showcased him peak and python ;-) [21:58:31] jack-e: Hehe-- I bet he'll be blown away after this stuff cools down a bit... [21:58:49] i'll wait till we have the first release before i'll try [22:00:58] So far I think the 3 python component/networking frameworks have all the fun stuff that I liked about j2ee (components, interfaces -- tinkertoy paradigm), but leave most of the heaviness behind. I hope they can continue that. I'm a little worried about Zope3 sometimes. It seems harder to pull pieces out of the whole and play w/ them individually. I don't have that much experience w/ it tho' [22:01:33] Peak has a great feel so far. (to me at least) [22:02:34] same feeling for me .. but (as i have a good amount of experience with zope2) zope3 let's you more easily tweak things and integrate .. it's not made for taking out a certain service or something like that i think [22:02:48] btw: If you're at all interested in twisted, I ran across this doc yesterday, and I think its the best tour of that framework I've seen yet: http://twistedmatrix.com/~moshez/haifux.html [22:02:55] in contrast to zope2 i mean [22:03:19] jack-e: Oh, I see. well if its not designed to do that, I shouldn't be complaining then... :-) [22:03:52] i'm interested in twisted (as i'm about to build networked apps) .. and i'll read it [22:48:16] --> jack-e has joined #peak [22:51:44] night