Indeed, thanks for the input, I've ruled out new_publish as the cause as
Right now, I'm at the stage where I severely suspect it's got something to
with i18n support or translation somehow, but don't know where exactly yet.
If I remove the message_catalog, the problem
Thanks yet again for all the valuable input.
I've started tracking down/running into the whole ExtensionClasses
As you suggest, the dict is probably help by BaseRequest.RequestContainer,
seen grow in parallel to the HTTPRequest refcounts ... Which seems to
I'm using 1.0.1 ... I'm just abotu to try and test with 1.1.0a3 ...
BTW, does that mean it's alpha software or something? is 1.1.0 stable?
If the problem comes from Localizer I suspect this patch might be the cause:
def new_publish(request, module_name, after_list, debug=0):
OK, 1.1.0a3 indeed suffers from the same problem, I'm going to take a closer
look the the publishing mechanism to see if I can find anything relevant.
From: J. David Ibáñez [mailto:[EMAIL PROTECTED]
Sent: May 20, 2004 10:17 AM
Indeed, I was hoping the ref in the dictionary there was getting in the way
when old_publish was raising an exception, but I tried using a
instead and that didn't help.
I managed to test without Localizer (It dawned on me that since I'm looking
at errors, it really doesn't matter
In following to the discussions regarding the leakage zope.org and my site
suffer from, I've done some testing, and here's what I've found.
First of all, the leak does seem to occur when errors occur. Unlike what
Chris suggested, I still suffer from this leak even when I completely
Well, I suspect the interest in this type of tool might be big enough
to allow for the open Source model to apply in an efficient manner ?
Depends on the skills required to bring it to life.
I've started using Eclipse lately, and I just love it, I've combined
PyDT/PyDEV + Subclipse + XMLBuddy
I agree with Andre.
The feature list is ambitious, but complete. That's pretty much what
I was about to write myself, but he beat me to it :)
More important is the second point: Having such a tool would bring a
HUGE amount of value added to Zope. Mega, super huge.
In fact I was once presented
I know I'm new here, but I think this may work to my benefit in this case
+1 on everything Jim just said!
Unlike some others it seems, I look at Zope almost uniquely as framework
building web applications. An API or SDK if you will. As such, I think it's
internal software desing and
Right now, the svn transactions are entirely contained within a single
fileops operation: for example a mkdir connects to a transaction root,
performs the necessary operations, and commits, all in one shot.
Last night I took some more time to try and learn more about Ape's
As Kapil already mentionned, svn's support for properties is quite flexible,
so that doesn't worry me too much.
I would imagine and administrator having the flexibility of choosing how
objects get translateds to files might be handy.
My initial, uneducated thoughts on the topic were
Well there you go, perfect :)
From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
Sent: April 14, 2004 6:49 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely
r evis ion based storage for Zope ?)
The property schema thing is a good point, though I'm not sure we could ever
do anything about it, not with the purpose to help naive gui clients work
better with the repository.
By nature the object structure (Class instance) is not fixed, so the
amount/name/data of properties could vary
+1 from me !
I'm always in favor of less typing :P Besides, you make good points :)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jim Fulton
Sent: April 14, 2004 3:54 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Oh, a very good idea indeed! We'll have to look at that eventually.
The mechanism you describe is preferable, but it should be noted that
subversion properties are easily accessible using the clients.
So long as said properties are human readable/writable, that's also an
Hmmm, well it's as stable as Ape and Subversion are respectively :)
I wouldn't call it stable no, it's something I did over the long week-end we
just had, and that's about it :)
Ape is at 0.8 and therefore becoming quite mature, I'd have to let others
speak as to it stability however ...
About the branch thing ... That's basically the idea!
The bigger problem here is how to manage this both internally and from a
This paradigm only really makes sense in the CMF world anyways, and I want
to focus on basic Zope before moving up to the extra
Thanks for the extra tips, I'll check out those interfaces! I'm also getting
up to speed on the whole mapper concept, where the work regarding properties
handling seems to be ?
I've done some reading, and I need to do some more, but I'll get there :)
As for the seperation of code ... I
Well, step one is done ... I now have Zope + Ape using Subversion as it's
This is step one because, as Shawn suggested (Thanks for the pointer, that's
what I needed!), this simply means that Zope uses SVN purely as a
Because of subversion's nature, I want to
A co-worker of mine had an idea I thought was interesting and would like to
First of all, the history behind:
We had requirements for:
- Out of synch editing: Editing objects that are currently published
and publishing those only once they've been workflowed
Mail list logo