| *** MJ has quit IRC | 00:00 | |
| *** afd_____ has quit IRC | 00:01 | |
| *** davisagli has joined #zope3-dev | 00:07 | |
| *** ignas has joined #zope3-dev | 00:25 | |
| *** benji has quit IRC | 00:30 | |
| *** tarek_ is now known as tarek | 00:35 | |
| *** mcdonc_ has joined #zope3-dev | 00:44 | |
| *** mcdonc has quit IRC | 00:44 | |
| *** mcdonc_ is now known as mcdonc | 00:45 | |
| *** redir_ has quit IRC | 00:54 | |
| *** J1m has quit IRC | 01:20 | |
| *** gary_poster has quit IRC | 01:20 | |
| *** aaronv has joined #zope3-dev | 01:28 | |
| *** srichter has quit IRC | 01:30 | |
| *** ignas has quit IRC | 01:36 | |
| *** mcdonc has quit IRC | 01:36 | |
| *** mcdonc has joined #zope3-dev | 01:39 | |
| *** fcorrea has joined #zope3-dev | 01:42 | |
| *** allisterb has joined #zope3-dev | 01:46 | |
| *** allisterb_ has quit IRC | 01:51 | |
| *** run|vm|winxp has quit IRC | 01:53 | |
| *** run|vm|winxp has joined #zope3-dev | 01:53 | |
| *** aaronv has quit IRC | 01:56 | |
| *** J1m has joined #zope3-dev | 01:56 | |
| *** J1m has quit IRC | 01:58 | |
| *** nathany has quit IRC | 02:00 | |
| *** sm_ has joined #zope3-dev | 02:02 | |
| *** hazmat has quit IRC | 02:09 | |
| *** sm has quit IRC | 02:11 | |
| *** sm_ is now known as sm | 02:11 | |
| *** lurkymclurklet-1 has quit IRC | 02:14 | |
| *** menesis has quit IRC | 02:24 | |
| *** sm has left #zope3-dev | 02:24 | |
| *** kaeru has quit IRC | 02:47 | |
| *** kaeru has joined #zope3-dev | 02:51 | |
| *** hathawsh is now known as hath|away | 02:51 | |
| *** hath|away is now known as hathawsh | 02:52 | |
| *** hathawsh is now known as hath|away | 02:52 | |
| *** dunny has joined #zope3-dev | 03:03 | |
| *** hath|away is now known as hathawsh | 03:17 | |
| *** srichter has joined #zope3-dev | 03:38 | |
| *** ChanServ sets mode: +o srichter | 03:38 | |
| *** huajie has joined #zope3-dev | 03:40 | |
| *** davisagli has quit IRC | 04:20 | |
| *** dunny has quit IRC | 04:22 | |
| *** matthal has joined #zope3-dev | 04:22 | |
| *** dunny has joined #zope3-dev | 04:22 | |
| *** dunny has quit IRC | 04:24 | |
| *** dunny has joined #zope3-dev | 04:24 | |
| *** davisagli has joined #zope3-dev | 04:57 | |
| *** _matth has joined #zope3-dev | 05:05 | |
| *** matthal has quit IRC | 05:13 | |
| *** _matth is now known as matthal | 05:13 | |
| *** hathawsh is now known as hath|away | 05:21 | |
| *** hath|away is now known as hathawsh | 05:22 | |
| *** hathawsh is now known as hath|away | 05:23 | |
| *** davisagli has quit IRC | 05:28 | |
| *** alecm has quit IRC | 05:34 | |
| *** davisagli has joined #zope3-dev | 05:35 | |
| *** dunny has quit IRC | 05:36 | |
| *** matthal has quit IRC | 05:41 | |
| *** chaoflow has joined #zope3-dev | 05:41 | |
| *** chaoflow_ has quit IRC | 05:41 | |
| *** chaoflow has quit IRC | 05:42 | |
| *** chaoflow has joined #zope3-dev | 05:42 | |
| *** hath|away is now known as hathawsh | 05:43 | |
| *** chaoflow has quit IRC | 05:43 | |
| *** chaoflow has joined #zope3-dev | 05:43 | |
| *** stub has joined #zope3-dev | 06:13 | |
| *** pcardune_ has joined #zope3-dev | 06:35 | |
| *** pcardune has quit IRC | 06:38 | |
| *** pcardune_ is now known as pcardune | 06:38 | |
| *** baijum has joined #zope3-dev | 06:53 | |
| *** hathawsh has quit IRC | 06:57 | |
| *** hathawsh has joined #zope3-dev | 06:57 | |
| *** afd_____ has joined #zope3-dev | 07:45 | |
| *** pcardune has quit IRC | 07:57 | |
| *** zagy has joined #zope3-dev | 08:07 | |
| *** afd____ has joined #zope3-dev | 08:16 | |
| *** afd___ has joined #zope3-dev | 08:18 | |
| *** afd_____ has quit IRC | 08:34 | |
| *** afd____ has quit IRC | 08:35 | |
| *** jukart has joined #zope3-dev | 08:41 | |
| *** davisagli has quit IRC | 09:08 | |
| *** huajie has quit IRC | 09:11 | |
| *** davisagli has joined #zope3-dev | 09:11 | |
| *** pcardune has joined #zope3-dev | 09:13 | |
| *** pcardune has quit IRC | 09:19 | |
| *** ignas has joined #zope3-dev | 09:22 | |
| *** markusleist has quit IRC | 09:30 | |
| *** sweh has joined #zope3-dev | 09:32 | |
| *** matthal has joined #zope3-dev | 09:36 | |
| *** dunny has joined #zope3-dev | 09:44 | |
| *** _matth has joined #zope3-dev | 09:45 | |
| *** stub has quit IRC | 09:47 | |
| *** _matth has quit IRC | 09:50 | |
| *** fRiSi has joined #zope3-dev | 10:00 | |
| *** fRiSi has quit IRC | 10:00 | |
| *** fRiSi has joined #zope3-dev | 10:01 | |
| *** matthal has quit IRC | 10:01 | |
| *** davisagli has quit IRC | 10:10 | |
| *** fRiSi has quit IRC | 10:15 | |
| *** goschtl has joined #zope3-dev | 10:17 | |
| *** junkafarian_ has joined #zope3-dev | 10:20 | |
| *** jpcw has joined #zope3-dev | 10:21 | |
| *** reinout has joined #zope3-dev | 10:21 | |
| *** junkafarian_ is now known as junk|home | 10:22 | |
| *** mgedmin has joined #zope3-dev | 10:24 | |
| *** junkafarian has quit IRC | 10:26 | |
| *** markusleist has joined #zope3-dev | 10:32 | |
| *** __mac__ has joined #zope3-dev | 10:38 | |
| *** agroszer has joined #zope3-dev | 10:45 | |
| *** junkafarian has joined #zope3-dev | 10:55 | |
| *** afd__ has joined #zope3-dev | 11:01 | |
| *** afd___ has quit IRC | 11:09 | |
| *** srichter has quit IRC | 11:10 | |
| *** srichter has joined #zope3-dev | 11:11 | |
| *** ChanServ sets mode: +o srichter | 11:11 | |
| *** stub has joined #zope3-dev | 11:24 | |
| *** menesis has joined #zope3-dev | 11:48 | |
| *** MJ has joined #zope3-dev | 11:50 | |
| *** __mac__ has quit IRC | 11:52 | |
| *** __mac__ has joined #zope3-dev | 11:53 | |
| *** mkerrin has joined #zope3-dev | 11:56 | |
| *** hathawsh is now known as hath|away | 11:58 | |
| *** ignas has quit IRC | 12:07 | |
| *** dunny has quit IRC | 12:11 | |
| *** alga has quit IRC | 12:39 | |
| vaab | I'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 |
|---|---|---|
| Theuni2 | vaab: usually not | 12:47 |
| * Theuni2 checks | 12:47 | |
| *** ignas has joined #zope3-dev | 12:49 | |
| Theuni2 | ah | 12:50 |
| Theuni2 | I'm not moderator on that list, sorry. | 12:50 |
| *** mintsauce has joined #zope3-dev | 13:06 | |
| mintsauce | Down to what level in the ZODB do things have an id? Lists? List items? | 13:06 |
| *** fcorrea has quit IRC | 13:09 | |
| *** afd_ has joined #zope3-dev | 13:11 | |
| ignas | mintsauce, Lists if you are talking about python list class | 13:14 |
| ignas | mintsauce, though if you are using PersistentList - then items in it will have an ID | 13:14 |
| ignas | same for dict vs PersistentDict(ionary) | 13:15 |
| *** afd__ has quit IRC | 13:16 | |
| lisppaste6 | mintsauce pasted "no p_oid?" at http://paste.lisp.org/display/90289 | 13:18 |
| ignas | not enough information | 13:19 |
| ignas | did you put the item into zodb? | 13:19 |
| ignas | did you commit? | 13:19 |
| lisppaste6 | mintsauce annotated #90289 "untitled" at http://paste.lisp.org/display/90289#1 | 13:19 |
| ignas | can you see it if you iterate all the oids in your database? | 13:19 |
| mintsauce | the item is in zodb (the record is a few weeks old) | 13:20 |
| mintsauce | iterate all the oids? Won't there be loads? | 13:20 |
| ignas | i 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 though | 13:21 |
| ignas | mintsauce, depends on your ZODB | 13:21 |
| ignas | but still, you could iterate until you get an instance of some list | 13:21 |
| ignas | and check out the list | 13:21 |
| ignas | to see if a list you got from ZODB has a poid assigned | 13:21 |
| ignas | maybe it's like a dict, you know - foo['a'] = your_list | 13:22 |
| ignas | you can get the list by id 'a' | 13:22 |
| ignas | but your list has no "id" | 13:22 |
| ignas | though hmm | 13:22 |
| ignas | ok, non-persistent classes don't have IDs i guess | 13:22 |
| ignas | they are probably stored as pickles in the attributes of other persistent items | 13:23 |
| ignas | so yeah, the list will not have a poid | 13:23 |
| ignas | a new "instance" gets "created" whenever you update an object that is actually persistent | 13:24 |
| mintsauce | hrrrrm | 13:29 |
| mintsauce | Back to the drawing board.... | 13:29 |
| *** stub has quit IRC | 13:30 | |
| mintsauce | I have a simple messaging system, its a nested list, each nested list contains sender, title, message. | 13:31 |
| mintsauce | But not (my oversight!) an id | 13:31 |
| mintsauce | I 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 |
| mintsauce | Toyed with hashing the entire contents, but the risk of identical messages is too great. | 13:32 |
| mintsauce | Thinking gonna have to retrospecively add via generations. | 13:37 |
| mintsauce | * retrospectively | 13:38 |
| *** jhauser has joined #zope3-dev | 13:46 | |
| *** alga has joined #zope3-dev | 13:49 | |
| *** jhauser has quit IRC | 13:52 | |
| *** jhauser has joined #zope3-dev | 13:53 | |
| *** afd_ has quit IRC | 14:02 | |
| *** afd_ has joined #zope3-dev | 14:03 | |
| *** fcorrea has joined #zope3-dev | 14:03 | |
| *** afd_____ has joined #zope3-dev | 14:04 | |
| *** zagy has quit IRC | 14:14 | |
| *** afd_ has quit IRC | 14:22 | |
| *** aaronv has joined #zope3-dev | 14:28 | |
| *** mintsauce has quit IRC | 14:44 | |
| *** J1m has joined #zope3-dev | 14:46 | |
| *** projekt01 has joined #zope3-dev | 14:53 | |
| *** mintsauce has joined #zope3-dev | 14:55 | |
| *** mintsauce has quit IRC | 14:55 | |
| *** zagy has joined #zope3-dev | 15:09 | |
| vaab | ignas: here's my patch proposal for features pluggability in zope.testing (http://pastebin.com/mb5c8b22)... I'm sending it to the mailing list as soon as my subscription to that ml is accepted ;) | 15:10 |
| vaab | if anyone is interested by zope.testing accepting features from other packages, please check and comment: http://pastebin.com/mb5c8b22 | 15:12 |
| Theuni2 | vaab: i already experimented with that a while ago, I found it to be pretty fragile to make the pipeline pluggable | 15:13 |
| vaab | Theuni2: could you be more specific ? | 15:13 |
| Theuni2 | well | 15:13 |
| Theuni2 | stuff like profiling/coverage analysis needs to go in at very specific places in the pipeline, otherwise they'll do the wrong thing | 15:13 |
| vaab | Theuni2: what's for sure is that there are some problem on the order of the pipeline | 15:14 |
| Theuni2 | I 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 plugins | 15:14 |
| ignas | vaab, sorted(entrypoints, lambda x,y: cmp(x.name, y.name)) -> sorted(entrypoints, key=lambda plugin: plugin.name) | 15:14 |
| vaab | but 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 |
| Theuni2 | full pluggability is a buzzword thingy | 15:14 |
| Theuni2 | IMHO | 15:14 |
| vaab | ignas: ok ;) | 15:15 |
| Theuni2 | all the plugins need to carefully play together | 15:15 |
| Theuni2 | it's not like you can just throw them in and wait for stuff to happen | 15:15 |
| Theuni2 | IMHO the pipeline is good for helping to understand what's going on | 15:15 |
| vaab | Theuni2: 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 |
| Theuni2 | can you be more specific what your itch is? | 15:16 |
| vaab | xml output should be providable without hacking around zope.testing. | 15:16 |
| Theuni2 | that's for the dashboard integration? | 15:16 |
| vaab | My itch is to give proper data on test execution times that could fit in our database | 15:16 |
| Theuni2 | can't remember which tool that was | 15:16 |
| Theuni2 | i saw a post about that recently, right? | 15:17 |
| vaab | Theuni2: I'm not on the ml ;) so I'm not really in the hot topics... | 15:17 |
| Theuni2 | someone said something about a buildbot-replacement they're using | 15:17 |
| agroszer | M. Aspeli did that for plone+hudson | 15:18 |
| Theuni2 | right | 15:18 |
| Theuni2 | that was it | 15:18 |
| Theuni2 | vaab: you're talking about that? | 15:18 |
| vaab | But 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 |
| Theuni2 | vaab: that was on purpose ;) | 15:18 |
| vaab | Theuni2: could you be cleared ? | 15:18 |
| vaab | clearer ? | 15:18 |
| Theuni2 | Really, pipelines aren't a magic bullet. | 15:18 |
| Theuni2 | vaab: are you talking about integration with "hudson"? | 15:18 |
| Theuni2 | is that the tool you're using? | 15:18 |
| vaab | Theuni2: no, not at all. Just heard somewhere that was also a problem. Mine is to provide data that I can reuse. | 15:19 |
| Theuni2 | what do you mean by provide data? | 15:20 |
| agroszer | what data and what for? | 15:20 |
| vaab | I need some specific test execution times information | 15:20 |
| Theuni2 | ah | 15:20 |
| Theuni2 | you want that on stdout or would you be happy to put that in a file? | 15:21 |
| vaab | I want to capture them to get some overview on how is our project going in terms of performance. | 15:21 |
| Theuni2 | right | 15:21 |
| vaab | Theuni2: 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 |
| agroszer | if you run buildbot, you could harvest that info from it | 15:22 |
| vaab | Theuni2: but you are right, some of the info I want are in the full verbose mode of zope.testing. | 15:22 |
| Theuni2 | vaab: IMHO reasonable and pluggable design comes from understanding which use cases one really wants to solve. | 15:23 |
| Theuni2 | So just invoking a mechanism to make something pluggable doesn't guarantee you a consistent design/system. | 15:23 |
| vaab | Theuni2: I feel like looking at std is a bad option, but it is an option. | 15:23 |
| Theuni2 | My 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, repeat | 15:24 |
| Theuni2 | with that you'll get to some kind of pluggable architecture eventually | 15:24 |
| Theuni2 | but IMHO pluggability hooks need to be done on the application level, otherwise your plugins will contradict each other | 15:24 |
| Theuni2 | especially with just registering entry points that will activate anything and everything just by an egg being present | 15:24 |
| ignas | application level? | 15:25 |
| Theuni2 | vaab: i'd be happy to put that data in a file | 15:25 |
| Theuni2 | ignas: the specific plugins in this case | 15:25 |
| ignas | as in - you pass the pipeline configuration to the bin/test | 15:25 |
| ignas | explicitly rather than to have it self assemble | 15:25 |
| Theuni2 | well that for one | 15:25 |
| Theuni2 | but still | 15:25 |
| Theuni2 | you remember how the code coverage is really fragile? | 15:26 |
| ignas | vaab, the downside of your current system is - that a rogue or incompatible plugin in pythonpath | 15:26 |
| Theuni2 | i would almost bet that moving it to a different position in the pipeline will cause all kinds of fun breakage? | 15:26 |
| ignas | vaab, will bring the testing infrastructure down | 15:26 |
| ignas | Theuni2, that is not a problem, as long as it does not happen automatically | 15:26 |
| ignas | i mean - default configuration works, you can change/fix the custom one | 15:26 |
| ignas | is good enough i'd say | 15:27 |
| Theuni2 | my proposal would be to have features like the statistics or the finder provide pluggability points specific to their behaviour | 15:27 |
| *** benji has joined #zope3-dev | 15:27 | |
| Theuni2 | e.g. currently it would be really hard to write a second finder plugin that works well with the original one | 15:27 |
| Theuni2 | so really you have to make your overlapping functionality work with each other | 15:27 |
| ignas | hmm | 15:27 |
| Theuni2 | and that's the reason why I'd rather have a specific feature provide a plugin-point | 15:27 |
| Theuni2 | instead of the o-so-almighty pipeline | 15:27 |
| Theuni2 | (I know that *I* built that pipeline. but really it's only there to make the code more understandable) | 15:28 |
| vaab | ignas: python system is already really weak against any rogue or incompatible plugins, but that's important point | 15:28 |
| ignas | Theuni2, if you provide custom pipeline why can't you "replace" one part of the old one? | 15:28 |
| Theuni2 | ignas: 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 |
| ignas | so if you want a pluggable test finder, first make it possible to replace the current one with a dummy one | 15:29 |
| Theuni2 | ignas: good point, i'm with you on that | 15:29 |
| Theuni2 | so if you join what both of us said IMHO you end up with: | 15:29 |
| Theuni2 | there's a feature for finding stuff | 15:30 |
| vaab | Theuni2: 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 |
| Theuni2 | that feature has a smallish API and a default implementation that can be taken out, but the feature is there. | 15:30 |
| Theuni2 | vaab: at last europython i came to the conclusion that in this case you have to be a bit more transcending about dependencies | 15:31 |
| Theuni2 | there are intricate matters that overlap and fight each other with test runners | 15:31 |
| Theuni2 | e.g. profiling and code coverage really step on each others toes if you don't watch out | 15:31 |
| vaab | Theuni2: Yes, I've seen some when writing/testing this code... | 15:31 |
| Theuni2 | so the subjects are already overlapping | 15:31 |
| Theuni2 | IMHO 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 |
| vaab | Theuni2: 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 |
| Theuni2 | I don't understand how a flexible pipeline does that. | 15:33 |
| ignas | simple interconnected systems *sometimes* are better than complex independent ones ;) | 15:33 |
| vaab | the interaction are implicit in the current code, and features are created as if they were pluggable, but they aren't. | 15:34 |
| ignas | i 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 |
| Theuni2 | noe they're not created as if pluggable | 15:34 |
| Theuni2 | there's no pluggability there | 15:34 |
| Theuni2 | vaab: you're looking at the code and think "hey that would be easy to *make* pluggable." | 15:34 |
| Theuni2 | but that's using an implementation detail | 15:35 |
| vaab | If 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 |
| Theuni2 | again, i'm not against pluggability | 15:36 |
| Theuni2 | my point is that IMHO plugins shouldn't be opaque things | 15:36 |
| Theuni2 | because that makes interdependent subjects appear to be independent when they're not | 15:37 |
| Theuni2 | i'd be happy to make the individual features provide plugin points | 15:37 |
| Theuni2 | but again, that should be done by each requirement where pluggability is needed in a specific manner | 15:38 |
| vaab | Most 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 |
| vaab | There 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 |
| Theuni2 | Right. That's what I think will happen when we introduce pluggability step by step instead of just opening everything up for everything. | 15:40 |
| Theuni2 | the test runner needs to be *very* stable IMHO | 15:41 |
| Theuni2 | because we rely heavily on correct operation | 15:41 |
| Theuni2 | would you notice if some bug would cause 2 tests to not be run? | 15:41 |
| Theuni2 | i probably wouldn't for example | 15:41 |
| Theuni2 | because other people implement new tests, remove old tests so the number varies a lot | 15:42 |
| vaab | separating 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/s | 15:42 |
| Theuni2 | for 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 |
| Theuni2 | i bet we can make the test runner itself better to provide functionality for you directly that others can use as well | 15:43 |
| ignas | vaab, 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 |
| vaab | ignas: 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 |
| ignas | too specific? | 15:46 |
| ignas | which part of it? | 15:46 |
| ignas | is it possible to separate it into 2 parts | 15:47 |
| ignas | 1 for collecting the data you need, which might be useful to others | 15:47 |
| ignas | and the other part that outputs it in format that you like | 15:47 |
| ignas | and making the feature pluggable so you could change the output format at will | 15:47 |
| ignas | either automatically, or by providing the output formatter as a parameter | 15:48 |
| vaab | I 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 |
| ignas | like: --profile=cProfile, --test-timing=my.xml.output.thingie.that.outputs.md5 | 15:49 |
| vaab | besides, parsing zope.testing std could bring some of these info. | 15:49 |
| ignas | with default being --test-timing=zope.testing.output.without.md5 | 15:49 |
| vaab | well cProfile doesn't give you info as you which, (it contains all the zope.testing methods perf...) | 15:50 |
| ignas | i mean --profile as an example | 15:51 |
| ignas | zope.testing used to allow you to pick one of the profilers | 15:51 |
| vaab | The 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-dev | 15:51 | |
| ignas | so your timing thingie can allow people pick different timing outputs, or even write one of their own | 15:51 |
| ignas | that is useful info, even without pluggability, it might be nice to add it to the verbose output of zope.testing | 15:52 |
| *** tisto has joined #zope3-dev | 15:52 | |
| ignas | (last time my tests began taking too much time, the flaw was in test setup ;) | 15:52 |
| vaab | ignas: we are looking at test setup also... ;) | 15:53 |
| *** J1m has joined #zope3-dev | 15:53 | |
| lisppaste6 | mintsauce pasted "Failing annotations" at http://paste.lisp.org/display/90298 | 15:54 |
| mintsauce | I'm trying and failing, to access user annotations in a site generation script: | 15:54 |
| mintsauce | Identical code works fine in the rest of the site, although memberlist[member] is usually exchanged for 'context' | 15:54 |
| ignas | mintsauce, failing? what's the precise error? | 15:55 |
| mintsauce | The attempt to adapt gives the error: | 15:55 |
| mintsauce | TypeError: ('Could not adapt', <zope.principalregistry.principalregistry.UnauthenticatedPrincipal object at 0x271e650>, <InterfaceClass zope.annotation.interfaces.IAnnotations>) | 15:55 |
| mintsauce | hmmmm ... just noticed the 'UnauthenticatedPrincipal' bit in the message ... | 15:56 |
| mgedmin | ignas, useful quote: <vimgor> What happens? Did it fall asleep on your couch? Eat your homework? Destroy your harddrive? Be specific | 15:56 |
| mgedmin | a bot's response to "doesn't work" | 15:56 |
| mintsauce | :P | 15:56 |
| vaab | ignas: 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 ML | 15:56 |
| *** drudi has joined #zope3-dev | 15:58 | |
| mintsauce | can't understand where UnauthenticatedPrincipal is coming from - im running the evolve script from the zmi as manager. | 16:00 |
| *** gary_poster has joined #zope3-dev | 16:00 | |
| ignas | getUtility(IAuthentication,'',memberlist[member]) this looks "interesting" | 16:01 |
| ignas | ahh, you just don't have this habit of providing names of keyword arguments | 16:02 |
| ignas | makes the code difficult to read... | 16:02 |
| *** jfkw has joined #zope3-dev | 16:02 | |
| *** lurkymclurkleton has joined #zope3-dev | 16:03 | |
| *** lurkymclurkleton has joined #zope3-dev | 16:03 | |
| ignas | nope, can't tell you whats wrong | 16:04 |
| mintsauce | ignas: shorcut code trying to get it to work - bad habit :) | 16:04 |
| ignas | would suggest import pdb; pdb.set_tracE() | 16:04 |
| ignas | and stepping through the getPrincipal() code | 16:04 |
| ignas | also - look whether you are getting the same pau | 16:05 |
| ignas | that you are getting in your code that *works* | 16:05 |
| mintsauce | same pau is a good point - will check | 16:06 |
| ignas | also I would try doing this with setSite(new_site) finally: setSite(old_site) around, maybe someone somewhere is not passing the context along | 16:07 |
| ignas | though my guess is that the site is the same anyway | 16:08 |
| ignas | so it should not matter | 16:08 |
| *** jukart has quit IRC | 16:09 | |
| *** lamike has joined #zope3-dev | 16:10 | |
| *** lamike has left #zope3-dev | 16:10 | |
| lisppaste6 | mintsauce annotated #90298 "pau doh?" at http://paste.lisp.org/display/90298#1 | 16:20 |
| mintsauce | p_oid is same, but 'object at' different ....... does that indicate the wrong pau ignas? | 16:20 |
| ignas | if pau is the same, then - ids are not ;) | 16:21 |
| ignas | the ones you pass to getPrincipal | 16:21 |
| mintsauce | are those two paus the same then? | 16:23 |
| mintsauce | p'raps i am passing wrong principal .... that's a common mistake (for me at least) | 16:23 |
| ignas | maybe | 16:24 |
| ignas | the paus are the same | 16:24 |
| ignas | zodb does not guarantee the same object address in two different sessions for the same object | 16:24 |
| *** baijum has quit IRC | 16:43 | |
| lisppaste6 | mintsauce annotated #90298 "works" at http://paste.lisp.org/display/90298#2 | 16:53 |
| ignas | mintsauce, hmm? | 16:55 |
| ignas | does that make it work? | 16:55 |
| mintsauce | setSite does the job | 16:55 |
| mintsauce | yup | 16:55 |
| ignas | anyway | 16:56 |
| ignas | an advice | 16:56 |
| ignas | do old_site = getSite() | 16:56 |
| ignas | before the script | 16:56 |
| ignas | and add finaly: setSite(old_site) | 16:56 |
| ignas | after it | 16:56 |
| ignas | because else - if you run the script from a different site | 16:56 |
| ignas | your site will get reset | 16:56 |
| ignas | which can kill error handling utilities | 16:56 |
| ignas | (had serious problems when the site got set to None) | 16:56 |
| ignas | the traceback was trying to get written into a local error handling utility that did not exist for site "None" | 16:57 |
| ignas | also - you probably don't have to pass the context to getUtility | 16:57 |
| ignas | if global site is set | 16:57 |
| *** srichter has quit IRC | 16:57 | |
| ignas | (i am not 100% sure) | 16:57 |
| *** sm has joined #zope3-dev | 17:04 | |
| *** jhauser has quit IRC | 17:09 | |
| *** __mac__ has quit IRC | 17:11 | |
| *** sweh has quit IRC | 17:20 | |
| mintsauce | thanks for help ignas | 17:21 |
| *** mintsauce has quit IRC | 17:21 | |
| *** hazmat has joined #zope3-dev | 17:25 | |
| *** ChanServ sets mode: +o hazmat | 17:25 | |
| *** srichter has joined #zope3-dev | 17:31 | |
| *** ChanServ sets mode: +o srichter | 17:31 | |
| *** baijum has joined #zope3-dev | 17:40 | |
| *** markusleist has quit IRC | 17:45 | |
| *** ignas has quit IRC | 17:54 | |
| *** baijum has quit IRC | 17:57 | |
| *** alexdb has joined #zope3-dev | 18:10 | |
| *** reinout has quit IRC | 18:19 | |
| *** jhauser has joined #zope3-dev | 18:25 | |
| *** mintsauce has joined #zope3-dev | 18:26 | |
| mintsauce | I'm getting the following error when trying to complete a db generation, never come across it before: | 18:27 |
| mintsauce | ConnectionStateError: Shouldn't load state for 0x8f when the connection is closed | 18:27 |
| mintsauce | Is it related to the setSite/getSite advice ignas gave me earlier (which I did follow) | 18:28 |
| *** projekt01 has quit IRC | 18:28 | |
| *** redir has joined #zope3-dev | 18:38 | |
| *** pcardune has joined #zope3-dev | 18:40 | |
| *** pcardune has quit IRC | 18:49 | |
| *** J1m has quit IRC | 18:50 | |
| *** sm has quit IRC | 18:50 | |
| *** goschtl has quit IRC | 18:50 | |
| *** davisagli has joined #zope3-dev | 18:51 | |
| *** sm_ has joined #zope3-dev | 18:51 | |
| *** davisagli has quit IRC | 18:52 | |
| *** sm_ is now known as sm | 18:52 | |
| *** J1m has joined #zope3-dev | 18:54 | |
| *** MJ has quit IRC | 18:55 | |
| *** ignas has joined #zope3-dev | 19:01 | |
| *** hath|away is now known as hathawsh | 19:02 | |
| *** mintsauce has quit IRC | 19:04 | |
| *** alecm has joined #zope3-dev | 19:12 | |
| *** mgedmin has quit IRC | 19:18 | |
| *** ignas has quit IRC | 19:29 | |
| *** pcardune has joined #zope3-dev | 19:35 | |
| *** nathany has joined #zope3-dev | 19:40 | |
| *** SteveA has quit IRC | 19:42 | |
| *** SteveA has joined #zope3-dev | 19:42 | |
| *** davisagli has joined #zope3-dev | 19:42 | |
| *** mkerrin has left #zope3-dev | 19:43 | |
| *** nathany_ has joined #zope3-dev | 19:48 | |
| *** nathany has quit IRC | 19:48 | |
| *** nathany_ is now known as nathany | 19:49 | |
| *** tisto has quit IRC | 19:50 | |
| *** pcardune has quit IRC | 19:50 | |
| *** agroszer_ has joined #zope3-dev | 19:51 | |
| *** alexdb has quit IRC | 19:53 | |
| *** pcardune has joined #zope3-dev | 19:54 | |
| *** allisterb_ has joined #zope3-dev | 19:55 | |
| *** pcardune has quit IRC | 19:55 | |
| *** run|vm|winxp has quit IRC | 20:07 | |
| *** agroszer has quit IRC | 20:10 | |
| *** matthal has joined #zope3-dev | 20:11 | |
| *** allisterb has quit IRC | 20:12 | |
| *** matthal has quit IRC | 20:22 | |
| *** afd_____ has quit IRC | 20:22 | |
| *** alga has quit IRC | 20:33 | |
| *** danielblackburn has joined #zope3-dev | 20:50 | |
| *** danielblackburn is now known as danielb2|afk | 20:50 | |
| *** pcardune has joined #zope3-dev | 20:52 | |
| *** hazmat has quit IRC | 20:55 | |
| *** sweh has joined #zope3-dev | 21:07 | |
| *** jpcw has quit IRC | 21:19 | |
| *** junkafarian has quit IRC | 21:38 | |
| *** srichter_ has joined #zope3-dev | 21:46 | |
| *** srichter has quit IRC | 21:47 | |
| *** aaronv has quit IRC | 21:59 | |
| *** hazmat has joined #zope3-dev | 22:04 | |
| *** ChanServ sets mode: +o hazmat | 22:04 | |
| *** davisagli has quit IRC | 22:07 | |
| *** davisagli has joined #zope3-dev | 22:08 | |
| *** markusleist has joined #zope3-dev | 22:32 | |
| *** hathawsh is now known as hath|away | 22:33 | |
| *** hath|away is now known as hathawsh | 22:39 | |
| *** dunny has joined #zope3-dev | 22:41 | |
| *** benji has quit IRC | 22:46 | |
| *** febb has joined #zope3-dev | 22:48 | |
| *** mcdonc has quit IRC | 22:50 | |
| *** febb_ has joined #zope3-dev | 22:51 | |
| *** febb has quit IRC | 22:51 | |
| *** benji has joined #zope3-dev | 22:51 | |
| *** mcdonc has joined #zope3-dev | 22:57 | |
| *** jpcw has joined #zope3-dev | 22:58 | |
| *** drudi has quit IRC | 23:08 | |
| *** menesis has quit IRC | 23:10 | |
| *** jhauser has quit IRC | 23:10 | |
| *** aaronv has joined #zope3-dev | 23:13 | |
| *** sweh has quit IRC | 23:14 | |
| *** hathawsh is now known as hath|away | 23:17 | |
| *** agroszer_ has quit IRC | 23:27 | |
| *** redir has quit IRC | 23:29 | |
| *** redir has joined #zope3-dev | 23:31 | |
| *** srichter_ has quit IRC | 23:34 | |
| *** Theuni2 has quit IRC | 23:36 | |
| *** hath|away is now known as hathawsh | 23:42 | |
| *** menesis has joined #zope3-dev | 23:52 | |
| *** hathawsh is now known as hath|away | 23:55 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!