December 2005 - Zope-Dev

buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin
by buildbot＠zope.com 21 Dec '05

21 Dec '05

The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 zc-bbwin. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2376 Blamelist: anguenot,efge,frerich,hdima,jim,poster BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin
by buildbot＠zope.com 21 Dec '05

21 Dec '05

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Windows 2000 zc-bbwin. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2375 Blamelist: anguenot,efge,frerich,hdima,jim,philikon,poster BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 21 Dec '05

21 Dec '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2376 Blamelist: anguenot,efge,frerich,hdima,jim,poster BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Re: [Zope-dev] Re: svn.zope.org borked
by Alan Milligan 20 Dec '05

20 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens, I have the latest subversion-1.2.3-4 compiled for python2.3. I am happy to make them available to you if you wish. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDp/1gCfroLk4EZpkRAg9jAKCAUkIuyhK1q7mrCiscfxpSM7tMwACeLt3J WIn0K8ovArTGMtcKnO+MOCw= =oFtk -----END PGP SIGNATURE-----

2 1

Zope tests: 8 OK
by Zope tests summarizer 20 Dec '05

20 Dec '05

Summary of messages to the zope-tests list. Period Mon Dec 19 12:01:02 2005 UTC to Tue Dec 20 12:01:02 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Mon Dec 19 20:51:25 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003802.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Dec 19 20:52:56 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003803.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Dec 19 20:54:26 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003804.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 19 20:55:56 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003805.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Dec 19 20:57:26 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003806.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 19 20:58:56 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003807.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 19 21:00:26 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003808.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 19 21:01:56 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003809.html

1 0

Re: [Zope] Re: [Zope-dev] Re: sessions in the presence of conflicts
by Dennis Allison 20 Dec '05

20 Dec '05

The interaction between sessions, conflicts, and persistence is a bit confusing. I am still trying to understand the code in depth. One thing is for sure, request.SESSION and/or request['SESSION'] must be persistent for things to work. Mutable objects in the session variable set (dictionaries and lists) have to be handled specially to get the persistence machinery to recognize they have been changed. In this case, I am trying to ensure that the session variables get identified as persistent. My question is whether using update (an implicit assignment) triggers the persistence mechanism. It is the moral equivalent of writing request['SESSION']['alpha'] = 'a'B request['SESSION']['beta'] = 'b' but I am unsure whether the persistence mechanism will recognize it as such. Doing session variable initialization in a Script(Python) object has a downside because one cannot set a _p_changed attribute and so must rely on the assignment paradigm. Perhaps the interface should be in a Product or External Method which is less constrained. Anyhow, David, thanks for the assist. On Mon, 19 Dec 2005, David H wrote: > Dennis Allison wrote: > > >Chris McDonough identified a persistence problem with the routine(s) that > >manage sessions variables. (Thanks Chris) I have put the correction in > >place which resolved some (but not all) of the problems. > > > >There are still problems which are apparently due conflicts in accessing > >the session variables. To minimize frequency of conflicts, I am rewriting > >several routines using Dieter's rules of the thumb (Thanks Dieter). > > > >One routine being modified is a Script(Python) that initializes a number > >of session variables. I am collecting the session values in a dictionary > >and then use update to set their value, for example: > > > > s = {} > > s['alpha'] = 'a' > > s['beta'] = 'b' > > request['SESSION'].update(s) > > > >Is the persistence machinery smart enough to detect this as a change? I > >suspect that it has to be flagged since the assignment won't be seen. > >Usually this means setting the _p_changed=1 attribute, but it is not clear > >to me where to set it in this particular context. > > > Dennis, > > Did you means request['SESSION']['someDictionary'].update(s)? > Anyway your idea seems correct - The SESSIONS chapter (at least on > plope.com) addresses SESSION "staleness" and mutable objects. > > 1) someDict = SESSION['someDict'] > 2) someDict['someKey'] = "newValue" > > But (2) does not guarentee that a subsequent lookups like: > SESSION['someDict'] will return "newValue". > > But this WILL: > 3) SESSION['someDict'] = someDict. > > Which looks like your example. How this connect to your primary issue: > *conflicts* is not clear to me. :-\ > > David > > --

2 1

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2342 Blamelist: shh BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Re: Unit Test Failures
by Tres Seaver 20 Dec '05

20 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: > >>Benji York wrote: >> >>>The Zope2 unit tests have been failing for some time on >>>buildbot.zope.com. Looks like a Five-related problem: >>>http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/10… >> >>The failing test is a functional test, not a unit test; I don't run >>them by default when I check in. > > Actually, I put this particular test (functional.txt) on level=2 because it would fail > when run together with other Five tests. It passes fine when run by itself. This test > exists identically in Five 1.2 (based on Zope 2.8) where it passes just fine when run > together with other tests and by itself. During the hot phase of making the deadline on > November 1st, I decided that this wasn't a big issue and could be resolved during the > beta phase (after all, the test passes by itself). I obviously forgot to look into it > again, but then again, I still don't know what the heck is wrong with this. > >> I see a couple of problem points: the biggest is the use in the >> output of 'checkSiteManager.html' of a repr'ed dict, which might >> render differently between different machines (or even the same >> machine across Python versions). > > Well, if you look closer you find that it uses pprint.pformat which always outputs the > same on all machines (because it provides output sorted by the dictionary key). I see that in the implementation; it isn't documented as part of pprint's contract, however. >> This is a classic case where the "doctest" does *not* provide >> clarity over a "traditional" 'unittest' style test, IMNSHO. > > Comparing dictionaries is not trivial in classic javiotic tests, either. Using pprint is > actually quite an elegant way, I think. But the dictionary here is an *artifact* -- what you are really trying to do would be expressed as individual assertions in a classic unit test: self.failUnless(IFiveUtilityRegistry.providedBy(utility_service)) self.failIf(zapi.getSiteManager() is zapi.getGlobalSiteManager()) etc. If you really want to test equality of dictionaries, then 'self.assertEqual' does the trick just fine. >>I'm not sure what it is testing, either; > > It's testing how local site managers get found during traversal and how that affects > component lookup of e.g. views (depending on which site is traversed, you would find > local components or not). OK, thanks! Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDptfi+gerLs4ltQ4RAtfkAKCiJLa+s+8GaNxew9DcIPWrbw7qXgCeNaSj csBJ641nurB0xPwBu6xLByY= =juKw -----END PGP SIGNATURE-----

6 15

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2341 Blamelist: shh BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 20 Dec '05

20 Dec '05

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2340 Blamelist: andreasjung BUILD FAILED: failed test sincerely, -The Buildbot

1 0