[Zope-dev] ZODB3 3.1.1 final
We've made the final release of ZODB 3.1.1 available, including ZEO 2.0.2. This release corresponds to the version of ZODB in Zope 2.6.1 which was also recently released. There's not much different from ZODB 3.1.1beta2, except for an updated tool. ZODB is the Zope Object Database, a system for providing transparent persistence for Python objects in a transactional framework. For more information, including links to download, please see: http://www.zope.org/Products/ZODB3.1 See also the ZODB wiki page for all things ZODB: http://www.zope.org/Wikis/ZODB Thanks go to Tim for building and testing the Windows installer for Python 2.1 and 2.2. There is also a distutils source tarball for building on *nix systems. Enjoy, -Barry, Jeremy, and Tim ___ 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] ZODB3 3.1.1b2
We've made another beta release of ZODB 3.1.1 available, including ZEO 2.0.2. This is primarily a bug fix release; see the NEWS.txt file excerpt below for details. Of particular note are the enabling of the BTrees-based index for FileStorage and the disabling of the rare "hosed" state in ZODB. This release corresponds to Zope 2.6.1b2 which was release on Friday 31-Jan-2003. (The releases differ only in some inconsequential Windows test modules.) For more information, including links to download, please see: http://www.zope.org/Products/ZODB3.1 See also the ZODB wiki page for all things ZODB: http://www.zope.org/Wikis/ZODB Enjoy, -Barry & Jeremy What's new in ZODB3 3.1.1 beta 2? = Release date: 03-Feb-2003 The Transaction "hosed" feature is disabled in this release. If a transaction fails during the tpc_finish() it is not possible, in general, to know whether the storage is in a consistent state. For example, a ZEO server may commit the data and then fail before sending confirmation of the commit to the client. If multiple storages are involved in a transaction, the problem is exacerbated: One storage may commit the data while another fails to commit. In previous versions of ZODB, the database would set a global "hosed" flag that prevented any other transaction from committing until an administrator could check the status of the various failed storages and ensure that the database is in a consistent state. This approach favors data consistency over availability. The new approach is to log a panic but continue. In practice, availability seems to be more important than consistency. The failure mode is exceedingly rare in either case. The BTrees-based fsIndex for FileStorage is enabled. This version of the index is faster to load and store via pickle and uses less memory to store keys. We had intended to enable this feature in an earlier release, but failed to actually do it; thus, it's getting enabled as a bug fix now. Two rare bugs were fixed in BTrees conflict resolution. The most probable symptom of the bug would have been a segfault. The bugs were found via synthetic stress tests rather than bug reports. A value-based consistency checker for BTrees was added. See the module BTrees.check for the checker and other utilities for working with BTrees. A new script called repozo.py was added. This script, originally written by Anthony Baxter, provides an incremental backup scheme for FileStorage based storages. zeopack.py has been fixed to use a read-only connection. Various small autopack-related race conditions have been fixed in the Berkeley storage implementations. There have been some table changes to the Berkeley storages so any storage you created in 3.1.1b1 may not work. Part of these changes was to add a storage version number to the schema so these types of incompatible changes can be avoided in the future. Removed the chance of bogus warnings in the FileStorage iterator. ZEO --- The ZEO version number was bumped to 2.0.2 on account of the following minor feature additions. The performance of full cache verification has improved dramatically. XXX Get measurements from Jim -- somewhere in 2x-5x recall. The implementation was fixed to use the very-fast getSerial() method on the storage instead of the comparatively slow load(). The ZEO server has an optional timeout feature that will abort a connection that does not commit within a certain amount of time. The timeout works by closing the socket the client is using, causing both client and server to abort the transaction and continue. This is a drastic step, but can be useful to prevent a hung client or other bug from blocking a server indefinitely. If a client was disconnected during a transaction, the tpc_abort() call did not properly reset the internal state about the transaction. The bug caused the next transaction to fail in its tpc_finish(). Also, any ClientDisconnected exceptions raised during tpc_abort() are ignored. ZEO logging has been improved by adding more logging for important events, and changing the logging level for existing messages to a more appropriate level (usually lower). ___ 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: [Zope-Coders] FYI: Zope 2.6.1 b2 scheduled for friday
> "BL" == Brian Lloyd <[EMAIL PROTECTED]> writes: BL> We're planning to cut 2.6.1 b2 this Friday. I wanted to give BL> the heads-up in case anyone was in the middle of anything that BL> needs to get in (I saw Toby had committed some things, and it BL> looks like that merge is complete). I intend to merge the ZODB 3.1.1 branch into the Zope 2.6.1 branch. I'll do that asap. I'm not sure how much work that is. -Barry ___ 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-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
> "CM" == Chris McDonough <[EMAIL PROTECTED]> writes: >> * configure; make; make install installation >> I thought that there was an effort to use distutils, or to at >> least use a distutils-ish setup. What happened to that? CM> It does use distutils, owing to the work of Matt Behrens and CM> Shane on the setup.py file. The configure; make stuff just CM> wraps distutils to a large degree. And "configure; make; make install" is a worth goal. From a sysadmin's point of view, they're already conditioned to doing this to install open source software, so under the Pinball Machine Principle, when they see one in Zope, they'll run that first before reading (the whole) README file. Low barrier of entry is a good thing! -Barry ___ 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: [ZODB-Dev] Re: [Zope-dev] DB.close() needs to be called
> "TD" == Toby Dickenson <[EMAIL PROTECTED]> writes: >> What would happen if the thread got killed in the middle of the >> move? TD> A more interesting question is what happens if the thread is TD> killed when it has moved some, but not all, of the files which TD> relate to one transaction. That's more what I was thinking about. TD> In DirectoryStorage terminology this leaves the data directory TD> in a state which "is not a snapshot". The only disadvantage is TD> that you can not use the tools which assume the data directory TD> is a snapshot: the checking tool, the incremental back tool, TD> and the replication tool. Interesting. Berkeley storage has something similar. Let's say the storage crashes in the middle of tpc_vote() or tpc_finish(). First, BerkeleyDB's recovery should clean up any of its corrupt transactions. Then the storage has its own recovery process for the "current" transaction, i.e. the one we were in the middle of at the time of the crash. Depending on when the crash occurred, the storages will either commit or abort the current transaction (if the crash happened in tpc_finish(), we'll complete the commit, otherwise we abort the transaction). So I believe -- although this isn't battle tested -- that the Berkeley storages should be pretty safe against inconsistency and corruption. >> We could make the autopack thread a daemon process >> TD> Thats how DirectoryStorage now works. Hmm, maybe we make >> it a daemon thread and put a timeout on the join, so we'll try >> to exit cleanly and won't hang if we can't. TD> Because some of the operations performed in the daemon thread TD> take a long time to complete? Potentially yes, although the steps in the pack process are BerkeleyDB transactionally protected. I think the mark-and-sweep phases are examples of things that could take a long time. It should be possible to craft some escape hatches to do a more controlled shutdown. TD> Would it be possible to break those operations into TD> transactionally-coherent chunks which complete in a reasonable TD> time? close() could wait for the current chunk to finish. Yep. >> Autopacking should be safe transactionally, but we'd have to do >> a recovery if it got killed uncleanly. TD> Doesnt having a good checkpointing strategy mean that this TD> should never take long? I think checkpointing itself is a trade-off between the length of time it takes to checkpoint and the length of time it could potentially take to recover. >> TD> Last time I looked at your BerkeleyDB storages, the TD> >> administrator needed to implement his own checkpointing TD> >> policy. I always thought that was a disadvantage. Would it now >> TD> be a good idea for the storages to trigger their own TD> >> checkpointing inside the autopacker thread? >> Actually, now you can configure the storages to automatically >> checkpoint every nth ZODB transaction. Checkpointing in a >> thread may or may not provide additional benefit. TD> Interesting. BerkeleyStorage's automatic checkpointing is TD> currently triggered inside a commit or abort. This means the TD> checkpoint overhead is incurred at the one time you dont want TD> it - while a user is waiting for his transaction to TD> commit. DirectoryStorage's main use for the thread is to TD> perform its equivalent asynchronously. Assuming your storage TD> is not saturated with writes (which only happens in benchmarks TD> ;-) then checkpointing happens for free. That's a very interesting idea! Hmm, checkpoint in a thread. Yeah, that sounds much better, although I'm mildly concerned with concurrancy issues, especially given that we don't use the BerkeleyDB locking subsystem. I'll have to read up on the docs, but it's a good idea. -Barry ___ 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] DB.close() needs to be called
> "TD" == Toby Dickenson <[EMAIL PROTECTED]> writes: >> worse" part. If you've enable autopacking and you don't >> cleanly close the storage, you won't exit the process because >> the autopack thread won't get stopped and joined. TD> Yes, I had the same problem with DirectoryStorage, which uses TD> a seperate thread to move writes from its journal directory TD> into the database directory. Ah. Is this transactional? What would happen if the thread got killed in the middle of the move? >> We could make the >> autopack thread a daemon process TD> Thats how DirectoryStorage now works. Hmm, maybe we make it a daemon thread and put a timeout on the join, so we'll try to exit cleanly and won't hang if we can't. Autopacking should be safe transactionally, but we'd have to do a recovery if it got killed uncleanly. >> It wouldn't be good, but remember that we run BerkeleyDB in >> auto-recovery mode, so it means that the next time you open the >> database, it will run recovery (you can also run recovery >> manually). However, depending on your checkpointing policy, >> and the size of committed data since your last checkpoint, >> recovery could end up taking a long time. TD> Last time I looked at your BerkeleyDB storages, the TD> administrator needed to implement his own checkpointing TD> policy. I always thought that was a disadvantage. Would it now TD> be a good idea for the storages to trigger their own TD> checkpointing inside the autopacker thread? Actually, now you can configure the storages to automatically checkpoint every nth ZODB transaction. Checkpointing in a thread may or may not provide additional benefit. >> Sure, any number of bad things can happen at any time, and >> defense against that is one of the benefits of using BerkeleyDB >> underneath. But under normal operations, we definitely want to >> exit cleanly. TD> Agreed, on both points. Cool. -Barry ___ 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] DB.close() needs to be called
> "TD" == Toby Dickenson <[EMAIL PROTECTED]> writes: >> This is a bad thing for the Berkeley storages because their >> .close() must get called or you'll end up with corrupt >> databases or worse . TD> How much of that paragraph is covered by the wink? The "or worse" part. If you've enable autopacking and you don't cleanly close the storage, you won't exit the process because the autopack thread won't get stopped and joined. We could make the autopack thread a daemon process, but it makes me nervous to do that in the general case, because if you exit while autopack is running, you could corrupt your database. Hmm, I guess we could make it a daemon process and yet still cleanly stop it on a close()... TD> Even before my recent changes, there are plenty of other ways TD> that Zope can open the storage, run a transaction, then hit an TD> error before properly starting up which means it fails to TD> close the database correctly. TD> Would this be bad? It wouldn't be good, but remember that we run BerkeleyDB in auto-recovery mode, so it means that the next time you open the database, it will run recovery (you can also run recovery manually). However, depending on your checkpointing policy, and the size of committed data since your last checkpoint, recovery could end up taking a long time. Sure, any number of bad things can happen at any time, and defense against that is one of the benefits of using BerkeleyDB underneath. But under normal operations, we definitely want to exit cleanly. >> So here's a patch to z2.py to fix this. I won't check this in >> because it looks a little ugly to me and I'm not sure what the >> right fix is, TD> That is exactly what I was planning to commit. Cool. :) TD> Before making that change, I need to remove a couple other TD> calls to db.close() to prevent it being called twice on the TD> same db. Ok. >> but we definitely need to fix this before Zope 2.6.1 is >> released. TD> 2.6.1? This change has only been on the trunk, not the 2.6 TD> maintenance branch. You're right. I was running from the trunk. Thanks, -Barry ___ 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] DB.close() needs to be called
Looks like Toby's recent change to ApplicationManager.py causes
DB.close() to never be called when you hit Shutdown in the Control
Panel. This is a bad thing for the Berkeley storages because their
.close() must get called or you'll end up with corrupt databases or
worse .
revision 1.83
date: 2002/11/12 17:19:13; author: htrd; state: Exp; lines: +2 -2
dont close the storages mid-transaction. need to check whether we need to close them
at the end of z2.py
"Um, yeah!" would be my answer. :)
So here's a patch to z2.py to fix this. I won't check this in because
it looks a little ugly to me and I'm not sure what the right fix is,
but we definitely need to fix this before Zope 2.6.1 is released.
-Barry
Index: z2.py
===
RCS file: /cvs-repository/Zope/z2.py,v
retrieving revision 1.88
diff -u -r1.88 z2.py
--- z2.py 4 Nov 2002 13:33:46 - 1.88
+++ z2.py 12 Nov 2002 19:15:51 -
@@ -909,5 +909,7 @@
import Lifetime
Lifetime.loop()
code = sys.ZServerExitCode
+import Zope
+Zope.DB.close()
zLOG.LOG("z2", zLOG.INFO, 'Exiting with code %d' % code )
sys.exit(code)
___
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: [ZODB-Dev] ZODB 3.2 release plan posted
> "TD" == Toby Dickenson <[EMAIL PROTECTED]> writes: >> I have posted a tenative release plan for ZODB 3.2 in the ZODB >> Wiki at http://www.zope.org/Wikis/ZODB/ZODB%203.2%20Release >> There are a small set of proposed features centering around >> better configuration and management of ZEO and ZODB. TD> Is 3.2 work happing on the trunk or a branch? Trunk. -Barry ___ 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] Non Bloating Page Counter
> "kt" == kapil thangavelu <[EMAIL PROTECTED]> writes: >> e.g. BerkeleyStorage or OracleStorage. kt> is there a useable undoable storage? I think you meant "useable non-undoable storage", right? If so, then I believe that ZODB 3.2 will have a such a useable storage. We've had some recent discussions with Sleepycat about some of the worst problems with the BerkeleyDB storages, and I think we now have some good strategies for greatly improving their utility. In the ZODB cvs tree there are now two completely rewritten implementations of the Full and Minimal storages. Full storage, as its name implies supports undo and versions. It reference counts objects and does mark-and-sweep garbage collection, but you need to pack in order to get rid of old object revisions or unreferenced objects. An interesting byproduct of the rewrite is that Full now supports something called "autopacking" -- essentially a background thread that can be configured to pack the database, say as of 4 hours ago, once per hour (these parameters are of course configurable). Autopacking usually only eliminates old object revisions (with reference counting), but it can be configured to occasionally do a "classic pack", which would also do a mark-and-sweep of the entire object space to get rid of unreferenced cycles. For example, you could tell autopack to do one of those once per day. Minimal storage does not support undo or versions because it keeps only the most current object revision. The current implementation of Minimal isn't quite complete because while it performs reference counting garbage collection, it doesn't yet do mark-and-sweep to collect unreferenced object cycles. I'll be adding this probably next week, with pack and autopack interfaces. One downside to the rewrite is that the table schemas aren't compatible with the older versions of these storages, so if you have data in an existing Berkeley storage, you'll need to use something like copyTransactionsFrom() to move them to the new storages. I plan on making a beta release of the new storages sometime early next week. They will be included in the ZODB 3.2 release, which will like get alpha'd soon, with hopefully a final release by the end of the year. If you want to take an early look, check out the ZODB3 cvs tree. What's there passes all the tests. Cheers, -Barry ___ 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] Fix broken python on Mac OS X version 10.2
> "JV" == Jens Vagelpohl <[EMAIL PROTECTED]> writes: JV> sorry for the crossposting, here's a little heads-up for the JV> mac OS X crowd: JV> upon upgrading to 10.2 (jaguar) you will most likely find that JV> your python binary (along with most other self-compiled JV> software) is broken. I think the basic cause of this is that 10.2 upgraded gcc, and that's what breaks self-compiled binaries. -Barry ___ 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] Confusing segfault for Zope2 head on RH7.3
> "DM" == Dieter Maurer <[EMAIL PROTECTED]> writes: DM> This looks like a compiler error, maybe an error in the DM> dynamic linking code. Matt Kromer spent some more time on this today and indeed he suspected ld.so (specifically /lib/ld-2.2.5.so). This makes perfect sense and Matt's analysis matches observed behavior. Matt's contacted the glibc maintainer at Redhat with details. Matt, maybe you'd like to post that message here for completeness? -Barry ___ 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] Confusing segfault for Zope2 head on RH7.3
> "MTK" == Matthew T Kromer <[EMAIL PROTECTED]> writes: MTK> On *my* RedHat 7.3 system, I cannot reproduce your problem. MTK> However, you do note that exception 0x6e727574 is ASCII for MTK> 'nrut' or 'turn' backwards. I dont know if that's meaningful MTK> or not. I usally watch out for ASCII in things that should MTK> otherwise be addresses. Ah, backwards masking C heaps! If you look at the whole thing, it says: 'natas fo rial eht retne ton ot dna dnuora nrut' Actually the tale gets weirder. With a Python 2.2.1 --with-pydebug build there is no crash at all. With a Python 2.1.3 built w/ gcc 3.1 and -g and -O2 I get no crash but this exception: Traceback (most recent call last): File "crash.py", line 8, in ? list(x) SystemError: error return without exception set With a Python 2.1.3 built w/gcc 3.1 and just -g (no -O2) I get some weird worst-of-both-worlds: Traceback (most recent call last): File "crash.py", line 8, in ? list(x) Segmentation fault (core dumped) So I'm totally confuzzled and am sick of wasting time on this, so I think I'll just trust Python 2.2.1. ;) -Barry ___ 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] Confusing segfault for Zope2 head on RH7.3
Working on the Zope 2.7 branch I noticed a very strange crash while
running the test suite. I re-checked out the Zope 2 cvs head, rebuilt
everything from scratch and I still get the crash. I'm about out of
ideas so I thought I'd post what I know here in case anyone else can
confirm or give clues.
First off, I'm using a fresh checkout of the Zope 2 cvs head with a
virgin Python 2.1.3 (although a cvs head of the Python 2.1 maintenance
branch has the same problem). I've rebuilt Python 2.1.3 with only the
-g option (no -O, although it makes no difference), and I've rebuilt
Zope using this command:
% python2.1 setup.py build_ext -i
which also builds with just the -g option, although that also makes no
difference. Note that I've also built using "python2.1 wo_pcgi.py"
and that also makes no difference.
I then run the test suite like so:
% PYTHONPATH=lib/python python2.1 utilities/testrunner -a
and I reliably get a crash in ISO_8859_1_Splitter.c I've boiled it
down to the following simplified test case:
snip snip crash.py
from Products.PluginIndexes.TextIndex.Splitter.ISO_8859_1_Splitter.ISO_8859_1_Splitter
import ISO_8859_1_Splitter
x = ISO_8859_1_Splitter('hello world')
list(x)
snip snip
run it like so:
% PYTHONPATH=lib/python python2.1 crash.py
The top of the backtrace is:
#0 PyErr_SetString (exception=0x6e727574,
string=0x402660dc "Splitter index out of range") at Python/errors.c:69
#1 0x402658af in ISO_Splitter_item (self=0x843ed98, i=2)
at
Products/PluginIndexes/TextIndex/Splitter/ISO_8859_1_Splitter/src/ISO_8859_1_Splitter.c:357
#2 0x0808b98d in PySequence_List (v=0x843ed98) at Objects/abstract.c:1258
#3 0x080b934f in builtin_list (self=0x0, args=0x810137c)
at Python/bltinmodule.c:1357
...
(I hacked the C code to rename Splitter_item() in
ISO_8859_1_Splitter.c to ISO_Splitter_item() for ease of setting the
break point.)
Here's the deal. Splitter_item() cruises along as expected until it
hits the end of the text. word is Py_None and it drops into the
clause that sets the IndexError exception. AFAICT, there are no
reference counting bugs in the code. At the PyErr_SetString() call
PyExc_IndexError is a perfectly valid PyObject*, but just one stack
frame later, inside the PyErr_SetString, the exception object is a
completely bogus address. PyErr_SetString() is not getting the same
object that Splitter_item() is providing in the first argument. Note
that the second argument, a char* is just fine.
Stepping through the code with gdb gives no help. I can set break
points and inspect all the objects created and decref'd and everything
appears okay. Printing PyExc_IndexError right before the call shows
nothing strange, but stepping into PyErr_SetString() shows the first
arg is corrupted. I don't get it. I've show the other PLabbers and
it perplexes them too. :)
To make matters weirder, we've tested this on various Linux flavors
and versions. On RH6.1 and MD8.{0,1} it works just fine -- no crash.
The /only/ system that I've seen the crash is RedHat 7.3, and there it
crashes on both of my up-to-date RH7.3 systems, every time, and
reliably.
I think I've eliminated gcc as a culprit because most of our Linux
boxes are using the same gcc version, according to gcc -v:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110)
i.e 2.96 2731.
The /only/ difference that I can tell is the glibc version. My RH7.3
systems have glibc 2.2.5 and on all the other systems glibc's are
older; no system with glibc 2.2.4 or earlier exhibits the crash.
I have not tested gcc 3.1 and I have not tried other glibc's on
RH7.3. I'd really like to know if anybody else on RH7.3 either sees
the same crash or doesn't. And if so what version of gcc and
glibc you've got. I'm starting to suspect a glibc bug, but it's dang
strange.
-Barry
___
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-CMF] i18n for CMF And Plone, backporting i18n to Zope 2.x
> "SdS" == Sidnei da Silva <[EMAIL PROTECTED]> writes: SdS> Well, i didnt told there was i18n support there ;) Oh! :) SdS> Basically, Alt-TAL is a rewrite of TAL to allow one to expand SdS> TAL by providing plugins. This means that if you want to SdS> provide i18n for Alt-TAL you just need to write an i18n SdS> plugin and register it as a handler for i18n:something. The SdS> the current TAL implementation is very obscure, and Shane SdS> agrees with us that it could be highly improved with no much SdS> effort. SdS> At a first glance, you can see that this implementation is SdS> much clear, and pluggable, and the current TAL needs too much SdS> hacking to extend support for new tags, and has too much SdS> dependencies on Zope right now, as someone pointed out. I don't know about the "not much effort" part, but in theory, this is something I'd support. We talked about doing this for the Zope3 i18n effort, but the primary reason we didn't was due to performance concerns. After talking with Fred, I came to understand that much of the code's current obscurity is due to optimizations to make TAL perform at least as fast as DTML. So while I'd love to have the code be cleaner and more pluggable, we have to decide 1) if we're willing to give up some performance to acheive this, and 2) if not, can you provide a design and implementation that will "perform adequately"? -Barry ___ 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-CMF] i18n for CMF And Plone, backporting i18n to Zope 2.x
> "SdS" == Sidnei da Silva <[EMAIL PROTECTED]> writes: SdS> My friend Lalo ([EMAIL PROTECTED]) started a rewrite of TAL to SdS> make it more pluggable and ease backporting of i18n to SdS> Zope2. I dont know how much if it is done right now, but the SdS> last time I talked to him, he said that only METAL was SdS> missing. SdS> His work is available at http://sf.net/projects/collective -> SdS> Browse CVS -> Alt-TAL module. SdS> I think that the best idea is support him, as he has almost SdS> everything in place. A quick scan didn't show much i18n support there, but perhaps I'm missing it. FTR, Stephan demoed the Zope3 i18n stuff at EuroPython and we're planning on backporting it to Zope2, but for the Zope 2.7 release. -Barry ___ 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: [Zope3-dev] Are there Graphic Designers?
> "JV" == Jens Vagelpohl <[EMAIL PROTECTED]> writes: JV> as a data point, here is browser data for one of the sites i JV> own. the data is produced by webalizer. NS4 is becoming JV> negligible:: > "PE" == Paul Everitt <[EMAIL PROTECTED]> writes: PE> However, it is important to note: Zope 3 is *not* a product. PE> It is used to build products. The core ZMI is needed to the PE> extent that it helps build or administer products. Thus, Zope PE> 3 is not like YABB. So the question is, who make up the audience for the ZMI and what are the browsers that /they/ use? The general populace isn't going to be developing apps for Zope, it's the site admins, and I'd venture to say that the distribution numbers are quite different for that group of people. > "JV" == Jens Vagelpohl <[EMAIL PROTECTED]> writes: JV> mac OS X browsers: | - IE 5.1 | - mozilla 0.99 (=>1.0) We (my wife and I :) are primarily a NS4 shop on MacOS9, and MacOSX comes with IE5, but we don't use it if we can help it. There it's Moz 0.9.9 which works great. -Barry ___ 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: [Zope3-dev] Are there Graphic Designers?
> "WT" == William Trenker <[EMAIL PROTECTED]> writes: WT> Current CSS standards even provide some of the dynamic WT> formatting, like text rollovers, that used to require WT> Javascript . When Fred showed me this, I freaked, it was so cool. But then I use Mozilla, so I don't know that you can rely on widespread support. :) -Barry ___ 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] RELEASED - StandaloneZODB 1.0 final
I'm please to announce the release of StandaloneZODB, the Python object persistency system also known as the Z Object Database. ZODB is the object-oriented database underlying Zope; the StandaloneZODB project's goal is to provide those same facilities to non-Zope related Python applications. Today we are releasing StandaloneZODB 1.0 final. A brief description of the changes since release candidate 1 is outlined below. StandaloneZODB is based on the same code as the ZODB in Zope, albeit on a separate release branch. Its inspiration comes from Andrew Kuchling's StandaloneZODB project on SourceForge. While there are still some differences, the Standalone 1.0 release is the first on the path toward convergence. Subsequent releases should complete the merge of Andrew's and Zope Corporation's packages. The StandaloneZODB release includes the following components: - Core ZODB, including the persistence machinery - Standard storages such as FileStorage - Supporting modules such as ExtensionClass - The persistent BTrees modules - ZEO - Experimental Berkeley storages - Some documentation See the README file for details on building and installing StandaloneZODB. For details on using ZODB, see Andrew's included user guide. StandaloneZODB 1.0 is released under the ZPL 2.0. It should be compatible with all Python versions from Python 2.1 to Python 2.2. It may or may not work with versions earlier than Python 2.1. Download StandaloneZODB-1.0 from: http://www.zope.org/Products/StandaloneZODB and visit the StandaloneZODB Wiki page at: http://www.zope.org/Wikis/ZODB/StandaloneZODB See also: http://www.zope.org/Wikis/ZODB/FrontPage for more information about our long-range ZODB plans. Enjoy, -Barry Barry A. Warsaw Zope Corporation, Pythonlabs [EMAIL PROTECTED] snip snip What's new in StandaloneZODB 1.0 final? Release date: 08-Feb-2002 === All copyright notices have been updated to reflect the fact that the ZPL 2.0 covers this release. Added a cleanroom PersistentList.py implementation, which multiply inherits from UserDict and Persistent. Some improvements in setup.py and test.py for sites that don't have the Berkeley libraries installed. A new program, zeoup.py was added which simply verifies that a ZEO server is reachable. Also, a new program zeopack.py was added which connects to a ZEO server and packs it. ___ 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] Confused: Does PersistentList exist?
> "LR" == Lennart Regebro <[EMAIL PROTECTED]> writes: LR> I found seceral seemingly up to date docuemnts claiming that LR> both PersistentMapping and PersistentList exists and is LR> included with Zope. However, I couldn't find PersistentList, LR> so I thought that it had been added after 2.3.3, which I am LR> using. So I checked the CVS. Nope, nothing there. LR> So whats the deal here, really? PersistentList is part of Andrew Kuchling's StandaloneZODB offering. It hasn't yet been integrated into ZC's offering, and won't for our StandaloneZODB 1.0 release. We have plans to continue to merge Andrew's version and ours, so it's likely that PersistentList will show up in a future version as released from ZC. -Barry ___ 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] RELEASED - StandaloneZODB 1.0 release candidate 1
I'm please to announce the first official release of StandaloneZODB, the Python object persistency system also known as the Z Object Database. ZODB is the object-oriented database underlying Zope; the StandaloneZODB project's goal is to provide those same facilities to non-Zope related Python applications. Today we are releasing StandaloneZODB 1.0 release candidate 1. We expect to release the final version on 1-Feb-2002. StandaloneZODB is based on the same code as the ZODB in Zope, albeit on a separate release branch. Its inspiration comes from Andrew Kuchling's StandaloneZODB project on SourceForge. While there are still some differences, the Standalone 1.0 release is the first on the path toward convergence. Subsequent releases should complete the merge of Andrew's and Zope Corporation's packages. The StandaloneZODB release includes the following components: - Core ZODB, including the persistence machinery - Standard storages such as FileStorage - Supporting modules such as ExtensionClass - The persistent BTrees modules - ZEO - Experimental Berkeley storages - Some documentation See the README file for details on building and installing StandaloneZODB. For details on using ZODB, see Andrew's included user guide. StandaloneZODB 1.0c1 is released under the ZPL 2.0. It should be compatible with all Python versions from Python 2.1 to Python 2.2. It may or may not work with versions earlier than Python 2.1. Download StandaloneZODB-1.0c1.tgz from: http://www.zope.org/Products/StandaloneZODB and visit the StandaloneZODB Wiki page at: http://www.zope.org/Wikis/ZODB/StandaloneZODB See also: http://www.zope.org/Wikis/ZODB/FrontPage for more information about our long-range ZODB plans. Enjoy, -Barry Barry A. Warsaw Zope Corporation, Pythonlabs [EMAIL PROTECTED] ___ 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] Searching/Indexing/ZODB/SQL/BerkleyDB
> "CW" == Chris Withers <[EMAIL PROTECTED]> writes: >> How much slower was is? Did you measure ratios (between the two >> storages) of time per indexing operation, or ratios of disk >> blocks transferred per indexing operation? CW> In my tests, Barry agreed with me that Berkley was turning out CW> between one and two _orders or magnitude_ slower than CW> FileStorage :-( Actually, let me clarify this! I just pointed out that your numbers showed you were seeing a two orders of magnitude difference. However, in my own testing, on my own data, I've been able to reduce the performance difference to about a factor of 4.5 -- much better than the factor of 100 your numbers showed for you data! I would not make the blanket assertion that Berkeley storage is 100 times slower than FileStorage. Let me just reiterate: it's vitally important to tune your Berkeley storage for your system and application, especially with regards to cachesize. E.g. Getting the cachesize wrong can definitely destroy your performance, maybe producing numbers as bad as you're seeing. I won't claim that Berkeley DB is easy to tune, though. -Barry ___ 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: ZPL and GPL
> "FWH" == Fred Wilson Horch <[EMAIL PROTECTED]> writes: FWH> But it would be nice to hear what Guido thinks, and what FWH> Digital Creation thinks. I won't speak on behalf of DC, but I'll bet Guido is pretty tired of talking about it. :) FWH> Knowing that the copyright holders have made a conscious FWH> decision not to allow developers to obtain Python and Zope FWH> under the terms of the GPL in the belief that this allows FWH> people to do "whatever they want" with it does help us FWH> evaluate the long-term prospects for these systems in the FWH> marketplace. I'm not sure what point you're making. With respect to Python, the issue has been hashed to death over in c.l.py and other forums, so I think this will be my last post on the subject here. IMO, the Python 2.0.1 license is the best of all possible worlds. In the words of the FSF themselves: The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Dual licensing (a la Perl) has practical problems, which have been raised in other forums, and you really want to avoid it if possible. Python 2.0.1's license allows Python to be linked with GPL'd software such as GNU readline. I don't see what advantages "allowing developers to obtain Python [...] under the terms of the GPL" would provide above and beyond that. Guido (and now, really the PSF) is clearly not concerned about freeloaders taking of Python and not contributing back, which is about the only additional thing a GPL release of Python could prevent. Any Python module or extension you write can now be legally released under the GPL and linked with Python. So if you feel that the GPL affords your code useful benefits and protections, you now have that option, whereas under Python 1.6, 2.0, or 2.1 you didn't. -Barry ___ 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
> "JA" == Jerome Alet <[EMAIL PROTECTED]> writes: JA> For Zope it's not sure, but for Python, as well as for all JA> what people usually call "open source" languages, the license JA> of choice should be the GPL, or at least the LGPL, in order JA> for the language in question to not become bastardized by some JA> powerful entity. I think I'm accurately channeling Guido when I say that Python will never be GPL'd. AFAIK, there is no GPL code even in the standard Python distribution. Both of those states of affair are by conscious decision: regardless of what you think of the GPL (and I personally happen to believe it can be a good license for /some/ software, but not all) GPL'ing Python would be a very bad thing. Guido has always intended for people to do whatever they want with Python, including using it in everything from closed source, proprietary, big-$$$ software to completely free software. That's been a key to Python's success, IMO. I don't think anybody's really concerned that forking and bastardizing is a real threat. Heck, if you include Jython/JPython, .NET Python, Vyper, and Stackless there are already forks of Python out in the world getting real use. (C)Python's success hasn't suffered one bit, in fact, it's probably /benefitted/ from them. Cheers, -Barry ___ 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: Zcatalog bloat problem (berkeleydb is a solution?)
> "GM" == Giovanni Maruzzelli <[EMAIL PROTECTED]> writes: GM> We are almost decided to switch to berkeleydb storage (the GM> Minimal one) to get rid of the bloating, we are testing with GM> it, but it seems to be discontinued because of a lack of GM> requests. GM> Any light on it? Is it production grade? There are currently two versions of non-undo, non-versioning Berkeley based storages. One is called Packless.py and one is called Minimal.py. Packless was written first, and is truly packless; it uses reference counting to get rid of unused objects. Minimal isn't quite packless yet, since the reference counting hasn't been added. OTOH, Minimal shares much as much implementation as possible with Full, so it shares e.g. the more robust backing commit log file stuff. A goal, although not likely for 1.0 is to merge the best features of Minimal and Packless into a single storage. I don't think it's a lot of work to do this, but Jim hasn't pressed this has as having a very high priority. -Barry ___ 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] ANNOUNCE Berkeley storage 1.0 beta 2 for Zope/ZODB
Hello Zope and ZODB users! The folks at Digital Creations, PythonLabs bring to you the second beta release of a Berkeley DB based storage for ZODB. Information about the Berkeley storage, can be found on the Berkeley storage Wiki at http://www.zope.org/Wikis/ZODB/BerkeleyStorage and other ZODB developments can be found on the ZODB Wiki page: http://www.zope.org/Wikis/ZODB/FrontPage This release of the Berkeley storage package contains the Packless.py implementation from 1.0beta1 which provides a non-versioning, non-undoable storage that uses reference counting to eliminate the need for explicit packs (except in the face of object cycles). The 1.0beta2 release adds two new storages: Full.py which is a complete versioning and undoable storage, and Minimal.py which is a rewritten non-versioning, non-undoable storage that will eventually replace Packless.py. Also included is an extensive PyUnit-based test suite. You must install Sleepycat's Berkeley DB 3.2.9 and Robin Dunn's PyBSDDB wrapper package. Berkeley storage 1.0beta2 has been tested with Python 2.0 and 2.1; it may work with Python 1.5.2 but no decision yet has been made whether that will be officially supported. Berkeley storage 1.0beta2 can be installed as a Python distutils package, and works well with StandaloneZODB distribution: http://www.zope.org/Wikis/ZODB/StandaloneZODB It, of course, can also be used with Zope, however please read the release notes concerning undo with the Full.py storage (there's a new non-destructive undo mechanism called Transactional Undo, which is not compatible with Zope 2.3.1 -- Full.py should work with Zope 2.3.1 but you will not be able to undo). Future development will include the integration of cyclic garbage detection with Full.py, and the addition of reference counting and cyclic gc to Minimal.py. See the ZODB Wiki for other developments. The release is available here: http://www.zope.org/Products/bsddb3Storage Discussions should take place on the [EMAIL PROTECTED] mailing list. Enjoy, -Barry Barry A. Warsaw PythonLabs at Digital Creations [EMAIL PROTECTED] ___ 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] 2gb ZODB size limit
> "MWP" == Morten W Petersen <[EMAIL PROTECTED]> writes: MWP> BTW, there is a list called [EMAIL PROTECTED], for ZODB MWP> specific questions. Make that [EMAIL PROTECTED] now! -Barry ___ 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] Berkeley Storage proposal
A draft of my Berkeley storage proposal is now in the fishbowl: http://dev.zope.org/Wikis/DevSite/Proposals/BerkeleyStorage Feel free to add your comments to the wiki. -Barry ___ 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
> "TJ" == Tom Jenkins <[EMAIL PROTECTED]> writes: TJ> I agree. I think this would be a good project for new zope TJ> developers to get into the zope code. Would we need an TJ> ZopeException class hierarchy? IME, it's been a good idea to have a root exception class per subsystem, which all inherit from a single system-wide root, which itself inherits from Exception. That was the motivation for Python's standard exception heirarchy. Greedy excepts have their uses, but IMHO they are limited to `infrastructure wrappers' only. E.g. a CGI wrapper might catch all exceptions so they don't percolate up to the web server, or a command line reader would catch them all so they don't exit the read loop. -Barry ___ 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 )
