From lists at zopyx.com Sun Jun 1 04:55:32 2008 From: lists at zopyx.com (Andreas Jung) Date: Sun Jun 1 04:55:35 2008 Subject: [Zope-dev] setuptools extension for buildout old-style tar-balls? Message-ID: <37FD7A9F662A26DC346FD8A8@[192.168.0.24]> Hi, lots of old-style Zope products are now available as eggs. However a lot of people still don't work with buildout and need the old-style tar-balls. Does anyone know of a setuptools extension for generating and upload the tar-balls directly from a Products.XXXX package? Using the 'sdist' command is not suitable since it includes the 'Products' top-level directory which is not what we want. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080601/47641a11/attachment.bin From zope-tests at epy.co.at Sun Jun 1 07:00:15 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Sun Jun 1 07:00:19 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200806011100.m51B0F6J012605@shnoll.test.at> Summary of messages to the zope-tests list. Period Sat May 31 11:00:00 2008 UTC to Sun Jun 1 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sat May 31 20:57:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009635.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sat May 31 20:58:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009636.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sat May 31 21:00:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009637.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sat May 31 21:01:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009638.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sat May 31 21:03:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009639.html From plone at hannosch.info Sun Jun 1 08:39:15 2008 From: plone at hannosch.info (Hanno Schlichting) Date: Sun Jun 1 08:39:27 2008 Subject: [Zope-dev] Re: setuptools extension for buildout old-style tar-balls? In-Reply-To: <37FD7A9F662A26DC346FD8A8@[192.168.0.24]> References: <37FD7A9F662A26DC346FD8A8@[192.168.0.24]> Message-ID: <48429873.3000305@hannosch.info> Andreas Jung wrote: > lots of old-style Zope products are now available as eggs. However a lot > of people still don't work with buildout and need the old-style tar-balls. > > Does anyone know of a setuptools extension for generating and upload the > tar-balls directly from a Products.XXXX package? Using the 'sdist' > command is not suitable since it includes the 'Products' top-level > directory which is not what we want. Not yet, but I would be willing to help with writing one, as I could use one quite regularly. Hanno From kapil.foss at gmail.com Sun Jun 1 20:11:56 2008 From: kapil.foss at gmail.com (Kapil Thangavelu) Date: Sun Jun 1 20:11:53 2008 Subject: [Zope-dev] Zope3 on Google AppEngine In-Reply-To: References: Message-ID: <9c97bd2b0806011711n1b5e7013xec4b727a30959818@mail.gmail.com> perhaps too late to help with the sprints, but i got zope3 running on app engine last week http://zope3.appspot.com and http://zope3.appspot.com/tests, and blogged about to http://blog.kapilt.com most of zope.app isn't useable due to persistence or containment and security proxies, but page templates and the publisher work. some fairly minor but pervasive changes (removing some deprecations/bbb code) were needed, and to have space (1000 file limit) to actually develop an application requires stripping the eggs of text and tests. i ended up using the publisher support in zope.publisher (3.5.1+) instead of ore.wsgiapp or lovely.nozodb as it presents a much more minimal dependency set. i'd like to see if i can get some form machinery going underneat the 1000 file limit, and publish a starter tarball for folks interested. i'm uncertain long term what's viable, as their were a number of changes needed, and how best to maintain them. if their suitable for upstream into the zope repository, or just done again for separate releases as gae variant of z3. cheers, kapil On 5/22/08, Jodok Batlogg wrote: > Hi, > > Next week Lovely will be sprinting in New York/San Francisco to get the > Zope3 framework and the first applications running on Google AppEngine. > You're welcome to join us. > Google AppEngine is a perfect match to the transition we at Lovely Systems > made during the last 12 month in "stealth mode". > We're using heavily WSGI and are replacing ZODB within most of our > applications. > Tomorrow we're leaving to New York visiting our friend reco. dobee and I > will be working on getting the component architecture running on AppEngine. > Later next week we'll fly to San Francisco to attend Google I/O and get > even more insight to the technology. > We're open to release lovely.nozodb and the related components in near > future, as usual - just some polishing missing? > Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or > give me a call (+43 664 9636963) if you want to join us. > > jodok > -- > Lovely Systems, Partner > > phone: +43 5572 908060, fax: +43 5572 908060-77 > Schmelzh?tterstra?e 26a, 6850 Dornbirn, Austria > _ From kapil.foss at gmail.com Sun Jun 1 20:46:42 2008 From: kapil.foss at gmail.com (Kapil Thangavelu) Date: Sun Jun 1 20:46:37 2008 Subject: [Zope-dev] Component registry simplification leftovers Message-ID: <9c97bd2b0806011746x1a05022cu5b767e7508beb016@mail.gmail.com> i was setting up a z3 app with a pau utility, and noticed some strange behavior, which tracked down to, the PluggableAuthentication's getPrincipal method, source below. def getPrincipal(self, id): if not id.startswith(self.prefix): next = queryNextUtility(self, IAuthentication) if next is None: raise PrincipalLookupError(id) return next.getPrincipal(id) id = id[len(self.prefix):] for name, authplugin in self.getAuthenticatorPlugins(): info = authplugin.principalInfo(id) if info is None: continue info.credentialsPlugin = None info.authenticatorPlugin = authplugin principal = interfaces.IFoundPrincipalFactory(info)(self) principal.id = self.prefix + info.id return principal next = queryNextUtility(self, IAuthentication) if next is not None: return next.getPrincipal(self.prefix + id) raise PrincipalLookupError(id) i had setup a local site with a pau with a prefix and an ldap auth, lookups for common groups like zope.EveryBody, zope.Authenticated, would in turn call queryNextUtility. however instead of returning the global site manager's principal registry, it would fail in the utility lookup. digging deeper, the queryNextUtility call is passing in a context of the authentication utility itself, which looks like a throwback to the older IComponentLookup adaptation, instead of the current thread local site manager with bases, thats currently used. When the auth utility is passed to queryNextUtility, the default site manager whose bases are queried is the global site manager, resulting in no utility found. Where as passing context none, gives the expected behavior, of looking up the current local site's bases for the auth utility in the global site manager. it appears to me, that this is a throwback/missed refactoring from jim's merge of the component registry refactoring.. can anyone confirm the analysis and the bug? this pattern is present in multiple places in pluggable auth utility implementation, and also, zope.app.security/zope/app/security/vocabulary.py:219 cheers, kapil From zope-tests at epy.co.at Mon Jun 2 07:00:11 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Mon Jun 2 07:00:06 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200806021100.m52B0B64005446@shnoll.test.at> Summary of messages to the zope-tests list. Period Sun Jun 1 11:00:00 2008 UTC to Mon Jun 2 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sun Jun 1 21:01:57 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009640.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sun Jun 1 21:03:28 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009641.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sun Jun 1 21:04:58 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009642.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sun Jun 1 21:06:33 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009643.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sun Jun 1 21:08:03 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009644.html From mgedmin at b4net.lt Mon Jun 2 08:05:26 2008 From: mgedmin at b4net.lt (Marius Gedminas) Date: Mon Jun 2 08:05:23 2008 Subject: [Zope-dev] Re: zope.sqlalchemy, integration ideas In-Reply-To: References: <20080530133618.GA12051@brian-sutherlands-macbook.local> <20080530174030.GB7291@brian-sutherlands-macbook.local> Message-ID: <20080602120526.GA10885@platonas> On Fri, May 30, 2008 at 01:55:44PM -0400, Benji York wrote: > On Fri, May 30, 2008 at 1:40 PM, Brian Sutherland > wrote: > > I've just decided to jettison IAbsoluteURL and make a new interface > > ICanonicalURL. The adapters for ICanonicalURL are available anywhere > > without specially wrapping the object in a location proxy. > > IAbsoluteURL doesn't neccesarily require a location proxy, it's just that the > default implementations require objects to implement ILocation. > > No need to define your own interface, just override the IAbsoluteURL > implementation(s) you don't like to behave differently (or better yet, don't > let them get registered in the first place). One thing I don't like about the default implementation is that if you override IAbsoluteURL for a container, it has no effect for contained objects. I suppose there's a good reason for that -- efficiency -- but it often makes custom IAbsoluteURL adapters pointless. LocationProxy helps then. Marius Gedminas -- Photons have energy, and trying to cram too many into too small of a space can cause a black hole to form, which is, needless to say, not a desirable trait for an optical computer. -- http://scottaaronson.com/blog/?p=261#comment-13693 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080602/24b437e0/attachment-0001.bin From fairwinds at eastlink.ca Mon Jun 2 08:09:38 2008 From: fairwinds at eastlink.ca (David Pratt) Date: Mon Jun 2 08:09:34 2008 Subject: [Zope-dev] Zope3 on Google AppEngine In-Reply-To: <9c97bd2b0806011711n1b5e7013xec4b727a30959818@mail.gmail.com> References: <9c97bd2b0806011711n1b5e7013xec4b727a30959818@mail.gmail.com> Message-ID: <4843E302.7080204@eastlink.ca> Interesting post. I am still not sure to what level I'll look to Google for app infrastructure. Seems to me there are too many restrictions on what you'd really be able to deploy and then you're stuck with married to what they've got for better or worse. On the other hand, Stripping zope to the minimum has certainly been an eye opener and certainly beneficial to get to a bare bones idea of what you could run with (with or without Google) though. Many thanks for sharing your efforts on this. Regards, David Kapil Thangavelu wrote: > perhaps too late to help with the sprints, but i got zope3 running on > app engine last week http://zope3.appspot.com and > http://zope3.appspot.com/tests, and blogged about to > http://blog.kapilt.com > > most of zope.app isn't useable due to persistence or containment and > security proxies, but page templates and the publisher work. some > fairly minor but pervasive changes (removing some deprecations/bbb > code) were needed, and to have space (1000 file limit) to actually > develop an application requires stripping the eggs of text and tests. > i ended up using the publisher support in zope.publisher (3.5.1+) > instead of ore.wsgiapp or lovely.nozodb as it presents a much more > minimal dependency set. > > i'd like to see if i can get some form machinery going underneat the > 1000 file limit, and publish a starter tarball for folks interested. > > i'm uncertain long term what's viable, as their were a number of > changes needed, and how best to maintain them. if their suitable for > upstream into the zope repository, or just done again for separate > releases as gae variant of z3. > > cheers, > > kapil > > On 5/22/08, Jodok Batlogg wrote: >> Hi, >> >> Next week Lovely will be sprinting in New York/San Francisco to get the >> Zope3 framework and the first applications running on Google AppEngine. >> You're welcome to join us. >> Google AppEngine is a perfect match to the transition we at Lovely Systems >> made during the last 12 month in "stealth mode". >> We're using heavily WSGI and are replacing ZODB within most of our >> applications. >> Tomorrow we're leaving to New York visiting our friend reco. dobee and I >> will be working on getting the component architecture running on AppEngine. >> Later next week we'll fly to San Francisco to attend Google I/O and get >> even more insight to the technology. >> We're open to release lovely.nozodb and the related components in near >> future, as usual - just some polishing missing? >> Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or >> give me a call (+43 664 9636963) if you want to join us. >> >> jodok >> -- >> Lovely Systems, Partner >> >> phone: +43 5572 908060, fax: +43 5572 908060-77 >> Schmelzh?tterstra?e 26a, 6850 Dornbirn, Austria >> _ > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > From faassen at startifact.com Mon Jun 2 09:40:42 2008 From: faassen at startifact.com (Martijn Faassen) Date: Mon Jun 2 09:41:00 2008 Subject: [Zope-dev] status of buildout.zope.org Message-ID: Hi there, So, what's the status of buildout.zope.org? It's not up and running yet. What's holding it up? Can I do something to help? (I won't actually do anything about the content or layout, but I can talk to people if it's somehow blocked) I mean, the initial site doesn't need to be much more work than, say, asking Rene Dudfield for permission to reuse his recent blog entry and dropping into some website with a reasonable layout, and then telling people what to do if they want to add content. http://renesd.blogspot.com/2008/05/buildout-tutorial-buildout-howto.html There's plenty of good content on buildout available, just gather it and put it into a single site. Regards, Martijn From dusty at qwer.tk Mon Jun 2 14:04:51 2008 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Mon Jun 2 14:05:02 2008 Subject: [Zope-dev] Strange serializing error when commiting Message-ID: <200806022004.51952.dusty@qwer.tk> Hi, In my zope3 tests, I set up some basic test data. After that, I'm calling transaction.commit(). However, I get the following traceback: --------------- snip ------------------- Error in test /home/dusty/prog/zope3-inst/lib/python/zbsp/tests/../auth.txt Traceback (most recent call last): File "/local/home/dusty/python/Python-2.4.4/lib/python2.4/unittest.py", line 251, in run self.setUp() File "/local/home/dusty/Zope-3.4.0c1/lib/python/zope/testing/doctest.py", line 2283, in setUp self._dt_setUp(test) File "/local/home/dusty/Zope-3.4.0c1/lib/python/zope/app/testing/functional.py", line 739, in setUp kwsetUp(test) File "/home/dusty/prog/zope3-inst/lib/python/zbsp/tests/test_doc.py", line 141, in setUp commit() File "/local/home/dusty/Zope-3.4.0c1/lib/python/transaction/_manager.py", line 93, in commit return self.get().commit() File "/local/home/dusty/Zope-3.4.0c1/lib/python/transaction/_transaction.py", line 325, in commit self._commitResources() File "/local/home/dusty/Zope-3.4.0c1/lib/python/transaction/_transaction.py", line 424, in _commitResources rm.commit(self) File "/local/home/dusty/Zope-3.4.0c1/lib/python/ZODB/Connection.py", line 541, in commit self._commit(transaction) File "/local/home/dusty/Zope-3.4.0c1/lib/python/ZODB/Connection.py", line 586, in _commit self._store_objects(ObjectWriter(obj), transaction) File "/local/home/dusty/Zope-3.4.0c1/lib/python/ZODB/Connection.py", line 613, in _store_objects p = writer.serialize(obj) # This calls __getstate__ of obj File "/local/home/dusty/Zope-3.4.0c1/lib/python/ZODB/serialize.py", line 407, in serialize return self._dump(meta, obj.__getstate__()) File "/local/home/dusty/Zope-3.4.0c1/lib/python/ZODB/serialize.py", line 416, in _dump self._p.dump(state) File "copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle module objects ------------------ snip ------------------- Does anyone know what this means and what I can do against it? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 From dusty at qwer.tk Mon Jun 2 19:10:12 2008 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Mon Jun 2 19:10:12 2008 Subject: [Zope-dev] Strange serializing error when commiting -> zope.sqlalchemy In-Reply-To: <200806022004.51952.dusty@qwer.tk> References: <200806022004.51952.dusty@qwer.tk> Message-ID: <200806030110.12978.dusty@qwer.tk> Am Montag, 2. Juni 2008 20:04 schrieb Hermann Himmelbauer: > Hi, > In my zope3 tests, I set up some basic test data. After that, I'm calling > transaction.commit(). However, I get the following traceback: > > > --------------- snip ------------------- > File "copy_reg.py", line 69, in _reduce_ex > raise TypeError, "can't pickle %s objects" % base.__name__ > TypeError: can't pickle module objects > ------------------ snip ------------------- I found it by myself: I registered a zope.sqlalchemy related utility, which stores an engine (self.engine = create_engine(DSN,...)) and a scoped session (self.Session = scoped_session(sessionmaker...)). These two objects cannot be serialized, hence the above problem. Now I'm unsure what to do about this problem - is there any code available that demonstrates how to register SA engines/Sessions as utilities? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 From mbaiju at zeomega.com Tue Jun 3 05:22:59 2008 From: mbaiju at zeomega.com (Baiju M) Date: Tue Jun 3 05:23:08 2008 Subject: [Zope-dev] status of buildout.zope.org In-Reply-To: References: Message-ID: <48450D73.6090504@zeomega.com> Martijn Faassen wrote: > Hi there, > > So, what's the status of buildout.zope.org? > > It's not up and running yet. What's holding it up? Can I do something > to help? (I won't actually do anything about the content or layout, > but I can talk to people if it's somehow blocked) We are still working on it. A site with content & basic design will be ready by next week. > I mean, the initial site doesn't need to be much more work than, say, > asking Rene Dudfield for permission to reuse his recent blog entry > and dropping into some website with a reasonable layout, and then > telling people what to do if they want to add content. > > http://renesd.blogspot.com/2008/05/buildout-tutorial-buildout-howto.html > > > There's plenty of good content on buildout available, just gather it > and put it into a single site. I will post details about adding content soon after the site is up and running. Regards, Baiju M From l at lrowe.co.uk Tue Jun 3 06:18:58 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Tue Jun 3 06:19:07 2008 Subject: [Zope-dev] Re: Strange serializing error when commiting -> zope.sqlalchemy In-Reply-To: <200806030110.12978.dusty@qwer.tk> References: <200806022004.51952.dusty@qwer.tk> <200806030110.12978.dusty@qwer.tk> Message-ID: Hermann Himmelbauer wrote: > Am Montag, 2. Juni 2008 20:04 schrieb Hermann Himmelbauer: >> Hi, >> In my zope3 tests, I set up some basic test data. After that, I'm calling >> transaction.commit(). However, I get the following traceback: >> >> >> --------------- snip ------------------- >> File "copy_reg.py", line 69, in _reduce_ex >> raise TypeError, "can't pickle %s objects" % base.__name__ >> TypeError: can't pickle module objects >> ------------------ snip ------------------- > > I found it by myself: I registered a zope.sqlalchemy related utility, which > stores an engine (self.engine = create_engine(DSN,...)) and a scoped session > (self.Session = scoped_session(sessionmaker...)). These two objects cannot be > serialized, hence the above problem. > > Now I'm unsure what to do about this problem - is there any code available > that demonstrates how to register SA engines/Sessions as utilities? The simplest solution is to register the Session object as a global utility. Laurence From l at lrowe.co.uk Tue Jun 3 06:21:25 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Tue Jun 3 06:25:00 2008 Subject: [Zope-dev] Re: Strange serializing error when commiting -> zope.sqlalchemy In-Reply-To: References: <200806022004.51952.dusty@qwer.tk> <200806030110.12978.dusty@qwer.tk> Message-ID: Laurence Rowe wrote: > Hermann Himmelbauer wrote: >> Am Montag, 2. Juni 2008 20:04 schrieb Hermann Himmelbauer: >>> Hi, >>> In my zope3 tests, I set up some basic test data. After that, I'm >>> calling >>> transaction.commit(). However, I get the following traceback: >>> >>> >>> --------------- snip ------------------- >>> File "copy_reg.py", line 69, in _reduce_ex >>> raise TypeError, "can't pickle %s objects" % base.__name__ >>> TypeError: can't pickle module objects >>> ------------------ snip ------------------- >> >> I found it by myself: I registered a zope.sqlalchemy related utility, >> which stores an engine (self.engine = create_engine(DSN,...)) and a >> scoped session (self.Session = scoped_session(sessionmaker...)). These >> two objects cannot be serialized, hence the above problem. >> >> Now I'm unsure what to do about this problem - is there any code >> available that demonstrates how to register SA engines/Sessions as >> utilities? > > The simplest solution is to register the Session object as a global > utility. Though that would be quite unnecessary too ;-). If you are ok with one global scoped session for your app, then just use `from mymodule import Session; session = Session()`. Laurence From faassen at startifact.com Tue Jun 3 06:53:29 2008 From: faassen at startifact.com (Martijn Faassen) Date: Tue Jun 3 06:53:24 2008 Subject: [Zope-dev] status of buildout.zope.org In-Reply-To: <48450D73.6090504@zeomega.com> References: <48450D73.6090504@zeomega.com> Message-ID: <8928d4e90806030353u4ad31b90hbbb6a95d55812aef@mail.gmail.com> Hi there, On Tue, Jun 3, 2008 at 11:22 AM, Baiju M wrote: > Martijn Faassen wrote: >> So, what's the status of buildout.zope.org? >> >> It's not up and running yet. What's holding it up? Can I do something >> to help? (I won't actually do anything about the content or layout, >> but I can talk to people if it's somehow blocked) > > We are still working on it. A site with content & basic design will be > ready by next week. Great to hear! Regards, Martijn From zope-tests at epy.co.at Tue Jun 3 07:00:10 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Tue Jun 3 07:00:09 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200806031100.m53B0Ap8011926@shnoll.test.at> Summary of messages to the zope-tests list. Period Mon Jun 2 11:00:00 2008 UTC to Tue Jun 3 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Mon Jun 2 20:57:27 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009645.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon Jun 2 20:59:03 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009646.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon Jun 2 21:00:33 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009647.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon Jun 2 21:02:09 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009648.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon Jun 2 21:03:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009649.html From dusty at qwer.tk Tue Jun 3 08:00:32 2008 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Tue Jun 3 08:00:32 2008 Subject: [Zope-dev] Re: Strange serializing error when commiting -> zope.sqlalchemy In-Reply-To: References: <200806022004.51952.dusty@qwer.tk> Message-ID: <200806031400.32654.dusty@qwer.tk> Am Dienstag, 3. Juni 2008 12:21 schrieb Laurence Rowe: > Laurence Rowe wrote: > >> I found it by myself: I registered a zope.sqlalchemy related utility, > >> which stores an engine (self.engine = create_engine(DSN,...)) and a > >> scoped session (self.Session = scoped_session(sessionmaker...)). These > >> two objects cannot be serialized, hence the above problem. > >> > >> Now I'm unsure what to do about this problem - is there any code > >> available that demonstrates how to register SA engines/Sessions as > >> utilities? > > > > The simplest solution is to register the Session object as a global > > utility. > > Though that would be quite unnecessary too ;-). If you are ok with one > global scoped session for your app, then just use `from mymodule import > Session; session = Session()`. Hmmm, it's not that easy: I have multiple sites on one Zope3 instance, whereas every site should connect to another database. For that reason, I thought about a local utility. However, this results in this serialization error. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 From mborch at gmail.com Tue Jun 3 08:52:20 2008 From: mborch at gmail.com (Malthe Borch) Date: Tue Jun 3 08:52:29 2008 Subject: [Zope-dev] Buildout parameter parsing Message-ID: <48453E84.2050306@gmail.com> I think a valuable extension to the parameter parsing in buildout's configuration language would be to allow += and -= operators, which would append and remove items, respectively. Example: [instance] eggs += Products.PDBDebugMode Singular or plural arguments would be supported. \malthe From ziade.tarek at gmail.com Tue Jun 3 10:19:27 2008 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Tue Jun 3 10:19:24 2008 Subject: [Zope-dev] Five, Z2 publisher, and zope.traversing views Message-ID: <94bdd2610806030719s1b4674e8t8fdb3c41fb3e8dfc@mail.gmail.com> Hi, When using a resource directory in a Zope 2 app, if the directory contains subdirectories that have the same names than the views defined in zope.traversing, this will lead to a bug when traversed because the Z2 Publisher will get slaped back. This can happen for example if your resourcedirectoy has a "lang" folder (or "vh" or "skin", etc..) We have wrote a small package with an adapter to make it work: http://ingeniweb.svn.sourceforge.net/svnroot/ingeniweb/iw.resourcetraverser/trunk/iw/resourcetraverser/README.txt But my understanding is that it would be better to fix it in Five, Opinions ? Regards, Tarek -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.zope.org/pipermail/zope-dev/attachments/20080603/59892d77/attachment.html From l at lrowe.co.uk Tue Jun 3 10:57:44 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Tue Jun 3 10:57:40 2008 Subject: [Zope-dev] Re: Strange serializing error when commiting -> zope.sqlalchemy In-Reply-To: <200806031400.32654.dusty@qwer.tk> References: <200806022004.51952.dusty@qwer.tk> <200806031400.32654.dusty@qwer.tk> Message-ID: See the long discussion on zope.sqlalchemy Integration ideas. I think the simplest way to achieve this is to register a global utility for each site, with the site name as the utility name perhaps. You can then register an ISession adapter for the root object in each site that does: session = getUtility(ISessionContext, name=sitename)() Also sqlalchemy.orm.session.object_session can be used to return the session of a currently mapped object. You could register it as an adapter for ISession too, and then ISession(context) should return the session wherever you need it. Laurence 2008/6/3 Hermann Himmelbauer : > Am Dienstag, 3. Juni 2008 12:21 schrieb Laurence Rowe: >> Laurence Rowe wrote: >> >> I found it by myself: I registered a zope.sqlalchemy related utility, >> >> which stores an engine (self.engine = create_engine(DSN,...)) and a >> >> scoped session (self.Session = scoped_session(sessionmaker...)). These >> >> two objects cannot be serialized, hence the above problem. >> >> >> >> Now I'm unsure what to do about this problem - is there any code >> >> available that demonstrates how to register SA engines/Sessions as >> >> utilities? >> > >> > The simplest solution is to register the Session object as a global >> > utility. >> >> Though that would be quite unnecessary too ;-). If you are ok with one >> global scoped session for your app, then just use `from mymodule import >> Session; session = Session()`. > > Hmmm, it's not that easy: I have multiple sites on one Zope3 instance, whereas > every site should connect to another database. For that reason, I thought > about a local utility. However, this results in this serialization error. > > Best Regards, > Hermann > > -- > hermann@qwer.tk > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > From rafaelbco at gmail.com Tue Jun 3 12:02:00 2008 From: rafaelbco at gmail.com (Rafael Oliveira) Date: Tue Jun 3 12:01:56 2008 Subject: [Zope-dev] Buildout parameter parsing In-Reply-To: <48453E84.2050306@gmail.com> References: <48453E84.2050306@gmail.com> Message-ID: On Tue, Jun 3, 2008 at 9:52 AM, Malthe Borch wrote: > I think a valuable extension to the parameter parsing in buildout's > configuration language would be to allow += and -= operators, which would > append and remove items, respectively. > > Example: > > [instance] > eggs += Products.PDBDebugMode > > Singular or plural arguments would be supported. It would be very useful when used together with "extends". Example (taken from [1]). You have a base.cfg: """ [instance] eggs = PILwoTK lxml > 2.0 zope.testing == 3.5 """ And you want to write a development.cfg, which adds a new egg for debugging. Currently you have to do: """ [buildout] extends = base.cfg [instance] eggs = PILwoTK lxml > 2.0 zope.testing == 3.5 Products.PDBDebugMode """ With the new operator you could simplify it to: """ [buildout] extends = base.cfg [instance] eggs += Products.PDBDebugMode """ Tell me if I misunderstood the idea. [1] https://svn.infrae.com/buildout/silva/trunk/profiles/ Regards, -- Rafael Bruno Cavalhero de Oliveira Analista de Sistemas - Paradigma Mestrando em Ci?ncia da Informa??o - UFMG http://rafaelb.objectis.net From philipp at weitershausen.de Tue Jun 3 12:09:59 2008 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Tue Jun 3 12:10:16 2008 Subject: [Zope-dev] Re: Buildout parameter parsing In-Reply-To: <48453E84.2050306@gmail.com> References: <48453E84.2050306@gmail.com> Message-ID: <48456CD7.5070003@weitershausen.de> Malthe Borch wrote: > I think a valuable extension to the parameter parsing in buildout's > configuration language would be to allow += and -= operators, which > would append and remove items, respectively. > > Example: > > [instance] > eggs += Products.PDBDebugMode > > Singular or plural arguments would be supported. > > \malthe This isn't the buildout list :). I think buildout matters are discussed on the distutils SIG mailinglist. There's also an issue tracker at https://edge.launchpad.net/zc.buildout. From mborch at gmail.com Tue Jun 3 12:31:23 2008 From: mborch at gmail.com (Malthe Borch) Date: Tue Jun 3 12:31:30 2008 Subject: [Zope-dev] Re: Buildout parameter parsing In-Reply-To: <48456CD7.5070003@weitershausen.de> References: <48453E84.2050306@gmail.com> <48456CD7.5070003@weitershausen.de> Message-ID: <484571DB.3050608@gmail.com> Philipp von Weitershausen wrote: > This isn't the buildout list :). I think buildout matters are discussed > on the distutils SIG mailinglist. I guess they're also discussed here now :P > There's also an issue tracker at > https://edge.launchpad.net/zc.buildout. I'll submit it there, thanks. \malthe From mborch at gmail.com Tue Jun 3 12:34:03 2008 From: mborch at gmail.com (Malthe Borch) Date: Tue Jun 3 12:34:57 2008 Subject: [Zope-dev] Re: Buildout parameter parsing In-Reply-To: <48453E84.2050306@gmail.com> References: <48453E84.2050306@gmail.com> Message-ID: <4845727B.7090202@gmail.com> This is now: https://answers.edge.launchpad.net/zc.buildout/+question/35159 From mborch at gmail.com Tue Jun 3 13:16:41 2008 From: mborch at gmail.com (Malthe Borch) Date: Tue Jun 3 13:16:48 2008 Subject: [Zope-dev] DirectoryResource, Five and IAbsoluteURL Message-ID: These three don't mix well; here's the setup: Using ``zope.traversing.api.traverse``, we're able to traverse from the site root to the directory resource, and on to the actual resource by way of OFS.Traversable. However, trying to get the absolute url of the resource fails, and it seems to be an acquisition-wrapping thing. We're in ``Products.Five.browser.resource.Resource``, and the directory resource has the following aq_chain: [, , ] A lethal cocktail. Can anyone shed light on this issue? \malthe From mborch at gmail.com Tue Jun 3 13:28:57 2008 From: mborch at gmail.com (Malthe Borch) Date: Tue Jun 3 13:28:59 2008 Subject: [Zope-dev] Re: DirectoryResource, Five and IAbsoluteURL In-Reply-To: References: Message-ID: Malthe Borch wrote: > However, trying to get the absolute url of the resource fails, and it > seems to be an acquisition-wrapping thing. FWIW, this adapter will do the trick, although it's hardly a solid solution: class SimpleResourceAbsoluteURL(object): interface.implements( zope.traversing.browser.interfaces.IAbsoluteURL) component.adapts( Products.Five.browser.resource.DirectoryResource, zope.publisher.interfaces.browser.IDefaultBrowserLayer) def __init__(self, context, request): self.context = context def __str__(self): return self.context() \malthe From dieter at handshake.de Tue Jun 3 14:47:37 2008 From: dieter at handshake.de (Dieter Maurer) Date: Tue Jun 3 14:47:52 2008 Subject: [Zope-dev] Re: Strange serializing error when commiting -> zope.sqlalchemy In-Reply-To: <200806031400.32654.dusty@qwer.tk> References: <200806022004.51952.dusty@qwer.tk> <200806031400.32654.dusty@qwer.tk> Message-ID: <18501.37321.623942.282774@gargle.gargle.HOWL> Hermann Himmelbauer wrote at 2008-6-3 14:00 +0200: > ... >Hmmm, it's not that easy: I have multiple sites on one Zope3 instance, whereas >every site should connect to another database. For that reason, I thought >about a local utility. However, this results in this serialization error. Usually, you should not commit in a test suite. If you do not commit, you will not have pickling problems. -- Dieter From shane at hathawaymix.org Wed Jun 4 02:01:32 2008 From: shane at hathawaymix.org (Shane Hathaway) Date: Wed Jun 4 02:01:33 2008 Subject: [Zope-dev] Deciphering Zope Comments Message-ID: <48462FBC.7070003@hathawaymix.org> Hi all, I'm trying to get a handle on Zope 3. I plan to take a bunch of Zope 3 modules and combine them in a new way. The goal is to create for myself a comfortable working environment that lets me run simple code in a small mod_wsgi environment with easy reloading and no ZODB initially. To achieve this, I need to understand what's going on in the Zope 3 code base. While the code itself is easy to understand, there are many comments in the code that suggest changes are coming soon. Please help me figure out what is meant by these comments. The first cryptic comment comes from zope.component. The _api module starts with this gem: # SiteManager API. This needs to get deprecated eventually. But... um... everything in the module uses getSiteManager(). The whole component foundation is built on it. When is it going to be replaced? With what? By whom? I'm assuming for the moment that the comment is a lie, and that getSiteManager() is not going away, since otherwise I have no foundation to build upon. I think I want to use a threading.local as my site manager. That way, I can use a different configuration for each WSGI app even if several apps run in different threads of a single Python interpreter. It looks like the zope.app.component.hooks module does something like what I want, but that module is complicated and lacks comments in the places that matter, so I'm not quite sure what it accomplishes. I'll add comments to that module if anyone can explain it fully. That led me to the zope.thread module, which is apparently deprecated already, yet zope.app.component still depends on it. Is that an hysterical accident? Shane From wichert at wiggy.net Wed Jun 4 03:40:18 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Wed Jun 4 03:40:19 2008 Subject: [Zope-dev] Deciphering Zope Comments In-Reply-To: <48462FBC.7070003@hathawaymix.org> References: <48462FBC.7070003@hathawaymix.org> Message-ID: <20080604074018.GA3812@wiggy.net> Previously Shane Hathaway wrote: > I think I want to use a threading.local as my site manager. That way, I > can use a different configuration for each WSGI app even if several apps > run in different threads of a single Python interpreter. It looks like > the zope.app.component.hooks module does something like what I want, but > that module is complicated and lacks comments in the places that matter, > so I'm not quite sure what it accomplishes. I'll add comments to that > module if anyone can explain it fully. You can also use a paste.registry StackedObjectProxy to provide access to a thread local site manager via the standard wsgi environ. That certainly fits well with the WSGI model and other frameworks such as Pylons and Turbogears use it. I'm not sure if Zope3 exposes that properly though. Admitedly paste.registry is not the best documented code either; some cleanup there is still useful but the ideal model has not been worked out yet. > That led me to the zope.thread module, which is apparently deprecated > already, yet zope.app.component still depends on it. Is that an > hysterical accident? I only learned yesterday that zope.thread is now basically just a wrapper around python 2.4's threading module so you can use that directly. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From shane at hathawaymix.org Wed Jun 4 04:16:22 2008 From: shane at hathawaymix.org (Shane Hathaway) Date: Wed Jun 4 04:16:19 2008 Subject: [Zope-dev] Deciphering Zope Comments In-Reply-To: <20080604074018.GA3812@wiggy.net> References: <48462FBC.7070003@hathawaymix.org> <20080604074018.GA3812@wiggy.net> Message-ID: <48464F56.60002@hathawaymix.org> Wichert Akkerman wrote: > Previously Shane Hathaway wrote: >> I think I want to use a threading.local as my site manager. That way, I >> can use a different configuration for each WSGI app even if several apps >> run in different threads of a single Python interpreter. It looks like >> the zope.app.component.hooks module does something like what I want, but >> that module is complicated and lacks comments in the places that matter, >> so I'm not quite sure what it accomplishes. I'll add comments to that >> module if anyone can explain it fully. > > You can also use a paste.registry StackedObjectProxy to provide access > to a thread local site manager via the standard wsgi environ. That > certainly fits well with the WSGI model and other frameworks such as > Pylons and Turbogears use it. I'm not sure if Zope3 exposes that > properly though. Admitedly paste.registry is not the best documented > code either; some cleanup there is still useful but the ideal model has > not been worked out yet. Thanks for the pointer. I'm not quite sure how StackedObjectProxy might fit in, but if it turns out I need it, at least now I don't have to rewrite it. >> That led me to the zope.thread module, which is apparently deprecated >> already, yet zope.app.component still depends on it. Is that an >> hysterical accident? > > I only learned yesterday that zope.thread is now basically just a > wrapper around python 2.4's threading module so you can use that > directly. Fred Drake also confirmed that nothing needs to use zope.thread anymore. I plan to clean it up. Shane From zope-tests at epy.co.at Wed Jun 4 07:00:06 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Wed Jun 4 07:00:02 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200806041100.m54B06Qt031576@shnoll.test.at> Summary of messages to the zope-tests list. Period Tue Jun 3 11:00:00 2008 UTC to Wed Jun 4 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Jun 3 20:54:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009650.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 20:55:46 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009651.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 20:57:17 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009652.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 20:58:47 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009653.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Jun 3 21:00:17 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009654.html From srichter at cosmos.phy.tufts.edu Wed Jun 4 08:39:28 2008 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Wed Jun 4 08:39:37 2008 Subject: [Zope-dev] Deciphering Zope Comments In-Reply-To: <48462FBC.7070003@hathawaymix.org> References: <48462FBC.7070003@hathawaymix.org> Message-ID: <200806040539.28366.srichter@cosmos.phy.tufts.edu> On Tuesday 03 June 2008, Shane Hathaway wrote: > # SiteManager API. This needs to get deprecated eventually. > > But... um... everything in the module uses getSiteManager(). ?The whole > component foundation is built on it. ?When is it going to be replaced? > With what? ?By whom? This is a result of the big zope component cleanup. I forgot the details. Jim would be the best person to answer this. If he does not know, we should just remove the comment. :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" From philipp at weitershausen.de Wed Jun 4 09:05:18 2008 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Wed Jun 4 09:05:16 2008 Subject: [Zope-dev] Re: Deciphering Zope Comments In-Reply-To: <48462FBC.7070003@hathawaymix.org> References: <48462FBC.7070003@hathawaymix.org> Message-ID: <4846930E.3010707@weitershausen.de> Shane Hathaway wrote: > Hi all, > > I'm trying to get a handle on Zope 3. I plan to take a bunch of Zope 3 > modules and combine them in a new way. The goal is to create for myself > a comfortable working environment that lets me run simple code in a > small mod_wsgi environment with easy reloading and no ZODB initially. > > To achieve this, I need to understand what's going on in the Zope 3 code > base. While the code itself is easy to understand, there are many > comments in the code that suggest changes are coming soon. Please help > me figure out what is meant by these comments. > > The first cryptic comment comes from zope.component. The _api module > starts with this gem: > > # SiteManager API. This needs to get deprecated eventually. I think this meant to say that the word "Site Manager" has been deprecated. Nowadays we just say component registry. In theory. I think we just found that renaming things isn't worth all the trouble. > But... um... everything in the module uses getSiteManager(). The whole > component foundation is built on it. When is it going to be replaced? > With what? By whom? I think the comment can go. It's the opposite of useful right now. > I'm assuming for the moment that the comment is a lie, and that > getSiteManager() is not going away, since otherwise I have no foundation > to build upon. Yup. > I think I want to use a threading.local as my site manager. That way, I > can use a different configuration for each WSGI app even if several apps > run in different threads of a single Python interpreter. It looks like > the zope.app.component.hooks module does something like what I want, but > that module is complicated and lacks comments in the places that matter, > so I'm not quite sure what it accomplishes. I'll add comments to that > module if anyone can explain it fully. zope.component.getSiteManager() is a "hooked" function (using zope.hookable). That means it can be replaced by some other implementation. zope.app.component.hooks makes use of that. It replaces zope.component.getSiteManager() with an implementation that looks up a thread local variable (SiteInfo). This replacement is done in the setHooks() function which is called some time during Zope startup. > That led me to the zope.thread module, which is apparently deprecated > already, yet zope.app.component still depends on it. Is that an > hysterical accident? As said previously, zope.thread.local is just a wrapper around Python's threading.local module (which was contributed by Jim based on zope.thread.local). From dusty at qwer.tk Wed Jun 4 12:02:13 2008 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Wed Jun 4 12:02:15 2008 Subject: [Zope-dev] SQLAlchemy (zope.sqlalchemy) integration Message-ID: <200806041802.13622.dusty@qwer.tk> Hi, Regarding to the discussion some days ago with the SQLAlchemy Zope3 integration, I still have problems with retrieving the session. I currently use a utility for the engine, which seems to work well. However, for retrieving the session, I tried to use the following pattern (many thanks to Michael Bayer, btw.): -------- database module ----------- SASession = scoped_session(sessionmaker( transactional = True, autoflush = True, extension = ZopeTransactionExtension())) def getSASession(): SASession.remove() engine = getUtility(ISAEngineUtility).getEngine() s = SASession() s.bind = engine return s -------------------------------------------- In my application, I then use getSASession() to retrieve my session. However, what I think is not that beautiful is the "s.bind = engine" part. Are there any suggestions how to improve this? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 From mike_mp at zzzcomputing.com Wed Jun 4 14:20:19 2008 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Wed Jun 4 14:20:16 2008 Subject: [Zope-dev] SQLAlchemy (zope.sqlalchemy) integration In-Reply-To: <200806041802.13622.dusty@qwer.tk> References: <200806041802.13622.dusty@qwer.tk> Message-ID: <43521135-A708-41C9-8484-D94AA0BAD2D6@zzzcomputing.com> On Jun 4, 2008, at 12:02 PM, Hermann Himmelbauer wrote: > Hi, > Regarding to the discussion some days ago with the SQLAlchemy Zope3 > integration, I still have problems with retrieving the session. I > currently > use a utility for the engine, which seems to work well. > > However, for retrieving the session, I tried to use the following > pattern > (many thanks to Michael Bayer, btw.): > > -------- database module ----------- > SASession = scoped_session(sessionmaker( > transactional = True, > autoflush = True, > extension = ZopeTransactionExtension())) > > def getSASession(): > SASession.remove() > engine = getUtility(ISAEngineUtility).getEngine() > s = SASession() > s.bind = engine > return s > -------------------------------------------- > > In my application, I then use getSASession() to retrieve my session. > > However, what I think is not that beautiful is the "s.bind = engine" > part. Are > there any suggestions how to improve this? FTR, my suggestion here is to configure/tear down sessions upon request boundaries, as described in http://www.sqlalchemy.org/docs/04/session.html#unitofwork_contextual_lifespan . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.zope.org/pipermail/zope-dev/attachments/20080604/aca0dffc/attachment.html From dieter at handshake.de Wed Jun 4 14:28:07 2008 From: dieter at handshake.de (Dieter Maurer) Date: Wed Jun 4 14:28:25 2008 Subject: [Zope-dev] Deciphering Zope Comments In-Reply-To: <48462FBC.7070003@hathawaymix.org> References: <48462FBC.7070003@hathawaymix.org> Message-ID: <18502.57015.182641.552106@gargle.gargle.HOWL> Shane Hathaway wrote at 2008-6-4 00:01 -0600: > ... ># SiteManager API. This needs to get deprecated eventually. > >But... um... everything in the module uses getSiteManager(). The whole >component foundation is built on it. When is it going to be replaced? >With what? By whom? > >I'm assuming for the moment that the comment is a lie, and that >getSiteManager() is not going away, since otherwise I have no foundation >to build upon. I, too, hope (and expect) so. >I think I want to use a threading.local as my site manager. That way, I >can use a different configuration for each WSGI app even if several apps >run in different threads of a single Python interpreter. It looks like >the zope.app.component.hooks module does something like what I want, but >that module is complicated and lacks comments in the places that matter, >so I'm not quite sure what it accomplishes. I'll add comments to that >module if anyone can explain it fully. > >That led me to the zope.thread module, which is apparently deprecated >already, yet zope.app.component still depends on it. Is that an >hysterical accident? As I have read, thread local variables have been invented and implemented in Zope 3 land and donated to Python. Now, that it is in Python, the original Zope implementation can go away. Maybe, that is the purpose of the "zope.thread" module? -- Dieter From l at lrowe.co.uk Wed Jun 4 16:09:23 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed Jun 4 16:09:40 2008 Subject: [Zope-dev] Re: SQLAlchemy (zope.sqlalchemy) integration In-Reply-To: <200806041802.13622.dusty@qwer.tk> References: <200806041802.13622.dusty@qwer.tk> Message-ID: Hermann Himmelbauer wrote: > Hi, > Regarding to the discussion some days ago with the SQLAlchemy Zope3 > integration, I still have problems with retrieving the session. I currently > use a utility for the engine, which seems to work well. > > However, for retrieving the session, I tried to use the following pattern > (many thanks to Michael Bayer, btw.): > > -------- database module ----------- > SASession = scoped_session(sessionmaker( > transactional = True, > autoflush = True, > extension = ZopeTransactionExtension())) > > def getSASession(): > SASession.remove() > engine = getUtility(ISAEngineUtility).getEngine() > s = SASession() > s.bind = engine > return s > -------------------------------------------- > > In my application, I then use getSASession() to retrieve my session. > > However, what I think is not that beautiful is the "s.bind = engine" part. Are > there any suggestions how to improve this? You have two options If you ever need to mix objects from different `sites` into the same session, you should use an adapter on your root object like: Sessions = {} @adapter(MyRoot) @provider(ISASession) def getSASession(context): Session = Sessions.get(context.uid, None) if Session is None: Session = Sessions.setdefault( context.uid, scoped_session(sessionmaker( transactional=True, autoflush=True, extension=ZopeTransactionExtension(), bind=Engine(context.engine_url) # or getUtility... )) ) return Session() And register orm.object_session also if you like to call consistently session = ISASession(context) If you don't need to mix objects from different `sites` then you can register a local utility for ISessionConfig. def scope(): return getUtility(ISessionConfig).uid, thread.get_ident() def factory(): engine = Engine(getUtility(ISessionConfig).url) return create_session( transactional=True, autoflush=True, bind=engine extension=ZopeTransactionExtension(), )) Session = scoped_session(factory, scopefunc=scope) Then you can just import Session and use: session = Session() Laurence From cz at gocept.com Thu Jun 5 02:08:31 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Thu Jun 5 02:08:46 2008 Subject: [Zope-dev] Re: Deciphering Zope Comments References: <48462FBC.7070003@hathawaymix.org> <18502.57015.182641.552106@gargle.gargle.HOWL> Message-ID: On 2008-06-04 20:28:07 +0200, "Dieter Maurer" said: > Shane Hathaway wrote at 2008-6-4 00:01 -0600: >> >> That led me to the zope.thread module, which is apparently deprecated >> already, yet zope.app.component still depends on it. Is that an >> hysterical accident? > > As I have read, thread local variables have been invented and > implemented in Zope 3 land and donated to Python. > > Now, that it is in Python, the original Zope implementation > can go away. Maybe, that is the purpose of the "zope.thread" module? Actually zope.thread does nothing but importhing the python implementation. The module is there for backward compatibility. -- Christian Zagrodnick ? cz@gocept.com gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany http://gocept.com ? tel +49 345 1229889 4 ? fax +49 345 1229889 1 Zope and Plone consulting and development From dusty at qwer.tk Thu Jun 5 04:16:16 2008 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Thu Jun 5 04:16:14 2008 Subject: [Zope-dev] Re: SQLAlchemy (zope.sqlalchemy) integration In-Reply-To: References: <200806041802.13622.dusty@qwer.tk> Message-ID: <200806051016.16670.dusty@qwer.tk> Am Mittwoch, 4. Juni 2008 22:09 schrieb Laurence Rowe: > Hermann Himmelbauer wrote: > > In my application, I then use getSASession() to retrieve my session. > > > > However, what I think is not that beautiful is the "s.bind = engine" > > part. Are there any suggestions how to improve this? > > You have two options > > If you ever need to mix objects from different `sites` into the same > session, you should use an adapter on your root object like: > > If you don't need to mix objects from different `sites` then you can > register a local utility for ISessionConfig. > > def scope(): > return getUtility(ISessionConfig).uid, thread.get_ident() > > def factory(): > engine = Engine(getUtility(ISessionConfig).url) > return create_session( > transactional=True, autoflush=True, bind=engine > extension=ZopeTransactionExtension(), > )) > > Session = scoped_session(factory, scopefunc=scope) > > Then you can just import Session and use: > session = Session() Ok, great, thanks for help. The only thing I don't understand is what "uid" from the SessionConfig utility is. Below is my full database integration code which works for me, perhaps this is helpful to someone else. Btw., I'd suggest to put such code / session use cases in some Zope package, maybe into zope.sqlalchemy, or e.g. zope.sqlalchemy_utility as it's really difficult for non-insiders to set this up. ------------------------------------- import thread from persistent import Persistent from sqlalchemy import create_engine from sqlalchemy.orm import scoped_session, create_session from zope.interface import Interface, implements, alsoProvides from zope.schema import TextLine, Bool from zope.component import getUtility, adapter from zope.sqlalchemy import ZopeTransactionExtension from zmyapp.interfaces import INewMySiteEvent from zope.i18nmessageid import MessageFactory _ = MessageFactory('xyz') class ISAEngineUtility(Interface): """SQLAlchemy Engine Utility""" db_type = TextLine(title = _(u"Database Type")) db_username = TextLine(title = _(u"Database Username")) db_password = TextLine(title = _(u"Database Password")) db_host = TextLine(title = _(u"Database Host")) db_name = TextLine(title = _(u"Database Name")) db_echo = Bool(title = _(u"Echo Database Operations")) db_enconding = TextLine(title = _(u"Database Encoding")) db_convert_unicode = Bool(title = _(u"Database Unicode Conversion")) class SAEngineUtility(Persistent): implements(ISAEngineUtility) # FIXME FIXME!!! uid = 12345 def reset_engine_on_attrset(dsn_part): doc = "Reset engine when setting variable (stored in %s)" % dsn_part def fget(self): return getattr(self, dsn_part, None) def fset(self, value): oldvalue = getattr(self, dsn_part, None) if oldvalue != value: setattr(self, dsn_part, value) if getattr(self, 'init_done', False): self._resetEngine() return {'fget': fget, 'fset': fset, 'doc': doc} db_type = property(**reset_engine_on_attrset('_db_type')) db_username = property(**reset_engine_on_attrset('_db_username')) db_password = property(**reset_engine_on_attrset('_db_password')) db_host = property(**reset_engine_on_attrset('_db_host')) db_name = property(**reset_engine_on_attrset('_db_name')) db_echo = property(**reset_engine_on_attrset('_db_echo')) db_encoding = property(**reset_engine_on_attrset('_db_encoding')) db_convert_unicode =property( **reset_engine_on_attrset('_db_convert_unicode')) def __init__(self, db_type, db_username, db_password, db_host, db_name, db_echo = False, db_encoding = 'utf-8', db_convert_unicode = False): self.db_type = db_type self.db_username = db_username self.db_password = db_password self.db_host = db_host self.db_name = db_name self.db_echo = db_echo self.db_encoding = db_encoding self.db_convert_unicode = db_convert_unicode self.init_done = True def mkDSN(self): """Create database DSN out of DSN elements""" userpass = '' if self.db_username: userpass += self.db_username if self.db_password: userpass += ':' + self.db_password if self.db_host == 'localhost': db_host = '' else: db_host = self.db_host if db_host and userpass: db_host = userpass + '@' + self.db_host elif not db_host and userpass: db_host = userpass + '@localhost' return '%s://%s/%s' % (self.db_type, db_host, self.db_name) def getEngine(self): engine = getattr(self, '_v_engine', None) if engine: return engine # No engine available, create a new one self._v_engine = create_engine(self.mkDSN(), echo = self.db_echo, encoding = self.db_encoding, convert_unicode = self.db_convert_unicode, ) return self._v_engine def _resetEngine(self): engine = getattr(self, '_v_engine', None) if engine is not None: engine.dispose() self._v_engine = None @adapter(INewMySiteEvent) def createSAEngineUtility(event): saUtility = SAEngineUtility( event.object.db_type, event.object.db_username, event.object.db_password, event.object.db_host, event.object.db_name) sm = event.object.getSiteManager() sm['saengine_utility'] = saUtility sm.registerUtility(saUtility, ISAEngineUtility) def scope(): return getUtility(ISAEngineUtility).uid, thread.get_ident() def session_factory(): engine = getUtility(ISAEngineUtility).getEngine() return create_session(transactional = True, autoflush = True, bind = engine, extension = ZopeTransactionExtension()) SASession = scoped_session(session_factory, scopefunc = scope) ------------------------------ Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 From zope-tests at epy.co.at Thu Jun 5 07:00:07 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Thu Jun 5 07:00:10 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200806051100.m55B07PH025777@shnoll.test.at> Summary of messages to the zope-tests list. Period Wed Jun 4 11:00:00 2008 UTC to Thu Jun 5 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Jun 4 21:00:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009655.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 4 21:02:18 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009656.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 4 21:03:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009657.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 4 21:05:18 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009658.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Jun 4 21:06:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009659.html From doterof at gmail.com Thu Jun 5 09:52:16 2008 From: doterof at gmail.com (David Otero Figueroa) Date: Thu Jun 5 09:52:12 2008 Subject: [Zope-dev] Conflict Errors Message-ID: Hello everyone, I have a couple questions related to "conflict errors". During our home page stress testing (20 concurrent users), we detected several conflict errors (see trace below), We thought these could ONLY appear when writing objects in the ZODB. 2008-05-27T18:57:53 INFO ZODB conflict error at /portal/ (26 conflicts since startup at 2008-05-27T13:37:19) I have this problems too in a not estress testing. In a simple access (2 concurrents users) I have this response: 2008-05-27T13:23:48 INFO ZODB conflict error at /portal/ (22 conflicts since startup at 2008-05-27T10:37:28) 2008-05-27T13:23:48 INFO ZODB conflict error at /portal/ (23 conflicts since startup at 2008-05-27T10:37:28) 2008-05-27T13:29:21 INFO ZODB conflict error at /portal/login_form_usuario_pwd/ (29 conflicts since startup at 2008-05-27T10:37:28) 2008-05-27T13:29:22 INFO ZODB conflict error at /portal/login_form_usuario_pwd/ (30 conflicts since startup at 2008-05-27T10:37:28) 2008-05-27T19:48:40 INFO ZODB conflict error at /portal/portal_css/Plone Default/ploneStyles5658.css (68 conflicts since startup at 2008-05-27T13:37:19) I would like to know: - Can conflict errors appear when reading objects from the ZODB? - Could conflict errors be the cause of a "spinning ZOPE" scenario? - Is there any situation where ZOPE could try to write objects when rendering an "only read" page? - How can they be solved? - Can I realize partial commits? How to? Our configuration is as follows: Apache + Pound + ZEO architecture (5 ZEO clients, 1 ZEO storage server - 650.000 ZODB objects) Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.zope.org/pipermail/zope-dev/attachments/20080605/31928922/attachment.html From wichert at wiggy.net Thu Jun 5 09:55:16 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu Jun 5 09:55:13 2008 Subject: [Zope-dev] Conflict Errors In-Reply-To: References: Message-ID: <20080605135516.GD4158@wiggy.net> Previously David Otero Figueroa wrote: > Hello everyone, > > > I have a couple questions related to "conflict errors". > > During our home page stress testing (20 concurrent users), we detected > several conflict errors (see trace below), We thought these could ONLY > appear when writing objects in the ZODB. That is correct. You need to audit your check to check for undesired writes. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From jim at zope.com Thu Jun 5 10:16:15 2008 From: jim at zope.com (Jim Fulton) Date: Thu Jun 5 10:16:18 2008 Subject: [Zope-dev] Conflict Errors In-Reply-To: References: Message-ID: On Jun 5, 2008, at 9:52 AM, David Otero Figueroa wrote: > > I would like to know: > - Can conflict errors appear when reading objects from the ZODB? Yes > > - Could conflict errors be the cause of a "spinning ZOPE" scenario? Yes. > > - Is there any situation where ZOPE could try to write objects when > rendering an "only read" page? Yes. Sessions can often cause writes, depending on how you use them and on the session implementation you're using. > - How can they be solved? You can set a break point in ZODB.Connection.register and then look at the call stack to see who's writing. > - Can I realize partial commits? How to? I don't know what a "partial commit" is. You can commit more often. This usually is a bad idea and wouldn't help if you don't intent to write in the first place. Jim -- Jim Fulton Zope Corporation From tino at wildenhain.de Thu Jun 5 10:40:47 2008 From: tino at wildenhain.de (Tino Wildenhain) Date: Thu Jun 5 10:40:47 2008 Subject: [Zope-dev] Conflict Errors In-Reply-To: References: Message-ID: <4847FAEF.6060400@wildenhain.de> Jim Fulton wrote: > > On Jun 5, 2008, at 9:52 AM, David Otero Figueroa wrote: >> >> I would like to know: >> - Can conflict errors appear when reading objects from the ZODB? > > Yes shouln't MVCC resolve this particular problem? Cheers Tino -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080605/c9804ec4/smime-0001.bin From jim at zope.com Thu Jun 5 10:46:08 2008 From: jim at zope.com (Jim Fulton) Date: Thu Jun 5 10:46:06 2008 Subject: [Zope-dev] Conflict Errors In-Reply-To: References: Message-ID: <01CCBF95-6000-44F5-A470-7BF3592ACF00@zope.com> On Jun 5, 2008, at 10:16 AM, Jim Fulton wrote: > > On Jun 5, 2008, at 9:52 AM, David Otero Figueroa wrote: >> >> I would like to know: >> - Can conflict errors appear when reading objects from the ZODB? > > Yes Gaaa. I meant no. Jim -- Jim Fulton Zope Corporation From srichter at cosmos.phy.tufts.edu Thu Jun 5 12:53:16 2008 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Thu Jun 5 12:53:28 2008 Subject: [Zope-dev] Restricted Python not handling slices correctly Message-ID: <200806050953.17058.srichter@cosmos.phy.tufts.edu> Hi everyone, I am starting to use Restricted Python a lot and I found the following problem with slicing: >>> from zope.security import checker >>> l = [1, 2] >>> l[-3:] [1, 2] >>> lp = checker.ProxyFactory(l) >>> lp[-3:] [2] The problem is that -3 gets converted to 1 somewhere, but it should be a negative number signalizing the slice to start at the beginning of the sequence. The problem exists both in Python 2.4 and 2.5 and affects both Zope 2 and 3, since both Zopes use the RestrictedPython package. I suspect that the problem lies with the new slicing syntax introduced in Python 2.4. I am willing to fix the bug, but I would need some guidance and goodwill from the gods of RestrictedPython. Anyone? Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" From l at lrowe.co.uk Thu Jun 5 13:38:26 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Thu Jun 5 13:38:36 2008 Subject: [Zope-dev] Re: SQLAlchemy (zope.sqlalchemy) integration In-Reply-To: <200806051016.16670.dusty@qwer.tk> References: <200806041802.13622.dusty@qwer.tk> <200806051016.16670.dusty@qwer.tk> Message-ID: Hermann Himmelbauer wrote: > Am Mittwoch, 4. Juni 2008 22:09 schrieb Laurence Rowe: >> Hermann Himmelbauer wrote: >>> In my application, I then use getSASession() to retrieve my session. >>> >>> However, what I think is not that beautiful is the "s.bind = engine" >>> part. Are there any suggestions how to improve this? >> You have two options >> >> If you ever need to mix objects from different `sites` into the same >> session, you should use an adapter on your root object like: >> >> If you don't need to mix objects from different `sites` then you can >> register a local utility for ISessionConfig. >> >> def scope(): >> return getUtility(ISessionConfig).uid, thread.get_ident() >> >> def factory(): >> engine = Engine(getUtility(ISessionConfig).url) >> return create_session( >> transactional=True, autoflush=True, bind=engine >> extension=ZopeTransactionExtension(), >> )) >> >> Session = scoped_session(factory, scopefunc=scope) >> >> Then you can just import Session and use: >> session = Session() > > Ok, great, thanks for help. The only thing I don't understand is what "uid" > from the SessionConfig utility is. Below is my full database integration code > which works for me, perhaps this is helpful to someone else. uid is some id that distinguishes your various application instances. On zope 2 I would probably use getPhysicalPath(). I don't know what the zope3 equivalent is. Looking at your code, why did you decide to store the engine on a _v_ attribute? I don't think you need to save it at all. You can access a connection through session.connection() > Btw., I'd suggest to put such code / session use cases in some Zope package, > maybe into zope.sqlalchemy, or e.g. zope.sqlalchemy_utility as it's really > difficult for non-insiders to set this up. We would need to work out what parts are useful to the various higher level sqlalchemy / zope packages. Once we can agree on a common core then we should at least make simple use cases available through zope.sqlalchemy directly. Laurence From faassen at startifact.com Thu Jun 5 14:14:36 2008 From: faassen at startifact.com (Martijn Faassen) Date: Thu Jun 5 14:14:46 2008 Subject: [Zope-dev] Re: Restricted Python not handling slices correctly In-Reply-To: <200806050953.17058.srichter@cosmos.phy.tufts.edu> References: <200806050953.17058.srichter@cosmos.phy.tufts.edu> Message-ID: Hey Stephan, Stephan Richter wrote: > I am starting to use Restricted Python a lot I'm curious to learn what you're using it for. Regards, Martijn From srichter at cosmos.phy.tufts.edu Thu Jun 5 15:34:06 2008 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Thu Jun 5 15:34:16 2008 Subject: [Zope-dev] Re: Restricted Python not handling slices correctly In-Reply-To: References: <200806050953.17058.srichter@cosmos.phy.tufts.edu> Message-ID: <200806051234.06430.srichter@cosmos.phy.tufts.edu> On Thursday 05 June 2008, Martijn Faassen wrote: > Stephan Richter wrote: > > I am starting to use Restricted Python a lot > > I'm curious to learn what you're using it for. I cannot give you the full details yet, but Keas, the company I am working for now, has been developing a domain-specific language that is based on Python. We did some cool stuff overriding slicing and item lookup; I will be able to say more once we launched. Clearly we do not allow to run unrestricted Python and run everything in restricted Python. The slicing and getitem syntax is very central to us, so then the problem popped up pretty quickly. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" From faassen at startifact.com Thu Jun 5 16:06:36 2008 From: faassen at startifact.com (Martijn Faassen) Date: Thu Jun 5 16:06:53 2008 Subject: [Zope-dev] Re: Restricted Python not handling slices correctly In-Reply-To: <200806051234.06430.srichter@cosmos.phy.tufts.edu> References: <200806050953.17058.srichter@cosmos.phy.tufts.edu> <200806051234.06430.srichter@cosmos.phy.tufts.edu> Message-ID: Stephan Richter wrote: > On Thursday 05 June 2008, Martijn Faassen wrote: >> Stephan Richter wrote: >>> I am starting to use Restricted Python a lot >> I'm curious to learn what you're using it for. > > I cannot give you the full details yet [snip hints] Thanks for the info nonetheless. My curiosity has only increased now, but that can't be helped. :) Keas sounds interesting! Regards, Martijn From stefan at epy.co.at Thu Jun 5 19:37:16 2008 From: stefan at epy.co.at (Stefan H. Holek) Date: Thu Jun 5 19:37:18 2008 Subject: [Zope-dev] fast_listen -> fast-listen for 2.11 Message-ID: <2C915058-A860-46AC-AFBB-A0E8BBC92967@epy.co.at> I'd like to sneak the following patch into 2.11 before final. The idea is that zope.conf option names should use dashes and not underscores. The downside is that it will break all zope.conf files that already use this option. Objections? Stefan + Bugs Fixed + + - Fixed against-the-rules zope.conf option 'fast_listen' to read + 'fast-listen' (dash, not underscore). + Zope 2.11 rc 1 (2008/05/08) Bugs Fixed Index: skel/etc/zope.conf.in =================================================================== --- skel/etc/zope.conf.in (revision 84838) +++ skel/etc/zope.conf.in (working copy) @@ -975,8 +975,7 @@ # # To defer the opening of the HTTP socket until the end of the # startup phase: - # fast_listen false - # + # fast-listen off # Examples: Index: lib/python/ZServer/component.xml =================================================================== --- lib/python/ZServer/component.xml (revision 84838) +++ lib/python/ZServer/component.xml (working copy) @@ -19,10 +19,10 @@ receive WebDAV source responses to GET requests. - + - Defines wether the http server should listen to requests immediately - or only after zope is ready to run + Defines whether the HTTP server should listen for requests + immediately or only after Zope is ready to run. -- Anything that, in happening, causes something else to happen, causes something else to happen. --Douglas Adams From shane at hathawaymix.org Thu Jun 5 20:50:03 2008 From: shane at hathawaymix.org (Shane Hathaway) Date: Thu Jun 5 20:50:02 2008 Subject: [Zope-dev] Restricted Python not handling slices correctly In-Reply-To: <200806050953.17058.srichter@cosmos.phy.tufts.edu> References: <200806050953.17058.srichter@cosmos.phy.tufts.edu> Message-ID: <484889BB.8030008@hathawaymix.org> Stephan Richter wrote: > Hi everyone, > > I am starting to use Restricted Python a lot and I found the following problem > with slicing: > >>>> from zope.security import checker >>>> l = [1, 2] >>>> l[-3:] > [1, 2] >>>> lp = checker.ProxyFactory(l) >>>> lp[-3:] > [2] > > The problem is that -3 gets converted to 1 somewhere, but it should be a > negative number signalizing the slice to start at the beginning of the > sequence. > > The problem exists both in Python 2.4 and 2.5 and affects both Zope 2 and 3, > since both Zopes use the RestrictedPython package. > > I suspect that the problem lies with the new slicing syntax introduced in > Python 2.4. I am willing to fix the bug, but I would need some guidance and > goodwill from the gods of RestrictedPython. Anyone? Are you in fact using RestrictedPython? The code snippet looks like it only uses a security proxy. RestrictedPython is a custom Python compiler; you're not using it unless your interactive Python prompt uses RestrictedPython to compile all expressions. The behavior you saw is exactly what happens when an object implements __getitem__ and __len__ but not __getslice__. If lp matches that description, and the length of lp is 2, then Python evaluates "lp[-3:]" as "lp.__getitem__(slice(-1, 2147483647, None))". I wish Python would instead evaluate it as "lp.__getitem__(slice(-3))", but maybe there are historical reasons for this. OTOH, if RestrictedPython really is involved, RP will convert the expression to "_getitem_(lp, slice(-3, None))", which would probably do what you wanted, assuming the _getitem_ function is not too clever. BTW, here's the code I used to answer this email. :-) >>> class itemgetter: ... def __getitem__(self, i): ... return i ... def __len__(self): ... return 2 ... >>> itemgetter()[-3:] slice(-1, 2147483647, None) Shane From ct at gocept.com Fri Jun 6 01:49:55 2008 From: ct at gocept.com (Christian Theune) Date: Fri Jun 6 01:49:52 2008 Subject: [Zope-dev] fast_listen -> fast-listen for 2.11 In-Reply-To: <2C915058-A860-46AC-AFBB-A0E8BBC92967@epy.co.at> References: <2C915058-A860-46AC-AFBB-A0E8BBC92967@epy.co.at> Message-ID: <20080606054955.GA8177@mindy> On Fri, Jun 06, 2008 at 01:37:16AM +0200, Stefan H. Holek wrote: > I'd like to sneak the following patch into 2.11 before final. The idea is > that zope.conf option names should use dashes and not underscores. The > downside is that it will break all zope.conf files that already use this > option. Hmm. Was this around in 2.10 already? If yes, then I'd consider it a bit late to make a cosmetic fix that breaks config files. If no, then it's probably not as bad and should be done to avoid config files getting created with a variable we know will change. Christian -- Christian Theune ? ct@gocept.com gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany http://gocept.com ? tel +49 345 1229889 7 ? fax +49 345 1229889 1 Zope and Plone consulting and development From ct at gocept.com Fri Jun 6 02:23:40 2008 From: ct at gocept.com (Christian Theune) Date: Fri Jun 6 02:23:37 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds Message-ID: <20080606062340.GB8177@mindy> Hi, I've watched my buildbot send out notifications for a while and pondered how to make them available to more people. I decided to send them to this list on a 'problem' level. The 'problem' level sends a message when a builder changes from a good state to a bad state but doesn't send a new message on subsequent failing builds. For me this has been reasonably quiet over the last two weeks although about 60 builders are broken. The risk of sending mail here is that a massive build failure can cause about 200 messages being send at once. If anybody knows a better approach with buildbot, please let me know, I'd be happy to implement it. For everyone else: please have a look at the list of broken builds: http://zopebuildbot.whq.gocept.com/cruise If a project that you feel responsible for is broken, please check out whats wrong and maybe fix it. If the build environment isn't suitable, I'll be happy to help. This page should show a green bar! Christian -- Christian Theune ? ct@gocept.com gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany http://gocept.com ? tel +49 345 1229889 7 ? fax +49 345 1229889 1 Zope and Plone consulting and development From lists at zopyx.com Fri Jun 6 02:35:57 2008 From: lists at zopyx.com (Andreas Jung) Date: Fri Jun 6 02:35:55 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: <20080606062340.GB8177@mindy> References: <20080606062340.GB8177@mindy> Message-ID: --On 6. Juni 2008 08:23:40 +0200 Christian Theune wrote: > Hi, > > I've watched my buildbot send out notifications for a while and pondered > how to make them available to more people. I decided to send them to this > list on a 'problem' level. > > The 'problem' level sends a message when a builder changes from a good > state to a bad state but doesn't send a new message on subsequent failing > builds. > > For me this has been reasonably quiet over the last two weeks although > about 60 builders are broken. > > The risk of sending mail here is that a massive build failure can cause > about 200 messages being send at once. If anybody knows a better approach > with buildbot, please let me know, I'd be happy to implement it. > > For everyone else: please have a look at the list of broken builds: > http://zopebuildbot.whq.gocept.com/cruise > > A minor usability suggestion: please provide links at the top of the page for every top-level namespace that would setup the filter for this namespace. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080606/8d813487/attachment-0001.bin From agroszer at gmail.com Fri Jun 6 03:44:14 2008 From: agroszer at gmail.com (Adam GROSZER) Date: Fri Jun 6 03:44:09 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: References: <20080606062340.GB8177@mindy> Message-ID: <889401661.20080606094414@gmail.com> Hello, Not this one, but I added some features on the branch: svn+ssh://svn.zope.org/repos/main/gocept.bsquare/branches/pcardune-setup Friday, June 6, 2008, 8:35:57 AM, you wrote: AJ> A minor usability suggestion: AJ> please provide links at the top of the page for every top-level namespace AJ> that would setup the filter for this namespace. AJ> Andreas -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: There's nothing so pathetic as a forgetful liar. - Unknown From dusty at qwer.tk Fri Jun 6 05:30:01 2008 From: dusty at qwer.tk (Hermann Himmelbauer) Date: Fri Jun 6 05:30:00 2008 Subject: [Zope-dev] Re: SQLAlchemy (zope.sqlalchemy) integration In-Reply-To: References: <200806041802.13622.dusty@qwer.tk> <200806051016.16670.dusty@qwer.tk> Message-ID: <200806061130.01808.dusty@qwer.tk> Am Donnerstag, 5. Juni 2008 19:38 schrieb Laurence Rowe: > Hermann Himmelbauer wrote: > > Am Mittwoch, 4. Juni 2008 22:09 schrieb Laurence Rowe: > >> Hermann Himmelbauer wrote: > >>> In my application, I then use getSASession() to retrieve my session. > >>> > >>> However, what I think is not that beautiful is the "s.bind = engine" > >>> part. Are there any suggestions how to improve this? > >> > >> You have two options > >> > >> If you ever need to mix objects from different `sites` into the same > >> session, you should use an adapter on your root object like: > >> > >> If you don't need to mix objects from different `sites` then you can > >> register a local utility for ISessionConfig. > >> > >> def scope(): > >> return getUtility(ISessionConfig).uid, thread.get_ident() > >> > >> def factory(): > >> engine = Engine(getUtility(ISessionConfig).url) > >> return create_session( > >> transactional=True, autoflush=True, bind=engine > >> extension=ZopeTransactionExtension(), > >> )) > >> > >> Session = scoped_session(factory, scopefunc=scope) > >> > >> Then you can just import Session and use: > >> session = Session() > > > > Ok, great, thanks for help. The only thing I don't understand is what > > "uid" from the SessionConfig utility is. Below is my full database > > integration code which works for me, perhaps this is helpful to someone > > else. > > uid is some id that distinguishes your various application instances. On > zope 2 I would probably use getPhysicalPath(). I don't know what the > zope3 equivalent is. Hmmm, maybe it's: from zope.traversing.api import getPath from zope.app.component.hooks import getSite @property def uid(self): return getPath(getSite()) > Looking at your code, why did you decide to store the engine on a _v_ > attribute? I don't think you need to save it at all. You can access a > connection through session.connection() Ok, but in case I create the engine in the session_factor, e.g.: def session_factory(): engine = createEngine(....) return create_session(transactional = True, autoflush = True, bind = engine, extension = ZopeTransactionExtension()) Wouldn't the engine be created for every request, as the scope changes and the factory is called? In my case, the engine is created when the first session is fetched. After that it will be recreated only if the DSN changes. > > Btw., I'd suggest to put such code / session use cases in some Zope > > package, maybe into zope.sqlalchemy, or e.g. zope.sqlalchemy_utility as > > it's really difficult for non-insiders to set this up. > > We would need to work out what parts are useful to the various higher > level sqlalchemy / zope packages. Once we can agree on a common core > then we should at least make simple use cases available through > zope.sqlalchemy directly. In my scenario, all I need is a local utility. This is something that was available in z3c.zalchemy, too (and I think also in z3c.sqlalchemy). The problem about putting this code into zope.sqlalchemy is that the local-utility code may be based on other zope packages and hence create unwanted dependencies. But I'm unsure about this. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 From zope-tests at epy.co.at Fri Jun 6 07:00:06 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Fri Jun 6 07:00:00 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200806061100.m56B066W009900@shnoll.test.at> Summary of messages to the zope-tests list. Period Thu Jun 5 11:00:00 2008 UTC to Fri Jun 6 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Jun 5 21:07:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009660.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jun 5 21:09:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009661.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jun 5 21:10:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009662.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jun 5 21:12:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009663.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Jun 5 21:13:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-June/009664.html From gary at zope.com Fri Jun 6 07:44:37 2008 From: gary at zope.com (Gary Poster) Date: Fri Jun 6 07:44:31 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: <20080606062340.GB8177@mindy> References: <20080606062340.GB8177@mindy> Message-ID: <8668AD5C-EC17-4DC9-AC13-3E4DE4A941EA@zope.com> Hey Christian. Thanks for this. It would be nice to have a link from this page to the failure output (to address "works for me" issues, as well as for a quick triage). Gary From gary at zope.com Fri Jun 6 07:50:30 2008 From: gary at zope.com (Gary Poster) Date: Fri Jun 6 07:50:24 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: <8668AD5C-EC17-4DC9-AC13-3E4DE4A941EA@zope.com> References: <20080606062340.GB8177@mindy> <8668AD5C-EC17-4DC9-AC13-3E4DE4A941EA@zope.com> Message-ID: <3492A759-C152-40E8-A839-19D173EA2387@zope.com> On Jun 6, 2008, at 7:44 AM, Gary Poster wrote: > Hey Christian. Thanks for this. It would be nice to have a link > from this page to the failure output (to address "works for me" > issues, as well as for a quick triage). ...but I found 'em by digging around on the site, so, mostly nevermind. From stefan at epy.co.at Fri Jun 6 07:55:43 2008 From: stefan at epy.co.at (Stefan H. Holek) Date: Fri Jun 6 07:55:38 2008 Subject: [Zope-dev] fast_listen -> fast-listen for 2.11 In-Reply-To: <20080606054955.GA8177@mindy> References: <2C915058-A860-46AC-AFBB-A0E8BBC92967@epy.co.at> <20080606054955.GA8177@mindy> Message-ID: No, fast-listen is new in Zope 2.11. Stefan On 06.06.2008, at 07:49, Christian Theune wrote: > Hmm. Was this around in 2.10 already? -- Stefan H. Holek stefan@epy.co.at From ct at gocept.com Fri Jun 6 08:35:49 2008 From: ct at gocept.com (Christian Theune) Date: Fri Jun 6 08:35:48 2008 Subject: [Zope-dev] fast_listen -> fast-listen for 2.11 In-Reply-To: References: <2C915058-A860-46AC-AFBB-A0E8BBC92967@epy.co.at> <20080606054955.GA8177@mindy> Message-ID: <20080606123549.GF8177@mindy> Hi, On Fri, Jun 06, 2008 at 01:55:43PM +0200, Stefan H. Holek wrote: > No, fast-listen is new in Zope 2.11. > > Stefan > > On 06.06.2008, at 07:49, Christian Theune wrote: > >> Hmm. Was this around in 2.10 already? Then it's a +1 from me. -- Christian Theune ? ct@gocept.com gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany http://gocept.com ? tel +49 345 1229889 7 ? fax +49 345 1229889 1 Zope and Plone consulting and development From benji at zope.com Fri Jun 6 08:37:48 2008 From: benji at zope.com (Benji York) Date: Fri Jun 6 08:37:44 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: <20080606062340.GB8177@mindy> References: <20080606062340.GB8177@mindy> Message-ID: On Fri, Jun 6, 2008 at 2:23 AM, Christian Theune wrote: > I've watched my buildbot send out notifications for a while and pondered how > to make them available to more people. We really need something like this. Thanks. A suggestion: I'd like to have the tests run with --all. -- Benji York Senior Software Engineer Zope Corporation From ct at gocept.com Fri Jun 6 09:01:20 2008 From: ct at gocept.com (ct@gocept.com) Date: Fri Jun 6 09:00:38 2008 Subject: [Zope-dev] buildbot failure in Zope on zc.ngi Message-ID: <20080606130043.61CC928C0@uter.whq.gocept.com> The Buildbot has detected a new failure of zc.ngi on Zope. Full details are available at: http://zopebuildbot.whq.gocept.com/zc.ngi/builds/96 Buildbot URL: http://zopebuildbot.whq.gocept.com/ Buildslave for this Build: local Build Reason: The Nightly scheduler named 'zc.ngi nightly' triggered this build Build Source Stamp: [branch zc.ngi/trunk] HEAD Blamelist: BUILD FAILED: failed test Logs are attached. sincerely, -The Buildbot -------------- next part -------------- A build/todo.txt A build/bootstrap.py A build/buildout.cfg A build/setup.py A build/src A build/src/zc A build/src/zc/__init__.py A build/src/zc/ngi A build/src/zc/ngi/blocking.py A build/src/zc/ngi/adapters.txt A build/src/zc/ngi/message.txt A build/src/zc/ngi/async.py A build/src/zc/ngi/testing.py A build/src/zc/ngi/__init__.py A build/src/zc/ngi/blocking.txt A build/src/zc/ngi/tests.py A build/src/zc/ngi/adapters.py A build/src/zc/ngi/interfaces.py A build/src/zc/ngi/README.txt A build/src/zc/ngi/async.txt A build/src/zc/ngi/message.py A build/src/zc/ngi/testing.test A build/src/zc/ngi/wordcount.py A build/README.txt U build Checked out revision 87191. -------------- next part -------------- Creating directory '/home/ctheune/zope.org/slave/zc.ngi/build/bin'. Creating directory '/home/ctheune/zope.org/slave/zc.ngi/build/parts'. Creating directory '/home/ctheune/zope.org/slave/zc.ngi/build/develop-eggs'. Generated script '/home/ctheune/zope.org/slave/zc.ngi/build/bin/buildout'. -------------- next part -------------- Upgraded: zc.buildout version 1.0.3, setuptools version 0.6c8; restarting. Generated script '/home/ctheune/zope.org/slave/zc.ngi/build/bin/buildout'. Develop: '/home/ctheune/zope.org/slave/zc.ngi/build/.' Installing test. Generated script '/home/ctheune/zope.org/slave/zc.ngi/build/bin/test'. -------------- next part -------------- Running unit tests: Failure in test /home/ctheune/zope.org/slave/zc.ngi/build/src/zc/ngi/async.txt Failed doctest test for async.txt File "/home/ctheune/zope.org/slave/zc.ngi/build/src/zc/ngi/async.txt", line 0 ---------------------------------------------------------------------- File "/home/ctheune/zope.org/slave/zc.ngi/build/src/zc/ngi/async.txt", line 161, in async.txt Failed example: print loghandler Expected: zc.ngi.async.client ERROR handle_input failed Got: ---------------------------------------------------------------------- File "/home/ctheune/zope.org/slave/zc.ngi/build/src/zc/ngi/async.txt", line 165, in async.txt Failed example: handler.closed Exception raised: Traceback (most recent call last): File "/home/ctheune/eggs/tmpY8_5rK/zope.testing-3.5.1-py2.4.egg/zope/testing/doctest.py", line 1356, in __run File "", line 1, in ? handler.closed AttributeError: LameClientConnectionHandler instance has no attribute 'closed' Ran 70 tests with 1 failures and 0 errors in 4.978 seconds. From gary at zope.com Fri Jun 6 09:34:30 2008 From: gary at zope.com (Gary Poster) Date: Fri Jun 6 09:34:25 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: References: <20080606062340.GB8177@mindy> Message-ID: On Jun 6, 2008, at 8:37 AM, Benji York wrote: > On Fri, Jun 6, 2008 at 2:23 AM, Christian Theune > wrote: >> I've watched my buildbot send out notifications for a while and >> pondered how >> to make them available to more people. > > We really need something like this. Thanks. > > A suggestion: I'd like to have the tests run with --all. Heh, I was going to try and fix a time-out failure (zc.blist) by moving the intentionally long tests to --all...maybe there would be some way to say "don't run me with --all"? Otherwise don't love this idea, though I understand its point. From l at lrowe.co.uk Fri Jun 6 09:35:32 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Fri Jun 6 09:36:03 2008 Subject: [Zope-dev] Re: SQLAlchemy (zope.sqlalchemy) integration In-Reply-To: <200806061130.01808.dusty@qwer.tk> References: <200806041802.13622.dusty@qwer.tk> <200806051016.16670.dusty@qwer.tk> <200806061130.01808.dusty@qwer.tk> Message-ID: Hermann Himmelbauer wrote: > Am Donnerstag, 5. Juni 2008 19:38 schrieb Laurence Rowe: >> Hermann Himmelbauer wrote: >>> Am Mittwoch, 4. Juni 2008 22:09 schrieb Laurence Rowe: >>>> Hermann Himmelbauer wrote: >>>>> In my application, I then use getSASession() to retrieve my session. >>>>> >>>>> However, what I think is not that beautiful is the "s.bind = engine" >>>>> part. Are there any suggestions how to improve this? >>>> You have two options >>>> >>>> If you ever need to mix objects from different `sites` into the same >>>> session, you should use an adapter on your root object like: >>>> >>>> If you don't need to mix objects from different `sites` then you can >>>> register a local utility for ISessionConfig. >>>> >>>> def scope(): >>>> return getUtility(ISessionConfig).uid, thread.get_ident() >>>> >>>> def factory(): >>>> engine = Engine(getUtility(ISessionConfig).url) >>>> return create_session( >>>> transactional=True, autoflush=True, bind=engine >>>> extension=ZopeTransactionExtension(), >>>> )) >>>> >>>> Session = scoped_session(factory, scopefunc=scope) >>>> >>>> Then you can just import Session and use: >>>> session = Session() >>> Ok, great, thanks for help. The only thing I don't understand is what >>> "uid" from the SessionConfig utility is. Below is my full database >>> integration code which works for me, perhaps this is helpful to someone >>> else. >> uid is some id that distinguishes your various application instances. On >> zope 2 I would probably use getPhysicalPath(). I don't know what the >> zope3 equivalent is. > > Hmmm, maybe it's: > > from zope.traversing.api import getPath > from zope.app.component.hooks import getSite > @property > def uid(self): > return getPath(getSite()) > >> Looking at your code, why did you decide to store the engine on a _v_ >> attribute? I don't think you need to save it at all. You can access a >> connection through session.connection() > > Ok, but in case I create the engine in the session_factor, e.g.: > > def session_factory(): > engine = createEngine(....) > return create_session(transactional = True, > autoflush = True, > bind = engine, > extension = ZopeTransactionExtension()) > > Wouldn't the engine be created for every request, as the scope changes and the > factory is called? In my case, the engine is created when the first session > is fetched. After that it will be recreated only if the DSN changes. The engines are created the same number of times either way. zope.sqlalchemy uses session.close() rather than session.remove(), so the session/engine is only created once per thread, then recycled. This is the same as storing it on a _v_ attribute, which are per thread as active objects live in the connection cache. Laurence From benji at zope.com Fri Jun 6 09:44:33 2008 From: benji at zope.com (Benji York) Date: Fri Jun 6 09:44:30 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: References: <20080606062340.GB8177@mindy> Message-ID: On Fri, Jun 6, 2008 at 9:34 AM, Gary Poster wrote: > > On Jun 6, 2008, at 8:37 AM, Benji York wrote: > >> A suggestion: I'd like to have the tests run with --all. > > Heh, I was going to try and fix a time-out failure (zc.blist) by moving the > intentionally long tests to --all...maybe there would be some way to say > "don't run me with --all"? Otherwise don't love this idea, though I > understand its point. I avoided suggesting this earlier, but perhaps we need to define a level to run the tests at. Then buildbot could run all tests at level X and below and you could put the truly long-running tests above X. -- Benji York Senior Software Engineer Zope Corporation From fdrake at gmail.com Fri Jun 6 09:48:42 2008 From: fdrake at gmail.com (Fred Drake) Date: Fri Jun 6 09:48:36 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: References: <20080606062340.GB8177@mindy> Message-ID: <9cee7ab80806060648m78b7c2f2j50e3aa9aeb1368ad@mail.gmail.com> On Fri, Jun 6, 2008 at 9:44 AM, Benji York wrote: > I avoided suggesting this earlier, but perhaps we need to define a level > to run the tests at. Then buildbot could run all tests at level X and > below and you could put the truly long-running tests above X. Another approach would be to have the buildbot run a bin/buildbot-test instead of bin/test, if present. That let's the package suggest what makes sense for running under buildbot without having to get people to agree on how "levels" are used (a more complicated issue). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From gary at zope.com Fri Jun 6 09:56:38 2008 From: gary at zope.com (Gary Poster) Date: Fri Jun 6 09:56:33 2008 Subject: [Zope-dev] buildbot news: sending notifications and current broken builds In-Reply-To: <9cee7ab80806060648m78b7c2f2j50e3aa9aeb1368ad@mail.gmail.com> References: <20080606062340.GB8177@mindy> <9cee7ab80806060648m78b7c2f2j50e3aa9aeb1368ad@mail.gmail.com> Message-ID: <808ACC4D-0B24-409A-803D-5FE9DD8CB642@zope.com> On Jun 6, 2008, at 9:48 AM, Fred Drake wrote: > On Fri, Jun 6, 2008 at 9:44 AM, Benji York wrote: >> I avoided suggesting this earlier, but perhaps we need to define a >> level >> to run the tests at. Then buildbot could run all tests at level X >> and >> below and you could put the truly long-running tests above X. > > Another approach would be to have the buildbot run a bin/buildbot-test > instead of bin/test, if present. That let's the package suggest what > makes sense for running under buildbot without having to get people to > agree on how "levels" are used (a more complicated issue). Huh, that sounds like it might be easy-ish for Christian, putting the responsibility where it arguably should be, on the package maintainer. +1, if Christian says it's easy for him. From dieter at handshake.de Fri Jun 6 14:41:43 2008 From: dieter at handshake.de (Dieter Maurer) Date: Fri Jun 6 14:41:57 2008 Subject: [Zope-dev] Conflict Errors In-Reply-To: <01CCBF95-6000-44F5-A470-7BF3592ACF00@zope.com> References: <01CCBF95-6000-44F5-A470-7BF3592ACF00@zope.com> Message-ID: <18505.34023.591209.618263@gargle.gargle.HOWL> Jim Fulton wrote at 2008-6-5 10:46 -0400: > >On Jun 5, 2008, at 10:16 AM, Jim Fulton wrote: > >> >> On Jun 5, 2008, at 9:52 AM, David Otero Figueroa wrote: >>> >>> I would like to know: >>> - Can conflict errors appear when reading objects from the ZODB? >> >> Yes > > >Gaaa. I meant no. Nevertheless, I think you have been right in the first place. Usually, MVCC prevents read conflict errors but "TempStorage" only maintains a very limited history -- occasionally to small to fully implement MVCC. Then read conflict errors will occur. -- Dieter From jim at zope.com Fri Jun 6 15:37:31 2008 From: jim at zope.com (Jim Fulton) Date: Fri Jun 6 15:37:30 2008 Subject: [Zope-dev] Conflict Errors In-Reply-To: <18505.34023.591209.618263@gargle.gargle.HOWL> References: <01CCBF95-6000-44F5-A470-7BF3592ACF00@zope.com> <18505.34023.591209.618263@gargle.gargle.HOWL> Message-ID: <067FBD1B-75B7-4D46-AFE2-21CE89418BD2@zope.com> On Jun 6, 2008, at 2:41 PM, Dieter Maurer wrote: > Jim Fulton wrote at 2008-6-5 10:46 -0400: >> >> On Jun 5, 2008, at 10:16 AM, Jim Fulton wrote: >> >>> >>> On Jun 5, 2008, at 9:52 AM, David Otero Figueroa wrote: >>>> >>>> I would like to know: >>>> - Can conflict errors appear when reading objects from the ZODB? >>> >>> Yes >> >> >> Gaaa. I meant no. > > Nevertheless, I think you have been right in the first place. > > Usually, MVCC prevents read conflict errors but "TempStorage" > only maintains a very limited history -- occasionally to small > to fully implement MVCC. Then read conflict errors will occur. Sure. The right answer is "generally, no". :) Jim -- Jim Fulton Zope Corporation From ct at gocept.com Fri Jun 6 16:14:16 2008 From: ct at gocept.com (ct@gocept.com) Date: Fri Jun 6 16:13:29 2008 Subject: [Zope-dev] buildbot failure in Zope on ZODB Message-ID: <20080606201332.B021728C0@uter.whq.gocept.com> The Buildbot has detected a new failure of ZODB on Zope. Full details are available at: http://zopebuildbot.whq.gocept.com/ZODB/builds/122 Buildbot URL: http://zopebuildbot.whq.gocept.com/ Buildslave for this Build: local Build Reason: The Nightly scheduler named 'ZODB nightly' triggered this build Build Source Stamp: [branch ZODB/trunk] HEAD Blamelist: BUILD FAILED: failed test Logs are attached. sincerely, -The Buildbot -------------- next part -------------- A build/HISTORY.txt A build/log.ini A build/LICENSE.txt A build/bootstrap.py A build/buildout.cfg A build/doc A build/doc/HOWTO-Blobs-NFS.txt A build/doc/zodb.pdf A build/doc/zeo-client-cache.txt A build/doc/zeo.txt A build/doc/storage.pdf A build/doc/guide A build/doc/guide/links.tex A build/doc/guide/introduction.tex A build/doc/guide/chatter.py A build/doc/guide/prog-zodb.tex A build/doc/guide/indexing.tex A build/doc/guide/TODO A build/doc/guide/storages.tex A build/doc/guide/admin.tex A build/doc/guide/modules.tex A build/doc/guide/transactions.tex A build/doc/guide/gfdl.tex A build/doc/guide/zeo.tex A build/doc/guide/README A build/doc/guide/zodb.tex A build/doc/zeo-client-cache-tracing.txt A build/COPYRIGHT.txt A build/release.py A build/setup.py A build/src A build/src/persistent A build/src/persistent/cPickleCache.c A build/src/persistent/ring.c A build/src/persistent/mapping.py A build/src/persistent/TimeStamp.c A build/src/persistent/DEPENDENCIES.cfg A build/src/persistent/ring.h A build/src/persistent/__init__.py A build/src/persistent/py24compat.h A build/src/persistent/wref.py A build/src/persistent/SETUP.cfg A build/src/persistent/tests A build/src/persistent/tests/test_PickleCache.py A build/src/persistent/tests/test_list.py A build/src/persistent/tests/test_mapping.py A build/src/persistent/tests/persistenttestbase.py A build/src/persistent/tests/__init__.py A build/src/persistent/tests/test_persistent.py A build/src/persistent/tests/testPersistent.py A build/src/persistent/tests/test_wref.py A build/src/persistent/tests/test_overriding_attrs.py A build/src/persistent/tests/test_pickle.py A build/src/persistent/tests/persistent.txt A build/src/persistent/list.py A build/src/persistent/cPersistence.c A build/src/persistent/interfaces.py A build/src/persistent/dict.py A build/src/persistent/README.txt A build/src/persistent/cPersistence.h A build/src/ZopeUndo A build/src/ZopeUndo/tests A build/src/ZopeUndo/tests/testPrefix.py A build/src/ZopeUndo/tests/__init__.py A build/src/ZopeUndo/Prefix.py A build/src/ZopeUndo/__init__.py A build/src/BTrees A build/src/BTrees/_OOBTree.c A build/src/BTrees/BTreeItemsTemplate.c A build/src/BTrees/IOBTree.py A build/src/BTrees/OIBTree.py A build/src/BTrees/intvaluemacros.h A build/src/BTrees/sorters.c A build/src/BTrees/OLBTree.py A build/src/BTrees/__init__.py A build/src/BTrees/OOBTree.py A build/src/BTrees/py24compat.h A build/src/BTrees/BucketTemplate.c A build/src/BTrees/floatvaluemacros.h A build/src/BTrees/intkeymacros.h A build/src/BTrees/_IFBTree.c A build/src/BTrees/Development.txt A build/src/BTrees/tests A build/src/BTrees/tests/testBTreesUnicode.py A build/src/BTrees/tests/test_check.py A build/src/BTrees/tests/testSetOps.py A build/src/BTrees/tests/__init__.py A build/src/BTrees/tests/test_btreesubclass.py A build/src/BTrees/tests/testConflict.py A build/src/BTrees/tests/testLength.py A build/src/BTrees/tests/testBTrees.py A build/src/BTrees/tests/test_compare.py A build/src/BTrees/_LFBTree.c A build/src/BTrees/SetOpTemplate.c A build/src/BTrees/_LLBTree.c A build/src/BTrees/LFBTree.py A build/src/BTrees/_OLBTree.c A build/src/BTrees/MergeTemplate.c A build/src/BTrees/BTreeTemplate.c A build/src/BTrees/LLBTree.py A build/src/BTrees/fsBTree.py A build/src/BTrees/LOBTree.py A build/src/BTrees/BTreeModuleTemplate.c A build/src/BTrees/DEPENDENCIES.cfg A build/src/BTrees/TreeSetTemplate.c A build/src/BTrees/SETUP.cfg A build/src/BTrees/objectvaluemacros.h A build/src/BTrees/_IIBTree.c A build/src/BTrees/check.py A build/src/BTrees/IFBTree.py A build/src/BTrees/SetTemplate.c A build/src/BTrees/Length.py A build/src/BTrees/_OIBTree.c A build/src/BTrees/_IOBTree.c A build/src/BTrees/IIBTree.py A build/src/BTrees/Interfaces.py A build/src/BTrees/_fsBTree.c A build/src/BTrees/objectkeymacros.h A build/src/BTrees/_LOBTree.c A build/src/CHANGES.txt A build/src/ZEO A build/src/ZEO/CommitLog.py A build/src/ZEO/StorageServer.py A build/src/ZEO/DEPENDENCIES.cfg A build/src/ZEO/__init__.py A build/src/ZEO/scripts A build/src/ZEO/scripts/manual_tests A build/src/ZEO/scripts/manual_tests/testzeopack.py A build/src/ZEO/scripts/parsezeolog.py A build/src/ZEO/scripts/zeoreplay.py A build/src/ZEO/scripts/zeopack.py A build/src/ZEO/scripts/__init__.py A build/src/ZEO/scripts/zeopasswd.py A build/src/ZEO/scripts/zeoctl.py A build/src/ZEO/scripts/runzeo.py A build/src/ZEO/scripts/zeoqueue.py A build/src/ZEO/scripts/zeoup.py A build/src/ZEO/scripts/mkzeoinst.py A build/src/ZEO/scripts/README.txt A build/src/ZEO/scripts/timeout.py A build/src/ZEO/scripts/zeoserverlog.py A build/src/ZEO/zeoctl.py A build/src/ZEO/cache.py A build/src/ZEO/ClientStorage.py A build/src/ZEO/ServerStub.py A build/src/ZEO/SETUP.cfg A build/src/ZEO/schema.xml A build/src/ZEO/zeoctl.xml A build/src/ZEO/component.xml A build/src/ZEO/auth A build/src/ZEO/auth/hmac.py A build/src/ZEO/auth/base.py A build/src/ZEO/auth/__init__.py A build/src/ZEO/auth/auth_digest.py A build/src/ZEO/tests A build/src/ZEO/tests/forker.py A build/src/ZEO/tests/auth_plaintext.py A build/src/ZEO/tests/multi.py A build/src/ZEO/tests/ThreadTests.py A build/src/ZEO/tests/zeo-fan-out.test A build/src/ZEO/tests/testZEO.py A build/src/ZEO/tests/testConnection.py A build/src/ZEO/tests/__init__.py A build/src/ZEO/tests/speed.py A build/src/ZEO/tests/testAuth.py A build/src/ZEO/tests/test_cache.py A build/src/ZEO/tests/Cache.py A build/src/ZEO/tests/InvalidationTests.py A build/src/ZEO/tests/deadlock.py A build/src/ZEO/tests/TestThread.py A build/src/ZEO/tests/testZEOOptions.py A build/src/ZEO/tests/testTransactionBuffer.py A build/src/ZEO/tests/registerDB.test A build/src/ZEO/tests/ConnectionTests.py A build/src/ZEO/tests/testConversionSupport.py A build/src/ZEO/tests/stress.py A build/src/ZEO/tests/CommitLockTests.py A build/src/ZEO/tests/zeoserver.py A build/src/ZEO/tests/testMonitor.py A build/src/ZEO/ClientStub.py A build/src/ZEO/version.txt A build/src/ZEO/DebugServer.py A build/src/ZEO/util.py A build/src/ZEO/TransactionBuffer.py A build/src/ZEO/zeopasswd.py A build/src/ZEO/Exceptions.py A build/src/ZEO/runzeo.py A build/src/ZEO/interfaces.py A build/src/ZEO/mkzeoinst.py A build/src/ZEO/README.txt A build/src/ZEO/monitor.py A build/src/ZEO/zrpc A build/src/ZEO/zrpc/error.py A build/src/ZEO/zrpc/client.py A build/src/ZEO/zrpc/__init__.py A build/src/ZEO/zrpc/connection.py A build/src/ZEO/zrpc/log.py A build/src/ZEO/zrpc/smac.py A build/src/ZEO/zrpc/trigger.py A build/src/ZEO/zrpc/server.py A build/src/ZEO/zrpc/_hmac.py A build/src/ZEO/zrpc/marshal.py A build/src/ZODB A build/src/ZODB/historical_connections.txt A build/src/ZODB/fsrecover.py A build/src/ZODB/BaseStorage.py A build/src/ZODB/Connection.py A build/src/ZODB/__init__.py A build/src/ZODB/fsIndex.py A build/src/ZODB/scripts A build/src/ZODB/scripts/migrate.py A build/src/ZODB/scripts/fsrefs.py A build/src/ZODB/scripts/simul.py A build/src/ZODB/scripts/space.py A build/src/ZODB/scripts/fsdump.py A build/src/ZODB/scripts/stats.py A build/src/ZODB/scripts/zodbload.py A build/src/ZODB/scripts/referrers.py A build/src/ZODB/scripts/__init__.py A build/src/ZODB/scripts/netspace.py A build/src/ZODB/scripts/tests.py A build/src/ZODB/scripts/analyze.py A build/src/ZODB/scripts/manual_tests A build/src/ZODB/scripts/manual_tests/testfstest.py A build/src/ZODB/scripts/manual_tests/testzeopack.py A build/src/ZODB/scripts/manual_tests/testrepozo.py A build/src/ZODB/scripts/manual_tests/test-checker.fs A build/src/ZODB/scripts/fstest.py A build/src/ZODB/scripts/fstail.txt A build/src/ZODB/scripts/repozo.py A build/src/ZODB/scripts/fstail.py A build/src/ZODB/scripts/checkbtrees.py A build/src/ZODB/scripts/README.txt A build/src/ZODB/scripts/referrers.txt A build/src/ZODB/scripts/fsstats.py A build/src/ZODB/scripts/fsoids.py A build/src/ZODB/cross-database-references.txt A build/src/ZODB/collaborations.txt A build/src/ZODB/ActivityMonitor.py A build/src/ZODB/config.py A build/src/ZODB/UndoLogCompatible.py A build/src/ZODB/DemoStorage.py A build/src/ZODB/subtransactions.txt A build/src/ZODB/component.xml A build/src/ZODB/tests A build/src/ZODB/tests/test_fsdump.py A build/src/ZODB/tests/dbopen.txt A build/src/ZODB/tests/__init__.py A build/src/ZODB/tests/blob_importexport.txt A build/src/ZODB/tests/test_storage.py A build/src/ZODB/tests/testhistoricalconnections.py A build/src/ZODB/tests/Corruption.py A build/src/ZODB/tests/BasicStorage.py A build/src/ZODB/tests/util.py A build/src/ZODB/tests/TransactionalUndoStorage.py A build/src/ZODB/tests/RecoveryStorage.py A build/src/ZODB/tests/loggingsupport.py A build/src/ZODB/tests/test_doctest_files.py A build/src/ZODB/tests/testfsoids.py A build/src/ZODB/tests/testSerialize.py A build/src/ZODB/tests/warnhook.py A build/src/ZODB/tests/testConnectionSavepoint.py A build/src/ZODB/tests/dangle.py A build/src/ZODB/tests/blob_consume.txt A build/src/ZODB/tests/StorageTestBase.py A build/src/ZODB/tests/testUtils.py A build/src/ZODB/tests/blob_packing.txt A build/src/ZODB/tests/testTimeStamp.py A build/src/ZODB/tests/test_datamanageradapter.py A build/src/ZODB/tests/synchronizers.txt A build/src/ZODB/tests/blob_transaction.txt A build/src/ZODB/tests/testPersistentMapping.py A build/src/ZODB/tests/testcrossdatabasereferences.py A build/src/ZODB/tests/testDB.py A build/src/ZODB/tests/ConflictResolution.py A build/src/ZODB/tests/test_lock_file.py A build/src/ZODB/tests/PackableStorage.py A build/src/ZODB/tests/testmvcc.py A build/src/ZODB/tests/blob_tempdir.txt A build/src/ZODB/tests/testZODB.py A build/src/ZODB/tests/Synchronization.py A build/src/ZODB/tests/ReadOnlyStorage.py A build/src/ZODB/tests/sampledm.py A build/src/ZODB/tests/testFileStorage.py A build/src/ZODB/tests/testConfig.py A build/src/ZODB/tests/blob_basic.txt A build/src/ZODB/tests/testblob.py A build/src/ZODB/tests/MinPO.py A build/src/ZODB/tests/blob_connection.txt A build/src/ZODB/tests/testconflictresolution.py A build/src/ZODB/tests/testpersistentclass.py A build/src/ZODB/tests/multidb.txt A build/src/ZODB/tests/testPersistentList.py A build/src/ZODB/tests/testConnection.py A build/src/ZODB/tests/testfsIndex.py A build/src/ZODB/tests/speed.py A build/src/ZODB/tests/test_cache.py A build/src/ZODB/tests/testCache.py A build/src/ZODB/tests/testActivityMonitor.py A build/src/ZODB/tests/testRecover.py A build/src/ZODB/tests/MTStorage.py A build/src/ZODB/tests/testDemoStorage.py A build/src/ZODB/tests/IteratorStorage.py A build/src/ZODB/tests/testConnectionSavepoint.txt A build/src/ZODB/tests/testMappingStorage.py A build/src/ZODB/tests/testBroken.py A build/src/ZODB/tests/RevisionStorage.py A build/src/ZODB/tests/PersistentStorage.py A build/src/ZODB/tests/HistoryStorage.py A build/src/ZODB/config.xml A build/src/ZODB/persistentclass.txt A build/src/ZODB/transact.py A build/src/ZODB/MappingStorage.py A build/src/ZODB/interfaces.py A build/src/ZODB/DB.py A build/src/ZODB/dbmStorage.py A build/src/ZODB/serialize.py A build/src/ZODB/fstools.py A build/src/ZODB/loglevels.py A build/src/ZODB/DEPENDENCIES.cfg A build/src/ZODB/utils.py A build/src/ZODB/SETUP.cfg A build/src/ZODB/conversionhack.py A build/src/ZODB/ConflictResolution.txt A build/src/ZODB/ExportImport.py A build/src/ZODB/storage.xml A build/src/ZODB/FileStorage A build/src/ZODB/FileStorage/format.py A build/src/ZODB/FileStorage/fsdump.py A build/src/ZODB/FileStorage/__init__.py A build/src/ZODB/FileStorage/FileStorage.py A build/src/ZODB/FileStorage/fsoids.py A build/src/ZODB/FileStorage/fspack.py A build/src/ZODB/lock_file.txt A build/src/ZODB/blob.py A build/src/ZODB/broken.py A build/src/ZODB/POSException.py A build/src/ZODB/ConflictResolution.py A build/src/ZODB/persistentclass.py A build/src/ZODB/lock_file.py A build/COPYING A build/README.txt U build Checked out revision 87215. -------------- next part -------------- Creating directory '/home/ctheune/zope.org/slave/ZODB/build/bin'. Creating directory '/home/ctheune/zope.org/slave/ZODB/build/parts'. Creating directory '/home/ctheune/zope.org/slave/ZODB/build/develop-eggs'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/buildout'. -------------- next part -------------- Upgraded: zc.buildout version 1.0.3, setuptools version 0.6c8; restarting. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/buildout'. Develop: '/home/ctheune/zope.org/slave/ZODB/build/.' Installing test. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/test'. Installing scripts. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/mkzeoinst'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/fstail'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/zeopack'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/runzeo'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/zeopasswd'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/zeoctl'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/fsdump'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/fsrefs'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/repozo'. Generated script '/home/ctheune/zope.org/slave/ZODB/build/bin/fsoids'. Generated interpreter '/home/ctheune/zope.org/slave/ZODB/build/bin/py'. -------------- next part -------------- Running unit tests: Failure in test checkVerificationWith2ClientsInvqOverflow (ZEO.tests.testConnection.FileStorageInvqTests) Traceback (most recent call last): File "/usr/local/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 753, in checkVerificationWith2ClientsInvqOverflow self.fail("timed out waiting for endVerify") File "/usr/local/lib/python2.4/unittest.py", line 301, in fail raise self.failureException, msg AssertionError: timed out waiting for endVerify The following test left new threads behind: checkVerificationWith2ClientsInvqOverflow (ZEO.tests.testConnection.FileStorageInvqTests) New thread(s): [] Error in test checkBasicPersistence (ZEO.tests.testConnection.MappingStorageConnectionTests) Traceback (most recent call last): File "/usr/local/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 433, in checkBasicPersistence self._storage = self.openClientStorage('test', 100000) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 194, in openClientStorage realm=realm) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/ClientStorage.py", line 342, in __init__ self._cache = self.ClientCacheClass(cache_path, size=cache_size) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/cache.py", line 168, in __init__ self._lock_file = ZODB.lock_file.LockFile(path + '.lock') File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 80, in __init__ _lock_file(fp) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 59, in _lock_file raise LockError("Couldn't lock %r" % file.name) LockError: Couldn't lock '/tmp/test-1.zec.lock' Error in test checkDisconnectedCacheFails (ZEO.tests.testConnection.MappingStorageConnectionTests) Traceback (most recent call last): File "/usr/local/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 469, in checkDisconnectedCacheFails self._storage = self.openClientStorage('test', cache_size=900) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 194, in openClientStorage realm=realm) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/ClientStorage.py", line 342, in __init__ self._cache = self.ClientCacheClass(cache_path, size=cache_size) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/cache.py", line 168, in __init__ self._lock_file = ZODB.lock_file.LockFile(path + '.lock') File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 80, in __init__ _lock_file(fp) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 59, in _lock_file raise LockError("Couldn't lock %r" % file.name) LockError: Couldn't lock '/tmp/test-1.zec.lock' Error in test checkDisconnectedCacheWorks (ZEO.tests.testConnection.MappingStorageConnectionTests) Traceback (most recent call last): File "/usr/local/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 447, in checkDisconnectedCacheWorks self._storage = self.openClientStorage('test') File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 194, in openClientStorage realm=realm) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/ClientStorage.py", line 342, in __init__ self._cache = self.ClientCacheClass(cache_path, size=cache_size) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/cache.py", line 168, in __init__ self._lock_file = ZODB.lock_file.LockFile(path + '.lock') File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 80, in __init__ _lock_file(fp) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 59, in _lock_file raise LockError("Couldn't lock %r" % file.name) LockError: Couldn't lock '/tmp/test-1.zec.lock' Error in test checkDisconnectionError (ZEO.tests.testConnection.MappingStorageConnectionTests) Traceback (most recent call last): File "/usr/local/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 386, in checkDisconnectionError self._storage = self.openClientStorage('test', 1000, wait=0) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 194, in openClientStorage realm=realm) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/ClientStorage.py", line 342, in __init__ self._cache = self.ClientCacheClass(cache_path, size=cache_size) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/cache.py", line 168, in __init__ self._lock_file = ZODB.lock_file.LockFile(path + '.lock') File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 80, in __init__ _lock_file(fp) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 59, in _lock_file raise LockError("Couldn't lock %r" % file.name) LockError: Couldn't lock '/tmp/test-1.zec.lock' Error in test checkMultipleAddresses (ZEO.tests.testConnection.MappingStorageConnectionTests) Traceback (most recent call last): File "/usr/local/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 274, in checkMultipleAddresses self._storage = self.openClientStorage('test', 100000) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/tests/ConnectionTests.py", line 194, in openClientStorage realm=realm) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/ClientStorage.py", line 342, in __init__ self._cache = self.ClientCacheClass(cache_path, size=cache_size) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZEO/cache.py", line 168, in __init__ self._lock_file = ZODB.lock_file.LockFile(path + '.lock') File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 80, in __init__ _lock_file(fp) File "/home/ctheune/zope.org/slave/ZODB/build/src/ZODB/lock_file.py", line 59, in _lock_file raise LockError("Couldn't lock %r" % file.name) LockError: Couldn't lock '/tmp/test-1.zec.lock' Error in test checkMultipleServers (ZEO.te