- Zope-Dev - Zope lists

Remove BDBStorage from 2.7 branch as well?
by Stefan H. Holek 04 Jun '04

04 Jun '04

As BDBStorage has been removed from HEAD quite some time ago, I was wondering whether it would be possible/advisable to remove it from 2.7 branch as well. Would it? Stefan -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/

2 1

Calling Zope users/developers active in Sweden and Nordic Countries
by Dario Lopez-Kästen 03 Jun '04

03 Jun '04

Hello, this is a General call to all Zope users and developers that are active in Sweden and other nordic Countries. There is a plan on gathering during the EuroPython Conference to meet and get to know each other and see who we are, what we do and ossibly future models of doing business. If you are interested, please send a message to the Swedish zope-list, zope(a)zope.se with a shor presentation. I hope to see you on EPC! /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.

1 1

Zope runs again on the Zope 2 trunk
by Jim Fulton 02 Jun '04

02 Jun '04

Zope hasn't run on the trunk for about a month and a half due to a bug introduced into the mounting code. The bug is now fixed and Zope runs again. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

More Transience weirdness in 2.7.1b1
by Steve Jibson 02 Jun '04

02 Jun '04

It seems that there may still be some strangeness with Transience. We're running Zope-2.7.1b1 (Python 2.3.3, Fedora Core 1) and after using the system for a day or two, it got the following error on a page that accesses the SESSION: 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 OFS.DTMLDocument, line 128, in __call__ - <DTMLDocument instance at 9e684350> -URL: http://george/login/root/ChooseAccount/chooseAccount/manage_main - Physical Path: /login/root/ChooseAccount/chooseAccount Module DocumentTemplate.DT_String, line 474, in __call__ Module DocumentTemplate.DT_With, line 76, in render Module DocumentTemplate.DT_In, line 703, in renderwob Module DocumentTemplate.DT_Let, line 76, in render Module DocumentTemplate.DT_Util, line 198, in eval - __traceback_info__: value Module <string>, line 1, in <expression> NameError: name 'SESSION' is not defined It doesn't appear to be a problem accessing a variable in the SESSION, but finding "SESSION" itself. So, I hook-up to the ZMI and click on *temp_folder*, then click on *session_data (Session Data Container)* and I get the following error: 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 App.special_dtml, line 62, in __call__ Module DocumentTemplate.DT_String, line 474, in __call__ Module Products.Transience.Transience, line 709, in nudge Module Products.Transience.Transience, line 555, in _gc RuntimeError: the bucket being iterated changed size The same thing happened yesterday and re-starting Zope seemed to get things working again. After the problem yesterday, I changed my temp database to use filestorage to see if that would help. No luck, the problem showed up again today. I have not restarted Zope again today, so my system is still in the "screwed-up" state. Chris, if you'd like, I can probably get you access to the system if there is anything to be learned from it in its current state. Thanks, Steve

3 4

RE: [Zope-dev] Help: __getstate__ overriding
by Dieter Maurer 02 Jun '04

02 Jun '04

Tim Peters wrote at 2004-5-30 14:49 -0400: >[Dieter Maurer] >> I think, this is a ZODB buglet: >> >> It should set "_p_changed = 0" before it calls "__setstate__" >> and not afterwards... > >I don't know; Jim (or Jeremy) may know the reasoning here, but I don't. > >Activation currently sets the state to changed *before* calling __setstate__ >too. A comment says this is to prevent recursively calling _PyPersist_Load, >and that makes sense to me, else unbounded recursion could occur. I see... > ... >On ZODB head, Jeremy also documented that __setstate__ can't affect the >persistent state (in persistent/interfaces.py's IPersistent). Whether this >is deliberate design, or a consequence of the current implementation, I >can't say. A potential problem: it *can* change the persistent state but it does not do it reliably. It does precisely when the object is later modified again: in this case modifications made in "__setstate__" become persistent, otherwise, they do not. -- Dieter

2 2

Placeless Translation Service
by Milos Prudek 02 Jun '04

02 Jun '04

where can I discuss Placeless Translation Service development? The original author Lalo Martins does not respond to emails - current PTS bears a "fork" suffix - who's in charge now? -- Milos Prudek

2 1

RFC: TALES adapters and TAL/Tales variable namespaces
by Jim Fulton 02 Jun '04

02 Jun '04

I've posted two proposals: http://dev.zope.org/Zope3/TALESPathExpressionAdapters Proposes a mechanism for easily using adapters in TALES expressions. http://dev.zope.org/Zope3/ZPTVariableNamespaces proposes a mechanism for qualifying names defined in TAL and used in TALES expressions. Comments are welcome, here or in the pages. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

11 30

Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
by Chris Withers 02 Jun '04

02 Jun '04

Garrett Smith wrote: >> I want to thank everyone who's participating in this >> thread. The input is extremely valuable. > > This might get an award for longest thread before The Edict is handed > down ;) Yeah, and I have to admit being a bemused bystander... I thought we had this whole discussion about 1-2 years ago, and I REMEMBER writing CODE for this back then that involved : as the adapter indicator. Why are we having this whole discussion again? Was there something wrong with the code? :-S Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 5

Re: [Zope] zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
by Richard Ettema 02 Jun '04

02 Jun '04

I tried running the instance on a single thread as suggested by a how-to I found at http://zope.org/Members/matt/StabilityHOWTO This has "fixed" this problem and also another long running problem with a huge memory leak. The howto suggests this indicates a problem with a C -extension. Is there any quick way to track this down or am I stuck with removing products out of the equation until I find the culprit? Is it definite that it will be a problem with a Product or could it be elsewhere in zope/python? Answering a couple of other questions... > > What OS are you running on? Debian stable > > ...why aren't you running on Python 2.3? Currently running zope 2.6.2 but in the middle of upgrading dev server to zope 2.7 and python 2.3 to see if this helps. Thanks for your help with this. Richard.

1 0

Help: __getstate__ overriding
by Syver Enstad 02 Jun '04

02 Jun '04

I have a Persistent derived class where I want to upgrade from using a PersistentList to a BTrees.IOBTree.IOBTree. _articleList is the old Persistent list _oidsToArticles is the new IOBTree. def __setstate__(self, state): articleList = state.get('_articleList') if articleList: oidsToArticles = self.makeBTree() for each in articleList: oidsToArticles[each.oid()] = each del state['_articleList'] state['_oidsToArticles'] = oidsToArticles Persistent.__setstate__(self, state) This seems to work fine, and I am adding more objects to _oidsToArticles. The problem is that when I commit the transaction, nothing is saved. I have tested the same code without __setstate__ and then it saves just fine. What hoops does one have to jump through to upgrade the state of a ZODB object?

5 9