Zope-Dev May 2004

zope-dev@zope.dev

70 participants
72 discussions

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

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

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

Bug Day status report (fwd)
by Ken Manheimer 01 Jun '04

01 Jun '04

[This was mistaken for spam by our filter, and i was too quick to confirm it as spam...] ---------- Forwarded message ---------- Date: Fri, 28 May 2004 18:02:50 -0400 From: Paul Winkler <pw_lists(a)slinkp.com> To: zope-dev(a)zope.org Subject: Bug Day status report Just a quick status report on today's Bug Day... 10 bugs resolved, 5 set to "won't fix", 4 rejected. RESOLVED: #1213, #852, #1293, #1355, #1265, #1352, #1094, #993, #1132, #596 WONTFIXED: #1193, #329, #1098, #1045, #981 REJECTED: #639, #1238, #489, #1297 The #zope-dev channel is quiet now, but feel free to hop in and rev it up again :-) -- Paul Winkler http://www.slinkp.com

5 4

Zope 2.7.1b1 broke my unit tests !
by Stefane Fermigier 01 Jun '04

01 Jun '04

Testing CPSCore: make: *** [test] Error 1 ( handlers.handleConfig(opts.configroot, opts.confighandlers)) Here is the full log: ------------------------------------------------------------------------------ Loading Zope, please stand by ...Traceback (most recent call last): File "runalltests.py", line 24, in ? m = __import__(test) File "test_base.py", line 23, in ? import Testing.ZopeTestCase.ZopeLite as Zope File "/home/fermigier/cvsnuxeo/tools/publication/Zope/lib/python/Testing/ZopeTestCase/__init__.py", line 7, in ? import ZopeLite as Zope File "/home/fermigier/cvsnuxeo/tools/publication/Zope/lib/python/Testing/ZopeTestCase/ZopeLite.py", line 105, in ? _theApp = Zope.app() File "/home/fermigier/cvsnuxeo/tools/publication/Zope/lib/python/Zope/__init__.py", line 53, in app configure() File "/home/fermigier/cvsnuxeo/tools/publication/Zope/lib/python/Zope/Startup/run.py", line 30, in configure opts = _setconfig(configfile) File "/home/fermigier/cvsnuxeo/tools/publication/Zope/lib/python/Zope/Startup/run.py", line 47, in _setconfig handlers.handleConfig(opts.configroot, opts.confighandlers) AttributeError: ZopeOptions instance has no attribute 'confighandlers' make: *** [test] Error 1 All the CPS tests pass under Zope 2.6.1, 2.6.4 and 2.7.0. Any idea of what's going on ? Could it be a problem with ZopeTestCase (I'm using ZTC 0.9.0) ? S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source!

3 2

cvs down ??
by robert rottermann 31 May '04

31 May '04

Hi there, I try to access the Zope cvs anonymously according to the instructions. However it fails. Has anything changed, or is this temporarily. Robert robert@salome:/home/zope/Products> cvs -d :pserver:anonymous@cvs.zope.org:/cvs-repository co Zope cvs [checkout aborted]: connect to cvs.zope.org:2401 failed: Connection refused

4 5

zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
by Richard Ettema 28 May '04

28 May '04

Hi, I have a cmf site that has begun restarting frequently and at random intervals for no apparent reason. This first occurred about 2 weeks ago for about 2-3 days with the instance being restarted every 15 mins at worst. This problem disappeared as quickly as it had appeared. 2-3 days ago this same problem reappeared but with the site sometimes being restarted 10 times in a 15 minute period. I can find no sequence of url calls or any common reason for this to be occurring. The only thing I could find was the following entry appearing in the event log matching the times I have witnessed the instance restarting via top. ERROR(200) zdaemon Process 25606 terminated by signal SIGSEGV(11) The only changes that have occurred around the time of this first problem turning up was (other than normal site operation with members/items being add/deleted): -the cpu and memory being upgraded. This was returned to the original memory and cpu state to make sure this wasn't the cause. These have been swapped in/out with no change so it looks like it is just coincidence. There is no obvious signs of anything malicious going on, but this is always a possibility I guess? What to check for? As this has basically brought the site to its knees with proxy errors displayed more often than not, has anyone got suggestions on what to look for. possibilities (however remote) as I am pretty desperate to get this fixed. If there is a simple explanation, what could cause it to start out of the blue? The only possible answer I have come up with while searching is about the thread stack size being to small. And having to recompile python with this set to a larger figure. Is this related to the problem I am having, and is there an easy way to check if this is the case for the version I have running? If this is what I need to do, is there a good link for details on what needs to be done and how to do it? CMF: 1.4.2 Zope: (unreleased version, python 2.1.3, linux2) Python: 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] Thank you for all your help on this as I am lost at what steps to take next. Thanks, Richard.

3 2

Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
by Jim Fulton 28 May '04

28 May '04

Garrett Smith wrote: > What was the reasoning behind selecting @@ for the view namespace > shortcut? (IIRC, the motivation was to use characters that could be used > in URLs, but I'm not sure that's an issue for adapters...or is it?) Legal in urls, no English. @@ looks like two eyes viwing something. :) 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

Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
by Stephan Richter 28 May '04

28 May '04

On Friday 28 May 2004 11:21, Garrett Smith wrote: > What was the reasoning behind selecting @@ for the view namespace > shortcut? Because it looks like two eyes. > (IIRC, the motivation was to use characters that could be used > in URLs, but I'm not sure that's an issue for adapters...or is it?) That was one consideration; there was extensive research done on which characters would be permissible. I do not think we have the same issue with the adapters though. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev May 2004