[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Fri Oct 26 12:00:00 2007 UTC to Sat Oct 27 12:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Oct 26 20:51:00 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008551.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Oct 26 20:52:30 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008552.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Oct 26 20:54:01 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008553.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Oct 26 20:55:31 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008554.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Oct 26 20:57:01 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008555.html ___ 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] Possible performance problem in Page Template engine?
--On 27. Oktober 2007 00:33:42 +0200 Christian Scholz [EMAIL PROTECTED] wrote: Hi everybody! When I was trying to fix portlets in Plone I was wondering why the render() method of my portlet actually gets called multiple times. After a bit of investigation I ended up in the Five product in browser/providerexpressions.py where provider expressions also seem to be called twice for each provider statement. The problem seems to be in Products/PageTemplates/Expressions.py in line 199/200 (in Zope 2.10.4): def evaluateStructure(self, expr): customized version in order to get rid of unicode errors for all and ever text = super(ZopeContext, self).evaluateStructure(expr) return self._handleText(text, expr) This construct seems to evaluate expr twice. One time in evaluateStructure() of the super class which is basically a call to self.evaluate(expr) (to be found in zope/tales/tales.py around line 713: def evaluateStructure(self, expr): return self.evaluate(expr) and then again in _handleText(): def _handleText(self, text, expr): text = self.evaluate(expr) ... I now tried to remove the evaluation of expr in handleText() and in a very simple test using ab on my site I got twice the speed! The evaluate() call within _handleText() is a culprit from my refactoring. However I see this code only on the trunk. It is not contained on the 2.10 branch. Anyway...I removed the culprit from the trunk and everything should be fast again. Andreas pgpLjFwlgIaks.pgp Description: PGP signature ___ 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] Re: [Plone-developers] zcml entry points
Martijn Faassen wrote at 2007-10-24 18:38 +0200: ... I disagree with the position that should not ever treat an adapter registration as an implementation detail to provide some default behavior. Sometimes the behavior of a library *relies* on certain adapters being registered. An example is an adapter registration to generate an appropriate error message (if no more specific adapters are registered by the user of the library). But requiring that a more specific adapter must be registered can be a bit tedious -- as it may require to define an additional (and unnatural) interface that derives from the original one -- just to be able to register a more specific adapter... -- Dieter ___ 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 )
[Zope-dev] zc.buildout installing parts not asked for
When using zc.buildout I discovered that it installed a part that I
didn't
specify in the 'parts' option. This happened because I referenced this
part somewhere else. Is this how it's supposed to be? I would prefer
if it
only installs the parts I specify in parts. I don't see anything
wrong with
reusing options from a part that I don't necessarily want to install.
This is a buildout.cfg that will reproduce it. The 'notusedinparts'
part is
installed even if not specified in 'parts'. It's installed because of
the
'dummy' option in the 'tok' section. Is this how it was meant to be?
[buildout]
develop = recipes
parts = tok
[tok]
recipe = recipes:debug
dummy = ${notusedinparts:someoption}
[notusedinparts]
recipe = recipes:debug
someoption = why
/Tim
ps. I tried to send this to the distutils-sig list, but it got stuck
in mailman
saying Message has a suspicious header and it doesn't look like
anyone wants to approve the email, so I'm trying here instead.
___
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] zc.buildout installing parts not asked for
On 10/27/07, TIm Terlegård [EMAIL PROTECTED] wrote:
When using zc.buildout I discovered that it installed a part that I
didn't
specify in the 'parts' option. This happened because I referenced this
part somewhere else. Is this how it's supposed to be? I would prefer
if it
only installs the parts I specify in parts. I don't see anything
wrong with
reusing options from a part that I don't necessarily want to install.
When a part refers to another part via ${...} variable expansion, a
dependency between parts is established. If you don't want a
dependency, move the setting into a separate section (with no recipe
setting) and reference that from both parts that need the setting.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
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 )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/DateTime/tests/testDateTime.py Fix test. According to http://en.wikipedia.org/wiki/ISO_8601
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laurence Rowe wrote:
Log message for revision 80922:
Fix test. According to http://en.wikipedia.org/wiki/ISO_8601
If no time zone information is given with a time, the time zone is assumed
to be in some conventional local time zone.
If I understand correctly, the trunk has had a BBB-incompatible change
to the semantics of the DateTime constructor:
In Zope 2.10.x (as well as 2.9x, 2.8x, and 2.7x):
from DateTime.DateTime import DateTime
DateTime('2006/01/01')._tz
'US/Eastern'
DateTime('2006/01/01 UTC')._tz
'Universal'
DateTime('2006-01-01')._tz
'GMT+0'
On the trunk:
from DateTime.DateTime import DateTime
DateTime('2006/01/01')
DateTime('2006/01/01')
DateTime('2006/01/01')._tz
'US/Eastern'
DateTime('2006/01/01 UTC')._tz
'UTC'
DateTime('2006-01-01')._tz
'US/Eastern'
I strongly disagreed with the argument for that change
(http://www.zope.org/Collectors/Zope/2109), because it broke the
semantics of the class, based on long-established use in Zope: datetime
strings which used ISO notation, but provided no explicit timezone, were
assigned 'GMT+0' as the timezone.
The trunk should be reverted to preserve the old behavior, which may be
relied on by third-party applications.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHI7U1+gerLs4ltQ4RAraFAJwKFa2DOCYn3dPzBM8jXnlajEcrpACeKalL
BxeHK/EzDNqV5tT0yY0J76I=
=HL8g
-END PGP SIGNATURE-
___
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] Re: SVN: Zope/trunk/lib/python/DateTime/tests/testDateTime.py Fix test. According to http://en.wikipedia.org/wiki/ISO_8601
--On 27. Oktober 2007 18:01:25 -0400 Tres Seaver [EMAIL PROTECTED]
wrote:
DateTime('2006-01-01')._tz
'US/Eastern'
Yeah, that's completely odd.
I strongly disagreed with the argument for that change
(http://www.zope.org/Collectors/Zope/2109), because it broke the
semantics of the class, based on long-established use in Zope: datetime
strings which used ISO notation, but provided no explicit timezone, were
assigned 'GMT+0' as the timezone.
Totally agreed.
(http://www.zope.org/Collectors/Zope/2109),
Is this right issue? The URL redirection to LP points me to this:
https://bugs.launchpad.net/zope2/+bug/143701
The trunk should be reverted to preserve the old behavior, which may be
relied on by third-party applications.
Jup, either revert the change or fix it.
Andreas
pgpVXY729nDgj.pgp
Description: PGP signature
___
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] backup full instances
On 26/10/2007 Andreas Jung wrote: Is it safe in general to copy Data.fs while the instance is running? Or might I end up with a broken Data.fs, which zope is not able to read at all? If you create a local copy, it is safe. If you rsync a running Data.fs, it is not safe. In this case you create a local copy and rsync the copy. what's the difference between local copy and rsync except for the time it takes? but if rsync is unsafe only because it takes long time, and changes on the instance during the copy process could cause a corrupted Data.fs to be backuped, then theoretically this could happen for a local copy as well, right? only that the probability would be far smaller. For incremental backups: check the repozo.py script. That one look interesting. thanks for the hint! greetings, jonas signature.asc Description: Digital signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] backup full instances
--On 27. Oktober 2007 16:29:18 +0200 Jonas Meurer [EMAIL PROTECTED] wrote: On 26/10/2007 Andreas Jung wrote: Is it safe in general to copy Data.fs while the instance is running? Or might I end up with a broken Data.fs, which zope is not able to read at all? If you create a local copy, it is safe. If you rsync a running Data.fs, it is not safe. In this case you create a local copy and rsync the copy. what's the difference between local copy and rsync except for the time it takes? but if rsync is unsafe only because it takes long time, and changes on the instance during the copy process could cause a corrupted Data.fs to be backuped, then theoretically this could happen for a local copy as well, right? Think twice about your last sentence. What should cause a local *copy* to be changed?? -aj pgpL7jXIiuTOY.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] backup full instances
On 27/10/2007 Andreas Jung wrote: If you create a local copy, it is safe. If you rsync a running Data.fs, it is not safe. In this case you create a local copy and rsync the copy. but if rsync is unsafe only because it takes long time, and changes on the instance during the copy process could cause a corrupted Data.fs to be backuped, then theoretically this could happen for a local copy as well, right? Think twice about your last sentence. What should cause a local *copy* to be changed?? zope might write to the Data.fs while it is copied, thus an inconsistent copy would be backuped, even inside one filesystem. i've asked in #debian on freenode as i wasn't sure, here's the log: mejo if i copy a large file inside a mounted filesystem (ext3), is it possible that the file is changed during the copy process? Wyzard mejo: Yes, it's possible that something else can write to the file while you're copying it mejo because i asked on the zope-users mailinglist if i could backup the global Data.fs (database) while the daemon is running, and someone answered: mejo If you create a local copy, it is safe. If you rsync a running Data.fs it is not safe. In this case you create a local copy and rsync the copy. Wyzard mejo: Making a local copy is faster, so it'd be safer, but still not completely safe mejo exactly, that's what i thought as well. mejo but when i wrote that, he replied: mejo Think twice about your last sentence. What should cause a local *copy* to be changed?? mejo so he's wrong? Wyzard I'd say he's wrong Wyzard A local copy isn't instantaneous, and Zope changes the file while it's being read wols_ he is wrong yes mejo thanks. is it ok for you if i quote you in my reply mail? Wyzard mejo: sure wols_ mejo: while copying zope could change the database and create an inconsistent state greetings, jonas signature.asc Description: Digital signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] backup full instances
On 10/27/07, Jonas Meurer [EMAIL PROTECTED] wrote: zope might write to the Data.fs while it is copied, thus an inconsistent copy would be backuped, even inside one filesystem. if you insist on copying a file, _and_ happen to be on linux with some lvm volumes, you can snapshot that volume with Data.fs on it (throw perhaps a sync before, don't know if it makes a difference). So you get the copy at one point in time. you can also rsync from that. --knitti ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] backup full instances
--On 27. Oktober 2007 18:18:23 +0200 Jonas Meurer [EMAIL PROTECTED] wrote: On 27/10/2007 Andreas Jung wrote: If you create a local copy, it is safe. If you rsync a running Data.fs, it is not safe. In this case you create a local copy and rsync the copy. but if rsync is unsafe only because it takes long time, and changes on the instance during the copy process could cause a corrupted Data.fs to be backuped, then theoretically this could happen for a local copy as well, right? Think twice about your last sentence. What should cause a local *copy* to be changed?? zope might write to the Data.fs while it is copied, thus an inconsistent copy would be backuped, even inside one filesystem. This is not the point. rsync will run into if the file to be synced changes in-between the sync operation. This will happen with the Data.fs - it won't happen with a static copy. An inconsistent copy of the Data.fs is not the problem since invalid transaction entries will be discarded by the ZODB. So rsyncing a copy of the Data.fs it the way to go. -aj pgpfgonwoDECt.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] backup full instances
Hi, Jonas Meurer schrieb: On 27/10/2007 Andreas Jung wrote: If you create a local copy, it is safe. If you rsync a running Data.fs, it is not safe. In this case you create a local copy and rsync the copy. but if rsync is unsafe only because it takes long time, and changes on the instance during the copy process could cause a corrupted Data.fs to be backuped, then theoretically this could happen for a local copy as well, right? Think twice about your last sentence. What should cause a local *copy* to be changed?? zope might write to the Data.fs while it is copied, thus an inconsistent copy would be backuped, even inside one filesystem. i've asked in #debian on freenode as i wasn't sure, here's the log: mejo if i copy a large file inside a mounted filesystem (ext3), is it possible that the file is changed during the copy process? Wyzard mejo: Yes, it's possible that something else can write to the file while you're copying it mejo because i asked on the zope-users mailinglist if i could backup the global Data.fs (database) while the daemon is running, and someone answered: mejo If you create a local copy, it is safe. If you rsync a running Data.fs it is not safe. In this case you create a local copy and rsync the copy. Wyzard mejo: Making a local copy is faster, so it'd be safer, but still not completely safe mejo exactly, that's what i thought as well. mejo but when i wrote that, he replied: mejo Think twice about your last sentence. What should cause a local *copy* to be changed?? mejo so he's wrong? Wyzard I'd say he's wrong Wyzard A local copy isn't instantaneous, and Zope changes the file while it's being read wols_ he is wrong yes mejo thanks. is it ok for you if i quote you in my reply mail? Wyzard mejo: sure wols_ mejo: while copying zope could change the database and create an inconsistent state Nobody is wrong. Your #debian guys just had not all informations. Zope is always appending to Data.fs, copy (cp) works linear, so it would always maintain a consistent state of this file. (It either copies before or after the last append operation) rsync on the other hand is very efficient by calculating only differences of the file contents to be copied. This may or may be not following the order of blocks in the file. In the latter case it could try to sync wrong information. (You would need a special rsync which would only transfer new blocks at the end in their given order - you could script something like this using dd, gzip/zcat, ssh. Regards Tino ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] backup full instances
Jonas Meurer wrote at 2007-10-26 16:57 +0200: ... The main problem with this backup approach is, that the zope instance is not stopped for the backup at all, thus the Data.fs might not be up to date. Why do you think that this is a problem? Of course, your backup process may read a partial transaction record -- it will be dropped automatically when the storage file is opened. Of course, your backup process may not have backed up the state at the end of the backup -- but it will have backed up the state at the start of the backup. Thus, all you can have as a problem: the effective backup may not exceed the state at it was when the backup started. I think, this should be good enough. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
