> "CD" == Casey Duncan <[EMAIL PROTECTED]> writes:
CD> Yes, except I would argue that such work is best left on the
CD> HEAD rather than applied to a maintenance branch until
CD> necessitated by bug reports on that branch, or at least the
CD> knowledge that such a bug definitely exists
> The nice thing about fixing this bug is that the code continues to be
> improved. The last round of beautification made the code
> substantially more readable. This was a direct result of trying to
> track down a reference count problem. The problem proved to be
> elsewhere, but it was nearly
Yes, except I would argue that such work is best left on the HEAD rather than
applied to a maintenance branch until necessitated by bug reports on that
branch, or at least the knowledge that such a bug definitely exists and can
be reproduced on that branch.
I'm all for improving the code base.
The nice thing about fixing this bug is that the code continues to be
improved. The last round of beautification made the code
substantially more readable. This was a direct result of trying to
track down a reference count problem. The problem proved to be
elsewhere, but it was nearly impossible
> "SH" == Shane Hathaway <[EMAIL PROTECTED]> writes:
SH> Jeremy Hylton wrote:
>> I'll have to take a look, but may not get to it today. FWIW I
>> thought I fixed the bug on Friday. I could certainly create
>> ZClasses through the web without getting any obvious errors.
SH> My litt
Jeremy Hylton wrote:
I'll have to take a look, but may not get to it today. FWIW I thought
I fixed the bug on Friday. I could certainly create ZClasses through
the web without getting any obvious errors.
My little test (attached to the patch submission) passes with my version
as well as your
On Monday 16 December 2002 11:55 am, Evan Simpson wrote:
> My trunk and 2.6 sandboxes are now behaving themselves. Thanks, guys!
Ok, then it must be time for some more "beautification"... ;^)
Idle hands are the work of the devil you know.
-Casey
___
I'll have to take a look, but may not get to it today. FWIW I thought
I fixed the bug on Friday. I could certainly create ZClasses through
the web without getting any obvious errors.
Jeremy
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zop
My trunk and 2.6 sandboxes are now behaving themselves. Thanks, guys!
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/l
On 12/12/2002 12:30 PM, Jeremy Hylton wrote:
>"SH" == Shane Hathaway writes:
SH> On Wed, 11 Dec 2002, Evan Simpson wrote:
>> I think I've fixed my ZGlobals, but there's definitely a problem
>> in coptimizations. I made Connections.py use the Python
>> persistent_id, restarted twic
> "SH" == Shane Hathaway <[EMAIL PROTECTED]> writes:
SH> On Wed, 11 Dec 2002, Evan Simpson wrote:
>> I think I've fixed my ZGlobals, but there's definitely a problem
>> in coptimizations. I made Connections.py use the Python
>> persistent_id, restarted twice, and ZGlobals was fine on
If you feel like it, the change that is biting you is probably in here:
http://cvs.zope.org/Zope/lib/python/ZODB/
coptimizations.c.diff?r1=1.17&r2=1.17.60.1&only_with_tag=Zope-2_6-branch
I looked and there are some changes to the persistent_id code, but I
lack sufficient background with this m
On Wednesday 11 December 2002 11:13 pm, Shane Hathaway wrote:
> On Wed, 11 Dec 2002, Evan Simpson wrote:
>
> > I think I've fixed my ZGlobals, but there's definitely a problem in
> > coptimizations. I made Connections.py use the Python persistent_id,
> > restarted twice, and ZGlobals was fine o
On Wed, 11 Dec 2002, Evan Simpson wrote:
> I think I've fixed my ZGlobals, but there's definitely a problem in
> coptimizations. I made Connections.py use the Python persistent_id,
> restarted twice, and ZGlobals was fine on the second restart.
Ah-ha, you now have a reproducible test case. Th
I think I've fixed my ZGlobals, but there's definitely a problem in
coptimizations. I made Connections.py use the Python persistent_id,
restarted twice, and ZGlobals was fine on the second restart.
Whew,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL
More data:
It may well be loading correctly, but it seems to be storing
incorrectly. I managed to grab the ZGlobals pickle string, and it has
the _zclass_ stored as a plain class instead of an oid.
I copied the commented-out Python persistent_id() in ZODB/Connections.py
into a method called t
Shane Hathaway wrote:
Shot in the dark #2: Does it enter the ClassFactory function in
Zope.ClassFactory? That's part of the ZClass magic... although there
are two ways that the pickler tries to load classes. ZODB only tries to
load Persistent instances as ZClasses. If there are things inside
On 12/10/2002 09:58 PM, Evan Simpson wrote:
Shane Hathaway wrote:
> My first recommendation would be to turn your ZClass registry into an
> OOBTree. OOBTree has been maintained and updated.
Good thought, but no dice.
Well, it was worth a shot. :-)
Since it is rebuilding the registry on ev
Shane Hathaway wrote:
My first recommendation would be to turn your ZClass registry into an
OOBTree. OOBTree has been maintained and updated.
Good thought, but no dice.
Since it is rebuilding the registry on every restart anyway, I went
ahead and made the changes to my OFS/Application.py. I
On 12/10/2002 12:53 PM, Evan Simpson wrote:
This past weekend I migrated a bunch of ZClasses and the web site that
uses them from a scratch Zope instance into my production instance. Both
run off the same 2.6 CVS branch checkout, connecting to ZEO servers
running from the same ZEO trunk checkout.
20 matches
Mail list logo