[Zope-dev] It's me again :(
So... this time I got a really weird one. I'm storing a subclass of File (Archetypes newBaseUnit, File is the only base class) into a PersistentMapping, and I'm getting: 'Can't pickle objects in acquisition wrappers' However, as far as I can see, the object is *not* acquisition wrapper. If I put a try: except in ZODB.serialize and try obj.aq_base, I get an attribute error, and aq_base(obj) is obj returns True. It *smells* like Implicit.__getstate__ is being called, though I can't really tell :( Any ideas? -- Sidnei da Silva <[EMAIL PROTECTED]> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Sic transit discus mundi -- From the System Administrator's Guide, by Lars Wirzenius ___ 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] Python 2.3.2 and dir
Alan Milligan wrote at 2003-12-15 13:45 +1100:
>I'm trying to upgrade my Zpydoc product to Python 2.3.2 from 2.1.3 and
>have come across a confusing situation in regard to the
>inspect.getmembers function.
>
>This function uses the builtin dir() function to get a list of an
>objects attributes. For Zope products, I am getting a situation where
>returned attributes are not found in the object - explicitly __call__,
>__delattr__, etc etc.
You know, I have a similar product ("DocFinder").
I directly look into the class' "__dict__" to learn about
a class' members.
--
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] Re: On with the show....
On Mon, 2003-12-15 at 11:51, Casey Duncan wrote:
> On Mon, 15 Dec 2003 10:02:58 -0600
> Evan Simpson <[EMAIL PROTECTED]> wrote:
>
> > Sidnei da Silva wrote:
> > > If you look at FSPageTemplate, its obvious that it doesn't subclass
> > > ZopePageTemplate, but the solution is not so obvious. Using:
> > >
> > > pt_getContext = ZopePageTemplate.pt_getContext.im_func
> >
> > Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
> > have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
> > code works out to the same thing. I don't endorse this sort of
> > cross-tree method copying, but if we're going to do it on this scale, at
> > least we can make it tidier. Before the Globals.InitializeClass:
> >
> > zpd = ZopePageTemplate.__dict__
> > for m in ('func_code', '_default_bindings', 'manage_FTPget',
> >'get_size', 'PrincipiaSearchSource', 'document_src',
> >'pt_getContext', 'ZScriptHTML_tryParams'):
> >setattr(FSPageTemplate, m, zpd[m])
> >
> > > A similar error also happened with FSImage.__str__ (which is assigned
> > > Image.__str__, but FSImage just subclasses FSObject).
> > >
> > > Any thought on those?
> >
> > Yep -- it seems very silly to copy a one-line method like that.
>
> Smells like a broken class hierarchy to me. I really think we need to
> consider refactoring the code so this sort of sillyness isn't necessary.
While we are at it, we need to refactor the "core" bits of ZPT
(expressions, PageTemplateFile, etc.) out of 'Products.PageTemplates'
and into a better "top-level" pacakge. People are beginning to use PTF
for ZMI, which shouldn't break in the absence of a product.
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation "Zope Dealers" http://www.zope.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] Re: On with the show....
On Mon, 15 Dec 2003 10:02:58 -0600
Evan Simpson <[EMAIL PROTECTED]> wrote:
> Sidnei da Silva wrote:
> > If you look at FSPageTemplate, its obvious that it doesn't subclass
> > ZopePageTemplate, but the solution is not so obvious. Using:
> >
> > pt_getContext = ZopePageTemplate.pt_getContext.im_func
>
> Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
> have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
> code works out to the same thing. I don't endorse this sort of
> cross-tree method copying, but if we're going to do it on this scale, at
> least we can make it tidier. Before the Globals.InitializeClass:
>
> zpd = ZopePageTemplate.__dict__
> for m in ('func_code', '_default_bindings', 'manage_FTPget',
>'get_size', 'PrincipiaSearchSource', 'document_src',
>'pt_getContext', 'ZScriptHTML_tryParams'):
>setattr(FSPageTemplate, m, zpd[m])
>
> > A similar error also happened with FSImage.__str__ (which is assigned
> > Image.__str__, but FSImage just subclasses FSObject).
> >
> > Any thought on those?
>
> Yep -- it seems very silly to copy a one-line method like that.
Smells like a broken class hierarchy to me. I really think we need to consider
refactoring the code so this sort of sillyness isn't necessary.
-Casey
___
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: On with the show....
Sidnei da Silva wrote: Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon? Maybe [EMAIL PROTECTED] is a better place for questions like that? Today Tres Seaver wrote: BTW, I plan to post a draft roadmap for CMF 1.5 soon (today, I hope), and to ask for feedback. Yuppie ___ 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] On with the show....
On Mon, Dec 15, 2003 at 07:56:04AM -0500, Chris McDonough wrote: | On Mon, 2003-12-15 at 08:04, Sidnei da Silva wrote: | > pt_getContext = ZopePageTemplate.pt_getContext.im_func | > | > Seemed to work, though I'm almost sure that is not the Right Thing (tm). | | This exact fix was already checked in to the CMF HEAD by Yuppie a couple | of days ago (and a series of other ones, as well as one for | Image.__str__) based on an audit by Dieter. Maybe you're using the 1.4 | branch? Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon? -- Sidnei da Silva <[EMAIL PROTECTED]> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Memory fault - where am I? ___ 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: On with the show....
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass
ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
code works out to the same thing. I don't endorse this sort of
cross-tree method copying, but if we're going to do it on this scale, at
least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__
for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned
Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Cheers,
Evan @ 4-am
___
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] Re: Converting from old-style BTreess
On Mon, Dec 15, 2003 at 05:21:55AM -0500, Jim Fulton wrote: > Chris McDonough wrote: > >Woot! ;-) Descriptors, yum... > > But you can use descriptors in extension classes now too. I wondered what the heck you guys were on about... google turned up this: http://users.rcn.com/python/download/Descriptor.htm very very cool stuff. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ZORRO SLUDGE! (random hero from isometric.spaceninja.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] Re: Converting from old-style BTreess
On Mon, 2003-12-15 at 05:21, Jim Fulton wrote: > Chris McDonough wrote: > > Woot! ;-) Descriptors, yum... > > But you can use descriptors in extension classes now too. > Extension classes are now just new-style classes with some > extra features and a different mro algorithm. Whoa. Cool. That really is great. You guys are so clever. ;-) - C ___ 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] Re: Converting from old-style BTreess
Chris McDonough wrote: Woot! ;-) Descriptors, yum... But you can use descriptors in extension classes now too. Extension classes are now just new-style classes with some extra features and a different mro algorithm. Jim On Mon, 2003-12-15 at 10:02, Jeremy Hylton wrote: On Mon, 2003-12-15 at 08:15, Chris McDonough wrote: Can you answer a question about the features we're allowed now? If we don't use extensionclass, is it possible to persist instances of new-style classes in ZODB now (ie. is persistent.Persistent really a new-style type/class)? Yes. (i.e. yes.) Jeremy -- 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 )
RE: [Zope-dev] Zope Head (2.8) breaks "refresh"
[Jeremy Hylton] >> I don't think it makes a lot of sense to put an __del__ method on a >> Persistent object. [Dieter Maurer] > I just read in "cPersistence.c:ghostify": > > /* We remove the reference to the just ghosted object that the ring >* holds. Note that the dictionary of oids->objects has an uncounted >* reference, so if the ring's reference was the only one, this frees >* the ghost object. Note further that the object's dealloc knows to >* inform the dictionary that it is going away. >*/ > > This means: *all* persistent objects have a special "dealloc" > function. Most Python objects do (persistent or not), pointed to by the type's tp_dealloc slot, or inherited from a base type's tp_dealloc. Having a tp_dealloc function isn't the same as having a __del__ method, though: tp_dealloc is part of the system implementation, while __del__ is arbitrary user-defined Python code. It's required that the presence or absence of tp_dealloc not make any difference to cyclic gc, and gc doesn't even check for their existence. Since tp_dealloc implementations are "part of the system", they can (and do) impose restrictions on their authors that aren't imposed on authors of Python __del__ methods. > Hope, this "dealloc" function plays well with the cyclic garbage > collector. If a case is found where it doesn't, it's a bug in the persistent tp_dealloc function. It was hard to get cyclic gc to work with the cache, in large part because of the "dictionary of oids->objects [with] uncounted reference[s]" (Python's cyclic gc is based on having truthful refcounts), and we did hit plenty of bugs in the process. We don't know of any that remain. Doesn't mean there aren't any remaining, but does mean a lot of brain cells already got burned trying to ensure that the persistent dealloc functions play nice with cyclic gc. ___ 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] Re: Converting from old-style BTreess
Woot! ;-) Descriptors, yum... On Mon, 2003-12-15 at 10:02, Jeremy Hylton wrote: > On Mon, 2003-12-15 at 08:15, Chris McDonough wrote: > > Can you answer a question about the features we're allowed now? If we > > don't use extensionclass, is it possible to persist instances of > > new-style classes in ZODB now (ie. is persistent.Persistent really a > > new-style type/class)? > > Yes. (i.e. yes.) > > Jeremy > ___ 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] Re: Converting from old-style BTreess
On Mon, 2003-12-15 at 08:15, Chris McDonough wrote: > Can you answer a question about the features we're allowed now? If we > don't use extensionclass, is it possible to persist instances of > new-style classes in ZODB now (ie. is persistent.Persistent really a > new-style type/class)? Yes. (i.e. yes.) Jeremy ___ 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 Head (2.8) breaks "refresh"
On Mon, 2003-12-15 at 07:34, Dieter Maurer wrote: > >I don't think it makes a lot of sense to put an __del__ method on a > >Persistent object. > > I just read in "cPersistence.c:ghostify": > > /* We remove the reference to the just ghosted object that the ring > * holds. Note that the dictionary of oids->objects has an uncounted > * reference, so if the ring's reference was the only one, this frees > * the ghost object. Note further that the object's dealloc knows to > * inform the dictionary that it is going away. > */ > > This means: *all* persistent objects have a special "dealloc" > function. Hope, this "dealloc" function plays well with the > cyclic garbage collector. All Python objects have a "dealloc" function -- whatever is in the tp_dealloc slot. The tp_dealloc function at the C level is completely different from an __del__ method at the Python level. Jeremy ___ 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] Re: Converting from old-style BTreess
> On Mon, 2003-12-15 at 02:39, Jim Fulton wrote: > > > I checked in the necessary fix for PersistentMapping. There was a > > change in the data structure and I had to add some logic to convert > > some old state. Oh, geez, I remember this setstate/getstate business now. FWIW, I think Jeremy added it at my insistence after he changed PersistentMapping to inherit from UserDict in order to maintain backwards compatibility for versions that didn't. The next panic will start when UserDict becomes a new-style class. ;-) - C ___ 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] Re: Converting from old-style BTreess
On Mon, 2003-12-15 at 02:39, Jim Fulton wrote: > I checked in the necessary fix for PersistentMapping. There was a > change in the data structure and I had to add some logic to convert > some old state. > > I also had to check in a %$#@ travesty because Data.fs.in still has > references to BoboPOS. Oh god. Well, the good news is that we don't use Data.fs.in in 2.7+ anymore, so this shouldn't be a problem after about 3 years. ;-) > With these changes, I can create a database with 2.6 and open it with the > head. > > Thanks Chris for helping us figure out that this was easier than we > thought. :) Just lazy. ;-) - C ___ 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] Re: Converting from old-style BTreess
On Mon, 2003-12-15 at 02:47, Jim Fulton wrote: > Chris McDonough wrote: > ... > > > Out of curiosity, could you explain why it matters in this context > > whether it's an extensionclass or not? Is it because there might be a > > set of people using PersistentMapping objects for whom its important > > that they be able to use extenionclass semantics against them? I'd just > > never thought of using __of__ or inheritedAttribute or any of the other > > EC-specific stuff on a PersistentMapping. > > Who knows. I'd rather be safe. It's not that hard. > In any case, we would have needed the fix to handle old pickles > correctly. Gotcha. Can you answer a question about the features we're allowed now? If we don't use extensionclass, is it possible to persist instances of new-style classes in ZODB now (ie. is persistent.Persistent really a new-style type/class)? - C ___ 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: On with the show....
Hi Sidnei! Sidnei da Silva wrote: So, it seems Chris McDonough figured out what we couldn't *wink*. Now, it seems like Zope HEAD boots fine with an old Data.fs, and I could even get a Plone 1.0 site migrated to Plone 2.0 and CMF 1.4 (a small problem on DCWorkflow, but I checked in a fix). Maybe you should have a look at CMF HEAD and either test with HEAD or backport some fixes. pt_getContext = ZopePageTemplate.pt_getContext.im_func Seemed to work, though I'm almost sure that is not the Right Thing (tm). Why? Based on Dieter's patches I fixed HEAD this way and it looks ok to me. I guess the Right Thing would be refactoring the classes so we can inherit these methods, but even if we change Zope now CMF would need the old code for a long time for backwards compatibility. A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject). Any thought on those? Same as above. What I'm missing is an easy way to find *all* of them. AFAICT, there's nothing wrong with DiscussionItemContainer. It has been InitializeClass()'ed and has a docstring. Setting __allow_access_to_unprotected_subobjects__ = 1 works, but that is obviously wrong. Ideas? No idea so far. The others didn't have a docstring. Cheers, Yuppie ___ 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] On with the show....
On Mon, 2003-12-15 at 08:04, Sidnei da Silva wrote: > pt_getContext = ZopePageTemplate.pt_getContext.im_func > > Seemed to work, though I'm almost sure that is not the Right Thing (tm). This exact fix was already checked in to the CMF HEAD by Yuppie a couple of days ago (and a series of other ones, as well as one for Image.__str__) based on an audit by Dieter. Maybe you're using the 1.4 branch? > Then a completely different error happened, when looking at a item > with comments: > > * Module Products.PageTemplates.ZRPythonExpr, line 48, in > __call__ > __traceback_info__: container.sort_modified_ascending( > here.portal_discussion.getDiscussionFor(here).getReplies()) > * Module Python expression "container.sort_modified_ascending( > here.portal_discussion.getDiscussionFor(here).getReplies())", line > 1, in > * Module Products.VerboseSecurity.VerboseSecurityPolicy, line 157, > in validate > > Unauthorized: The container has no security assertions. Access to > 'getReplies' of > (Products.CMFDefault.DiscussionItem.DiscussionItemContainer object at > 0x419681ac) denied. > > AFAICT, there's nothing wrong with DiscussionItemContainer. It has > been InitializeClass()'ed and has a docstring. Setting > __allow_access_to_unprotected_subobjects__ = 1 works, but that is > obviously wrong. I think this may also be fixed in the stuff that Yuppie checked in because plope.com is running fine on the head and it uses discussions too. - C ___ 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] problem with TAL statements across multiple lines in zope 2.7b3
These are lines that did not produce an error with zope 2.6.2. They aren't even my code - I've run into errors in two different products - Plone and PloneCalendar. For testing, I merged the line together, then pressed Enter and used spaces to move the code across multiple lines. Gerry Kirk Project Manager www.faithonline.com www.dioceseonline.com > -Original Message- > From: Stuart Bishop [mailto:[EMAIL PROTECTED] > Sent: December 12, 2003 11:55 PM > To: Gerry Kirk > Cc: [EMAIL PROTECTED] > Subject: Re: [Zope-dev] problem with TAL statements across > multiple lines in zope 2.7b3 > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On 13/12/2003, at 3:34 AM, Gerry Kirk wrote: > > > i didn't have this problem with zope 2.6.2. I have a TAL > statement as > > follows: > > > > tal:define = "url python:test(item_typeinfo.getId() in > > use_folder_contents, item.absolute_url()+'/folder_contents', > > item.absolute_url()+'/'+action);" > > > > this statement works if it is all on one line, but i get a syntax > > error if it is spread across multiple lines. is this a bug, or a > > change in TAL design? > > Works for me. You aren't accidently splitting inside of a string are > you? > > - -- > Stuart Bishop <[EMAIL PROTECTED]> > http://www.stuartbishop.net/ -BEGIN PGP > SIGNATURE- > > Version: GnuPG v1.2.3 (Darwin) > > iD8DBQE/2puKAfqZj7rGN0oRAs9IAJ0SudIu20xmevZrSIHTPu2Aug9cDwCgiRFw > 7x6vS4ticldQQ6H+Q4dL8xU= > =hBXD > -END PGP SIGNATURE- > ___ 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] On with the show....
So, it seems Chris McDonough figured out what we couldn't *wink*. Now, it seems like Zope HEAD boots fine with an old Data.fs, and I could even get a Plone 1.0 site migrated to Plone 2.0 and CMF 1.4 (a small problem on DCWorkflow, but I checked in a fix). Soo... now, i'm getting some errors out of CMF which seem pretty obvious, and I wonder how they worked before. Example: * TypeError: unbound method pt_getContext() must be called with ZopePageTemplate instance as first argument (got nothing instead) (Also, an error occurred while attempting to render the standard error message.) If you look at FSPageTemplate, its obvious that it doesn't subclass ZopePageTemplate, but the solution is not so obvious. Using: pt_getContext = ZopePageTemplate.pt_getContext.im_func Seemed to work, though I'm almost sure that is not the Right Thing (tm). A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject). Any thought on those? Then a completely different error happened, when looking at a item with comments: * Module Products.PageTemplates.ZRPythonExpr, line 48, in __call__ __traceback_info__: container.sort_modified_ascending( here.portal_discussion.getDiscussionFor(here).getReplies()) * Module Python expression "container.sort_modified_ascending( here.portal_discussion.getDiscussionFor(here).getReplies())", line 1, in * Module Products.VerboseSecurity.VerboseSecurityPolicy, line 157, in validate Unauthorized: The container has no security assertions. Access to 'getReplies' of (Products.CMFDefault.DiscussionItem.DiscussionItemContainer object at 0x419681ac) denied. AFAICT, there's nothing wrong with DiscussionItemContainer. It has been InitializeClass()'ed and has a docstring. Setting __allow_access_to_unprotected_subobjects__ = 1 works, but that is obviously wrong. Ideas? -- Sidnei da Silva <[EMAIL PROTECTED]> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher This system will self-destruct in five minutes. ___ 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 Head (2.8) breaks "refresh"
Jeremy Hylton wrote at 2003-12-8 15:28 -0500: >On Mon, 2003-12-08 at 13:17, Dieter Maurer wrote: >> Jeremy Hylton wrote at 2003-12-7 23:01 -0500: >> >On Sun, 2003-12-07 at 08:15, Dieter Maurer wrote: >> >> ATT: replacing the cache without clearing it can lead to huge >> >> memory leaks (everything in the old cache is leaked!). >> > >> >Without commenting on the rest of the bug report, I should mention that >> >caches and persistent objects all participate in cyclic GC. They will >> >not leak the way pre-2.8 caches did. >> >> Has the "do not free when a cycle contains an object with destructor" >> restriction been removed from the cyclic GC? >> >> It is not unlikely that the cache references an object with a "__del__". >> This may keep the cache and all its content. > >I don't think it makes a lot of sense to put an __del__ method on a >Persistent object. I just read in "cPersistence.c:ghostify": /* We remove the reference to the just ghosted object that the ring * holds. Note that the dictionary of oids->objects has an uncounted * reference, so if the ring's reference was the only one, this frees * the ghost object. Note further that the object's dealloc knows to * inform the dictionary that it is going away. */ This means: *all* persistent objects have a special "dealloc" function. Hope, this "dealloc" function plays well with the cyclic garbage collector. -- 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] SMPT Authorization support
OK, 2 against 1 for. I won't make anything extra. I'll do the merge today or tomorrow or something. ___ 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: Converting from old-style BTreess
Chris McDonough wrote: ... Out of curiosity, could you explain why it matters in this context whether it's an extensionclass or not? Is it because there might be a set of people using PersistentMapping objects for whom its important that they be able to use extenionclass semantics against them? I'd just never thought of using __of__ or inheritedAttribute or any of the other EC-specific stuff on a PersistentMapping. Who knows. I'd rather be safe. It's not that hard. In any case, we would have needed the fix to handle old pickles correctly. 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 )
Re: [Zope-dev] Re: Converting from old-style BTreess
Chris McDonough wrote: On Sun, 2003-12-14 at 23:02, Chris McDonough wrote: Here's an idea: create a simple script that manufactured a module which set up the Zope configuration, "filled in" for BTree in sys.modules, and got a hold of Zope.app(), causing ZGlobals to be replaced by a new-style BTree due to the above magic. People upgrading to 2.8 with databases created by Zope versions older than 2.3 would still need to run convertBTrees inside a different Zope version, but people upgrading databases created in versions equalling or later than 2.3 wouldn't because we stopped using the old BTree module for anything except ZGlobals after 2.3 AFAICT. Actually, given my findings later in this email, this isn't even necessary. Right. Whew. I checked in the necessary fix for PersistentMapping. There was a change in the data structure and I had to add some logic to convert some old state. I also had to check in a %$#@ travesty because Data.fs.in still has references to BoboPOS. With these changes, I can create a database with 2.6 and open it with the head. Thanks Chris for helping us figure out that this was easier than we thought. :) 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 )
