[Zope-dev] Bug Day status report (fwd)
[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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Help: __getstate__ overriding
Syver Enstad wrote at 2004-5-28 12:41 +0200: >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? This does not work as changes made in "__setstate__" are not explicitly persisted. Whether or not they become persistent depends on whether the object is changed again outside "__setstate__". Use an explicit conversion script instead... -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
Richard Ettema wrote at 2004-5-28 11:28 +0100: >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) Let your operating system write core files (usually disabled, read the manual page for "ulimit"). Analyse the resulting core file with "gdb". -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: Given that, I still prefer context#dc to context/##dc. +1, also in preference to "/#" and the other options I've seen. Gary ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Help: __getstate__ overriding
FWIW, __setstate__ for Zope objects has typically been used as a "one-way" kind of backwards compatibility mechanism (where the object's database state remains unmodified, but the in-memory state is changed) not only for the reasons that Tim just explained, but also because changing the persistent state of an object as a side effect of unghosting would can be a bad idea anyway. ZODB writes can be very expensive and having them occur as side effects of loading state from the database could be problematic in some circumstances. This is commonly referred to as the "write on read" pattern and is largely discouraged. Tim pointed at a proposal by Jim which aims to allow for orderly upgrade of database state based on developer-defined schema versions where the upgrade is done at known times (like, when someone presses a button, or at Zope startup time) which seems saner. There is an (experimental) Zope 2 product that implements the pattern in Jim's proposal (using mostly the same code that Zope 3 uses for its experimental implementation of the same) available at http://cvs.zope.org/Products/zzz_generations/ On Fri, 2004-05-28 at 14:51, Tim Peters wrote: > [Syver Enstad, wants to switch an attribute of a Persitent subclass > From PersistentList to an IOBTree] > > [Tim, guessing] > > Quick guess (untested, untried, ... > ... > > Perhaps shuffling the code around would work, a la: > > > > Persistent.__setstate__(self, state) > > articleList = state.get('_articleList') > > if articleList is not None: > > # make the BTree in local oidsToArticles as above, then > > del self._articlelist > > self._oidsToArticles = oidsToArticles > > > > The thinking there is that then you've truly modified self, after self has > > been activated. > > Nope, sorry, not a chance. You have truly modified self then, but > __setstate__ is called by magic as part of activation (unghostifying), and > the activation machinery resets self._p_changed after it calls __setstate__. > So same result as your code: the in-memory version of self has the BTree, > but commit() doesn't change anything about self in the database (again > because self._p_changed is false -- and will be no matter what you try to do > in __setstate__()). > > This appears to be one of those "severely underdocumented" minefields. The > best older thread I found is here: > > http://mail.zope.org/pipermail/zodb-dev/2002-March/002442.html > > but it doesn't actually spell out something "that works" in the way you > want. > > One possibility is to use any of these __setstate__ implementations > temporarily, in a one-shot database conversion script: load every object of > your subclass's type, and for each one "obj", after loading it do > > obj._p_changed = True > get_transaction().commit() > > Note again that setting _p_changed *inside* __setstate__ won't do any good. > > Note too that Jim Fulton has a recent proposal for Zope3 in this area: > > http://tinyurl.com/ypkhk > > [Zope URLs are generally so long my mailer refuses to keep them on one line] > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Help: __getstate__ overriding
[Syver Enstad, wants to switch an attribute of a Persitent subclass From PersistentList to an IOBTree] [Tim, guessing] > Quick guess (untested, untried, ... ... > Perhaps shuffling the code around would work, a la: > > Persistent.__setstate__(self, state) > articleList = state.get('_articleList') > if articleList is not None: > # make the BTree in local oidsToArticles as above, then > del self._articlelist > self._oidsToArticles = oidsToArticles > > The thinking there is that then you've truly modified self, after self has > been activated. Nope, sorry, not a chance. You have truly modified self then, but __setstate__ is called by magic as part of activation (unghostifying), and the activation machinery resets self._p_changed after it calls __setstate__. So same result as your code: the in-memory version of self has the BTree, but commit() doesn't change anything about self in the database (again because self._p_changed is false -- and will be no matter what you try to do in __setstate__()). This appears to be one of those "severely underdocumented" minefields. The best older thread I found is here: http://mail.zope.org/pipermail/zodb-dev/2002-March/002442.html but it doesn't actually spell out something "that works" in the way you want. One possibility is to use any of these __setstate__ implementations temporarily, in a one-shot database conversion script: load every object of your subclass's type, and for each one "obj", after loading it do obj._p_changed = True get_transaction().commit() Note again that setting _p_changed *inside* __setstate__ won't do any good. Note too that Jim Fulton has a recent proposal for Zope3 in this area: http://tinyurl.com/ypkhk [Zope URLs are generally so long my mailer refuses to keep them on one line] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Help: __getstate__ overriding
[Syver Enstad] > 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. Quick guess (untested, untried, just from eyeballing this snippet quickly): nothing is marking self itself as being changed. The only things getting changed are the throw-away in-memory 'state' dict, the throw-away in-memory self.__dict__, and a throw-away in-memory BTree. The primary purpose of p.__setstate__ is to activate a ghost, after which point p is in the up-to-date state (i.e., not changed -- calling Persistent.__setstate__(self, ...) isn't going to mark self as changed, and nothing in the code above modifies self itself). If self doesn't look changed, its state in the DB won't change during commit(), and the DB will still reference your old PersistentList. Perhaps shuffling the code around would work, a la: Persistent.__setstate__(self, state) articleList = state.get('_articleList') if articleList is not None: # make the BTree in local oidsToArticles as above, then del self._articlelist self._oidsToArticles = oidsToArticles The thinking there is that then you've truly modified self, after self has been activated. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: Given that, I still prefer context#dc to context/##dc. +1 I like the idea that '/' and '#' are both path separators, and that the semantics of each path segment depend on the preceding separator. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces
I want to thank everyone who's participating in this thread. The input is extremely valuable. Garrett Smith wrote: Jim Fulton wrote: > We don't. In fact, one could argue that adaptation is a bit like > a different kind of traversal. In fact, in Zope 3, we already have > a notion of this. In general, in Zope 3 paths, we can say: > > foo/++namespace++name > > where "/++namespace++" can be thought of as a special form of > namespace operator (similar and partly inspired by xpaths > "/:namespace:"). > > So, we could also use something like: > > content/++adapter++dc/title > > but I think people want something more concide for ZPT. I prefer this notation, even though it's more verbose. I think it should be supported along with a short cut syntax. This problem seems analogous to view lookup -- "content/++view++index.html" and "content/@@index.html" are equivalent. So, applied to adapters, we could use: content/++adapter++dc/title (or '++adapt++') one could use: content/##dc/title or perhaps (yuckier): content/**dc/title I'd hate to see Yet Another Traversal Syntax introduced Too late. :) Path expressions already introduce separate syntax. This is, in part, to take advantage of the TALES variable namespaces, which aren't relevent to generic path traversal. > when we already have a decent pattern established. We are talking about two different systems here. The ++namespace++name syntax is part of Zope's generic path execution machinery, which Zope 3 TALES uses. When we use this syntax, or @@name. all of the work is done by the namespace machinery, not by TALES. This means that TALES has no control over it. So, if you rely solely on the standard traversal machinery, you won't be able to define short names within the template. I suggest that whatever short syntax we come up with should be handled by TALES, not the standard path traversal machinery. Given that, I still prefer context#dc to context/##dc. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
On Friday 28 May 2004 11:21, Garrett Smith wrote: > context/##dc/title Not so good; looks convoluted. > context/**dc/title This one looks good. Remind me of the power of a number, like dc takes over context. :-) > context/::dc/title I am fine with this one as well. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
Hi, Just some quick suggestions: - First, can you reproduce the problem in a test environment? - In general, I would say one of the first steps you should take is try it out with the latest stable versions of Zope (2.7.0) and Python (2.3.4). You shouldn't be surprised to find bugs running old versions of software and prerelease versions of your OS. For example, there are some BTree-related bugs in older Zope versions that could cause this, IIRC - I doubt the thread stack size is the issue, although others may be better equipped to say so - I guess it's possible that when you replaced the CPU you didn't upgrade the ventilation/cooling adequately? Hot CPUs can cause all kinds of strange things. seb Richard Ettema wrote: Hi, I have a cmf site that has begun restarting frequently and at random intervals for no apparent reason. ERROR(200) zdaemon Process 25606 terminated by signal SIGSEGV(11) -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. The only possible answer I have come up with while searching is about the thread stack size being to small. 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)] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
On Friday 28 May 2004 02:48, Philipp von Weitershausen wrote: > Garrett Smith wrote: > > This problem seems analogous to view lookup -- > > "content/++view++index.html" and "content/@@index.html" are equivalent. > > > > So, applied to adapters, we could use: > > > > content/++adapter++dc/title (or '++adapt++') > > +1 on ++adapt++. > > I think using the the traversal machinery and its syntax would be a very > elegant solution. Then using either ##, ** or :: as a shortcut (in > analogy to @@) would be even more consistent, since in current > component-architecture-speak, views are multi-adapters. > > Just compare them visually: > > - context/@@absolute_url +1 -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Help: __getstate__ overriding
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? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope (with cmf) instance being frequently restarted by signal SIGSEGV(11)
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )