Re: [Zope-dev] import of zexp containing Page Template objects causes sudden zope death
Tres Seaver wrote: Now, how in gdb do I find out what it was that was trying to be imported? (should any sort of import cause a core dump?!) http://wiki.python.org/moin/DebuggingWithGdb Things you learn, thanks for that :-) Okay, another interesting data point; this appears to be related to OS. The originating server is a 32-bit (I think, how can I double check?) linux box, the crashing machine is my 64-bit (but I'm pretty sure python is 32-bit, how can I check?) MacBook Pro. I tried importing the .zexp back onto the originating server; no crashes. I tried importing the .zexp onto my linux dev both; no crashes. This ring any bells for anyone? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 30 OK, 9 Failed, 4 Unknown
Summary of messages to the zope-tests list. Period Fri Aug 27 12:00:00 2010 UTC to Sat Aug 28 12:00:00 2010 UTC. There were 43 messages: 6 from Zope Tests, 2 from buildbot at enfoldsystems.com, 4 from buildbot at pov.lt, 13 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 10 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : winbot / ztk_dev py_244_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:12:24 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019032.html Subject: FAILED : winbot / ztk_dev py_254_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:14:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019033.html Subject: FAILED : winbot / ztk_dev py_265_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:17:20 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019034.html Subject: FAILED : winbot / ztk_dev py_265_win64 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:20:18 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019035.html Subject: FAILED : winbot / ztk_10 py_244_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:28:24 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019036.html Subject: FAILED : Zope Buildbot / zope2.12 slave-osx From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:55:49 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019047.html Subject: FAILED : Zope Buildbot / zope2 slave-osx From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:58:27 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019050.html Subject: FAILED : winbot / ZODB_dev py_270_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 21:30:37 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019058.html Subject: FAILED : winbot / ZODB_dev py_270_win64 From: buildbot at winbot.zope.org Date: Fri Aug 27 22:25:39 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019066.html Unknown --- Subject: UNKNOWN : Zope-trunk Python-2.6.5 : Linux From: Zope Tests Date: Fri Aug 27 21:33:04 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019059.html Subject: UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux From: Zope Tests Date: Fri Aug 27 21:35:04 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019060.html Subject: [zodb-tests] buildbot failure in Enfold Systems on zodb-trunk-python-2.6-maestro From: buildbot at enfoldsystems.com Date: Sat Aug 28 02:01:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019073.html Subject: [zodb-tests] buildbot failure in Enfold Systems on zodb-trunk-python-2.5-maestro From: buildbot at enfoldsystems.com Date: Sat Aug 28 02:03:45 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019074.html Tests passed OK --- Subject: OK : winbot / ztk_10 py_254_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:35:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019037.html Subject: OK : winbot / ztk_10 py_265_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:42:49 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019038.html Subject: OK : winbot / ztk_10 py_265_win64 From: buildbot at winbot.zope.org Date: Fri Aug 27 16:49:53 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019039.html Subject: OK : winbot / ZODB_dev py_254_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 18:44:05 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019040.html Subject: OK : winbot / ZODB_dev py_265_win32 From: buildbot at winbot.zope.org Date: Fri Aug 27 19:39:00 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019041.html Subject: OK : Zope Buildbot / zope2.12 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:44:43 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019042.html Subject: OK : Zope Buildbot / zope2 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:46:24 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019043.html Subject: OK : Zope Buildbot / zope2.12 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:49:18 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019044.html Subject: OK : Zope Buildbot / zope2 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:51:07 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019045.html Subject: OK : Zope Buildbot / ztk slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:51:46 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-August/019046.html Subject: OK : Zope Buildbot / ztk_win slave-win From: jdriessen at thehealthagency.com Date: Fri Aug 27 19:56:11 EDT 2010 URL:
Re: [Zope-dev] SVN: Zope/trunk/buildout.cfg AccessControl has changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Glick wrote: Log message for revision 115948: AccessControl has changes Changed: U Zope/trunk/buildout.cfg -=- Modified: Zope/trunk/buildout.cfg === --- Zope/trunk/buildout.cfg 2010-08-25 17:16:57 UTC (rev 115947) +++ Zope/trunk/buildout.cfg 2010-08-25 17:18:10 UTC (rev 115948) @@ -18,6 +18,7 @@ wsgi sources-dir = develop auto-checkout = +AccessControl This change is breaking the buildout for the buildbots, and for my Linux checkout. We should just release a new version of AccessControl and wire it in anyway. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkx5NWQACgkQ+gerLs4ltQ6B/wCgxksIGREpCqBg35orOFEJPtBo qeIAn3zGuWtfRjt5iFXJIvPmkolehL1Y =/slH -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.keyreference hashes vs. 32/64bit
Hi.
I've recently stumbled on some at least to me unexpected behavior with
zope.keyreference. For a persistent object it generates a unique key
using:
hash((database_name, oid))
where hash is Python's built-in hash function.
Reading the documentation I assumed that a keyreference for the same
object (as identified by database name and oid) should be stable and
always produce the same result. This isn't always true, when you look
up persisted keyreference data, upgrade your software versions and
compare it to a new calculation.
Python's hash function is only stable inside the same Python version
and 32/64 bit combination. The same input in a 32bit Python 2.6 and
64bit Python 2.6 produces different results, as both try to use the
maximum available integer space and thus a 64bit Python generates keys
above the 32int range. As a simple example hash(('main', 1)) 2**32
is True in a 64bit Python and False in a 32bit Python.
The internal hash implementation seems to have been pretty stable in
all the latest Python versions up to 3.1. So the algorithm produces
the same results for all 32bit version of Python 2.x to 3.1 and 64bit
respectively. But as far as I understand this isn't guaranteed to be
the case for future versions.
Does anyone else see a problem with this? Should keyreference use a
different hash algorithm?
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/buildout.cfg AccessControl has changes
On Sat, Aug 28, 2010 at 6:12 PM, Tres Seaver tsea...@palladion.com wrote: Modified: Zope/trunk/buildout.cfg === --- Zope/trunk/buildout.cfg 2010-08-25 17:16:57 UTC (rev 115947) +++ Zope/trunk/buildout.cfg 2010-08-25 17:18:10 UTC (rev 115948) @@ -18,6 +18,7 @@ wsgi sources-dir = develop auto-checkout = + AccessControl This change is breaking the buildout for the buildbots, and for my Linux checkout. We should just release a new version of AccessControl and wire it in anyway. This approach was my idea. I wanted to give more people a chance to review and comment on the new feature in AccessControl, before actually releasing it. But we need to fix the buildbots to be able to deal with this setup to make this actually work. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/buildout.cfg AccessControl has changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: This approach was my idea. I wanted to give more people a chance to review and comment on the new feature in AccessControl, before actually releasing it. But we need to fix the buildbots to be able to deal with this setup to make this actually work. The breakage might be in mr.developer, expecting a svn 1.6-only feature? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkx5RLkACgkQ+gerLs4ltQ6/2gCgvwj/hDXdcsps4l/9TxMa1LQ1 P5sAnRQe8rorkNvpC+Yzjw5BhZpk2dX9 =cz8t -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/buildout.cfg AccessControl has changes
On Sat, Aug 28, 2010 at 7:17 PM, Tres Seaver tsea...@palladion.com wrote: The breakage might be in mr.developer, expecting a svn 1.6-only feature? I think it only requires Subversion 1.5 and not 1.6, which shouldn't be a problem. 1.4 is from the stone-age :) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.keyreference hashes vs. 32/64bit
On Sat, Aug 28, 2010 at 12:17 PM, Hanno Schlichting ha...@hannosch.eu wrote:
Hi.
I've recently stumbled on some at least to me unexpected behavior with
zope.keyreference.
Specifically, zope.keyreference.persistent, I assume.
For a persistent object it generates a unique key
using:
hash((database_name, oid))
No, it generates a hash this way.
where hash is Python's built-in hash function.
Reading the documentation I assumed that a keyreference for the same
object (as identified by database name and oid) should be stable and
always produce the same result. This isn't always true, when you look
up persisted keyreference data, upgrade your software versions and
compare it to a new calculation.
Python's hash function is only stable inside the same Python version
and 32/64 bit combination. The same input in a 32bit Python 2.6 and
64bit Python 2.6 produces different results, as both try to use the
maximum available integer space and thus a 64bit Python generates keys
above the 32int range. As a simple example hash(('main', 1)) 2**32
is True in a 64bit Python and False in a 32bit Python.
The internal hash implementation seems to have been pretty stable in
all the latest Python versions up to 3.1. So the algorithm produces
the same results for all 32bit version of Python 2.x to 3.1 and 64bit
respectively. But as far as I understand this isn't guaranteed to be
the case for future versions.
Does anyone else see a problem with this? Should keyreference use a
different hash algorithm?
Potentially, yes. In current practice, I don't think so.
When a key reference is uses as a BTree key, its comparison function,
rather than it's hash is used.
If a key reference hash was used as a persistent key, then this would
definitely be a problem.
Note that in a dictionary or PersistentMapping, the hash isn't
saved persistently. The object is saves as a collection of items and the
hashes are recomputed on unpickling.
I'm in favor of someone coming up with a stable hash to
avoid future pitfalls.
It's sad that Python's hash isn't stable across Python versions
and architectures. Is this documented? If so, It's a missfeature.
If not, perhaps it should be reported as a bug.
Jim
--
Jim Fulton
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.keyreference hashes vs. 32/64bit
Hi. On Sat, Aug 28, 2010 at 8:47 PM, Jim Fulton j...@zope.com wrote: On Sat, Aug 28, 2010 at 12:17 PM, Hanno Schlichting ha...@hannosch.eu wrote: I've recently stumbled on some at least to me unexpected behavior with zope.keyreference. Specifically, zope.keyreference.persistent, I assume. Yes. Does anyone else see a problem with this? Should keyreference use a different hash algorithm? Potentially, yes. In current practice, I don't think so. When a key reference is uses as a BTree key, its comparison function, rather than it's hash is used. If a key reference hash was used as a persistent key, then this would definitely be a problem. Note that in a dictionary or PersistentMapping, the hash isn't saved persistently. The object is saves as a collection of items and the hashes are recomputed on unpickling. Ah right. This makes it less likely to be a problem in practice. I'm in favor of someone coming up with a stable hash to avoid future pitfalls. It's sad that Python's hash isn't stable across Python versions and architectures. Is this documented? If so, It's a missfeature. If not, perhaps it should be reported as a bug. The official Python documentation doesn't specify anything explicitly, but it also doesn't describe the algoritm or state that it's stable. You do immediately find http://effbot.org/zone/python-hash.htm googling for python hash though. This notes that the algorithm changed in Python 2.4. Looking at the NEWS file of Python, the hash algorithm has again changed in Python 3.2 alpha 1 referencing issue 8188. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.keyreference hashes vs. 32/64bit
On Sat, Aug 28, 2010 at 3:12 PM, Hanno Schlichting ha...@hannosch.eu wrote: Hi. On Sat, Aug 28, 2010 at 8:47 PM, Jim Fulton j...@zope.com wrote: On Sat, Aug 28, 2010 at 12:17 PM, Hanno Schlichting ha...@hannosch.eu wrote: I've recently stumbled on some at least to me unexpected behavior with zope.keyreference. Specifically, zope.keyreference.persistent, I assume. Yes. Does anyone else see a problem with this? Should keyreference use a different hash algorithm? Potentially, yes. In current practice, I don't think so. When a key reference is uses as a BTree key, its comparison function, rather than it's hash is used. If a key reference hash was used as a persistent key, then this would definitely be a problem. Note that in a dictionary or PersistentMapping, the hash isn't saved persistently. The object is saves as a collection of items and the hashes are recomputed on unpickling. Ah right. This makes it less likely to be a problem in practice. I'm in favor of someone coming up with a stable hash to avoid future pitfalls. It's sad that Python's hash isn't stable across Python versions and architectures. Is this documented? If so, It's a missfeature. If not, perhaps it should be reported as a bug. The official Python documentation doesn't specify anything explicitly, but it also doesn't describe the algoritm or state that it's stable. You do immediately find http://effbot.org/zone/python-hash.htm googling for python hash though. This notes that the algorithm changed in Python 2.4. Looking at the NEWS file of Python, the hash algorithm has again changed in Python 3.2 alpha 1 referencing issue 8188. If someone has the energy, I think it's worth trying to report this as a bug. :) Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
