Re: [Zope-dev] In Defense of ZClasses
On 9/28/06, Lennart Regebro <[EMAIL PROTECTED]> wrote: My 0.02 EUR: I like the idea and aim of ZClasses. However: I think the implementation makes them more difficult to create than disk-based classes, which defeats the purpose. I also think that without exact knowledge of the limitations of ZClasses they have a high risk of programming yourself into a corner. Create, no. *Maintain*, absolutely. Anthony, who has a vast number of ZClasses dating back rather a long time now that need a rewrite, sigh. ___ Zope-Dev maillist - Zope-Dev@zope.org 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 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please
Chris McDonough wrote: That is very critital and 'blocker' bug for Zope. I do not understand how people could use Zope on a sites with high load.. They don't use sessions under high load. Or they don't use the standard session machinery. We use my SQLSession stuff, and it's fine under load. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
Jeffrey P Shell wrote: What should I do next? Should I familiarize myself with gdb and inspect the core? What are some things I could look for if that's the next step? I suspect that this is your next step. Try and figure out whether it's Python, or the C extensions that ship with Zope, that are at fault. Of course, if it's memory corruption, this could be tricky to figure out... -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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: Resolved security-related collector issues for the public?
>>> Jamie Heilman wrote > Given that ZC clearly doesn't have the resources available to do (a), > irrespective of if its even technically feasible, we can rule it out. > And (b), well (b) just screws everybody. Exploits are a byproduct of > understanding the vulnerability, they're a natural part of > experimentation and learning. You usually can't discuss a vulnerabilty > without implying the exploit. If you really want to help people who > can't help themselves, offer education, not censorship in the guise of > protection. Worse yet, hiding the security bugs mean that other people who might be motivated to supply fixes are unaware of the issue and cannot help. I'd be +1 on exposing the security bugs - maybe after 2 weeks so that critical security flaws have a chance to be fixed immediately. But it should be an automatic thing, not something that requires manual intervention. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] app = Zope.app() backwards incompatibility notice / discussion
>>> Chris McDonough wrote
> Code which used to do:
>
> import Zope
> app = Zope.app()
>
> Will need to do this under 2.7b4+:
>
> import Zope
> Zope.configure('/path/to/configfile')
> app = Zope.app()
Can we get an exception in the first case that states something like
"No config file, use Zope.configure('configfile')"?
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Windoz file naming
>>> "alan milligan" wrote > Guys, > > I've just run into a problem and wondered if there was an elegant > resolution. > > My BastionBanking package contains: > > currency.py - pure python > Currency.py - Zope derivation The "typical" approach in Python is to have, e.g. Tkinter, and _tkinter. But if it's a zope derivation of currency, why not call it zcurrency? ___ 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] cvs.zope.org down
>>> Toby Dickenson wrote > That makes me nervous. How will you know that the sources in cvs havent been > compromised? Surely people can compare checkouts of the various branches (2.6, 2.7) against downloaded tarballs? We can't do the same with TRUNK, but that should be still possible to check against, say, a 2.7 beta. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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: [Zope] Using 2.3.2 for Zope 2.7
>>> "Fred L. Drake, Jr." wrote > > Requiring 2.3 (any flavor) would allow us to drop the copy of the > logging package from Zope 2.7 and newer. > > There are greater benefits for Zope 3, where we have several modules > and packages laying around that would no longer be needed (logging, > csv, gettext). Don't forget you also get the C version of datetime. > I also don't know that we should consider 2.3.1 "acceptable" for any > version of Zope. Meh. 2.3.1 gets a bad rap. Aside from the fsync problem, there's nothing fundamentally broken about it. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] upgrading and getting rid of SearchIndex
I've got a couple of ZODBs here that's been gradually upgraded over time from Zope version to Zope version (I think they were initially started on Zope 1.x!) I'm sick of the SearchIndex deprecation warnings, so I've gone and re-created all of the catalog indexes. This fixed it for the indexes, but it's still showing up - any ideas how I can determine which objects are still referencing SearchIndex? Is it worth making a little script that Does The Right Thing when upgrading? It's a pretty trivial script to open a Data.fs and hunt for indexes, then re-create them - is this something that could/should be included with Zope? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] 2.6.2b..., Find is busted
Go to the Find tab in the ZMI, select "All types", containing "" Error type: TypeError Error value: expected a character buffer object Traceback (innermost last): Module ZPublisher.Publish, line 49, in publish Module ZPublisher.mapply, line 32, in mapply Module ZPublisher.Publish, line 38, in call_object Module Shared.DC.Scripts.Bindings, line 250, in __call__ Module Shared.DC.Scripts.Bindings, line 270, in _bindAndExec Module App.special_dtml, line 110, in _exec Module DocumentTemplate.DT_With, line 58, in render Module DocumentTemplate.DT_Util, line 175, in eval __traceback_info__: obj_metatypes Module, line 0, in ? Module OFS.FindSupport, line 51, in ZopeFind TypeError: expected a character buffer 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 )
Re: [Zope-dev] Very severe memory leak
>>> Leonardo Rochael Almeida wrote > Lately this was not enough, however, as Zope started taking more and > more memory, to the point that it frequently required more than one > restart during the day. Note that running with ZEO will at least mean that your server restarts happen a lot faster. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Can't build 2.6.2-b5 on Redhat 7.3
>>> Paul Winkler wrote > Like the subject says... python2.1 wo_pcgi fails... > > this is the same python 2.1.3 that I built from source, and which > I used to build and run zope 2.6.1 for a few months now... > > gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall > -Wstrict-prototypes -fPIC > -I/zope/Zope-2.6.2b5-src/lib/Components/ExtensionClass/src > -I/usr/local/include/python2.1 -c AccessControl/cAccessControl.c > -o build/temp.linux-i686-2.1/cAccessControl.o > In file included from AccessControl/cAccessControl.c:54: > /zope/Zope-2.6.2b5-src/lib/Components/ExtensionClass/src/ExtensionClass.h:94:20: > Python.h: No such file or directory It can't find Python.h - it's looking in /usr/local/include/python2.1 for it - is the file there? Is it readable by the user that the build is running under? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Packing (still) hosed in 2.6.2?
>>> "Jeremy Hylton" wrote > I don't recall that any of the pack bugs that we fixed caused this sort of > error. My first guess would be that the file is a bit damaged, perhaps in a > way that the old pack did not check. > Can you run fsdump.py and see if that output sheds any light. It will give > you a detailed text summary of all the transactions and data records. You > could use the dump to figure out if, for example, the two numbers in the > error message are indeed transaction header locations. Ok. The original error, reformatted for clarity: ZODB.fspack.CorruptedError: /app/zope/dev_csr_server/recover/Data.fs:9200838: data record does not point to transaction header: 17391715 != 9200760 Here's the 3 transactions (one before, dead one, one after). There's definately a screwed transaction there. offset: 9198385 end pos: 9200752 transaction id: 033bb0f41f05f3aa trec len: 2367 status: ' ' user: ' jasonb' description: '/admin_tools/accounts/update_account/manage_edit' len(extra): 0 offset: 9198463 oid: 000206bb revid: 033bb0f41f05f3aa previous record offset: 9193826 transaction offset: 9198385 len(data): 2247 redundant trec len: 2367 offset: 9200760 end pos: 9202513 transaction id: 033bb0f4b80ad42a trec len: 1753 status: 'u' user: ' jasonb' description: '/admin_tools/accounts/update_account/manage_edit' len(extra): 0 offset: 9200838 oid: 000206bb revid: 033bb0f4b80ad42a previous record offset: 17389418 # woopsie transaction offset: 17391715 # woopsie len(data): 1633 redundant trec len: 1753 offset: 9202521 end pos: 9204883 transaction id: 033bb0f7be87736e trec len: 2362 status: ' ' user: ' jasonb' description: '/admin_tools/accounts/update_account/manage_edit' len(extra): 0 offset: 9202599 oid: 000206bb revid: 033bb0f7be87736e previous record offset: 9198463 transaction offset: 9202521 len(data): 2242 redundant trec len: 2362 So, fixing this. fsrecover.py doesn't do the right thing, unfortunately. It just leaves the broken record alone. I'm not sure if making fsrecover handle this class of error is useful... It should be simply a matter of walking through the transactions, and patching the one that's busted. Or alternately, simply skipping it. I'll look into fixing this now. More in a bit. Anthony ___ 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] Packing (still) hosed in 2.6.2?
Woohoo! Fixed. I created an empty file, then used copyTransactionsFrom to copy all transactions across. This patched the backpointers. fsrecover.py should probably get some smarts to do something like this as well, but I've spent far too long on this problem already... :-/ from ZODB import FileStorage infilename='/app/zope/dev_csr_server/recover/Data.fs' outfilename='/app/zope/dev_csr_server/recover/Out.fs' outfs = FileStorage.FileStorage(outfilename) infs = FileStorage.FileStorage(infilename) outfs.copyTransactionsFrom(infs) I have some small patches to fsdump that outputs expected prev records alongside the actual ones, is this useful enough to check in? Anthony ___ 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] Packing (still) hosed in 2.6.2?
I remember that 2.6 had issues with packing, but I was under the impression that they'd been fixed... However, attempting to pack a Data.fs in 2.6-current-cvs fails for me: File "/export/01/zope/dev_csr_code/lib/python/ZODB/DB.py", line 526, in pack try: self._storage.pack(t,referencesf) File "/export/01/zope/dev_csr_code/lib/python/ZODB/FileStorage.py", line 1503, in pack opos = p.pack() File "/export/01/zope/dev_csr_code/lib/python/ZODB/fspack.py", line 680, in pack self.gc.findReachable() File "/export/01/zope/dev_csr_code/lib/python/ZODB/fspack.py", line 464, in findReachable self.buildPackIndex() File "/export/01/zope/dev_csr_code/lib/python/ZODB/fspack.py", line 486, in buildPackIndex self.checkData(th, tpos, dh, pos) File "/export/01/zope/dev_csr_code/lib/python/ZODB/fspack.py", line 189, in checkData ": %d != %d", dh.tloc, tpos) File "/export/01/zope/dev_csr_code/lib/python/ZODB/fspack.py", line 170, in fail raise CorruptedError(s) ZODB.fspack.CorruptedError: /app/zope/dev_csr_server/var/Data.fs.packtest:9200838:data record does not point to transaction header: 17391715 != 9200760 This is reproducible. The particular Zope that uses this file was shut down cleanly before attempting to pack the DB. The code that fails to pack is: import ZODB from ZODB import FileStorage filename='/app/zope/dev_csr_server/var/Data.fs.packtest' store = FileStorage.FileStorage(filename) db = ZODB.DB(store) db.pack() # boom. Help? I'm using the ZODB that's in the current 2.6 branch of CVS - according to ZODB/__init__.py it's version 3.1.2. Is a newer version of ZODB going to help here? Anthony ___ 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] more Zope2.6 fun: ZEO client death.
>>> Anthony Baxter wrote > Updating it by hand to ZEO2 hasn't made all good and happy, though - > the ZEO/start.py includes > import ThreadedAsync.LoopCallback > at the top of the file, but the sys.path magic that makes this > available is inside the main() function. Moving the import to > the line after the sys.path magic fixes this. > > I'm now getting a failed import for ZODB.utils.oid_repr, which > suggests that I'm going to need to update the ZODB installation > here from the one that's in 2.6.2. :-/ Ok, this was easy - Zope2.6 requires the ZODB3-3_1-branch ZEO code. The previous ThreadedAsync import fix still needs to be applied, though... Anthony ___ 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] more Zope2.6 fun: ZEO client death.
Jim and Andrew hit the nail on the head - excessive cleverness with vendor branches here meant that the ZEO directory had ZEO1 installed. Updating it by hand to ZEO2 hasn't made all good and happy, though - the ZEO/start.py includes import ThreadedAsync.LoopCallback at the top of the file, but the sys.path magic that makes this available is inside the main() function. Moving the import to the line after the sys.path magic fixes this. I'm now getting a failed import for ZODB.utils.oid_repr, which suggests that I'm going to need to update the ZODB installation here from the one that's in 2.6.2. :-/ -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] more Zope2.6 fun: ZEO client death.
>>> Anthony Baxter wrote
> So I see ZEO clients here falling over all over the place under current
> 2.6 with:
>
> 2003-07-30T07:01:04 ERROR(200) ZEO uncaptured python exception,
> closing channel
>
> (exceptions.AttributeError:keys
> [/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|poll|94]
> [/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|handle_read_event|395]
> [/export/01/zope/dev_ekit/lib/python/ZEO/smac.py|handle_read|172]
> [/export/01/zope/dev_ekit/lib/python/ZEO/zrpc.py|message_input|282]
> [/export/01/zope/dev_ekit/lib/python/ZEO/ClientStorage.py|out_of_band_hook|191]
> [/export/01/zope/dev_ekit/lib/python/ZEO/Invalidator.py|end|126]
> [/export/01/zope/dev_ekit/lib/python/ZODB/DB.py|invalidate|318])
For what it's worth, the following patch "makes it work" for me.
RCS file: /export/00/cvsroot/Zope/lib/python/ZODB/DB.py,v
retrieving revision 1.1.1.11
diff -u -r1.1.1.11 DB.py
--- DB.py 2003/07/24 08:35:40 1.1.1.11
+++ DB.py 2003/07/30 08:57:02
@@ -315,6 +315,8 @@
version=connection._version
# Update modified in version cache
# XXX must make this work with list or dict to backport to 2.6
+if type(oids) is type(''):
+oids = { oids: 1 }
for oid in oids.keys():
h=hash(oid)%131
o=self._miv_cache.get(h, None)
Note that despite the comment, it's in fact getting passed a single
oid as a string, not a dict or a list. I have no idea if there's _also_
code that might be passing a list, which will still be broken.
I'm not committing this to the CVS yet, because I'm not 100% positive
it's the "correct" fix. It certainly _seems_ to be, and I've now got
ZEO clients that actually work worth a damn...
Anthony
___
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] more Zope2.6 fun: ZEO client death.
So I see ZEO clients here falling over all over the place under current 2.6 with: 2003-07-30T07:01:04 ERROR(200) ZEO uncaptured python exception, closing channel (exceptions.AttributeError:keys [/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|poll|94] [/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|handle_read_event|395] [/export/01/zope/dev_ekit/lib/python/ZEO/smac.py|handle_read|172] [/export/01/zope/dev_ekit/lib/python/ZEO/zrpc.py|message_input|282] [/export/01/zope/dev_ekit/lib/python/ZEO/ClientStorage.py|out_of_band_hook|191] [/export/01/zope/dev_ekit/lib/python/ZEO/Invalidator.py|end|126] [/export/01/zope/dev_ekit/lib/python/ZODB/DB.py|invalidate|318]) The relevant code in current 2.6 CVS: if connection is not None: version=connection._version # Update modified in version cache # XXX must make this work with list or dict to backport to 2.6 >>> for oid in oids.keys(): h=hash(oid)%131 o=self._miv_cache.get(h, None) if o is not None and o[0]==oid: del self._miv_cache[h] (or http://cvs.zope.org/Zope/lib/python/ZODB/DB.py?annotate=1.43.6.4#316 ) The comment is correct. It _does_ need to work with a list or dict. It doesn't right now. If I'm _really_ _really_ lucky, I can have a ZEO client stay up for nearly half an hour before it hits this problem and falls over. The code was committed 2 months ago, as rev 1.43.6.3 "Backport atomic invalidations code." This, to me, seems a showstopper for 2.6.2. Anthony ___ 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: segfaults in cPersistence under 2.6
>>> "Tim Peters" wrote > Jeremy and I saw cases of ring corruption while putting together the > experimental ZODB 3.3, but they were 100% reproducible on all platforms, and > turned out to have clear causes (some of the C objects we backported from > ZODB4 were getting ghostified by the ZODB4 code without removing themselves > from the ZODB3 ring). So "ring corruption" rang a bell for me, but not one > that makes any sense in your context. > > Keep your eyes open, Anthony! If it happens again, I want to know. One thing that might be worthwhile is to move the MUCH_RING_CHECKING code from cPickleCache.c into a common file, and use it in cPersistence.c as well as cPickleCache.c. The latter wasn't seeing the corruption at all, while the former was. If this seems like a good idea I'm happy to make the change. Anthony ___ 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: segfaults in cPersistence under 2.6
*sigh* So I tried a fresh checkout on a different box, no crash. Completely nuked old checkout (which was a new checkout last night), checked out again, rebuilt, no crash. Beats me. I'm going to blame the electrician who took out power to our floor this morning, because it's that or cosmic rays. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] segfaults in cPersistence under 2.6
>>> Toby Dickenson wrote > On Friday 25 July 2003 08:30, Anthony Baxter wrote: > > More information: I don't see the failure with a fresh Data.fs. The > > Data.fs in question is my 2.5 one. > > Do you have any custom persistent extension classes stored in that Data.fs > that might not have been updated to the 2.6 persistence C API? Nope. The only C-code Product that's been added to this Zope (aside from those that ship with the system) is DCOracle/ZOracleDA, and I'm pretty certain that it's not doing anything with C code persistence. Is it possible that there's a C code product that's not been updated? How would I figure out what it might be? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] segfaults in cPersistence under 2.6
More information: I don't see the failure with a fresh Data.fs. The
Data.fs in question is my 2.5 one. I'm running the current HEAD of
Zope-2_6-branch. I packed the Data.fs, the same result.
I've added a simple function to 2.6's cPersistence.c:
static void
ringcheck(CPersistentRing *start)
{
CPersistentRing *s, *t;
int i=0;
s = start;
t = start;
if (!s) { return; }
for (;;) {
assert(s == s->next->prev);
assert(s == s->prev->next);
s = s->next;
i++;
if (s == t) {
break;
}
}
printf("ringcheck ok, %d items\n", i);
}
I then hooked into calling it from accessed(), ghostify() and unghostify()
and I'm seeing it consistently corrupted after 103 items end up in the
ring. I also turned on MUCH_RING_CHECKING in cPickleCache.c, but it
failed to see anything broken.
Interestingly, at the point it's detecting that the ring is busted
(rather than when it trips over the breakage, later on)
##1 0xfe451914 in accessed (self=0xeddb00) at ZODB/cPersistence.c:184
##2 0xfe452834 in Per_getattr (self=0xeddb00, oname=0x594368,
name=0x59437e "bjects", getattrf=0xfe6d7cec )
at ZODB/cPersistence.c:551
##3 0xfe4528f4 in Per_getattro (self=0xeddb00, name=0x594368)
at ZODB/cPersistence.c:566
##4 0x64bd8 in PyObject_GetAttr (v=0xeddb00, name=0x594368)
at Objects/object.c:1052
Maybe it's just me, but that name="bjects" looks suspicious as hell.
___
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] segfaults in cPersistence under 2.6
Wow. I'm having _so_ much fun with 2.6. I'm now seeing a reproducible
segfault on startup.
Program received signal SIGSEGV, Segmentation fault.
0xfe4517c8 in accessed (self=0xedbe58) at ZODB/cPersistence.c:160
160 self->ring.next->prev = self->ring.prev;
(gdb) p self
$1 = (cPersistentObject *) 0xedbe58
(gdb) p self->ring
$2 = {prev = 0xe5d8fc, next = 0xeb7b210c}
(gdb) p self->ring.prev
$3 = (struct CPersistentRing_struct *) 0xe5d8fc
(gdb) p self->ring.next
$4 = (struct CPersistentRing_struct *) 0xeb7b210c
(gdb) p self->ring.next->prev
Cannot access memory at address 0xeb7b210c.
#0 0xfe4517c8 in accessed (self=0xedbe58) at ZODB/cPersistence.c:160
#1 0xfe4526b4 in Per_getattr (self=0xedbe58, oname=0xbf280,
name=0xbf295 "as_key", getattrf=0xfe6d7cec )
at ZODB/cPersistence.c:524
#2 0xfe452774 in Per_getattro (self=0xedbe58, name=0xbf280)
at ZODB/cPersistence.c:539
#3 0x64bd8 in PyObject_GetAttr (v=0xedbe58, name=0xbf280)
at Objects/object.c:1052
#4 0x21c34 in eval_code2 (co=0x8090f8, globals=0x49daac, locals=0x8,
args=0xbf280, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:1773
#5 0x245b8 in call_eval_code2 (func=0x80ac24, arg=0xd9230c, kw=0x0)
at Python/ceval.c:2979
#6 0x24108 in call_object (func=0x80ac24, arg=0xd9230c, kw=0x0)
at Python/ceval.c:2818
#7 0x23f64 in PyEval_CallObjectWithKeywords (func=0x80ac24, arg=0xd9230c,
kw=0x0) at Python/ceval.c:2753
#8 0xfe6d4614 in callMethodWithPossibleHook (inst=0xea55d8, meth=0x80ac24,
args=0xd9230c, kw=0x0)
The code in question is here:
/* Do nothing unless the object is in a cache and not a ghost. */
if (self->cache && self->state >= 0) {
CPersistentRing *home = &self->cache->ring_home;
self->ring.prev->next = self->ring.next;
>>> self->ring.next->prev = self->ring.prev;
self->ring.next = home;
self->ring.prev = home->prev;
home->prev->next = &self->ring;
home->prev = &self->ring;
}
So it seems that the ring's getting corrupted in some way. Any tips on
tracking this down? I'm thinking of a simple function that just zips
around the ring checking that it's sane in both directions...
(yes, I've confirmed that all the C extensions have been rebuilt cleanly).
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] ZCatalog Indexes tab crawls...
>>> Andreas Jung wrote > I agree but the current implementation sux. Switching to a counter based > solution would solve the problem. The only problem I see is to keep the > code fully backward compatible. if there's no counter present: create one, do a count of the docs, initialise the counter display counter ___ 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] current zope2 head warnings with cur-cvs python
Running the current Zope2 HEAD with current-cvs python, starting gives the following 3 warnings. /home/anthony/src/zope/ZopeHead/lib/python/ZServer/medusa/test/max_sockets.py:53: DeprecationWarning: integer argument expected, got float for i in range(1 + len(sl) * 0.05): /home/anthony/src/zope/ZopeHead/lib/python/AccessControl/User.py:438: DeprecationWarning: assignment shadows builtin SpecialUsers.super=emergency_user -- 2003-07-11T22:40:10 PROBLEM(100) OFS.Application Duplicate Product name After loading Product 'README.txt' from '/tmp/z27/Products', I skipped the one in '/home/anthony/src/zope/ZopeHead/Products'. ___ 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] Versions: should they die?
>>> Oliver Bleutgen wrote > As you and Guido are talking about the ZMI (which means, AFAIK, the > managament interface), let me just say that as far as I understand it, > deprecating/marking-as-evil and even removing OFSP/Version.py is not > what I would like to see happen (not only). > > The problem lies in ZODB.ZApplication.ZApplicationWrapper > > def __bobo_traverse__(self, REQUEST=None, name=None): > db, aname, version_support = self._stuff > if version_support is not None and REQUEST is not None: > version=REQUEST.get(version_support,'') > else: version='' > conn=db.open(version) >... > > As I understand it, even if the Version product is removed, just putting > at variable named 'Zope-Version' into the REQUEST will cause reads and > writes to happen in a version. > Am I missing something here? I think that will only work if there's a Version with the specified name. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Versions: should they die?
>>> Guido van Rossum wrote > IMO versions do nothing except complexify the code. I believe it's an > official Zope Corp position to discourage them for new projects. Yet > Jeremy Hylton seems to think that they are somehow useful and has > carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, > they would have been gone, with a big helping of YAGNI! Worse yet, they _seem_ like a neat/useful solution. But they're not - it's a path that leads to madness and despair. I'd prefer the approach of making you change some code in lib/python/ to enable them, with them disabled by default. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] How (in)secure is Zope?
>>> Jamie Heilman wrote > Without properly configured resource limits, it is trivial to use an > exposed Zope instance to exhaust host resources. If this is a real risk for you, you should be using per-process limits to make sure that the host can't be completely destroyed. Sure, zope will fall over when it hits the limit, but that's better than taking out the whole host. Yes, the existing bugs should (and probably will) be addressed as they're found, but as a belt-and-braces kinda thing, limits are also useful. > > Zope's bug collector hides security related bugs until they are deemed > worth of display by the controllers. Personally I think full > disclosure is preferable to secrecy, but I'm willing to play by the > rules laid down as long as I think the system is working for the > general benefit of the community. You may have noticed I haven't been > terribly secretive about recent cross site scripting or cache > poisoning issues, and that can be attributed to, in part, my growing > disastifaction with the system. That's really a separate issue that is a zope corp thing to address... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] if-then-else expression in Python
>>> Dieter Maurer wrote > Currently, there is a heated debate in c.l.p about PEP 308, an > "if-then-else" expression for Python. > Some vote should decide its fate. > > I think, we want an "if-then-else" expression for Zope, as it would > make decisions in TALES expressions much clearer and more > robust than with the "... and ... or" hack or the "test" function which > evaluates all arguments before testing (which confuses newbies). > > Do not forget to vote! But please, please, don't just vote "yes" or "no" blindly. Read the vote proposal, when it's posted, and think about it. And _please_ don't go out soliciting "no" votes or "yes" votes from people who aren't going to read the proposal. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Does zope still need a python compiled with "--without-pymalloc" ?
>>> Dieter Maurer wrote > I am almost sure, you no longer need it. > At least, we use Python 2.1.3 compiled without this option > and do not see problems (attributable "malloc"). The (known) bugs that pymalloc (and cycle-gc) triggered are fixed in 2.1.3. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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 and python compatibility
>>> Leonardo Rochael Almeida wrote > It is possible to run 2.6 under Python 2.2, but it's unsupported Note that you'll need 2.2.2. 2.2 and 2.2.1 have bugs that Zope triggers. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCatalogs with SearchIndexes in ZODB - how to fix?
I've got a Data.fs which has been gradually moved from Zope version to zope version (it's quite possible that the same Data.fs was originally a Data.bbb!) We've been getting the SearchIndex deprecation warning for some time, and I'd like to fix it - as far as I can tell, it's caused by some ZCatalog objects in the ZODB that were created back when using SearchIndex was the hip'n'groovy way to impress the other catalog objects. Short of manually deleting and re-creating all the ZCatalog objects in the ZODB, is there a way to get these puppies updated to get rid of the warnings? Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ACTION: 2.6 project status updates...
I haven't yet finished of the CallProfiler bits, but it's a long weekend here, and I plan to attack and finish it over this weekend. I've had more of a go at the refresh problem, and I think I'll just make sure there's no refresh.txt for now :( Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope process killed
> It very nice to hear that I can simply upgrade and my problem will go away :) > And it did! Just thought I'd mention this since I didn't find anything > in the collector about it. maybe not in the zope collector, but there's several copies of it (and variants) in the python bugtracker :) If there was a Zope FAQ, I'd say this one'd get an entry. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope process killed
>>> =?ISO-8859-1?Q?Roch=E9?= Compaan wrote > When I try to view or delete a particular folder the Zope process (on > Zope 2.4.3) suddenly gets killed with this message in the log: > > python2.1: Python/ceval.c:695: eval_code2: Assertion `(stack_pointer - > f->f_valuestack) <= f->f_stacksize' failed. You should be running 2.4.4 or 2.5.1. This is a known bug in 2.4.3. (It only shows up under python 2.1.3 or later - earlier versions of python silently corrupt memory). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tyring to FTP to Zope running behind firewall, get login box but no directory listing
> > Do not be so quick to conclude that. FTP *has* firewall problems. since > I know nothing of the firewall, I can not help in too much detail. ftp connections, by default, go from the ftp server->client for the data connections. the data is carried by a seperate channel, on a randomly numbered port. I'd say it's almost _certainly_ a firewall issue. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
> Chris - stay in the stone age, I hear they have fire there ;-) mmm. fre pretty. "Page Templates burn, don't dey. Be a shame if somefing was to happen to your nice shiny website". Anthony, who might have been spending too long in the bad places of SQL. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
>>> Toby Dickenson wrote > Do you remember what we had to type to achieve the equivalent of > dtml-let, before dtml-let was introduced? That *was* horrible. gee, I dunno... has a sort of charm to it. sheesh, it's still not as ugly as ZPT. deliberately-trolling-for-ChrisW-ly yrs, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
>>> "Brian Lloyd" wrote > We've been trying hard to adopt this bit of Zen. If you write > REQUEST.set, you can look at it and easily see what is happening. > Same with SESSION.set. The other reason why I made SESSION all shouty-caps in SQLSession[*] is to make it _very_ obvious when it's being used. Storing stuff in a session is often one of the critical bits of a web request, so it's important to me that it be clear and easy to see this. Anthony [*] I assume the standard Zope session stuff has adopted the SESSION convention now? it wasn't in CST -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Python 2.1.3 is out.
Python 2.1.3 is out. See http://www.python.org/2.1.3/ This release _should_ now make Zope happy - it has the recent bugfix for the GC/Trashcan interaction ugliness. I'd recommend anyone running Zope 2.4 or 2.5 to upgrade to this version, in particular if you use PythonScripts. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ding, dong, the segfault is dead. Patch attached
> Nice to hear. Is there any change that this patch will be included in > the next Zope Binary release? Well, there will be a python 2.1.3 release for this fix, so I'd imagine that there will be a binary release from that... > The beast is killed! Finally! :) do I hear the sound of the next killer mongrel bug warming up, just offstage? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Final Python 2.1.x and Zope 2.5.x releases?
>>> Adam Manock wrote > Does anyone know of a release timeline for a new bugfix release of Python, > be it 2.1.2a or 2.1.3? I'm looking at it at the moment - I plan to roll out a version of this today on some of my ZEO clients and check it's stable. Sometime next week would be my guess for a release. At the moment it's looking like a source release, with RPMs and and ActiveState windows packages. I don't think there'll be a PythonLabs windows binary release, and there wasn't a 2.1.2 Mac binary release, either... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZClass Constructor Cleanup for 2.6
>>> Casey Duncan wrote > I don't think this is a big enough change to warrant a real proposal, so > I'll shoot this out here: > > Does anyone see a problem with changing the default generated > constructor method for ZClasses to a python script in Zope 2.6? +1. There's always some funniness in ZClass constructors anyway with the stupid acquisition tricks that get played, so making it a pythonscript can only make it more obvious what's going on... ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A thought for 2.6 about various leaks and memory problems
>>> "Adrian Hungate" wrote > moved to a different thread or earlier, before the fork, so that we could > simply kill senile threads without killing the entire shooting match? unfortunately apache does this with seperate processes, not threads. memory corruption and leaks aren't solved by offing threads, unfortunately. the equivalent would be to start a bunch of single threaded zeo clients on a machine, with a loadbalancer in front of them, and periodically off one. the only decent loadbalancers I've seen, however, are pretty heavy weight, flaky, limited in functionality, or some combination of all three. also, the start time for a new ZEO client is non-trivial. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] manage frame change
>>> seb bacon wrote > But we come back to the point that you may be logged into one of (say) 3 > app servers (ZEO clients) all serving the same domain, no? and on the same box ... :) Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] manage frame change
>>> seb bacon wrote > anyone object to changing the text at in the top ZMI frame to "Logged in > as on ?" Or is there a better place to put that info? > I find it useful when I've got several windows open to different servers. What does "" mean? The host running the ZEO server? The host running the ZEO client? What about those of us who run multiple ZEO clients on the same machine (multi-cpu, test instances, whatever)... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never to late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more on the segfault saga
>>> Dieter Maurer wrote > Just a wild guess: is the GC guaranteed to be thread safe? Yep. The GC is _almost_ certainly not the problem here - it's just that the GC is the poor bunny that has to walk through the objects in memory. So when something's been mangled, the GC is the thing that falls over and breaks. I think I've mentioned it before, but looking at the object _before_ the corrupted one in memory might be a useful thing to try... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never to late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.4.4b1 and Python 2.1.2 crash again
>>> Nicola Larosa wrote > you should read the Stability Howto: > > http://www.zope.org/Members/matt/StabilityHOWTO This docco doesn't clearly state that you MUST recompile your pythonscripts when upgrading to 2.4.4+ (when do we see a real 2.4.4, anyway?) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never to late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
>>> "Brian Lloyd" wrote
> What if, instead of the static list of callable info that the CP
> currently uses, Zope objects could register themselves as profilable?
> We would then make sure that the object types that CP handles now
> register themselves, but other products that we don't know (or
> have to know) about could register themselves too if they wanted.
This would resolve the problems, yes. It's a nice approach to take,
and it also allows the object to register a different method to be
patched.
> Think of this as "consentual" monkey-patching (hmm... may have to
> change this metaphor soon!).
Call it "gorilla-patching" - it's like monkey-patching.[1]
> The products have to take some explicit
> action to be profilable, so it is not invisible in the code of the
> product. The hooks will continue to installed as-needed, so there
> is no performance issue.
This would suggest that the CallProfiler shouldn't be an add-on product,
then, but installed in lib/python ? What's the best approach there?
Rich didn't get any response on zope-coders about this...
Anthony
[1]
Seagoon: Here! Have a gorilla.
Eccles: Oh! Thanks.
Grams: [Two gorillas fighting, or if you can't get that, lions.]
Eccles: Oww! Oww! Ooh! Oww! Hey! These gorillas are strong. Here!
Have one of my monkeys -- they're milder.
-- http://www.residents.com/Goons/napoleon.piano.html
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never to late to have a happy childhood.
Seagoon:
Here! Have a gorilla. Eccles:
Oh! Thanks. Grams:
[Two gorillas fighting, or if you can't get that, lions.] Eccles:
Oww! Oww! Ooh! Oww! Hey! These gorillas are strong. Here! Have one of my monkeys --
they're milder.
___
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/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6 planning - call for contributors!
> My main concern is the use of monkeypatching in the core makes it difficult > for someone else to release a product that also MPs without them worrying > about whether something has already patched code. Especially when we're > talking about MP'ing so many core Zope objects (yes, I count >1 as "so many" > :) Multiple monkeypatches should be fine, so long as each renames the __call__ method to something unique. > I think the performance hit is really quite minimal for two if statements at > the entry and exit point(s) of a function to turn the behaviour on and off. I'm not convinced. Those small increments of performance really add up. Look at how Python's performance over time has degraded as one after another small bits of cruft accumulated. It's also not just an if statement, it's a global lookup. > ps. don't forget Anthony, our first reaction when we both thought of this > approach was *shudder* :) Sure, but after tinkering a bit, and compared to the original hack that I did, this is sooo much cleaner. The amount of work required to instrument a new object is close to zero. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never to late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6 planning - call for contributors!
>>> seb bacon wrote > > [CallProfiler] > FWIW, my own opinion is that it should not take the 'MonkeyPatch' > approach. Why? Any other approach means a slowdown in the Zope code regardless of whether profiling is turned on or off... monkeypatching means you end up with zero slowdown when not profiling. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never to late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] still segfaults, this time no ZMySQLDA
>>> Leonardo Rochael Almeida wrote > So, what should I try now? I've been unable to keep up with email lately (no decent net connection) but can I ask if you've got a core dump at all? If so, where was it? Inside the garbage collector, I'm guessing... If so, what was the object _before_ the corrupted object in memory? (Had I thought to look at this when I had similar problems, I would have picked up the stupid stacksize bug much earlier...) If you haven't recompiled the scripts after upgrading to a working PythonScripts, you'll still see crashes. When you run with '-D', do you get a lot of "Script (Python) foo needs to be recompiled"? If the problem is that you can't recompile the scripts, why not shut it all down, manually mount the ZODB, and recompile 10 scripts at a time? (This is a not-particularly difficult task - I can give a sample bit of source if it would help...) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never to late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Load balancing over FastCGI
(apologies for formatting oddness - at conference, so don't have access to normal mailer. _hopefully_ this will be in plain text...) Andy Sydelko wrote: >Has anyone actually used multiple FastCgiExternalServer >directives within apache, each pointing to a separate ZEO >client, to load balance? > We do this by pointing the apache fastcgi at a loadbalancer, and loadbalancing the fastcgi ports that way. I tried to do it with apache and gave up. It's just too awful. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Call Profiler
>>> Richard Jones wrote > I've just announced our Call Profiler product on zope.org and the zope > announce list (waiting for people in different timezones to authorise them :) > ( http://www.zope.org/Members/richard/CallProfiler/ for the impatient) >From my point of view, this is a critical piece for Zope - right now, trying to work out what's going on in a Zope page render is somewhat painful. We found once we'd turned this onto our production code (and Richard had made my initial vile hack actually work in a way that didn't cause bleeding from the brain) we were able to very very quickly spot a whole lot of stuff that was Just Not Doing The Right Thing. Unfortunately, the existing python profiling stuff is at too low a level to be useful - this stuff really fills a need. Plus, if it's integrated into Zope, Richard doesn't have to spend work time on maintaining it :) Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BUG] Python 2.1.2 & Zope 2.4.1
>>> "Olivier Deckmyn" wrote > assertion "STACK_LEVEL() <= f->f_stacksize" failed: file "Python/ceval.c", > line 687 This is a new assertion, put in to catch the case where the RestrictedCompiler code used by PythonScripts incorrectly calculates stack size. > After some hours of researches, I have a (dirty, really) fix : > I had to modify Python sources and hack line 687 in ceval.c : I removed > it... This is _not_ a fix, any more than putting in a signal handler for SIGSEGV that ignored it and kept going would be a "fix" for a segfault bug. The bug is _real_ and causes memory corruption. The most likely result is that Zope will crash mysteriously, some time later down the track, but it's also possible you'll end up with random data corruption. This is _far_ worse than just a crash. If upgrading to 2.5 or 2.4.4-to-be is not an issue, just replace the lib/python/RestrictedPython package in your Zope installation and reboot. Please, please, please, don't propagate dodgy and incorrect fixes like the above (removing the assertion). The assertion is in the code for a very, very good reason. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
>>> Behrens Matt - Grand Rapids wrote > Anthony Baxter wrote: > > > In that case, how about cutting a version which is 2.4.3 + the compiler > > fixes? Crashes are bad, and it would be very nice to Make Them Go Away. :) > > You already have that. Check out the Zope-2_4-branch from CVS (see > http://dev.zope.org/CVS for info). Now leave poor Matt alone :-) I know - I do have this. Plenty of other people, tho, do NOT have the ability to build their own version of Zope. Requiring people to follow a somewhat arcane set of instructions and steps merely to get a stable version of Zope that doesn't crash strikes me as... odd. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
>>> "Matthew T. Kromer" wrote > 2.4.4 (which should be mostly the equivalent of the Zope-2_4-branch in > our CVS) hasn't been extensively tested. There are a LOT of things that > I'm aware of that _can_ cause crashes, ie in MySQL when the database > object switches threads, it can get unhappy (I think something in MySQL > may have thread-local state). In that case, how about cutting a version which is 2.4.3 + the compiler fixes? Crashes are bad, and it would be very nice to Make Them Go Away. :) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
>>> Harald Koschinski wrote > >Which version of Zope? > 2.4.3 > >Does it have the RestrictedCompiler fix? > Good question - next question please :-((( My understanding is that 2.4.3 still has the bug. > I am again a little bit confused - I thought that the problem is only in > the GC module of Python because zope is running without any crashes when > I disable GC. The bug's still there, it's just that the corrupted data is hit much more frequently when GC is on. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
>>> Harald Koschinski wrote > Hallo, > > after switching to python 2.1.2 compiled with GC > (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) > the crashes are back again :-((( > Which version of Zope? Does it have the RestrictedCompiler fix? As far as I am aware, Zope 2.4 includes it's own version of the Compiler code, and the current release of 2.4 still has the stacksize bug. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Core dumps - How to find out the bug?
>>> =?iso-8859-1?Q?Dario_Lopez-K=E4sten?= wrote > I only have core dumps to work from. I include the stack from latest core > dump. > I am using python 2.1.2 (release), Zope2.4.3 release, RedHat Linux 7.2. > Python is compiled --without-pymalloc Hm. The bug report you sent is pretty much exactly what I'd expect when hitting the Python Compiler stacksize bug. I suspect the problem here is that Zope 2.4.3 provides it's own complete copy of the Compiler, so you're not seeing Jeremy's fixes. Possible solutions: - wait for Zope 2.4.4 - upgrade to the current CVS version of the Zope 2.4 branch, Zope-2_4-branch. This contains what will become (hopefully, shortly) 2.4.4. I'm assuming there's a 2.4.4 planned. - upgrade to the current 2.5 beta. > > - > #0 0x0806fb77 in subtract_refs (containers=0x80b228c) at > ./Modules/gcmodule.c:170 > #1 0x0806ff74 in collect (young=0x80b228c, old=0x80b2298) at > ./Modules/gcmodule.c:382 > #2 0x080701c2 in collect_generations () at > ./Modules/gcmodule.c:479 Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Session Tracking in 2.5
>>> "Chris McDonough" wrote > There are supposed to be docs for the sessioning stuff, and > there *are* API docs in the help system. However, the > narrative docs that went along with CST were not translated > for the Zope 2.5 stuff. The docs folks here dont seem to > think its important, so I may need to do this and put it in > the Dev Guide. Well, I know _I_ think Session support is important (hint: I wouldn't have spent the effort on SQLSession otherwise). If the decision was made to take the CST package and change the interface before making it part of the preinstalled set of Products, I'd _strongly_ urge that the documentation for it be updated. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.4 crashes -- possible fix identified, other solutions also suggested
>>> "Matthew T. Kromer" wrote > Well, if you want to grab what is probably going to turn in to Python > 2.1.2 from CVS, you can get the release21-maint branch from > :pserver:[EMAIL PROTECTED]:/cvsroot/python package > python. I'd _love_ it if people wanted to do this, once the release candidate is out - I don't have access to a massive number of platforms, so I'd like to know if I've accidentally broken anything. :) Watch this space... -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.4 crashes -- possible fix identified, other solutions also suggested
>>> "Matthew T. Kromer" wrote > Anthony Baxter is anticipating a Python 2.1.2 beta real soon now (probably > this weekend) so I am going to try to get that into Zope 2.5's binary > releases, although we may put out a Zope 2.5 beta 3 first. This will > include the necessary Python patches to ceval.c to fix the frame bug; after > it hits the streets Python 2.1.2 will become our recommended Python for > Zope. That's still the plan - ripping along through the todo list at the moment. I'm just double-quadruple-triple checking the safety of the patch to make solaris threading not suck as a backport. Note that it's not going to be a beta, but a release candidate - it shouldn't be necessary to have a beta for a bugfix release. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] disabling gc does not necessarily hide memory corruption
>>> Jeremy Hylton wrote > Actually, I don't think the leaks haven't been fixed in CVS. It would > be at best painful to try and get the compiler code to work without > cycle GC. I really don't want to have to do it. In that case, there should probably be a readme note or similar saying "if you're using pythonscripts, don't bother without cyclic GC". For me, I run the ZEO server without GC (because that stops the stomped stack bug killing the ZEO server), and the ZEO clients with GC (and just wear the restarts. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] disabling gc does not necessarily hide memory corruption
>>> Chris McDonough wrote > This behavior is with the patches to the compiler package that were the > genesis of this thread? No, prior to that. I posted something about it to zope-dev an age or six ago - it seemed like the RestrictedPython compiler had mungo mungo numbers of cycles, and we found we couldn't run a zeo client on a nogc python for more than about an hour. ah - here's the message I sent: Date:Wed, 17 Oct 2001 18:10:27 +1000 To: [EMAIL PROTECTED] From:Anthony Baxter <[EMAIL PROTECTED]> Subject: RestrictedPython under no-GC 2.1 seems to leak a hell of a lot. Running current Zope 2.4 CVS under python 2.1 built --without-cycle-gc, I'm seeing an absolutely _enormous_ amount of leaked objects in RestrictedPython. This is on one of our ZEO clients, after 45 minutes of runtime. The deltas are after 5 minutes. RestrictedPython.compiler.transformer.Transformer 146527 163546 +17019 RestrictedPython.compiler.visitor.ASTVisitor 55842 62333 +6491 RestrictedPython.compiler.misc.Set 34827 38843 +4016 RestrictedPython.compiler.pyassem.FlowGraph 19173 21413 +2240 RestrictedPython.compiler.ast.Stmt 19174 21390 +2216 RestrictedPython.compiler.pycodegen.CodeGenerator 18333 20486 +2153 RestrictedPython.compiler.symbols.SymbolVisitor 15303 17096 +1793 RestrictedPython.compiler.ast.Name 13917 15542 +1625 RestrictedPython.compiler.ast.Const 14083 15691 +1608 RestrictedPython.compiler.ast.CallFunc 13798 15405 +1607 RestrictedPython.MutatingWalker.MutatingWalker 11968 13360 +1392 RestrictedPython.compiler.ast.Return 11986 13371 +1385 RestrictedPython.compiler.ast.Function 11986 13371 +1385 RestrictedPython.RestrictionMutator.RestrictionMutator 11800 13166 +1366 RestrictedPython.compiler.pycodegen.LocalNameFinder 11028 12322 +1294 RestrictedPython.compiler.pyassem.Block 10226 11401 +1175 RestrictedPython.compiler.pyassem.PyFlowGraph 9587 10707 +1120 RestrictedPython.compiler.misc.Stack 9587 10703 +1116 RestrictedPython.compiler.ast.Module 9590 10698 +1108 RestrictedPython.compiler.ast.Global 5761 6433 +672 RestrictedPython.compiler.ast.Assign 5761 6433 +672 RestrictedPython.compiler.ast.AssName 5761 6433 +672 [] ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] disabling gc does not necessarily hide memory corruption
>>> Leonardo Rochael Almeida wrote > >From my mile-high look at the issues, it seems like the cycle-gc asks > for an object where to look for for it's references (at least thats what > the tp_traverse function looks like it does). So, if your tp_traverse > sends the gc somewhere it shouldn't go (or if tp_traverse itself is not > some C function pointer), you get a crash. When I look at it, I see the GC hitting an object with a null tp_type, and a refcount of 1. This is monster bogus - but normally (non-GC) it would just be ignored and sit there as a small memory leak. > import gc > gc.disable() > also stops the SIG11 without the need of a python recompile, but I'll > only be sure when the server gets office-hours-traffic tomorrow morning. I find that if I do this I get a vast vast number of RestrictedPython cycles leaking (according to the manage_debug screen) and memory consumption goes through the roof. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.4 crashes -- possible fix identified, other solutions also suggested
>>> Jeremy Hylton wrote > Do you have any more idea about what shutting the garbage collector > off achieves? In practice, the garbage collector's most common effect > is to turn latent bugs into manifest bugs; a bug has trashed part of > memory and the garbage collector just happens to find it first. If > you turn GC off in these cases, you run a little longer, but you're > running with corrupted memory. Sorry I haven't been keeping up with the zope-* lists of late - this is what I've found as well. Something, and I strongly suspect it's inside the Zope C code, is playing jumpy-jumpy-stomp-stomp on bits of memory. The garbage collector is hitting this corrupted data and dying. I've posted before about the structure I've found that's corrupted (it's _always_ the same structure) but I've not yet been able to track down what it is. For us, the "fix" has been to run more zeo clients behind a loadbalancer, so that when one crashes out (about every 10-12 hours for us) things keep working, and the zopecontrol script restarts it. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Any interest in a set of Zope products to support CVS-versioned, XML/XSLT-based Zope development?
You might want to look at the fishbowl project on this that was recently announced: http://dev.zope.org/Projects/Wikis/DevSite/Projects/ZopeVersionControl/ (URL copied from Brian Lloyd's earlier email - with a 7s delay in the AU-US net link at the moment, I can't check it's correct, unfortunately...) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] login prompt after letting user change his password.
Or use a session cookie for the user/pw - when the user changes their password, change it in the current session, as well. Basic Auth is not going to allow you to do this at all[1] Anthony [1] ok, there's a possibility that you could do browser specific JS to hack the stored auth credentials, but it's pretty unlikely... >>> Steve Alexander wrote > Chris Withers wrote: > > > Clark OBrien wrote: > > > >>It is really confusing for the login to pop up at this point- > >>particularly because > >>it looks like it is asking for permissions to change the password ( > >>needs OLD password) > >> > > > > You're asking for Web browser functionaility to be changed, go bug W3C, > > Microsoft, Netscape and any other browser vendor you want to ;-) > > > You could program something really fancy into the UserFolder that > continued to allow the old password until the new password has been > used, or one day has passed. > > -- > Steve Alexander > Software Engineer > Cat-Box limited > > > > ___ > 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/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] help identifying a structure inside Zope.
>>> Chris McDonough wrote > I'd be tempted to suspect the BTrees module setstate code. Yeah? This is something that you'd expect to see with it? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] help identifying a structure inside Zope.
I'm hunting for a very very obscure python-crashing bug on Solaris with Zope2.4 on Python2.1.1. The structure that's getting corrupted looks something like: 299, (300, (301, (302, (303, ( 304, ( 3, "c_o_s" ) ) ) ) ) ) (nested tuples) I'm wondering if anyone can think of somewhere inside Zope that generates this sort of structure? "c_o_s" is a string we use in our code as a property, a database column, and a REQUEST variable. As far as we can tell, it's not something being generated by our code... Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] RestrictedPython under no-GC 2.1 seems to leak a hell of a lot.
Running current Zope 2.4 CVS under python 2.1 built --without-cycle-gc, I'm seeing an absolutely _enormous_ amount of leaked objects in RestrictedPython. This is on one of our ZEO clients, after 45 minutes of runtime. The deltas are after 5 minutes. RestrictedPython.compiler.transformer.Transformer 146527 163546 +17019 RestrictedPython.compiler.visitor.ASTVisitor 55842 62333 +6491 RestrictedPython.compiler.misc.Set 34827 38843 +4016 RestrictedPython.compiler.pyassem.FlowGraph 19173 21413 +2240 RestrictedPython.compiler.ast.Stmt 19174 21390 +2216 RestrictedPython.compiler.pycodegen.CodeGenerator 18333 20486 +2153 RestrictedPython.compiler.symbols.SymbolVisitor 15303 17096 +1793 RestrictedPython.compiler.ast.Name 13917 15542 +1625 RestrictedPython.compiler.ast.Const 14083 15691 +1608 RestrictedPython.compiler.ast.CallFunc 13798 15405 +1607 RestrictedPython.MutatingWalker.MutatingWalker 11968 13360 +1392 RestrictedPython.compiler.ast.Return 11986 13371 +1385 RestrictedPython.compiler.ast.Function 11986 13371 +1385 RestrictedPython.RestrictionMutator.RestrictionMutator 11800 13166 +1366 RestrictedPython.compiler.pycodegen.LocalNameFinder 11028 12322 +1294 RestrictedPython.compiler.pyassem.Block 10226 11401 +1175 RestrictedPython.compiler.pyassem.PyFlowGraph 9587 10707 +1120 RestrictedPython.compiler.misc.Stack 9587 10703 +1116 RestrictedPython.compiler.ast.Module 9590 10698 +1108 RestrictedPython.compiler.ast.Global 5761 6433 +672 RestrictedPython.compiler.ast.Assign 5761 6433 +672 RestrictedPython.compiler.ast.AssName 5761 6433 +672 After around an hour of runtime, the various ZEO clients are chewing about 100M of virtual memory each, and growing at a fearsome fearsome rate... Is this just a "known problem, deal with it"? I can't just turn back on the garbage collector, as it's causing random segfaults (yes, I'm working on trying to fix this as I speak^H^H^H^H^Htype). Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS: Zope-2_4-branch HelpSys b0rken.
> > For the URL http://ekit-host.ekorp.com:8880/HelpSys/menu > This URL is not reachable Yes, that's right. It's an internal system. > I can't reproduce this problem with a fresh 2.4 checkout. Maybe they are > running > some 2.4 alpha oder beta version. This functionality in the released Zope > 2.4 versions > is working. I'm running CVS: Zope-2_4-branch, as the subject states. As of today. I'm mentioning this so that if there _is_ a problem in the current CVS (there's been a number of CVS commits related to catalog on that branch lately) it can be fixed before the next 2.4 release. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CVS: Zope-2_4-branch HelpSys b0rken.
Someone's busted the help system recently. On a system running the current Zope-2_4-branch, I get: For the URL http://ekit-host.ekorp.com:8880/HelpSys/menu No error message. Error type: TypeError Error value: Catalog addIndex now requires the index type to be resolved prior to adding; create the proper index in the caller. Traceback follows: Traceback (innermost last): File /app/zope/ekit_code/lib/python/ZPublisher/Publish.py, line 122, in publish File /app/zope/ekit_code/lib/python/ZPublisher/mapply.py, line 104, in mapply (Object: menu) File /app/zope/ekit_code/lib/python/ZPublisher/Publish.py, line 111, in call_object (Object: menu) File /app/zope/ekit_code/lib/python/Shared/DC/Scripts/Bindings.py, line 322, in __call__ (Object: menu) File /app/zope/ekit_code/lib/python/Shared/DC/Scripts/Bindings.py, line 342, in _bindAndExec (Object: menu) File /app/zope/ekit_code/lib/python/App/special_dtml.py, line 182, in _exec (Object: menu) File /app/zope/ekit_code/lib/python/TreeDisplay/TreeTag.py, line 163, in render (Object: a tree tag) File /app/zope/ekit_code/lib/python/TreeDisplay/TreeTag.py, line 179, in tpRender (Object: HelpSys) File /app/zope/ekit_code/lib/python/TreeDisplay/TreeTag.py, line 306, in tpRenderTABLE (Object: HelpSys) File /app/zope/ekit_code/lib/python/HelpSys/HelpSys.py, line 190, in tpValues (Object: HelpSys) File /app/zope/ekit_code/lib/python/HelpSys/HelpSys.py, line 120, in helpValues (Object: HelpSys) File /app/zope/ekit_code/lib/python/App/Product.py, line 355, in getProductHelp (Object: PluginIndexes) File /app/zope/ekit_code/lib/python/HelpSys/HelpSys.py, line 278, in __init__ (Object: Help) File /app/zope/ekit_code/lib/python/Products/ZCatalog/ZCatalog.py, line 237, in __init__ (Object: catalog) File /app/zope/ekit_code/lib/python/Products/ZCatalog/Catalog.py, line 322, in addIndex TypeError: Catalog addIndex now requires the index type to be resolved prior to adding; create the proper index in the caller. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] making wo_pcgi only rebuild when necessary.
I've got Zope code and installation pretty heavily automated here, but one thing that takes a while is that after a cvs update, I have to do a complete wo_pcgi on each box to make sure everything's up to date. This forces everything to be rebuilt. Is there anything that could be done to make it only rebuild what's needed? Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DISCUSS: Community checkins for CVS
>>> "Morten W. Petersen" wrote > Will a ZPL-ish license [1] be accepted (declared, ref. paragraph > 4 of the Zope Contributor Agreement) by the Zope Corporation? > [1] http://www.thingamy.org/tpl Um, this license would seem to have the "obnoxious advertising clause" problem - it requires you to put the "This product... blah blah" in. If you end up with 25 different contributors with the same sort of clause, you're going to have a complete shambles. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] [patch] making 'Find' traverse into ZClass Products
I got completely fed up with the Zope 'Find' stuff not being about to traverse through Products/Foo/FooProduct, where FooProduct is a ZClass. The following patch adds this support to the FindSupport.ZopeFind method through the simple fix of saying "if it's a ZClass, keep looking in ob.propertysheets.methods" It seems to Work For Me - I'd post it to the collector, but I can't reach it at the moment... Anthony Index: FindSupport.py === RCS file: /export/00/cvsroot/Zope/lib/python/OFS/FindSupport.py,v retrieving revision 1.1.1.5 diff -u -u -r1.1.1.5 FindSupport.py --- FindSupport.py 2001/09/21 04:25:43 1.1.1.5 +++ FindSupport.py 2001/09/21 06:15:53 @@ -152,11 +152,16 @@ if hasattr(obj, 'aq_base'): base=obj.aq_base -if not hasattr(base, 'objectItems'): -return result -try:items=obj.objectItems() -except: return result - +if hasattr(base, 'objectItems'): + try:items=obj.objectItems() + except: return result + else: + if base.meta_type == "Z Class": + try:items=obj.propertysheets.methods.objectItems() + except: return result + else: + return result + try: add_result=result.append except: raise AttributeError, `result` @@ -195,13 +200,21 @@ add_result((p, ob)) dflag=0 -if search_sub and hasattr(bs, 'objectItems'): -self.ZopeFind(ob, obj_ids, obj_metatypes, +if search_sub and ( hasattr(bs, 'objectItems') or +bs.meta_type == "Z Class") : + if bs.meta_type == "Z Class": + subob = ob.propertysheets.methods + sub_p = '%s/propertysheets/methods'%p + else: + subob = ob + sub_p = p + +self.ZopeFind(subob, obj_ids, obj_metatypes, obj_searchterm, obj_expr, obj_mtime, obj_mspec, obj_permission, obj_roles, search_sub, - REQUEST, result, p) + REQUEST, result, sub_p) if dflag: ob._p_deactivate() return result
Re: [Zope-dev] ZPL and GPL
>>> Michael "R." Bernstein wrote > I guess I don't understand how licensing Python under the GPL would > prevent people from writing proprietary software in Python. embedded or frozen python. I know I'd much rather see Python embedded in applications than Tcl or (god help us all) Javascript/ECCCHMAScript. I can't see cisco agreeing to opensource IOS so that they can embed a decent language in it. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL
>>> Michael "R." Bernstein wrote > Unless I've misunderstood something (which is certainly possible), DC > doesn't seem to have anything to lose by switching from a BSD style > license to the GPL (or a GPL style license with an additional optional > attribution clause), and quite a bit to gain. They will probably lose developer mindshare. Given how important this is to Zope's growth (and to DC's growth, as a result), this is far far more important than the karma from switching to the far less flexible GPL. Your argument seems to be that DC would want to control other companies ability to make distributions derived from Zope - unless they've been hiding this nefarious plan from the community, this doesn't seem to be an objective for them. As far as a contributor to Zope wanting to keep their work free, then if the ZPL is GPL compatible, they can make their components GPLd. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL
>>> Jerome Alet wrote > I personnally would love to see both Python and Zope be GPLed. Why? No really. Exactly what do you gain from this? Assuming Zope's license becomes GPL compatible, any packages you release you can choose to GPL. Why do you think having the GPL is a good thing for the core package? Ideological reasons? How does releasing under the GPL make the world a better place? Anthony, who's seen too much of the GPLd-for-GPLs-sake. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZEO Clients, broken servers, and Z2.pid
As far as I can see, ZEO clients don't write a pid to Z2.pid until after they've successfully connected to a storage. Is there a reason for this? Ta, Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZEO client-server protocol endian-safe?
Any known gotchas with running ZEO server and ZEO client on boxes of different endianness? e.g. the server running on sun solaris/sparc, while the clients are on x86 linux boxes. I'd expect it to be fine, but am feeling paranoid... ta, Anthony. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Greedy except clauses
I took the list I generated, and started looking at a number of them. There seems to be a number of different types of case: There's the "just too slack to specify the exception" case -- generally easy, if tedious, to fix. There's the "we're rendering DTML, it could raise an exception of some sort, let's just eat it" -- this is almost certainly the worst sort. Then there's the 'gods only know what this is for' ones -- I think these might best be approached by putting a logging statement in the except body just to get an idea of what they're doing. There's certainly ones that are exceptions around too many lines, when it's obviously just meant to catch the one line. I just realised the list I put up has a few that are wrong, for some reason - my simple-minded script was obviously too simple-minded - will fix. (hm, in the case where a bare except _is_ genuinely what's wanted, could we put a comment in the source to make it easier to strip them out). Anthony, working towards an "except:" free-world :) >>> Jeremy Hylton wrote > >>>>> "AB" == Anthony Baxter <[EMAIL PROTECTED]> writes: > > AB> Now, it's obvious that not all of these are bad - some are > AB> probably fine - but there's also many that are _not_ good. The > AB> one in MailHost.py does eat exceptions. I'm sure there are > AB> others. > > I am probably a bit idiosyncratic, but I prefer to avoid bare excepts > at all costs. I often use "except Exception:", otherwise I add a > comment that specifically notes that I intend to catch everything. > Otherwise, you can't tell the difference between intentional and > accidental use. > > AB> I've done a quickie hack script that runs over the source and > AB> produces a list of matches to lines in the file, and links to a > AB> lightly patched viewcvs so that you can jump straight to the > AB> lines. It seems like it would be reasonably easy to make this a > AB> bit more sophisticated to include things like the nesting 'def' > AB> and 'class' method. > > AB> This, to me, seems like a pretty nice community type task - > AB> people could take one of them off the list of unchecked ones, > AB> and have a look through the code... no? > > It would also be interesting to see how many try/except blocks are > including more code than they should. The larger the block, the more > likely that a line of code raises an error that the author didn't > consider; these errors can mean that real bugs get caught be accident > and ignore. When the block is small -- preferably just a line or two > -- there is litle chance for error. Of course, there are very good > reasons to have longer except blocks. > > Jeremy > -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Greedy except clauses
Ok, my last for tonight - I put the output of my horrible script at http://www.zope.org/Members/anthony/BarewordExcepts I'll work over it a bit probably early next week - an obviousish next step is to make it note when the body of the except: contains a 'raise' statement. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Greedy except clauses
ooo. Richard didn't do it right - there's actually over _600_ bareword except: clauses in the current zope-2_3-branch A quick breakdown of some of the biggies: 71 in OFS/ 61 in ZODB/ 56 in ZServer/ 53 in ZGadflyDA 50 or so in what seems to be test scripts or modules (probably ok) 42 in ZPublisher/ 42 in DocumentTemplate/ 40 in App/ 38 in AccessControl/ 32 in Shared/DC/ZRDB/ 24 in ZCatalog 15 in webdav/ 15 in DateTime/ 13 in PythonScripts 12 in utilities/ or the install scripts 11 in OFSP/ Now, it's obvious that not all of these are bad - some are probably fine - but there's also many that are _not_ good. The one in MailHost.py does eat exceptions. I'm sure there are others. I've done a quickie hack script that runs over the source and produces a list of matches to lines in the file, and links to a lightly patched viewcvs so that you can jump straight to the lines. It seems like it would be reasonably easy to make this a bit more sophisticated to include things like the nesting 'def' and 'class' method. This, to me, seems like a pretty nice community type task - people could take one of them off the list of unchecked ones, and have a look through the code... no? Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Greedy except clauses
> > Is it the sort of thing where it's just work putting a list of all of > > them (line numbers, &c) up on a web page, maybe crosslinked into cvsweb? > > Then people can go and pick them off, one at a time. ok dokey - so, is DC still running a source view web system? If so, you could easily enough run a daily job like: find . -name '*.py' -print | xargs grep -n 'except:' | cut -d: -f1,2 to get the list of them from the source, and put the root of a viewcvs URL on it. Hm, viewcvs doesn't really cut it for this, but lxr would... whatcha think? ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Greedy except clauses
>>> [EMAIL PROTECTED] wrote > I've run into several greedy except: clauses now, and have submitted > patches to make them a little less greedy. Out of curiosity, I searched the > Zope source for "unfiltered" except: clauses... > % grep -rl "except:$" . |wc -l > 102 > ... erk Erk and a lot. This is a major major pain in the backside - e.g. the one in MailHost that just eats template rendering errors. > I'm willing to have a go at cleaning some of those except: clauses up, but > I can't possibly do 102 of them (I have a product dealine coming up :) Is it the sort of thing where it's just work putting a list of all of them (line numbers, &c) up on a web page, maybe crosslinked into cvsweb? Then people can go and pick them off, one at a time. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux Zope <-> Win2K SQL Server?
Use the Sybase client libraries, with ZSybaseDA. We do that here, and it works fine (but not for much longer, byebye sqlserver...) Or FreeTDS, but I don't think it's thread-safe, so you'll need to use a Thunked adaptor. >>> "Neil K" wrote > > I'm still trying to figure out what the missing pieces are... if anyone else > has gotten a Linux Zope talking to a Win2K SQL Server 2000, I would > appreciate some guidance. > > It seems I would have to write my own Product from scratch to do this, no > matter what. None of the ODBC Products seem to be available for Unix, and > ODBC from Unix <-> Windows will require additional software like EasySoft's > ODBC Bridge anyway. Or I could just not use ODBC at all and make some > Product customized to MS SQL Server. > > Some may suggest using ActiveState's Perl Methods for Zope and DBD::Proxy. > :) It's a possibility, but I'd like to see if more conventional solutions > exist. > > -- > Neil Kandalgaonkar, ActiveState > > > > ___ > 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/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
>>> Toby Dickenson wrote > > Are you suggesting that the session token should actually > > store session > > data? > As an alternative SessionManager, it appears to have some advatanges that > others do not. It also has a major disadvantage, if you don't want the users to be able to monkey with their session settings. > Its also the only sensible option that lets you bookmark your place in a > session, and return to it much later (which interests me more). This of course assumes you put _everything_ in the session. This could become quite horribly Notes-like in it's URL. > Isnt the tree tag an example of one Session use case? It smells alot like a > session to me. Note that www.ekit.com's tree tag (go to, e.g. http://www.ekit.com/ekit/Info/) stores the tree tag state in the session. It was a simple enough mod to the tree tag (btw, in case no-one's repeated it recently, the tree tag is Pure Evil From Planet Ten, and must be destroyed :) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CoreSessionTracking proposal
>>> KevinL wrote > > Please, please, please, do _not_ use IP numbers to verify it's the same > connection. You guys don't have the problem in .us, but out here at the > fringes (.au, and presumably .uk and similar), proxy server use is rampant - > and leaning on IP breaks, because proxy's share the connection around. worse yet, the customer may not even be aware of the proxy, if the network provider is using some sort of device like those cruddy cisco transparent proxies (hi Kev!) having spent a fair chunk of the last week dealing with issues of caching and general mangling caused by dodgy and strange proxies, I can only add that if it's possible for a proxy to do something wierd and wrong (like, lie about the original IP address) assume that it will. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: "permission mapping error" when importing a ZClass-based product.
Ok, I got a quick workaround by making a new Product, and creating the permissions it needed inside there. I _suspect_ the problem was caused by nested ZClasses. Uuuugly. Anthony >>> Anthony Baxter wrote > > I'm trying to export/import a ZClass based product from one Zope2.2 > system to another, and I'm getting the following: > > Error Type: Permission mapping error > Error Value: Attempted to map a permission to a permission, Edit ekit Partn er, > that is not valid. This should never happen. (Waaa). > > Well, it has happened, and I'd like it to go away. Any ideas what causes > this? > > Anthony > -- > Anthony Baxter <[EMAIL PROTECTED]> > It's never too late to have a happy childhood. > -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] "permission mapping error" when importing a ZClass-based product.
I'm trying to export/import a ZClass based product from one Zope2.2 system to another, and I'm getting the following: Error Type: Permission mapping error Error Value: Attempted to map a permission to a permission, Edit ekit Partner, that is not valid. This should never happen. (Waaa). Well, it has happened, and I'd like it to go away. Any ideas what causes this? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 2.0
What was once known as 1.6 is now called 2.0. There's probably more at the pythonlabs website. ah, here we go http://www.pythonlabs.com/tech/python2.html Note that the release is currently held up for some reasons to do with the python team all leaving CNRI and going to BeOpen - sounds like some sort of licensing or copyright ugliness. The python development's moved to sourceforge in the meantime, so you can track it in CVS if you feel so inclined. Anthony >>> "Jeff K. Hoffman" wrote > On Mon, 24 Jul 2000, Toby Dickenson wrote: > > > On Fri, 21 Jul 2000 16:29:23 +0100, Toby Dickenson > > <[EMAIL PROTECTED]> wrote: > > > > This problem goes away if I don't compile python with garbage > > collection support. I guess I shouldn't be suprised. > > Python 2.0? Garbage collection? Huh? What? > > Last I checked, Python 1.5.2 was the newest stable release, with 1.6 being > under development. 1.7 due out by the end of the year, and Python 3000 > being a redesign from the ground up. > > Is there a 2.0 somewhere that I don't know about? > > > Toby Dickenson > > [EMAIL PROTECTED] > > --Jeff > > --- > Jeff K. Hoffman 704.849.0731 x108 > Chief Technology Officer mailto:[EMAIL PROTECTED] > Going Virtual, L.L.C. http://www.goingv.com/ > > > ___ > 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/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO and Mountable Fses?
It's on my list, but I'm not going to get to it for a week or so. Anthony, building a MountRegistry... >>> Bill Anderson wrote > > Subject carries the question. Anyone tried this yet, or have any > insights about it? > > I am considering giving a go this week, thought I'd see if there are any > heads-up notices I should be aware of. :) > > Back-to-the-migrations-to-ZEO-ly y'rs Bill > > -- > "Linux: the operating system with a CLUE... > Command Line User Environment". > > seen in a posting on comp.software.testing > > ___ > 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/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: advice on MountedFileStorage changes.
>>> Shane Hathaway wrote > I looked some more at ZClasses and such today, hoping to solve the > problem with mounted databases. Guess what! It turned out to be a > simple matter. Excellent! I've added support in CVS, and I'll do a new release this evening. > The latest addition to Mount.py provides the ability for a MountPoint > to get its ZClass definitions from the root database rather than the > mounted database. Anthony, I think you'll want to make > "classDefsFromRoot" a checkbox available when adding a new mount point. Done. Cool, it looks like it even handles recursive mounts. > Depending on the application, this can be the more sensible (and more > manageable) approach. For example, you may want to have a large > collection of little FileStorages, all using the same ZClass > definitions. You certainly wouldn't want to make a copy of all > ZClasses in each FileStorage. Exactly. For me, one of the big things about the MountedFileStorage is the ability to split out the data for various sections of the tree - I still want to be able to make ZClass instances, but I don't want to have to manage copying all products all over the place. > In doing this I realized, and Jim suggested, that there are other > situations where you'd really want ZClass definitions to come from the > mounted database. This is a larger issue. We will first need to > provide a way to manage the databases. Then there will be a need to > load/unload products dynamically. I don't think we want to try to > finish that for 2.2.0. The next MountedFS release will have a teeny tiny Control_Panel like thing in the root of the mountpoint. I'll try putting a Products folder in it. Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] advice on MountedFileStorage changes.
>>> Anthony Baxter wrote
>
> I've nearly completed the code to make MountedFileStorage able to
> create new FileStorages on demand, _however_...
>
> I'm hitting a bit of a problem with the Product initialisation. Right
> now I'm just calling OFS.Application.initialize(), which goes through
> and re-imports all the products, and adds them to the global meta_types
> list. This is bad - it means it's slow as hell reimporting everything,
> and everything gets listed twice. It's fine after a restart, but that's
> not much help.
Ok, I've gone with the 'subclass Application' approach, and made a
couple of slight changes to the core code. Now, stuff won't be added
to global registries like Products.meta_types if the application doesn't
have isTopLevelPrincipiaApplicationObject set to true.
It seems to work well, patch follows - any comments?
Anthony.
This patch (against current CVS, 2000-06-11) stops the addition of a new
MountedFileStorage adding all the products to the master meta_types list.
It's not _essential_, but without it, you'll find you need to restart Zope
to get the 'Add' list back to sanity.
Index: OFS/Application.py
===
RCS file: /cvs-repository/Zope2/lib/python/OFS/Application.py,v
retrieving revision 1.128
diff -u -r1.128 Application.py
--- Application.py 2000/06/09 23:52:45 1.128
+++ Application.py 2000/06/11 07:00:30
@@ -511,7 +511,8 @@
error=sys.exc_info())
get_transaction().abort()
-Products.meta_types=Products.meta_types+tuple(meta_types)
+if app.isTopLevelPrincipiaApplicationObject:
+ Products.meta_types=Products.meta_types+tuple(meta_types)
Globals.default__class_init__(Folder)
Index: App/ProductContext.py
===
RCS file: /cvs-repository/Zope2/lib/python/App/ProductContext.py,v
retrieving revision 1.22
diff -u -r1.22 ProductContext.py
--- ProductContext.py 2000/06/09 01:22:13 1.22
+++ ProductContext.py 2000/06/11 07:00:30
@@ -202,12 +202,13 @@
if not hasattr(pack, '_m'): pack._m={}
m=pack._m
-Products.meta_types=Products.meta_types+(
-{ 'name': meta_type or instance_class.meta_type,
- 'action': ('manage_addProduct/%s/%s' % (pid, name)),
- 'product': pid,
- 'permission': permission,
- },)
+ if app.isTopLevelPrincipiaApplicationObject:
+ Products.meta_types=Products.meta_types+(
+ { 'name': meta_type or instance_class.meta_type,
+ 'action': ('manage_addProduct/%s/%s' % (pid, name)),
+ 'product': pid,
+ 'permission': permission,
+ },)
m[name]=initial
m[name+'__roles__']=pr
___
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/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] advice on MountedFileStorage changes.
I've nearly completed the code to make MountedFileStorage able to create new FileStorages on demand, _however_... I'm hitting a bit of a problem with the Product initialisation. Right now I'm just calling OFS.Application.initialize(), which goes through and re-imports all the products, and adds them to the global meta_types list. This is bad - it means it's slow as hell reimporting everything, and everything gets listed twice. It's fine after a restart, but that's not much help. I can't just skip product initialisation, as it's kinda needed to create objects in the sub-zodb. So, approaches I'm considering: passing a flag through initialize() saying 'don't put products in the meta_types' (seems hacky). subclassing OFS.Application.Application, and copying the method except for the last line that alters the meta_types (fragile - have to track changes to the main body of code). trying something else entirely, such as copying the products from the main products folder, and installing them that way... ? Any ideas appreciated. (There's an ongoing issue, too - there will need to be some sort of way to copy any new/changed Products from the main ZODB to the children...) Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] transaction support for ordering transactions.
>>> "Phillip J. Eby" wrote > There is an error in your patch, however. _prepend should use > self._objects.insert(0,object), as the way you're doing it now will break > the _append method. (Because _append is a reference to _objects.append, > and you're replacing the old _objects with a new list. Subsequent calls to > _append will append the object to the old _objects list, not the new one > you've just added.) Darn. That'll teach me to make a quick patch like this. Still, getting the feedback is the key thing - I wasn't sure if the approach I was taking was the right one. > There is also a *second* problem with your patch, which is more serious and > less correctable. If a _prepend takes place *during* a commit operation, > the current implementation of the commit operation will be blown all to Ugh. Ok, how about then just doing something like not allowing a prepend once the committings already started? > Anyway... I'm very much in favor of solving the same problem that you > are... But it requires a rather more complex patch (so that > transaction.commit() could deal with prepends during commit) and first we'd > need to convince Jim that it's the right thing to do. :) (Not only that, > but he might come up with a better way to do it than prepending...) He does tend to do that. I'd very much like a way to fix this - at the moment, the only workaround for me is for SQLSessions to have an entirely different database connection to themselves. > Ironically, I'm not sure your problem actually *needs* this fix to be > solved. You probably need to tie your session object's behavior to an > earlier transaction event (the "_p_jar.commit()" operation rather than > tpc_finish()), and you can then be guaranteed that the SQL connection has > not yet seen a tpc_finish() either. I'm not sure I understand this - are you suggesting hooking it to the database connector's commit? > *My* problem, on the other hand, is that even if I do this, ZODB does not > allow objects to be _p_jar.commit()ed twice; if you modify an object which > has already been _p_jar.commit()ed in the same transaction, you will get an > unresolvable ConflictError (because the ZODB thinks another transaction > modified the object before you). Ugh. Nasty nasty. But hey, isn't the whole point of ZPatterns to expose all the nasty corners of the Zope innards to light? > Thus, I need to ensure that DataManagers > which are saving things up 'till a _p_jar.commit() operation, get > registered ahead of any modification to an object that they might need to > modify again later. So a fully functional "prepend" capability would be of > great benefit to ZPatterns, but I'm not sure that your problem actually > needs it, and your patch, unfortunately, does not achieve it. Thanks for the feedback - time for me to hit the source code again. :) Anthony ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] transaction support for ordering transactions.
As part of making SQLSession transaction-sane, I'd like to be able to specify that something can register itself to be committed or aborted earlier in the list of objects rather than just being put on the end of the list. The reason for this: I want SQLSession to just use a normal DB connection, and have the commits &c to "just work". The new code now only does the SQL statements in SQLSessionObj's _finish() method - unfortunately, by that time, the database's '_finish()' method has sometimes already been called (if there's a different database call before the Session object is created, then the database adaptor will be registered first). I thought about various ways of dealing with this, such as being able to say 'register me _before_ that object', but ended up going simply with a flag to say 'put me on the front of the list, rather than the back.' This way, anything that needs to say 'no, put me before the standard ones' can do so. Thoughts? Alternatives? Anthony Patch against current-cvs follows: --- lib/python/ZODB/Transaction.py 2000/05/30 19:03:27 1.22 +++ lib/python/ZODB/Transaction.py 2000/06/06 04:01:51 @@ -117,6 +117,9 @@ for c in self._connections.values(): c.close() del self._connections +def _prepend(self, object): + self._objects = [object] + self._objects + def sub(self): # Create a manually managed subtransaction for internal use r=self.__class__() @@ -315,9 +318,12 @@ del objects[:] # clear registered if not subtransaction and self._id is not None: free_transaction() -def register(self,object): +def register(self,object,early=0): 'Register the given object for transaction control.' -self._append(object) + if early: + self._prepend(object) + else: + self._append(object) def note(self, text): if self.description: -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
