IRC log of #zope3-dev for Friday, 2009-11-13

*** MJ has quit IRC00:00
*** afd_____ has quit IRC00:01
*** davisagli has joined #zope3-dev00:07
*** ignas has joined #zope3-dev00:25
*** benji has quit IRC00:30
*** tarek_ is now known as tarek00:35
*** mcdonc_ has joined #zope3-dev00:44
*** mcdonc has quit IRC00:44
*** mcdonc_ is now known as mcdonc00:45
*** redir_ has quit IRC00:54
*** J1m has quit IRC01:20
*** gary_poster has quit IRC01:20
*** aaronv has joined #zope3-dev01:28
*** srichter has quit IRC01:30
*** ignas has quit IRC01:36
*** mcdonc has quit IRC01:36
*** mcdonc has joined #zope3-dev01:39
*** fcorrea has joined #zope3-dev01:42
*** allisterb has joined #zope3-dev01:46
*** allisterb_ has quit IRC01:51
*** run|vm|winxp has quit IRC01:53
*** run|vm|winxp has joined #zope3-dev01:53
*** aaronv has quit IRC01:56
*** J1m has joined #zope3-dev01:56
*** J1m has quit IRC01:58
*** nathany has quit IRC02:00
*** sm_ has joined #zope3-dev02:02
*** hazmat has quit IRC02:09
*** sm has quit IRC02:11
*** sm_ is now known as sm02:11
*** lurkymclurklet-1 has quit IRC02:14
*** menesis has quit IRC02:24
*** sm has left #zope3-dev02:24
*** kaeru has quit IRC02:47
*** kaeru has joined #zope3-dev02:51
*** hathawsh is now known as hath|away02:51
*** hath|away is now known as hathawsh02:52
*** hathawsh is now known as hath|away02:52
*** dunny has joined #zope3-dev03:03
*** hath|away is now known as hathawsh03:17
*** srichter has joined #zope3-dev03:38
*** ChanServ sets mode: +o srichter03:38
*** huajie has joined #zope3-dev03:40
*** davisagli has quit IRC04:20
*** dunny has quit IRC04:22
*** matthal has joined #zope3-dev04:22
*** dunny has joined #zope3-dev04:22
*** dunny has quit IRC04:24
*** dunny has joined #zope3-dev04:24
*** davisagli has joined #zope3-dev04:57
*** _matth has joined #zope3-dev05:05
*** matthal has quit IRC05:13
*** _matth is now known as matthal05:13
*** hathawsh is now known as hath|away05:21
*** hath|away is now known as hathawsh05:22
*** hathawsh is now known as hath|away05:23
*** davisagli has quit IRC05:28
*** alecm has quit IRC05:34
*** davisagli has joined #zope3-dev05:35
*** dunny has quit IRC05:36
*** matthal has quit IRC05:41
*** chaoflow has joined #zope3-dev05:41
*** chaoflow_ has quit IRC05:41
*** chaoflow has quit IRC05:42
*** chaoflow has joined #zope3-dev05:42
*** hath|away is now known as hathawsh05:43
*** chaoflow has quit IRC05:43
*** chaoflow has joined #zope3-dev05:43
*** stub has joined #zope3-dev06:13
*** pcardune_ has joined #zope3-dev06:35
*** pcardune has quit IRC06:38
*** pcardune_ is now known as pcardune06:38
*** baijum has joined #zope3-dev06:53
*** hathawsh has quit IRC06:57
*** hathawsh has joined #zope3-dev06:57
*** afd_____ has joined #zope3-dev07:45
*** pcardune has quit IRC07:57
*** zagy has joined #zope3-dev08:07
*** afd____ has joined #zope3-dev08:16
*** afd___ has joined #zope3-dev08:18
*** afd_____ has quit IRC08:34
*** afd____ has quit IRC08:35
*** jukart has joined #zope3-dev08:41
*** davisagli has quit IRC09:08
*** huajie has quit IRC09:11
*** davisagli has joined #zope3-dev09:11
*** pcardune has joined #zope3-dev09:13
*** pcardune has quit IRC09:19
*** ignas has joined #zope3-dev09:22
*** markusleist has quit IRC09:30
*** sweh has joined #zope3-dev09:32
*** matthal has joined #zope3-dev09:36
*** dunny has joined #zope3-dev09:44
*** _matth has joined #zope3-dev09:45
*** stub has quit IRC09:47
*** _matth has quit IRC09:50
*** fRiSi has joined #zope3-dev10:00
*** fRiSi has quit IRC10:00
*** fRiSi has joined #zope3-dev10:01
*** matthal has quit IRC10:01
*** davisagli has quit IRC10:10
*** fRiSi has quit IRC10:15
*** goschtl has joined #zope3-dev10:17
*** junkafarian_ has joined #zope3-dev10:20
*** jpcw has joined #zope3-dev10:21
*** reinout has joined #zope3-dev10:21
*** junkafarian_ is now known as junk|home10:22
*** mgedmin has joined #zope3-dev10:24
*** junkafarian has quit IRC10:26
*** markusleist has joined #zope3-dev10:32
*** __mac__ has joined #zope3-dev10:38
*** agroszer has joined #zope3-dev10:45
*** junkafarian has joined #zope3-dev10:55
*** afd__ has joined #zope3-dev11:01
*** afd___ has quit IRC11:09
*** srichter has quit IRC11:10
*** srichter has joined #zope3-dev11:11
*** ChanServ sets mode: +o srichter11:11
*** stub has joined #zope3-dev11:24
*** menesis has joined #zope3-dev11:48
*** MJ has joined #zope3-dev11:50
*** __mac__ has quit IRC11:52
*** __mac__ has joined #zope3-dev11:53
*** mkerrin has joined #zope3-dev11:56
*** hathawsh is now known as hath|away11:58
*** ignas has quit IRC12:07
*** dunny has quit IRC12:11
*** alga has quit IRC12:39
vaabI'm trying to subscribe to zope3-dev, but it seem to be moderated on subscription... "Your subscription request was deferred because subscriptions to Zope3-dev require moderator approval". I've a patch that I would like to discuss on this list. Will this moderation take long to be accepted ?12:40
Theuni2vaab: usually not12:47
* Theuni2 checks 12:47
*** ignas has joined #zope3-dev12:49
Theuni2I'm not moderator on that list, sorry.12:50
*** mintsauce has joined #zope3-dev13:06
mintsauceDown to what level in the ZODB do things have an id? Lists? List items?13:06
*** fcorrea has quit IRC13:09
*** afd_ has joined #zope3-dev13:11
ignasmintsauce, Lists if you are talking about python list class13:14
ignasmintsauce, though if you are using PersistentList - then items in it will have an ID13:14
ignassame for dict vs PersistentDict(ionary)13:15
*** afd__ has quit IRC13:16
lisppaste6mintsauce pasted "no p_oid?" at
ignasnot enough information13:19
ignasdid you put the item into zodb?13:19
ignasdid you commit?13:19
lisppaste6mintsauce annotated #90289 "untitled" at
ignascan you see it if you iterate all the oids in your database?13:19
mintsaucethe item is in zodb (the record is a few weeks old)13:20
mintsauceiterate all the oids? Won't there be loads?13:20
ignasi am pretty sure that if you would ask ZODB for an object with some poid you would get the list, I am not sure whether ZODB is porxying non-persistent objects though13:21
ignasmintsauce, depends on your ZODB13:21
ignasbut still, you could iterate until you get an instance of some list13:21
ignasand check out the list13:21
ignasto see if a list you got from ZODB has a poid assigned13:21
ignasmaybe it's like a dict, you know - foo['a'] = your_list13:22
ignasyou can get the list by id 'a'13:22
ignasbut your list has no "id"13:22
ignasthough hmm13:22
ignasok, non-persistent classes don't have IDs i guess13:22
ignasthey are probably stored as pickles in the attributes of other persistent items13:23
ignasso yeah, the list will not have a poid13:23
ignasa new "instance" gets "created" whenever you update an object that is actually persistent13:24
mintsauceBack to the drawing board....13:29
*** stub has quit IRC13:30
mintsauceI have a simple messaging system, its a nested list, each nested list contains sender, title, message.13:31
mintsauceBut not (my oversight!) an id13:31
mintsauceI want to directly address each message - trying to work out the best way, without having to go back through via generations and add an id....13:31
mintsauceToyed with hashing the entire contents, but the risk of identical messages is too great.13:32
mintsauceThinking gonna have to retrospecively add via generations.13:37
mintsauce* retrospectively13:38
*** jhauser has joined #zope3-dev13:46
*** alga has joined #zope3-dev13:49
*** jhauser has quit IRC13:52
*** jhauser has joined #zope3-dev13:53
*** afd_ has quit IRC14:02
*** afd_ has joined #zope3-dev14:03
*** fcorrea has joined #zope3-dev14:03
*** afd_____ has joined #zope3-dev14:04
*** zagy has quit IRC14:14
*** afd_ has quit IRC14:22
*** aaronv has joined #zope3-dev14:28
*** mintsauce has quit IRC14:44
*** J1m has joined #zope3-dev14:46
*** projekt01 has joined #zope3-dev14:53
*** mintsauce has joined #zope3-dev14:55
*** mintsauce has quit IRC14:55
*** zagy has joined #zope3-dev15:09
vaabignas: here's my patch proposal for features pluggability in zope.testing ( I'm sending it to the mailing list as soon as my subscription to that ml is accepted ;)15:10
vaabif anyone is interested by zope.testing accepting features from other packages, please check and comment:
Theuni2vaab: i already experimented with that a while ago, I found it to be pretty fragile to make the pipeline pluggable15:13
vaabTheuni2: could you be more specific ?15:13
Theuni2stuff like profiling/coverage analysis needs to go in at very specific places in the pipeline, otherwise they'll do the wrong thing15:13
vaabTheuni2: what's for sure is that there are some problem on the order of the pipeline15:14
Theuni2I ended up thinking that it might be more worthwhile to keep the existing pipeline as is and allow individual features (like find) to register specific plugins15:14
ignasvaab, sorted(entrypoints, lambda x,y: cmp(, -> sorted(entrypoints, key=lambda plugin:
vaabbut this should not remove the possibility to add a element. I think that in the long term a full pluggability should be supported...15:14
Theuni2full pluggability is a buzzword thingy15:14
vaabignas: ok ;)15:15
Theuni2all the plugins need to carefully play together15:15
Theuni2it's not like you can just throw them in and wait for stuff to happen15:15
Theuni2IMHO the pipeline is good for helping to understand what's going on15:15
vaabTheuni2: I'm scratching my itch : I need to provide a business module to zope.testing and I can't... this is not buzzword for me.15:15
Theuni2can you be more specific what your itch is?15:16
vaabxml output should be providable without hacking around zope.testing.15:16
Theuni2that's for the dashboard integration?15:16
vaabMy itch is to give proper data on test execution times that could fit in our database15:16
Theuni2can't remember which tool that was15:16
Theuni2i saw a post about that recently, right?15:17
vaabTheuni2: I'm not on the ml ;) so I'm not really in the hot topics...15:17
Theuni2someone said something about a buildbot-replacement they're using15:17
agroszerM. Aspeli did that for plone+hudson15:18
Theuni2that was it15:18
Theuni2vaab: you're talking about that?15:18
vaabBut it is quite strange to see such a pluggable architecture around Features in zope.testing that was not carryed enough to allow extensibility.15:18
Theuni2vaab: that was on purpose ;)15:18
vaabTheuni2: could you be cleared ?15:18
vaabclearer ?15:18
Theuni2Really, pipelines aren't a magic bullet.15:18
Theuni2vaab: are you talking about integration with "hudson"?15:18
Theuni2is that the tool you're using?15:18
vaabTheuni2: no, not at all. Just heard somewhere that was also a problem. Mine is to provide data that I can reuse.15:19
Theuni2what do you mean by provide data?15:20
agroszerwhat data and what for?15:20
vaabI need some specific test execution times information15:20
Theuni2you want that on stdout or would you be happy to put that in a file?15:21
vaabI want to capture them to get some overview on how is our project going in terms of performance.15:21
vaabTheuni2: that's a shame that we must get to that, isn't it ? since Features seems particularly adapted to that... except implementing one means having our one patched zope.testing.15:22
agroszerif you run buildbot, you could harvest that info from it15:22
vaabTheuni2: but you are right, some of the info I want are in the full verbose mode of zope.testing.15:22
Theuni2vaab: IMHO reasonable and pluggable design comes from understanding which use cases one really wants to solve.15:23
Theuni2So just invoking a mechanism to make something pluggable doesn't guarantee you a consistent design/system.15:23
vaabTheuni2: I feel like looking at std is a bad option, but it is an option.15:23
Theuni2My cycle for that is: code something specific, code something more specific, review how the first and the second work together, join the code to do both elegantly, rinse, repeat15:24
Theuni2with that you'll get to some kind of pluggable architecture eventually15:24
Theuni2but IMHO pluggability hooks need to be done on the application level, otherwise your plugins will contradict each other15:24
Theuni2especially with just registering entry points that will activate anything and everything just by an egg being present15:24
ignasapplication level?15:25
Theuni2vaab: i'd be happy to put that data in a file15:25
Theuni2ignas: the specific plugins in this case15:25
ignasas in - you pass the pipeline configuration to the bin/test15:25
ignasexplicitly rather than to have it self assemble15:25
Theuni2well that for one15:25
Theuni2but still15:25
Theuni2you remember how the code coverage is really fragile?15:26
ignasvaab, the downside of your current system is - that a rogue or incompatible plugin in pythonpath15:26
Theuni2i would almost bet that moving it to a different position in the pipeline will cause all kinds of fun breakage?15:26
ignasvaab, will bring the testing infrastructure down15:26
ignasTheuni2, that is not a problem, as long as it does not happen automatically15:26
ignasi mean - default configuration works, you can change/fix the custom one15:26
ignasis good enough i'd say15:27
Theuni2my proposal would be to have features like the statistics or the finder provide pluggability points specific to their behaviour15:27
*** benji has joined #zope3-dev15:27
Theuni2e.g. currently it would be really hard to write a second finder plugin that works well with the original one15:27
Theuni2so really you have to make your overlapping functionality work with each other15:27
Theuni2and that's the reason why I'd rather have a specific feature provide a plugin-point15:27
Theuni2instead of the o-so-almighty pipeline15:27
Theuni2(I know that *I* built that pipeline. but really it's only there to make the code more understandable)15:28
vaabignas: python system is already really weak against any rogue or incompatible plugins, but that's important point15:28
ignasTheuni2, if you provide custom pipeline why can't you "replace" one part of the old one?15:28
Theuni2ignas: well you *could* but if you look at the code you don't want to ;)15:29
ignas(my outlook on pluggability is mostly - you want it pluggable, first make it possible to do without the "old" part)15:29
ignasso if you want a pluggable test finder, first make it possible to replace the current one with a dummy one15:29
Theuni2ignas: good point, i'm with you on that15:29
Theuni2so if you join what both of us said IMHO you end up with:15:29
Theuni2there's a feature for finding stuff15:30
vaabTheuni2: isn't it bad design if features are not so independant ? We could also allow a basic fixed number of features plus additional pluggable features. And provide a way to override basic feature without changing the order of them.15:30
Theuni2that feature has a smallish API and a default implementation that can be taken out, but the feature is there.15:30
Theuni2vaab: at last europython i came to the conclusion that in this case you have to be a bit more transcending about dependencies15:31
Theuni2there are intricate matters that overlap and fight each other with test runners15:31
Theuni2e.g. profiling and code coverage really step on each others toes if you don't watch out15:31
vaabTheuni2: Yes, I've seen some when writing/testing this code...15:31
Theuni2so the subjects are already overlapping15:31
Theuni2IMHO the ideal of independent code is good but you have to check whether the actual subject you're talking about are independent or not.15:32
vaabTheuni2: this could bring to a clear reflexion of their interaction. These are not clear now... And make manipulation of current code more complicated.15:32
Theuni2I don't understand how a flexible pipeline does that.15:33
ignassimple interconnected systems *sometimes* are better than complex independent ones ;)15:33
vaabthe interaction are implicit in the current code, and features are created as if they were pluggable, but they aren't.15:34
ignasi guess a simple profile and a simple coverage tester that can't be turned on at the same time is better than ones that work together through magic ;)15:34
Theuni2noe they're not created as if pluggable15:34
Theuni2there's no pluggability there15:34
Theuni2vaab: you're looking at the code and think "hey that would be easy to *make* pluggable."15:34
Theuni2but that's using an implementation detail15:35
vaabIf trying to get a pluggable system leads to interesting thoughts on not very explicit interaction between different object, I think it is a god thing. This need some cleaning and to be explicited. This might lead to get out of the pluggable "features" the corresponding parts...15:36
Theuni2again, i'm not against pluggability15:36
Theuni2my point is that IMHO plugins shouldn't be opaque things15:36
Theuni2because that makes interdependent subjects appear to be independent when they're not15:37
Theuni2i'd be happy to make the individual features provide plugin points15:37
Theuni2but again, that should be done by each requirement where pluggability is needed in a specific manner15:38
vaabMost of the features are really independant, it seems that only 2 or 3 main features are to be executed in the correct order. This should not close the possibility to get pluggability as it is a very usefull feature that scratch a lots of itches around the testing community.15:38
vaabThere might be a way to ensure correct stability and execution of the main features, and allow at the same times a controlled pluggability.15:40
Theuni2Right. That's what I think will happen when we introduce pluggability step by step instead of just opening everything up for everything.15:40
Theuni2the test runner needs to be *very* stable IMHO15:41
Theuni2because we rely heavily on correct operation15:41
Theuni2would you notice if some bug would cause 2 tests to not be run?15:41
Theuni2i probably wouldn't for example15:41
Theuni2because other people implement new tests, remove old tests so the number varies a lot15:42
vaabseparating core features from the pluggable feature could be the first step. I'm willing to provide other patch that would take into account to types of features.15:42
vaab/to types/two types/s15:42
Theuni2for one, i think your requirement is pretty neat and interesting for others so I'd also like to see the actual plugin for that.15:43
Theuni2i bet we can make the test runner itself better to provide functionality for you directly that others can use as well15:43
ignasvaab, point is - it will take less time for you to write the actual feature and get it integrated than trying to get a pluggability system everyone agrees upon ;)15:43
vaabignas: that's sure ;) but my feature is too specific to be used by other people, so I will need to keep a private version of zope.testing just for that... Not to painfull, but I would rather contribute to zope.testing for a pluggability feature.15:46
ignastoo specific?15:46
ignaswhich part of it?15:46
ignasis it possible to separate it into 2 parts15:47
ignas1 for collecting the data you need, which might be useful to others15:47
ignasand the other part that outputs it in format that you like15:47
ignasand making the feature pluggable so you could change the output format at will15:47
ignaseither automatically, or by providing the output formatter as a parameter15:48
vaabI will output directly in csv or sqlite some specific information (md5 of code under test, test execution time, name of module, name of function/doctest...). I'm not sure the MD5 part is of some interest for others.15:48
ignaslike: --profile=cProfile,  --test-timing=my.xml.output.thingie.that.outputs.md515:49
vaabbesides, parsing zope.testing std could bring some of these info.15:49
ignaswith default being --test-timing=zope.testing.output.without.md515:49
vaabwell cProfile doesn't give you info as you which, (it contains all the zope.testing methods perf...)15:50
ignasi mean --profile as an example15:51
ignaszope.testing used to allow you to pick one of the profilers15:51
vaabThe only info that is of interest (for me in this particular situation) is the total time each test took (without setup/teardowns)15:51
*** mintsauce has joined #zope3-dev15:51
ignasso your timing thingie can allow people pick different timing outputs, or even write one of their own15:51
ignasthat is useful info, even without pluggability, it might be nice to add it to the verbose output of zope.testing15:52
*** tisto has joined #zope3-dev15:52
ignas(last time my tests began taking too much time, the flaw was in test setup ;)15:52
vaabignas: we are looking at test setup also... ;)15:53
*** J1m has joined #zope3-dev15:53
lisppaste6mintsauce pasted "Failing annotations" at
mintsauceI'm trying and failing, to access user annotations in a site generation script:15:54
mintsauceIdentical code works fine in the rest of the site, although memberlist[member] is usually exchanged for 'context'15:54
ignasmintsauce, failing? what's the precise error?15:55
mintsauceThe attempt to adapt gives the error:15:55
mintsauceTypeError: ('Could not adapt', <zope.principalregistry.principalregistry.UnauthenticatedPrincipal object at 0x271e650>, <InterfaceClass zope.annotation.interfaces.IAnnotations>)15:55
mintsaucehmmmm ... just noticed the 'UnauthenticatedPrincipal' bit in the message ...15:56
mgedminignas, useful quote: <vimgor> What happens? Did it fall asleep on your couch? Eat your homework? Destroy your harddrive? Be specific15:56
mgedmina bot's response to "doesn't work"15:56
vaabignas: I'll try to write a IFeature that could be integrated in zope.testing (and any pluggable system) with separation of concerns as you suggested... but this might also be subject to heavy discussion so I'm not sure I'll take to much time to implement this for now. If the feature is clean enough I'll might make a proposition on the ML. Thx for the ideas and discuss (thx Theunix also for feedback and ideas). see you soon on the ML15:56
*** drudi has joined #zope3-dev15:58
mintsaucecan't understand where UnauthenticatedPrincipal is coming from - im running the evolve script from the zmi as manager.16:00
*** gary_poster has joined #zope3-dev16:00
ignasgetUtility(IAuthentication,'',memberlist[member]) this looks "interesting"16:01
ignasahh, you just don't have this habit of providing names of keyword arguments16:02
ignasmakes the code difficult to read...16:02
*** jfkw has joined #zope3-dev16:02
*** lurkymclurkleton has joined #zope3-dev16:03
*** lurkymclurkleton has joined #zope3-dev16:03
ignasnope, can't tell you whats wrong16:04
mintsauceignas: shorcut code trying to get it to work - bad habit :)16:04
ignaswould suggest import pdb; pdb.set_tracE()16:04
ignasand stepping through the getPrincipal() code16:04
ignasalso - look whether you are getting the same pau16:05
ignasthat you are getting in your code that *works*16:05
mintsaucesame pau is a good point - will check16:06
ignasalso I would try doing this with setSite(new_site) finally: setSite(old_site) around, maybe someone somewhere is not passing the context along16:07
ignasthough my guess is that the site is the same anyway16:08
ignasso it should not matter16:08
*** jukart has quit IRC16:09
*** lamike has joined #zope3-dev16:10
*** lamike has left #zope3-dev16:10
lisppaste6mintsauce annotated #90298 "pau doh?" at
mintsaucep_oid is same, but 'object at' different ....... does that indicate the wrong pau ignas?16:20
ignasif pau is the same, then - ids are not ;)16:21
ignasthe ones you pass to getPrincipal16:21
mintsauceare those two paus the same then?16:23
mintsaucep'raps i am passing wrong principal .... that's a common mistake (for me at least)16:23
ignasthe paus are the same16:24
ignaszodb does not guarantee the same object address in two different sessions for the same object16:24
*** baijum has quit IRC16:43
lisppaste6mintsauce annotated #90298 "works" at
ignasmintsauce, hmm?16:55
ignasdoes that make it work?16:55
mintsaucesetSite does the job16:55
ignasan advice16:56
ignasdo old_site = getSite()16:56
ignasbefore the script16:56
ignasand add finaly: setSite(old_site)16:56
ignasafter it16:56
ignasbecause else - if you run the script from a different site16:56
ignasyour site will get reset16:56
ignaswhich can kill error handling utilities16:56
ignas(had serious problems when the site got set to None)16:56
ignasthe traceback was trying to get written into a local error handling utility that did not exist for site "None"16:57
ignasalso - you probably don't have to pass the context to getUtility16:57
ignasif global site is set16:57
*** srichter has quit IRC16:57
ignas(i am not 100% sure)16:57
*** sm has joined #zope3-dev17:04
*** jhauser has quit IRC17:09
*** __mac__ has quit IRC17:11
*** sweh has quit IRC17:20
mintsaucethanks for help ignas17:21
*** mintsauce has quit IRC17:21
*** hazmat has joined #zope3-dev17:25
*** ChanServ sets mode: +o hazmat17:25
*** srichter has joined #zope3-dev17:31
*** ChanServ sets mode: +o srichter17:31
*** baijum has joined #zope3-dev17:40
*** markusleist has quit IRC17:45
*** ignas has quit IRC17:54
*** baijum has quit IRC17:57
*** alexdb has joined #zope3-dev18:10
*** reinout has quit IRC18:19
*** jhauser has joined #zope3-dev18:25
*** mintsauce has joined #zope3-dev18:26
mintsauceI'm getting the following error when trying to complete a db generation, never come across it before:18:27
mintsauceConnectionStateError: Shouldn't load state for 0x8f when the connection is closed18:27
mintsauceIs it related to the setSite/getSite advice ignas gave me earlier (which I did follow)18:28
*** projekt01 has quit IRC18:28
*** redir has joined #zope3-dev18:38
*** pcardune has joined #zope3-dev18:40
*** pcardune has quit IRC18:49
*** J1m has quit IRC18:50
*** sm has quit IRC18:50
*** goschtl has quit IRC18:50
*** davisagli has joined #zope3-dev18:51
*** sm_ has joined #zope3-dev18:51
*** davisagli has quit IRC18:52
*** sm_ is now known as sm18:52
*** J1m has joined #zope3-dev18:54
*** MJ has quit IRC18:55
*** ignas has joined #zope3-dev19:01
*** hath|away is now known as hathawsh19:02
*** mintsauce has quit IRC19:04
*** alecm has joined #zope3-dev19:12
*** mgedmin has quit IRC19:18
*** ignas has quit IRC19:29
*** pcardune has joined #zope3-dev19:35
*** nathany has joined #zope3-dev19:40
*** SteveA has quit IRC19:42
*** SteveA has joined #zope3-dev19:42
*** davisagli has joined #zope3-dev19:42
*** mkerrin has left #zope3-dev19:43
*** nathany_ has joined #zope3-dev19:48
*** nathany has quit IRC19:48
*** nathany_ is now known as nathany19:49
*** tisto has quit IRC19:50
*** pcardune has quit IRC19:50
*** agroszer_ has joined #zope3-dev19:51
*** alexdb has quit IRC19:53
*** pcardune has joined #zope3-dev19:54
*** allisterb_ has joined #zope3-dev19:55
*** pcardune has quit IRC19:55
*** run|vm|winxp has quit IRC20:07
*** agroszer has quit IRC20:10
*** matthal has joined #zope3-dev20:11
*** allisterb has quit IRC20:12
*** matthal has quit IRC20:22
*** afd_____ has quit IRC20:22
*** alga has quit IRC20:33
*** danielblackburn has joined #zope3-dev20:50
*** danielblackburn is now known as danielb2|afk20:50
*** pcardune has joined #zope3-dev20:52
*** hazmat has quit IRC20:55
*** sweh has joined #zope3-dev21:07
*** jpcw has quit IRC21:19
*** junkafarian has quit IRC21:38
*** srichter_ has joined #zope3-dev21:46
*** srichter has quit IRC21:47
*** aaronv has quit IRC21:59
*** hazmat has joined #zope3-dev22:04
*** ChanServ sets mode: +o hazmat22:04
*** davisagli has quit IRC22:07
*** davisagli has joined #zope3-dev22:08
*** markusleist has joined #zope3-dev22:32
*** hathawsh is now known as hath|away22:33
*** hath|away is now known as hathawsh22:39
*** dunny has joined #zope3-dev22:41
*** benji has quit IRC22:46
*** febb has joined #zope3-dev22:48
*** mcdonc has quit IRC22:50
*** febb_ has joined #zope3-dev22:51
*** febb has quit IRC22:51
*** benji has joined #zope3-dev22:51
*** mcdonc has joined #zope3-dev22:57
*** jpcw has joined #zope3-dev22:58
*** drudi has quit IRC23:08
*** menesis has quit IRC23:10
*** jhauser has quit IRC23:10
*** aaronv has joined #zope3-dev23:13
*** sweh has quit IRC23:14
*** hathawsh is now known as hath|away23:17
*** agroszer_ has quit IRC23:27
*** redir has quit IRC23:29
*** redir has joined #zope3-dev23:31
*** srichter_ has quit IRC23:34
*** Theuni2 has quit IRC23:36
*** hath|away is now known as hathawsh23:42
*** menesis has joined #zope3-dev23:52
*** hathawsh is now known as hath|away23:55

Generated by 2.15.1 by Marius Gedminas - find it at!