[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 )
