June 2005 - Zope-Dev

Zope 2.7.7 release schedule
by Andreas Jung 15 Jun '05

15 Jun '05

Planned release dates are: 2.7.7 b1 : July, 3rd 2.7.7 final: July, 10th All dates in 2005 of course :-) Cheers, -aj

1 0

Upcoming Zope 2.8 release
by Andreas Jung 14 Jun '05

14 Jun '05

Hi, after resolving all outstanding problems with Zope 2.8 under Windows the next releases will be Zope 2.8 b2 (this weekend) and Zope 2.8.0 final (scheduled for 2005/06/11). I will cut a 2.8 release branch for Zope 2.8 b2. This means that the trunk is open for new development (Zope 2.9). Bugs (as always) have to be fixed on the 2.8 branch, SVN trunk and 2.7 branch (CVS). Andreas

5 11

Re: [Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ - Collector #1792: applied patch for broken ZClasses
by Florent Guillaume 13 Jun '05

13 Jun '05

> Modified: Zope/branches/Zope-2_8-branch/lib/python/ZClasses/_pmc.py > =================================================================== > --- Zope/branches/Zope-2_8-branch/lib/python/ZClasses/_pmc.py 2005-06-10 23:57:01 UTC (rev > 30750) > +++ Zope/branches/Zope-2_8-branch/lib/python/ZClasses/_pmc.py 2005-06-11 06:20:42 UTC (rev > 30751) > @@ -56,15 +56,20 @@ > ExtensionClass.pmc_init_of(result) > return result > > + # copy_reg.py:_slotnames() tries to use this attribute as a cache. > + # Dont allow this attribute to be written as it may cause us > + # to register with the data_manager. > + __slotnames__ = property(None) > + > def __setattr__(self, name, v): > + super(ZClassPersistentMetaClass, self).__setattr__(name, v) > if not ((name.startswith('_p_') or name.startswith('_v'))): > self._p_maybeupdate(name) > - super(ZClassPersistentMetaClass, self).__setattr__(name, v) Not caused by this patch, but shouldn't this be '_v_' instead of '_v' ? ZODB/persistentclass.py has the same code, by the way... Florent > > def __delattr__(self, name): > + super(ZClassPersistentMetaClass, self).__delattr__(name) > if not ((name.startswith('_p_') or name.startswith('_v'))): > self._p_maybeupdate(name) > - super(ZClassPersistentMetaClass, self).__delattr__(name) > -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

2 2

Windows Builds
by Christian Theune 13 Jun '05

13 Jun '05

Hi, it looks like in principle the windows building mechanism got a bit better in the last time. Unfortunately I'm extremely busy and couldn't follow all the changes that are required on my building site, so I'm technically currently not able to compile the release for 2.8 final. If Tim (or someone else) is able (regarding time and technical abilities) and willing to care for the Windows builds in future, I'd like to step back from the job of creating the Windows builds. I'm not using Windows on a daily basis and it is very time consuming to keep a working building environment around when something changes. Cheers, Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct(a)gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development

2 1

ZpdfDocument
by Fernando Lujan 13 Jun '05

13 Jun '05

Hi, Are someone developing some Product like ZpdfDocument? Today, If I need a pdf file, I use the reporlab lib, and write it from scratch... A better solution exist? Thanks and Regards. -- Fernando Lujan

3 2

Zope 2.8 coming this weekend
by Andreas Jung 10 Jun '05

10 Jun '05

Heads up for the 2.8.0 final release. My plans are to make the final release on Saturday morning. So any further changes should be done by tomorrow at the latest. Cheers, -aj

4 11

Logging after ConflictError Retries
by Malcolm Cleaton 10 Jun '05

10 Jun '05

After a ConflictError causes a request to be retried, a few things go a bit wrong with error handling and logging in the Zope server. 1. If the request is abandoned after repeated ConflictErrors, no error at all appears in the error log. The following change to Zope/App/startup.py appears to fix this, although I'm not sufficiently experienced in the depths of Zope to be sure there are no downsides: 162,163c162 < if REQUEST.supports_retry(): < raise ZPublisher.Retry(t, v, traceback) --- > raise ZPublisher.Retry(t, v, traceback) If a Retry error is raised again here even though we don't support any more retries, the ZServer calls the exception hook again with the Retry error, we throw it again and the error logging is missed. Simply not raising the Retry error again once we don't support any more retries means we fall through to the rest of the exception handling hook, and the ConflictError itself is logged, which I think is right. 2. If there is at least one ConflictError and then the request finishes with an error (either more ConflictErrors or something else), the Z2 log shows the request as having been answered with status 200, although actually a status 500 error response has been served. I've managed to work out what's causing this, but fixing may be more fiddly. What happens is, once the request is abandoned because of the error, when control comes back to publish_module_standard in Publish.py, response.exception() is called on the original response, not on the latest retry. Then, when HTTPResponse _finish() is called, it traces down to the latest retry to find the status code for the logging, which is now the wrong one. I can think of a few things which might fix this, but they all feel like they might also break many other subtle things, and I've got The Fear; can somebody more experienced in the core comment on the Right Way? I've submitted this to the Collector: http://www.zope.org/Collectors/Zope/1805 Thanks, Malcolm. -- [] j a m k i t web solutions for charities malcolm cleaton T: 020 7549 0520 F: 020 7490 1152 M: 07986 563852 W: www.jamkit.com

2 5

[Proposal] Drop Mount.py from ZODB 3.5
by Tim Peters 10 Jun '05

10 Jun '05

http://www.zope.org/Collectors/Zope/1800 describes some of the code problems with Zope's current way of mounting databases. ZODB 3.4 (still) has a Mount.py module, unused and untested by ZODB. Jim and I were both surprised today to discover that Zope (2.8) still imports it, so we can't drop it for ZODB 3.4 (Zope 2.8, and the ZODB 3.4 it uses, are both in beta). We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's "standalone" ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ...

6 7

spider cache blowout [was RE: [ZODB-Dev] Generational Caching]
by Dylan Jay 09 Jun '05

09 Jun '05

> -----Original Message----- > From: Chris McDonough [mailto:chrism@plope.com] > Sent: Wednesday, 8 June 2005 11:56 AM > To: Dylan Jay > Cc: zodb-dev(a)zope.org > Subject: Re: [ZODB-Dev] Generational Caching > > One way to potentially soften the impact of cache busting by spiders > might be to allow Zope to choose a particular ZODB connection based on > request parameters (like sessionid or requesting ip address, or most > likely user agent in the case of "legitimate" spiders). This is a > modification to Zope that would be largely independent of ZODB, > however, so might be more appropriate to discuss on zope-dev. I think this sounds like a very smart idea. I'll forward this to the zope-dev list. > On Wed, 2005-06-08 at 10:20 +1000, Dylan Jay wrote: > > I've been thinking about the problems of memory use. One use case > > that > seems > > hard is web crawlers. That will wake up a lot of objects for just a > single > > read possibly getting rid of many often used objects from the zodb > cache. > > Has anyone investigated the idea of a generational cache? > > > > Another idea I had was asymetric cache sizes. I believe that zope > > uses a single thread if all requests are serial and just uses the > > other > connections > > when similtanious requests are handled. Since some threads will be > > less > used > > than others perhaps there could be cache settings so memory can be > > minimised. > > > -- Dylan Jay --- http://www.meetmemap.com - makes giving directions easy http://www.pretaweb.com - Update-it-yourself, low cost websites http://www.eatmanifesto.com - against all dumbing down of food Y!:dylan_jay ICQ:520341 MSN:djsq@hotmail.com Ph:+61423198306

1 0

Re: [Zope-Checkins] CVS: Packages/Signals - WinSignalHandler.py:1.1.2.2
by Tim Peters 07 Jun '05

07 Jun '05

[Mark Hammond] > Update of /cvs-repository/Packages/Signals > In directory cvs.zope.org:/tmp/cvs-serv23505 > > Modified Files: > Tag: Zope-2_7-branch > WinSignalHandler.py > Log Message: > As at pywin32-204, we must ensure pywintypes is the first win32 module > imported in our process, otherwise we can end up with 2 pywintypesxx.dll > instances in our process resulting in: > TypeError: The object is not a PySECURITY_ATTRIBUTES object Mark, should Zope's nt_svcutils/service.py also be changed to import pywintypes first? Its import block looks like this now: import sys, os, time, threading, signal import win32api, win32event, win32file, win32pipe, win32process, win32security import win32service, win32serviceutil, servicemanager import pywintypes, winerror, win32con I had "funny problems" getting the Windows ZRS installer to register the ZRS service on older machines, primarily the python.exe - Entry Point Not Found The procedure entry point ?PyWinObject_AsDEVMODE@@YAHPAU_object@@PAPAU_devicemodeA@@H@Z could not be located in the dynamic link library pywintypes23.dll popup box on a machine with an older pywintypes23.dll in the system32 directory.

2 1