August 2004 - Zope - Zope lists

RE: [Zope] Zope2.7.2 with ActivePython2.3.2
by Jim Abramson 25 Aug '04

25 Aug '04

Thanks Tim, I definitely understand your point and knowing about these issues is certainly useful. Maybe mentioning the unit tests muddied my original question. My practical reality is a production environment in which a number of applications are already in heavy use, running happily against python2.3.2. I want to run an up-to-date Zope2 that can talk to these applications (i.e. as a frontend utility), without the considerable block of setting up a whole new python build and upsetting the otherwise-placid state of affairs. What's confusing, though not exactly critical, is why source distributions seem to allow for some leeway as far as which python version you build Zope onto, but binaries have this less forgiving posture. The less-forgiving approach implies that Zope will not work with an earlier py version, but that doesn't exactly seem to be the case (it works, just 'sub-optimally'). Jim -----Original Message----- From: Tim Peters [mailto:tim.peters@gmail.com] Sent: Tuesday, August 24, 2004 5:05 PM To: Jim Abramson Cc: zope(a)zope.org Subject: Re: [Zope] Zope2.7.2 with ActivePython2.3.2 [Jim Abramson] > As a small aside to this topic, I just ran the (entire?) suite of unit > tests - 2586 of them - with Zope2.7.2 using an ActivePython2.3.2 > binary install (pretty much out of the box) on WinXP. I realize this > isn't everything as far as a full compatibility assessment goes - but > nothing erred. Bugfix releases of Python strive not to change visible behavior, so that's not surprising. Later versions of Python are generally required because of bugs in Python that afffected Zope, often in endcases so bizarre (Zope plays in Python's dark corners like few other apps dare) that only one way to trigger it is ever discovered. Tests to ensure that such bugs are fixed end up in Python's test suite, not in Zope's -- because they're Python bugs, not Zope bugs. For example, here are a subset of items fixed in Python 2.3.3 that were discovered in Zope (2 or 3): - Critical bugfix, for SF bug 839548: if a weakref with a callback, its callback, and its weakly referenced object, all became part of cyclic garbage during a single run of garbage collection, the order in which they were torn down was unpredictable. It was possible for the callback to see partially-torn-down objects, leading to immediate segfaults, or, if the callback resurrected garbage objects, to resurrect insane objects that caused segfaults (or other surprises) later. In one sense this wasn't surprising, because Python's cyclic gc had no knowledge of Python's weakref objects. It does now. When weakrefs with callbacks become part of cyclic garbage now, those weakrefs are cleared first. The callbacks don't trigger then, preventing the problems. If you need callbacks to trigger, then just as when cyclic gc is not involved, you need to write your code so that weakref objects outlive the objects they weakly reference. - Critical bugfix, for SF bug 840829: if cyclic garbage collection happened to occur during a weakref callback for a new-style class instance, subtle memory corruption could result (in a release build; in a debug build, a segfault occurred reliably very soon after). This has been repaired. - At Python shutdown time (Py_Finalize()), 2.3 called cyclic garbage collection twice, both before and after tearing down modules. The call after tearing down modules has been disabled, because too much of Python has been torn down then for __del__ methods and weakref callbacks to execute sanely. The most common symptom was a sequence of uninformative messages on stderr when Python shut down, produced by threads trying to raise exceptions, but unable to report the nature of their problems because too much of the sys module had already been destroyed. There are more in 2.3.4: - Fixed problem where PyWeakref_NewRef() and PyWeakref_NewProxy() assumed that initial existing entries in an object's weakref list would not be removed while allocating a new weakref object. Since GC could be invoked at that time, however, that assumption was invalid. In a truly obscure case of GC being triggered during creation for a new weakref object for an referent which already has a weakref without a callback which is only referenced from cyclic trash, a memory error can occur. This consistently created a segfault in a debug build, but provided less predictable behavior in a release build. - Fixed a bug in object.__reduce_ex__ when using protocol 2. Failure to clear the error when attempts to get the __getstate__ attribute fail caused intermittent errors and odd behavior. You're insane if you think you want to track down one of those nightmares yourself all over again <wink>.

3 2

RE: [Zope] Zope2.7.2 with ActivePython2.3.2
by Jim Abramson 24 Aug '04

24 Aug '04

As a small aside to this topic, I just ran the (entire?) suite of unit tests - 2586 of them - with Zope2.7.2 using an ActivePython2.3.2 binary install (pretty much out of the box) on WinXP. I realize this isn't everything as far as a full compatibility assessment goes - but nothing erred. Jim -----Original Message----- From: Ausum Studio [mailto:ausum_studio@hotmail.com] Sent: Tuesday, August 24, 2004 3:23 PM To: zope(a)zope.org Subject: Re: [Zope] Zope2.7.2 with ActivePython2.3.2 (erratum corrected) I agree that Zope 2.7.2's deafult installation works OK in w2k. Unfortunately, there are many reasons why there's this need to use at least a system Python installation, and the main one is maybe that many Python add-ons distributed as binary installers require the system-registered version, while they can't recognize Zope's one. >From that perspective, current stable Zope 2.7.2 still has issues that previous releases didn't use to have. Ausum ----- Original Message ----- From: "Chris Withers" <chris(a)simplistix.co.uk> (...) > For Zope on Windows, I'd recommend just usingthe Zope binary installer > for windows and not trying to do anything clever ;-) > > cheers, > > Chris > > -- _______________________________________________ Zope maillist - Zope(a)zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )

2 1

question about displaying object content in page template
by Andras Frankel 24 Aug '04

24 Aug '04

Hello, I would like to ask for help concerning page templates. I created two classes. First one is called "CatPageTemp", and it has the property "MyContent" of type TextArea. MyContent contains HTML encoded text. The second class is called "PageLayout", and has a property called "ModNames" of type tokens. ModNames contains a list of objects of type CatPageTemp that reside in folder /SSS/priv. Note that the folder name is not explicitly stored in ModNames. I created a page_template called index_html in PageLayout, whose goal is to iterate through the object names in ModNames and display the content of their "MyContent". Here is the code: <ul> <span tal:repeat="item template/ModNames"> <li tal:content="item"></li> <span tal:define="file python:'/root/SSS/priv/' + item" tal:condition="exists:file/MyContent" tal:replace="structure file/MyContent"></span> </span> </ul> Now, that doesn't work. Zope believes that file/MyContent doesn't exist, even though it does. I tried displaying the value of the attribute/variable (?) "file", and it indeed is /root/SSS/priv/<some_object> which is correct. Can somebody tell me what's wrong and help me how to fix this? Thanks. Andras PS: I am ready to give clarifications if this post is not clear enough.

2 2

Re: [Zope] Zope2.7.2 with ActivePython2.3.2
by Ausum Studio 24 Aug '04

24 Aug '04

(erratum corrected) I agree that Zope 2.7.2's deafult installation works OK in w2k. Unfortunately, there are many reasons why there's this need to use at least a system Python installation, and the main one is maybe that many Python add-ons distributed as binary installers require the system-registered version, while they can't recognize Zope's one. >From that perspective, current stable Zope 2.7.2 still has issues that previous releases didn't use to have. Ausum ----- Original Message ----- From: "Chris Withers" <chris(a)simplistix.co.uk> (...) > For Zope on Windows, I'd recommend just usingthe Zope binary installer > for windows and not trying to do anything clever ;-) > > cheers, > > Chris > > --

1 0

Zope2.7.2 with ActivePython2.3.2
by Jim Abramson 24 Aug '04

24 Aug '04

Anybody out there doing this? Our co. is using the ActivePy 2.3.2 for a number of other systems - I want to upgrade our 2.6.2 zope to the latest...wondering if there are any caveats. I know out-of-the-box 2.7.2 will complain about the python version, the plan was to -ahem- hack around this... Thanks, Jim

3 2

Upgrade 2.7 > 2.7.2: Unreleased version message
by hpinson＠indepthl.com 24 Aug '04

24 Aug '04

Upon upgrading to Zope 2.7.2, version information now reports: (unreleased version, python 2.3.3, linux2) Is the "unreleased version" normal? Any other way to confirm a version number? Harlow Pinson Indepth Learning Email: hpinson(a)indepthl.com Web: http://www.indepthl.com Voice: 505-994-2135 FAX: 208-475-7678

3 2

Zope contract work
by Roché Compaan 24 Aug '04

24 Aug '04

If there are any individuals or small companies looking for Zope contract work, please send me a mail indicating your hourly rate for short and long term contracts. Include any relevant information that sells your skills and experience. Thanks, -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za

1 0

Reverting to previous version of Zope
by Tiller, Michael (M.M.) 24 Aug '04

24 Aug '04

I have a system running Zope 2.7.2 but because of a critical bug (http://zope.org/Collectors/Zope/1401) I'd like to revert to Zope 2.7.0. I have Zope 2.7.0 installed, but in my instance directory I changed zopectl, runzope and zope.conf to point to Zope 2.7.0 but it still invokes Zope 2.7.2 (at least according to what Control Panel says). How do you control what version of Zope is run? It seems like there are all these environment variables (in the files I listed above) but none of them seem to actually affect it?!? Any suggestions? -- Mike

2 1

RE: [Zope] Zope2.7.2 with ActivePython2.3.2
by Jim Abramson 24 Aug '04

24 Aug '04

Thanks, OK I see, Zope 2.7.2 will give you a hard time on Win32 if you, for some ghastly reason, try to hook it up to some external python.exe with < 2.3.3 - but should build on Linux for example with anything past 2.2.2 (if I'm reading correctly at plope.com)...yes? I do a lot of development on windows but our production environments are linux, and I was confused by the discrepancy here. Is the windows version restriction really just a disincentive against using any other binary than the one that ships with Zope? Jim -----Original Message----- From: Chris Withers [mailto:chris@simplistix.co.uk] Sent: Tuesday, August 24, 2004 4:53 AM To: Jim Abramson Cc: zope(a)zope.org Subject: Re: [Zope] Zope2.7.2 with ActivePython2.3.2 Jim Abramson wrote: > I know out-of-the-box 2.7.2 will complain about the python version, > the plan was to -ahem- hack around this... For Zope on Windows, I'd recommend just usingthe Zope binary installer for windows and not trying to do anything clever ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

ZEO, Persistent Sessions
by Travis Miller 24 Aug '04

24 Aug '04

hi, my zeo setup is running like a top :-) ...until! i would like my zeo clients to share the same session storage. out of the box, zope has a temporary storage database (/temp_folder) for the session data (/temp_folder/session_data). the session data manager (/session_data_manager) is then configured to pull from the session data (/temp_folder/session_data). my first inclination was to create another session data object (/session_folder/session_data) in the main database and to configure the session data manager to pull from it. (i've also tried using a separate zeo filestorage and mounting it. as expected, i saw the same results through out.) however, when i do this, it seems as though only one zeo client is allowed to use the session. a simple python script that prints request.SESSION succeeds on one client, but fails with a key error on the other. Traceback (innermost last): Module ZPublisher.Publish, line 101, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Shared.DC.Scripts.Bindings, line 306, in __call__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module Products.PythonScripts.PythonScript, line 323, in _exec Module None, line 7, in test-session - <PythonScript at /Portals/test-session> - Line 7 Module ZPublisher.HTTPRequest, line 1218, in __getattr__ Module ZPublisher.HTTPRequest, line 1178, in get Module Products.Sessions.SessionDataManager, line 94, in getSessionData Module Products.Sessions.SessionDataManager, line 181, in _getSessionDataObject Module Products.Transience.Transience, line 768, in new_or_existing Module Products.Transience.Transience, line 439, in __setitem__ KeyError: 1091449200 i have: python 2.3.4 Zope 2.7.1 ..compiled from source this was all i could really find on zeo clients sharing sessions. it seems to support what i have attempted: http://www.zopelabs.com/cookbook/1061234337 what might i be missing? if sharing the session is a bad idea. where else could i store session like information for a script based application? thanks for any help thanks, travis

4 7