Re: [Zope] Error: Picked: Jinja2 = 2.6
Your buildout has been configured to only allow *pinned* dependencies; eggs for which you specified the version. Add `Jinja2 = 2.6` to your `[versions]` section. — Martijn Pieters zopatista.com On Fri, May 3, 2013 at 3:43 AM, Tamer Higazi th9...@googlemail.com wrote: Hi people! in my new bluebream application I tried to add the template engine jinja2 in setup.py before running buildout and I get this error?! Am I doing something wrong?! Develop: '/storage/PyProjects/bbreamAPP/.' install_dir /storage/PyProjects/bbreamAPP/develop-eggs/tmp6qhLW1build Updating app. While: Updating app. Getting distribution for 'jinja2'. Error: Picked: Jinja2 = 2.6 ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] ZTK 2.0: Deprecate zope.sequencesort
On Thursday, February 28, 2013, Stephan Richter wrote: I would like to deprecate zope.sequencesort in ZTK 2.0, since it cannot properly ported to Python 3, since it depends heavily on the cmp() way of sorting. I am also not a user of the package and I only tried to port the package for completeness sake. You can always fall back to functools.cmp_to_key() to use cmp-based sorting in python 3: http://docs.python.org/3/library/functools.html#functools.cmp_to_key -- Martijn Pieters -- Martijn Pieters ___ 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] [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Mon, Aug 27, 2012 at 2:37 PM, Vincent Pelletier vinc...@nexedi.com wrote: NEO aims at being a replacement for use-cases where ZEO is used, but with better scalability (by allowing data of a single database to be distributed over several machines, and by removing database-level locking), with failure resilience (by mirroring database content among machines). Under the hood, it relies on simple features of SQL databases (safe on-disk data structure, efficient memory usage, efficient indexes). How does NEO compare to RelStorage? NEO appears to implement the storage roughly in the same way; store pickles in tables in a SQL database. Some differences that I can see from reading your email: * NEO takes care of replication itself; RelStorage pushes that responsibility to the database used. * NEO supports MySQL and sqlite, RelStorage MySQL, PostgreSQL and Oracle. * RelStorage can act as a BlobStorage, NEO can not. Anything else different? Did you make any performance comparisons between RelStorage and NEO? -- Martijn Pieters ___ 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] [Checkins] SVN: Zope/trunk/ `setHeader('Set-Cookie', ...)` special-casing can die
On Mon, Oct 17, 2011 at 11:57, Stefan H. Holek ste...@epy.co.at wrote: There are test failures on Zope trunk which look to be connected to your changes. https://mail.zope.org/pipermail/zope-tests/2011-October/051224.html Please investigate, Ugh. Those tests can go, and someone already dealt with them before I got to them. Mea Culpa! -- Martijn Pieters ___ 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-Checkins] SVN: Zope/trunk/ `setHeader('Set-Cookie', ...)` special-casing can die
Log message for revision 123087:
`setHeader('Set-Cookie', ...)` special-casing can die
Use the cookie APIs or addHeader instead.
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/ZPublisher/HTTPResponse.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2011-10-13 09:46:28 UTC (rev 123086)
+++ Zope/trunk/doc/CHANGES.rst 2011-10-13 13:18:32 UTC (rev 123087)
@@ -50,6 +50,11 @@
Restructuring
+
+- Removed the special handling of `Set-Cookie` headers in
+ `HTTPResponse.setHeader`. Use the `setCookie`/`appendCookie`/`expireCookie`
+ methods instead, or if low-level control is needed, use `addHeader` instead
+ to get the exact same effect.
+
- Removed the `App.version_txt.getZopeVersion` API, you can use
``pkg_resources.get_distribution('Zope2').version`` instead.
Modified: Zope/trunk/src/ZPublisher/HTTPResponse.py
===
--- Zope/trunk/src/ZPublisher/HTTPResponse.py 2011-10-13 09:46:28 UTC (rev
123086)
+++ Zope/trunk/src/ZPublisher/HTTPResponse.py 2011-10-13 13:18:32 UTC (rev
123087)
@@ -330,13 +330,8 @@
if not scrubbed:
name, value = _scrubHeader(name, value)
key = name.lower()
-# The following is crazy, given that we have APIs for cookies.
-# Special behavior will go away in Zope 2.13
-if key == 'set-cookie':
-self.accumulated_headers.append((name, value))
-else:
-name = literal and name or key
-self.headers[name] = value
+name = literal and name or key
+self.headers[name] = value
def appendHeader(self, name, value, delimiter=, ):
Append a value to an HTTP return header.
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Remove the lock around the cookie parsing code.
Log message for revision 123088:
Remove the lock around the cookie parsing code.
The locking here was only ever needed for the old `regex` module that was
originally used for this code, but that was replaced by the thread-safe `re`
some 10 years ago (see r20110, april 2001).
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/ZPublisher/HTTPRequest.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2011-10-13 13:18:32 UTC (rev 123087)
+++ Zope/trunk/doc/CHANGES.rst 2011-10-13 14:15:41 UTC (rev 123088)
@@ -50,6 +50,10 @@
Restructuring
+
+- Removed the (very obsolete) thread lock around the cookie parsing code
+ in HTTPRequest.py; the python `re` module is thread-safe, unlike the
+ ancient `regex` module that was once used here.
+
- Removed the special handling of `Set-Cookie` headers in
`HTTPResponse.setHeader`. Use the `setCookie`/`appendCookie`/`expireCookie`
methods instead, or if low-level control is needed, use `addHeader` instead
Modified: Zope/trunk/src/ZPublisher/HTTPRequest.py
===
--- Zope/trunk/src/ZPublisher/HTTPRequest.py2011-10-13 13:18:32 UTC (rev
123087)
+++ Zope/trunk/src/ZPublisher/HTTPRequest.py2011-10-13 14:15:41 UTC (rev
123088)
@@ -40,7 +40,6 @@
from ZPublisher.BaseRequest import BaseRequest
from ZPublisher.BaseRequest import quote
from ZPublisher.Converters import get_converter
-from ZPublisher.maybe_lock import allocate_lock
# Flags
SEQUENCE = 1
@@ -1649,7 +1648,6 @@
return self
-parse_cookie_lock = allocate_lock()
QPARMRE= re.compile(
'([\x00- ]*([^\x00- ;,=]+)=([^]*)([\x00- ]*[;,])?[\x00- ]*)')
PARMRE = re.compile(
@@ -1661,43 +1659,36 @@
qparmre=QPARMRE,
parmre=PARMRE,
paramlessre=PARAMLESSRE,
- acquire=parse_cookie_lock.acquire,
- release=parse_cookie_lock.release,
):
if result is None:
result = {}
-acquire()
-try:
+mo_q = qparmre.match(text)
-mo_q = qparmre.match(text)
+if mo_q:
+# Match quoted correct cookies
+l = len(mo_q.group(1))
+name = mo_q.group(2)
+value = mo_q.group(3)
-if mo_q:
-# Match quoted correct cookies
-l = len(mo_q.group(1))
-name = mo_q.group(2)
-value = mo_q.group(3)
+else:
+# Match evil MSIE cookies ;)
+mo_p = parmre.match(text)
+if mo_p:
+l = len(mo_p.group(1))
+name = mo_p.group(2)
+value = mo_p.group(3)
else:
-# Match evil MSIE cookies ;)
-mo_p = parmre.match(text)
-
-if mo_p:
-l = len(mo_p.group(1))
-name = mo_p.group(2)
-value = mo_p.group(3)
+# Broken Cookie without = nor value.
+broken_p = paramlessre.match(text)
+if broken_p:
+l = len(broken_p.group(1))
+name = broken_p.group(2)
+value = ''
else:
-# Broken Cookie without = nor value.
-broken_p = paramlessre.match(text)
-if broken_p:
-l = len(broken_p.group(1))
-name = broken_p.group(2)
-value = ''
-else:
-return result
-finally:
-release()
+return result
if name not in result:
result[name] = unquote(value)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting ha...@hannosch.eu wrote: Ok, seems 4.0 is the more popular choice. I don't agree. Let's go with Fibonacci and call the next release Zope 8, as the logical extension of the series 1, 2, 3, and 5! :-P -- Martijn Pieters ___ 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] Security announcement update
On Tue, Jun 28, 2011 at 15:30, Sascha Welter zopel...@betabug.ch wrote: It says Zope 2.10 and 2.11 users who have not installed PloneHotfix20110720 are not affected - can I conclude from that, that Zope 2.9 would not be affected either? Indeed, Zope 2.9 is not affected, with or without the previous hotfix. -- Martijn Pieters ___ 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] Security announcement update
On Tue, Jun 28, 2011 at 15:40, Norbert Marrale norbertmarr...@yahoo.com wrote: Why must PluggableAuthService (+ its dependencies) even be installed? It is a dependency of Plone itself. -- Martijn Pieters ___ 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] [Zope-dev] Security announcement update
On Tue, Jun 28, 2011 at 15:30, Sascha Welter zopel...@betabug.ch wrote: It says Zope 2.10 and 2.11 users who have not installed PloneHotfix20110720 are not affected - can I conclude from that, that Zope 2.9 would not be affected either? Indeed, Zope 2.9 is not affected, with or without the previous hotfix. -- Martijn Pieters ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] [Zope-dev] Security announcement update
On Tue, Jun 28, 2011 at 15:40, Norbert Marrale norbertmarr...@yahoo.com wrote: Why must PluggableAuthService (+ its dependencies) even be installed? It is a dependency of Plone itself. -- Martijn Pieters ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] zope-tests - OK: 77
On Wed, Jun 22, 2011 at 10:01, Lennart Regebro rege...@gmail.com wrote: Whohoo! Amesome work all bugfixers! Wohoo disabling the windows bots! -- Martijn Pieters ___ 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] 2.13 upgrade problems
On Fri, Jun 3, 2011 at 12:42, Peter Bengtsson m...@peterbe.com wrote: I'm getting the error below when trying to boot up a zope 2.13.7 using a Data.fs I took from a zope 2.8.12 instance. You may want to try to boot up the instance on intermediary Zope versions first, it may well update the pickles for you along the way. -- Martijn Pieters ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] z3c.form: Default form content type
On Sun, Apr 10, 2011 at 15:54, Markus Kemmerling markus.kemmerl...@meduniwien.ac.at wrote: By default z3c.form sets the form content type to 'multipart/form-data' (the default value of IInputForm['enctype']). According to http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 this MIME type should be used for submitting forms that contain files, non-ASCII data, and binary data. Shouldn't the default value rather be set to the default content type of HTML forms, i.e. 'application/x-www-form-urlencoded'? The majority of forms use Unicode widgets, so this falls under the heading of non-ASCII data. Also, it'd be almost impossible to auto-detect when binary data will be handled by the form, unless you start introspecting widget output, so the default looks entirely sane to me. -- Martijn Pieters ___ 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] [Distutils] [buildout] private releases
On Wed, Mar 30, 2011 at 15:08, Jim Fulton j...@zope.com wrote: We do something similar with sftp (zc.buildoutsftp). To publish eggs, we just use scp. The advantage of this is that it leverages ssh infrastructure, so *no* additional password management is needed. This is wildly better, IMO, than keeping passwords in clear text in your buildout configuration or in a dot file. That depends on your deployment scenarios. We generate separate passwords per customer, and give them a dedicated URL to load their private eggs from, then put the password in the buildout.cfg. To load the buildout.cfg in the first place, the exact same password is used. Managing SSH accounts and keys for those customers would cost us much more overhead, and would complicate our instructions for deployment to them. On the other hand, for deployments of a buildout from a SVN repository already served over SSH would make the sftp route the logical choice. -- Martijn Pieters ___ 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] [buildout] private releases
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER agroszer...@gmail.com wrote: Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). -- Martijn Pieters ___ 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] PAS, AuthEncoding and zope.password
On Fri, Feb 18, 2011 at 22:19, Martijn Pieters m...@zopatista.com wrote:
We should at the very least convert PAS to use zope.password instead
of AccessControl.AuthEncoding.
There is a snag. The zope.password API doesn't provide any way to
detect what scheme was used for a given hash.
Say you have a SSHA hash, it'll start with the string {SSHA}, while
a bcrypt encryption starts with $2a$. Unfortunately, the
zope.password IPasswordManager only provides methods to encode the
password and check if a given password is correct. The only consumer
of the interface, zope.app.authentication.principalfolder only
supports one password manager at a time so never had a need to detect
schemes.
I'll just go ahead and expand then IPasswordManager interface to
provide a match method that returns a boolean if a given hash uses the
specific encoding scheme. Presumably this'll be zope.password 4.0.0.
What does this mean for the versioning of AccessControl however? Will
that'll be a 2.14 release? What version of Zope2 can start using the
new AccessControl package with a zope.password = 4.0.0 dependency?
Zope2 primarily uses the ZTK, so a version pin would be needed there
until the new zope.password release makes it into the ZTK.
--
Martijn Pieters
___
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] PAS, AuthEncoding and zope.password
On Sun, Feb 20, 2011 at 11:56, Hanno Schlichting ha...@hannosch.eu wrote:
Yes, changing the existing interface would require a 4.0. If you'd add
a new interface extending the IPasswordManager one, we could do it in
a 3.x release.
A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a
backwards incompatible 4.0 would have to wait for ZTK 1.2.
Right. What would be a suitable name for the extended interface?
IMatchingPasswordManager?
I've committed a revision that implements this as an extension to the
existing interface:
http://zope3.pov.lt/trac/changeset/120458/zope.password/trunk
but that's easy enough to change.
I've also found that the SHA1 scheme in zope.password uses the {SHA1}
prefix, which is incompatible with LDAP and
AccessControl.AuthEncoding, which both use {SHA} instead. I'll change
zope.password to support {SHA} as well, defaulting to that prefix.
What version of Zope2 can start using the
new AccessControl package with a zope.password = 4.0.0 dependency?
This depends on the changes in AccessControl and how backwards
compatible they are.
If backwards compatibility is preserved, this can go into Zope 2.13
and trunk, since we allow minor feature additions in the stable
series. Zope 2.12 is at a 2.12.15 release now and at the end of its
lifecycle - it'll only see bugfixes.
It'll be backwards compatible. I'm planning to keep supporting legacy
schemes registered with registerScheme, with listSchemes listing
zope.password managers as well.
The only thing that could perhaps be removed are the SSHADigestScheme
and SHADigestSCheme classes, as these will be completely redundant
with zope.password support.
--
Martijn Pieters
___
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] PAS, AuthEncoding and zope.password
On Sun, Feb 20, 2011 at 12:39, Martijn Pieters m...@zopatista.com wrote:
Yes, changing the existing interface would require a 4.0. If you'd add
a new interface extending the IPasswordManager one, we could do it in
a 3.x release.
A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a
backwards incompatible 4.0 would have to wait for ZTK 1.2.
Right. What would be a suitable name for the extended interface?
IMatchingPasswordManager?
I've committed a revision that implements this as an extension to the
existing interface:
http://zope3.pov.lt/trac/changeset/120458/zope.password/trunk
but that's easy enough to change.
I've also found that the SHA1 scheme in zope.password uses the {SHA1}
prefix, which is incompatible with LDAP and
AccessControl.AuthEncoding, which both use {SHA} instead. I'll change
zope.password to support {SHA} as well, defaulting to that prefix.
I've implemented the {SHA} prefix change, as well as implement {CRYPT}
support, making zope.password useful for all schemes explicitly named
in RFC 2307, except the MD5 scheme.
The latter uses a salt by default, making it incompatible with LDAP
{MD5}. Open LDAP implements a salted MD5 scheme ({SMD5}) but places
the salt at the end of the hash, not at the beginning as the
zope.password manager implements it.
I think I can keep that one backwards compatible but disable support
for generating hashes with a salt, and add a SMD5 manager to implement
a compatible scheme.
With all the new password managers, this will be at least a 3.7
release, with a separate extended interface.
--
Martijn Pieters
___
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 Tests: 72 OK, 15 Failed
On Fri, Feb 18, 2011 at 10:39, Adam GROSZER agroszer...@gmail.com wrote: Windowze... We also have such a failure 1 in 50 buildbot runs. Tho very misterious how it could happen 3x in a row. If the failure is random, with a chance of 1 in 50, 3 times in a row is no mystery. It shows the failure is truly random! :-) -- Martijn Pieters ___ 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] PAS, AuthEncoding and zope.password
I was looking into bcrypt[1] support for PAS I found z3c.bcrypt, which implements zope.password compontents (named utilities). PAS, however, uses Zope2's AccessControl.AuthEncoding module to handle password encryption / hashing schemes. Now, while AuthEncoding certainly supports extending the available schemes, it does need additional glue-code to be able to reuse zope.password components. Moreover, we now have two places to maintain the various hashing and encryption schemes. We should at the very least convert PAS to use zope.password instead of AccessControl.AuthEncoding. With that change it is then at least trivial to support bcrypt as well, you simply install the additional z3c.bcrypt egg and be done with it. But would it make sense to convert Zope2 itself as well? We could make the AuthEncodings module simply a proxy (with deprecation warnings if need be) for zope.password components. Any objections to reworking both AuthEncoding and PAS? -- Martijn Pieters [1] see http://codahale.com/how-to-safely-store-a-password/ and http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt ___ 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] New release of z3c.form
On Thu, Jul 1, 2010 at 3:10 PM, Godefroid Chapelle got...@bubblenet.be wrote: http://packages.python.org/z3c.form The index is empty and module index appears to be missing altogether: http://packages.python.org/z3c.form/index.html#indices-and-tables -- Martijn Pieters ___ 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-Checkins] SVN: Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py Fix _getContextName; does anyone test this stuff?
Log message for revision 109473: Fix _getContextName; does anyone test this stuff? Changed: U Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py -=- Modified: Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py === --- Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py 2010-02-26 15:23:23 UTC (rev 109472) +++ Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py 2010-02-26 16:46:18 UTC (rev 109473) @@ -62,7 +62,7 @@ def _getContextName(self, context): if getattr(context, 'getId', None) is not None: return context.getId() -getattr(context, '__name__', None) +return getattr(context, '__name__', None) def breadcrumbs(self): context = self.context ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/src/Products/Five/browser/absoluteurl.py Merge r109473 from the 2.12 branch
Log message for revision 109474: Merge r109473 from the 2.12 branch Changed: U Zope/trunk/src/Products/Five/browser/absoluteurl.py -=- Modified: Zope/trunk/src/Products/Five/browser/absoluteurl.py === --- Zope/trunk/src/Products/Five/browser/absoluteurl.py 2010-02-26 16:46:18 UTC (rev 109473) +++ Zope/trunk/src/Products/Five/browser/absoluteurl.py 2010-02-26 16:49:27 UTC (rev 109474) @@ -62,7 +62,7 @@ def _getContextName(self, context): if getattr(context, 'getId', None) is not None: return context.getId() -getattr(context, '__name__', None) +return getattr(context, '__name__', None) def breadcrumbs(self): context = self.context ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] SVN: Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py Fix _getContextName; does anyone test this stuff?
2010/2/26 Tres Seaver tsea...@palladion.com: Kettle to pot: Did you add a test? I ran out of time; the current tests weren't easily molded to add a case for this. I felt that at least the simple 'return' statement fix should go in. I'll get the test case in this weekend, hopefully. -- Martijn Pieters ___ 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-Checkins] SVN: Zope/branches/2.12/ Fall back to HELO when EHLO (an optional extension) fails
Log message for revision 108731:
Fall back to HELO when EHLO (an optional extension) fails
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U Zope/branches/2.12/src/Products/MailHost/mailer.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
===
--- Zope/branches/2.12/doc/CHANGES.rst 2010-02-03 09:07:14 UTC (rev 108730)
+++ Zope/branches/2.12/doc/CHANGES.rst 2010-02-03 14:07:58 UTC (rev 108731)
@@ -5,6 +5,14 @@
Change information for previous versions of Zope can be found in the
file HISTORY.txt.
+Zope 2.12.4 (Unreleased)
+
+
+Bugs Fixed
+++
+
+- MailHost should fall back to HELO when EHLO fails.
+
Zope 2.12.3 (2010/01/12)
Modified: Zope/branches/2.12/src/Products/MailHost/mailer.py
===
--- Zope/branches/2.12/src/Products/MailHost/mailer.py 2010-02-03 09:07:14 UTC
(rev 108730)
+++ Zope/branches/2.12/src/Products/MailHost/mailer.py 2010-02-03 14:07:58 UTC
(rev 108731)
@@ -49,8 +49,10 @@
# send EHLO
code, response = connection.ehlo()
if code 200 or code 300:
-raise RuntimeError('Error sending EHLO to the SMTP server '
-'(code=%s, response=%s)' % (code, response))
+code, response = connection.helo()
+if code 200 or code 300:
+raise RuntimeError('Error sending HELO to the SMTP server '
+ '(code=%s, response=%s)' % (code, response))
# encryption support
have_tls = connection.has_extn('starttls')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/src/Products/MailHost/mailer.py Merge r108731 from 2.12: MailHost fallback to HELO
Log message for revision 108732:
Merge r108731 from 2.12: MailHost fallback to HELO
Changed:
U Zope/trunk/src/Products/MailHost/mailer.py
-=-
Modified: Zope/trunk/src/Products/MailHost/mailer.py
===
--- Zope/trunk/src/Products/MailHost/mailer.py 2010-02-03 14:07:58 UTC (rev
108731)
+++ Zope/trunk/src/Products/MailHost/mailer.py 2010-02-03 14:10:01 UTC (rev
108732)
@@ -49,8 +49,10 @@
# send EHLO
code, response = connection.ehlo()
if code 200 or code 300:
-raise RuntimeError('Error sending EHLO to the SMTP server '
-'(code=%s, response=%s)' % (code, response))
+code, response = connection.helo()
+if code 200 or code 300:
+raise RuntimeError('Error sending HELO to the SMTP server '
+ '(code=%s, response=%s)' % (code, response))
# encryption support
have_tls = connection.has_extn('starttls')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/ Merge r108731 from 2.12: MailHost fallback to HELO
Log message for revision 108733:
Merge r108731 from 2.12: MailHost fallback to HELO
Changed:
U Zope/branches/2.11/doc/CHANGES.txt
U Zope/branches/2.11/lib/python/Products/MailHost/mailer.py
-=-
Modified: Zope/branches/2.11/doc/CHANGES.txt
===
--- Zope/branches/2.11/doc/CHANGES.txt 2010-02-03 14:10:01 UTC (rev 108732)
+++ Zope/branches/2.11/doc/CHANGES.txt 2010-02-03 14:15:23 UTC (rev 108733)
@@ -4,6 +4,12 @@
Change information for previous versions of Zope can be found in the
file HISTORY.txt.
+ Zope 2.11.7 (Unreleased)
+
+Bugs Fixed
+
+ - MailHost should fall back to HELO when EHLO fails.
+
Zope 2.11.6 (2010/01/12)
Bugs Fixed
Modified: Zope/branches/2.11/lib/python/Products/MailHost/mailer.py
===
--- Zope/branches/2.11/lib/python/Products/MailHost/mailer.py 2010-02-03
14:10:01 UTC (rev 108732)
+++ Zope/branches/2.11/lib/python/Products/MailHost/mailer.py 2010-02-03
14:15:23 UTC (rev 108733)
@@ -49,8 +49,10 @@
# send EHLO
code, response = connection.ehlo()
if code 200 or code 300:
-raise RuntimeError('Error sending EHLO to the SMTP server '
-'(code=%s, response=%s)' % (code, response))
+code, response = connection.helo()
+if code 200 or code 300:
+raise RuntimeError('Error sending HELO to the SMTP server '
+ '(code=%s, response=%s)' % (code, response))
# encryption support
have_tls = connection.has_extn('starttls')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope] UTF-8 problem with zope2.10 and postgresql
2009/11/8 Andrew Milton a...@theinternet.com.au: PageTemplateFile stops Zope from starting if the file they refer to does not exist, rather than the 'at-access-time' error they used to generate. When you have place holder code and templates in abstract base-classes, this sucks the big one let me tell you. I don't know why or what changed there, but have you considered that this could be a bug? It sounds as if you have a legitimate usecase there, at least something you could argue convincingly about. -- Martijn Pieters ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] sharing instance_home?
2009/11/4 Jürgen Herrmann juergen.herrm...@xlhost.de: currently i'm running a single zope2 process with relstorage as storage backend. to improve performance for our end users i'd like to fire up a 2nd zope2 process that will handle all internal background processes and db packing. for simplicity's sake i'd like to share the instance_home directory between these two processes, just use a different config file to enter a different http port for each server. no how can i run 2 zope processes from the same instance home with 2 different config files? modifying $INSTANCE_HOME/zopectl to include a different config file name does not work, as it's also contained in $INSTANCE_HOME/runzope. renaming/modifying runzope does not work either, as it's name is hardcoded somewhere in zopectl. If you are using RelStorage you won't be saving much space by reusing the instance home. I'd be wary of sharing the directory between instances, because 3rd party products sometimes use it to store instance-specific data (e.g. not sharable between 2 zope processes). -- Martijn Pieters ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Zope Tests: 6 OK, 2 Failed
2009/10/31 Tres Seaver tsea...@palladion.com: I can't reproduce this failure when running the Acquisition 2.12.4 tests with Python 2.4 on my machine. This is python 2.4 on 64-bit linux. I bet it's because of: typedef int Py_ssize_t; and sys.maxint overflows to -1 with that definition. I suspect that all open-ended slicing ops in Python C extensions are borken in python 2.4, because it doesn't have Py_ssize_t. -- Martijn Pieters ___ 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-Checkins] SVN: Zope/trunk/ Separate clearing and closing a request.
Log message for revision 104360:
Separate clearing and closing a request.
Clearing frees resources, closing also sends out the end-request event. Clones
of the current request need to be cleared, only the actual current request
needs to be closed. Fixes LP #414757.
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/ZPublisher/BaseRequest.py
U Zope/trunk/src/ZPublisher/HTTPRequest.py
U Zope/trunk/src/ZPublisher/tests/testHTTPRequest.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2009-09-18 19:46:22 UTC (rev 104359)
+++ Zope/trunk/doc/CHANGES.rst 2009-09-18 20:16:03 UTC (rev 104360)
@@ -51,6 +51,8 @@
Bugs Fixed
++
+- LP #414757: Don't send a request closed event from a cloned request.
+
- LP #418454: FTP server did not work with Python 2.6.X
- Fixed issue with sending text containing ':' from MailHost.
Modified: Zope/trunk/src/ZPublisher/BaseRequest.py
===
--- Zope/trunk/src/ZPublisher/BaseRequest.py2009-09-18 19:46:22 UTC (rev
104359)
+++ Zope/trunk/src/ZPublisher/BaseRequest.py2009-09-18 20:16:03 UTC (rev
104360)
@@ -206,11 +206,14 @@
else: other.update(kw)
self.other=other
-def close(self):
+def clear(self):
self.other.clear()
-notify(EndRequestEvent(None, self))
self._held=None
+def close(self):
+self.clear()
+notify(EndRequestEvent(None, self))
+
def processInputs(self):
Do any input processing that could raise errors
Modified: Zope/trunk/src/ZPublisher/HTTPRequest.py
===
--- Zope/trunk/src/ZPublisher/HTTPRequest.py2009-09-18 19:46:22 UTC (rev
104359)
+++ Zope/trunk/src/ZPublisher/HTTPRequest.py2009-09-18 20:16:03 UTC (rev
104360)
@@ -184,7 +184,7 @@
r.retry_count = self.retry_count
return r
-def close(self):
+def clear(self):
# Clear all references to the input stream, possibly
# removing tempfiles.
self.stdin = None
@@ -194,7 +194,7 @@
# one. Without this, there's the possibility of memory leaking
# after every request.
self._lazies = {}
-BaseRequest.close(self)
+BaseRequest.clear(self)
def setServerURL(self, protocol=None, hostname=None, port=None):
Set the parts of generated URLs.
@@ -1171,7 +1171,7 @@
except:
rsp.exception()
if object is None:
-req.close()
+req.clear()
raise rsp.errmsg, sys.exc_info()[1]
# The traversal machinery may return a default object
@@ -1191,7 +1191,7 @@
if name != os.path.split(path)[-1]:
object = req.PARENTS[0]
-req.close()
+req.clear()
return object
def clone(self):
Modified: Zope/trunk/src/ZPublisher/tests/testHTTPRequest.py
===
--- Zope/trunk/src/ZPublisher/tests/testHTTPRequest.py 2009-09-18 19:46:22 UTC
(rev 104359)
+++ Zope/trunk/src/ZPublisher/tests/testHTTPRequest.py 2009-09-18 20:16:03 UTC
(rev 104360)
@@ -975,7 +975,20 @@
clone = request.clone()
self.failUnless(IFoo.providedBy(clone))
+def test_resolve_url_doesnt_send_endrequestevent(self):
+import zope.event
+events = []
+zope.event.subscribers.append(events.append)
+request = self._makeOne()
+request['PARENTS'] = [object()]
+try:
+request.resolve_url(request.script + '/')
+finally:
+zope.event.subscribers.remove(events.append)
+self.failIf(len(events),
+HTTPRequest.resolve_url should not emit events)
+
TEST_ENVIRON = {
'CONTENT_TYPE': 'multipart/form-data; boundary=12345',
'REQUEST_METHOD': 'POST',
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.12/ Backport r104360 from trunk: do not emit the request closed event from a request clone
Log message for revision 104361:
Backport r104360 from trunk: do not emit the request closed event from a
request clone
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U Zope/branches/2.12/src/ZPublisher/BaseRequest.py
U Zope/branches/2.12/src/ZPublisher/HTTPRequest.py
U Zope/branches/2.12/src/ZPublisher/tests/testHTTPRequest.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
===
--- Zope/branches/2.12/doc/CHANGES.rst 2009-09-18 20:16:03 UTC (rev 104360)
+++ Zope/branches/2.12/doc/CHANGES.rst 2009-09-18 20:26:31 UTC (rev 104361)
@@ -15,7 +15,12 @@
- ZODB3 = 3.9.0
+Bugs Fixed
+++
+- LP #414757 (backported from Zope trunk): don't emit a IEndRequestEvent when
+ clearing a cloned request.
+
Zope 2.12.0 c1 (2009/09/04)
---
Modified: Zope/branches/2.12/src/ZPublisher/BaseRequest.py
===
--- Zope/branches/2.12/src/ZPublisher/BaseRequest.py2009-09-18 20:16:03 UTC
(rev 104360)
+++ Zope/branches/2.12/src/ZPublisher/BaseRequest.py2009-09-18 20:26:31 UTC
(rev 104361)
@@ -206,11 +206,14 @@
else: other.update(kw)
self.other=other
-def close(self):
+def clear(self):
self.other.clear()
-notify(EndRequestEvent(None, self))
self._held=None
+def close(self):
+self.clear()
+notify(EndRequestEvent(None, self))
+
def processInputs(self):
Do any input processing that could raise errors
Modified: Zope/branches/2.12/src/ZPublisher/HTTPRequest.py
===
--- Zope/branches/2.12/src/ZPublisher/HTTPRequest.py2009-09-18 20:16:03 UTC
(rev 104360)
+++ Zope/branches/2.12/src/ZPublisher/HTTPRequest.py2009-09-18 20:26:31 UTC
(rev 104361)
@@ -184,7 +184,7 @@
r.retry_count = self.retry_count
return r
-def close(self):
+def clear(self):
# Clear all references to the input stream, possibly
# removing tempfiles.
self.stdin = None
@@ -194,7 +194,7 @@
# one. Without this, there's the possibility of memory leaking
# after every request.
self._lazies = {}
-BaseRequest.close(self)
+BaseRequest.clear(self)
def setServerURL(self, protocol=None, hostname=None, port=None):
Set the parts of generated URLs.
@@ -1171,7 +1171,7 @@
except:
rsp.exception()
if object is None:
-req.close()
+req.clear()
raise rsp.errmsg, sys.exc_info()[1]
# The traversal machinery may return a default object
@@ -1191,7 +1191,7 @@
if name != os.path.split(path)[-1]:
object = req.PARENTS[0]
-req.close()
+req.clear()
return object
def clone(self):
Modified: Zope/branches/2.12/src/ZPublisher/tests/testHTTPRequest.py
===
--- Zope/branches/2.12/src/ZPublisher/tests/testHTTPRequest.py 2009-09-18
20:16:03 UTC (rev 104360)
+++ Zope/branches/2.12/src/ZPublisher/tests/testHTTPRequest.py 2009-09-18
20:26:31 UTC (rev 104361)
@@ -975,7 +975,20 @@
clone = request.clone()
self.failUnless(IFoo.providedBy(clone))
+def test_resolve_url_doesnt_send_endrequestevent(self):
+import zope.event
+events = []
+zope.event.subscribers.append(events.append)
+request = self._makeOne()
+request['PARENTS'] = [object()]
+try:
+request.resolve_url(request.script + '/')
+finally:
+zope.event.subscribers.remove(events.append)
+self.failIf(len(events),
+HTTPRequest.resolve_url should not emit events)
+
TEST_ENVIRON = {
'CONTENT_TYPE': 'multipart/form-data; boundary=12345',
'REQUEST_METHOD': 'POST',
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/ Backport r104360 from trunk: do not emit the request closed event from a request clone
Log message for revision 104363:
Backport r104360 from trunk: do not emit the request closed event from a
request clone
Changed:
U Zope/branches/2.11/doc/CHANGES.txt
U Zope/branches/2.11/lib/python/ZPublisher/BaseRequest.py
U Zope/branches/2.11/lib/python/ZPublisher/HTTPRequest.py
U Zope/branches/2.11/lib/python/ZPublisher/tests/testHTTPRequest.py
-=-
Modified: Zope/branches/2.11/doc/CHANGES.txt
===
--- Zope/branches/2.11/doc/CHANGES.txt 2009-09-18 20:32:27 UTC (rev 104362)
+++ Zope/branches/2.11/doc/CHANGES.txt 2009-09-18 20:55:40 UTC (rev 104363)
@@ -4,6 +4,13 @@
Change information for previous versions of Zope can be found in the
file HISTORY.txt.
+ Zope 2.11.5 (Unreleased)
+
+Bugs Fixed
+
+ - LP #414757 (backported from Zope trunk): don't emit a IEndRequestEvent
+when clearing a cloned request.
+
Zope 2.11.4 (2009/08/06)
Restructuring
Modified: Zope/branches/2.11/lib/python/ZPublisher/BaseRequest.py
===
--- Zope/branches/2.11/lib/python/ZPublisher/BaseRequest.py 2009-09-18
20:32:27 UTC (rev 104362)
+++ Zope/branches/2.11/lib/python/ZPublisher/BaseRequest.py 2009-09-18
20:55:40 UTC (rev 104363)
@@ -203,11 +203,14 @@
else: other.update(kw)
self.other=other
-def close(self):
+def clear(self):
self.other.clear()
-notify(EndRequestEvent(None, self))
self._held=None
+def close(self):
+self.clear()
+notify(EndRequestEvent(None, self))
+
def processInputs(self):
Do any input processing that could raise errors
Modified: Zope/branches/2.11/lib/python/ZPublisher/HTTPRequest.py
===
--- Zope/branches/2.11/lib/python/ZPublisher/HTTPRequest.py 2009-09-18
20:32:27 UTC (rev 104362)
+++ Zope/branches/2.11/lib/python/ZPublisher/HTTPRequest.py 2009-09-18
20:55:40 UTC (rev 104363)
@@ -149,7 +149,7 @@
r.retry_count=self.retry_count
return r
-def close(self):
+def clear(self):
# Clear all references to the input stream, possibly
# removing tempfiles.
self.stdin = None
@@ -159,7 +159,7 @@
# one. Without this, there's the possibility of memory leaking
# after every request.
self._lazies = {}
-BaseRequest.close(self)
+BaseRequest.clear(self)
def setServerURL(self, protocol=None, hostname=None, port=None):
Set the parts of generated URLs.
@@ -1082,7 +1082,7 @@
try: object=req.traverse(path)
except: rsp.exception()
if object is None:
-req.close()
+req.clear()
raise rsp.errmsg, sys.exc_info()[1]
# The traversal machinery may return a default object
@@ -1100,7 +1100,7 @@
if name != os.path.split(path)[-1]:
object=req.PARENTS[0]
-req.close()
+req.clear()
return object
Modified: Zope/branches/2.11/lib/python/ZPublisher/tests/testHTTPRequest.py
===
--- Zope/branches/2.11/lib/python/ZPublisher/tests/testHTTPRequest.py
2009-09-18 20:32:27 UTC (rev 104362)
+++ Zope/branches/2.11/lib/python/ZPublisher/tests/testHTTPRequest.py
2009-09-18 20:55:40 UTC (rev 104363)
@@ -75,6 +75,20 @@
self.assertEqual( user_id_x, user_id )
self.assertEqual( password_x, password )
+def test_resolve_url_doesnt_send_endrequestevent(self):
+import zope.event
+events = []
+zope.event.subscribers.append(events.append)
+request = self._makeOne()
+request['PARENTS'] = [object()]
+try:
+request.resolve_url(request.script + '/')
+finally:
+zope.event.subscribers.remove(events.append)
+self.failIf(len(events),
+HTTPRequest.resolve_url should not emit events)
+
+
class RecordTests( unittest.TestCase ):
def test_repr( self ):
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Sat, Aug 8, 2009 at 13:19, Hanno Schlichting ha...@hannosch.eu wrote: One thing to note here is that the above change is indeed only of of probably many that need to be made to support 64-bit platforms properly. The other thing to note is that the change now introduces a hard requirement on Python 2.5 or later. Neither Martijn nor me could figure out a way to make the function calls to Build have different format identifier arguments dependent on the Python version. On Python 2.4 there is only i for integer and 2.5 introduces n for Py_ssize_t. Since this is an argument to a function showing up in various combinations of nn, nO and others, there seems to be no easy way to make this work. Someone with more knowledge about pre-processor tricks might come up with a solution to this, otherwise we will have to choose between dropping 64-bit support or dropping the unofficial Python 2.4 support. It turned out to be really simple as consecutive string literals are concatenated into one after macros are expanded. The following changeset should make Acquisition python 2.4 compatible again and also properly 64-bit capable: http://svn.zope.org/Acquisition/trunk/src/Acquisition/_Acquisition.c?rev=102577view=rev To summarize: when passing Py_BuildValue a Py_ssize_t value to build a python int, you need to use the 'n' format string instead of 'i'. But because 'n' and Py_ssize_t are both defined as of python 2.5, for C code to work in python 2.4 you need to redefine these two back to 'i' and int. -- Martijn Pieters ___ 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] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Mon, Aug 3, 2009 at 08:04, Martijn Pieters m...@zopatista.com wrote: AssertionError: Incorrect Content-Length is set! Expected 20425, got 20426. I don't grok the range support code at all: probably Martijn Pieters is the only person in the world who does. The tests are quite obscure to me, so I can't diagnose even whether the failure is a testing artifact or a real bug. Here's my response to Tres; for some reason my mail reader didn't include zope-dev. I can add now that I'll be at a sprint this weekend where I'll probably have time to take a look myself: I have found the problem, but do not understand where exactly the error occurs. The problem is caused by an acquisition wrapped object with a __getslice__ method get the wrong indices passed in when the end parameter is ommitted: data[start:] Image.Pdata classes have a __getslice__ method, and when data is acquisition wrapped, that method gets (start, -1) passed in on 64-bit platforms, while on my Macbook (start, sys.maxint) is passed in instead. Obviously this means that the slice returns not everything from 'start' to the end, but from 'start' until the one-but-last byte. However, as far as I can tell cAcquisition.c doesn't touch the start and end values. Anyone want to investigate why this goes wrong? Here is the simple test case: from Acquisition import Implicit class Root(Implicit): pass class Slicer(Implicit): def __getslice__(self, start, end): return [start, end] root = Root() slicer = Slicer().__of__(root) print slicer[1:] Run this as bin/zopepy acquisition.py and verify that [1, -1] is printed on 64-bit platforms as opposed to [1, 2147483647] on 32-bit platforms. -- Martijn Pieters ___ 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] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Fri, Aug 7, 2009 at 14:55, Martijn Pieters m...@zopatista.com wrote: Here is the simple test case: from Acquisition import Implicit class Root(Implicit): pass class Slicer(Implicit): def __getslice__(self, start, end): return [start, end] root = Root() slicer = Slicer().__of__(root) print slicer[1:] Run this as bin/zopepy acquisition.py and verify that [1, -1] is printed on 64-bit platforms as opposed to [1, 2147483647] on 32-bit platforms. Further datapoints, the following extra lines for the above script give more context to compare: import sys print slicer[sys.maxint:] print slicer[sys.maxint-1:] print Slicer()[1:] So we pass in sys.maxint and sys.maxint-1 as start values, and also run the Slicer without acquisition wrapping to demonstrate that the wrapper is the culprit, not python itself. Python passes in sys.maxint for the end value for the slice if you omit it, and these high values overflow somewhere in the wraper. -- Martijn Pieters ___ 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] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Fri, Aug 7, 2009 at 14:55, Martijn Pieters m...@zopatista.com wrote: The problem is caused by an acquisition wrapped object with a __getslice__ method get the wrong indices passed in when the end parameter is ommitted: data[start:] Image.Pdata classes have a __getslice__ method, and when data is acquisition wrapped, that method gets (start, -1) passed in on 64-bit platforms, while on my Macbook (start, sys.maxint) is passed in instead. Obviously this means that the slice returns not everything from 'start' to the end, but from 'start' until the one-but-last byte. However, as far as I can tell cAcquisition.c doesn't touch the start and end values. Anyone want to investigate why this goes wrong? The following checkin fixed this particular problem: http://svn.zope.org/Acquisition/trunk/src/Acquisition/_Acquisition.c?rev=102564view=rev The acquisition slice wrapper accepted Py_ssize_t arguments, but then passed these of as C ints (format string 'i'). Changing the format string to 'n' (Py_ssize_t) fixed *this particular case*. Likely more such fixes must be made. In any case, the HTTP range test no longer fails with this fix. -- Martijn Pieters ___ 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] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Tue, Jul 21, 2009 at 18:40, Tres Seaver tsea...@palladion.com wrote:
File /home/tseaver/projects/Zope-trunk/src/OFS/tests/testRanges.py,
line 332, in testMultipleRangesBigFileOutOfOrder
(7, 80001)])
File /home/tseaver/projects/Zope-trunk/src/OFS/tests/testRanges.py,
line 209, in expectMultipleRanges
str(len(body)), rsp.getHeader('content-length')))
File /opt/Python-2.6.2/lib/python2.6/unittest.py, line 321, in
failIf
if expr: raise self.failureException, msg
AssertionError: Incorrect Content-Length is set! Expected 20425,
got 20426.
I don't grok the range support code at all: probably Martijn Pieters is
the only person in the world who does. The tests are quite obscure to
me, so I can't diagnose even whether the failure is a testing artifact
or a real bug.
Here's my response to Tres; for some reason my mail reader didn't
include zope-dev. I can add now that I'll be at a sprint this weekend
where I'll probably have time to take a look myself:
8--
Sorry you find them obscure; I followed unit test expectations as best
as I could.
The test that fails does the following:
1) Create a big file (uploadBigFile, enough random data to be more
than one pdata chunk)
2) Request for multiple HTTP ranges (slices) of the file to be sent.
These slices should be returned a) in the same order, b) of the
correct length, and of course c) the correct slice of the big file
created in 1.
In this case line 330 specifies that bytes 10-15 (inclusive), the last
1 bytes, and bytes 7-8 (inclusive) are are to be returned.
The call to expectMultipleRanges includes the expected slices (python
syntax, so end value is exclusive).
3) On line 209 of expectMultipleRanges it then tests if the resulting
response has the correct content length header for the whole response
set. The failure reported is that the Content-Length header reports 1
byte more than what was actually sent, so the body was 20425 bytes
long, while the content-header claims it would be 20426 bytes.
Because this is a multi-part range request, Image.py line 277 and
onwards handle this request. The response ends up looking something
like this:
Content-length: size we pre-calculate
Content-type: multipart/byteranges; boundary=boundarystring
More headers
--boundarystring
Content-type: image/whatever
Content-range: bytes start-end/total-file-size
data ...
--boundarystring
... Another section
... etc.
--boundarystring--
There are 2 ways the failure could be caused.
Something could go wrong with the size calculation on lines 280-287;
the total body length is the length of the range data plus the length
of the headers per multi-part plus the length of the MIME boundaries
between them. There is thus a length per part plus the length of the
last boundary.
Or something goes wrong when writing the range data in lines 309-358.
Because there is only one byte difference between what was calculated
on lines 280-287 and what is produced here this is probably a newline
somewhere.
I do find it puzzling this only fails on 64 bit platforms. It could be
that the pdata chunk handling is borken and has a off-by-one error
when running on 64-bit platforms.
Hope this clarifies things a little. I have little time right now to
chase this myself right now, sorry!
8--
--
Martijn Pieters
___
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] HA storage for zope
On Wed, Jun 3, 2009 at 01:04, Miles Waller mi...@jamkit.com wrote: 1. RelStorage Using this, I think I can then take care of replication/mirroring as I have access to a database that is already clustered in a HA environment. My questions are: + Are the connections opened only when zope is started? Say I unplugged a network cable and then plugged it back in again (breaking the database connection) - will it be re-opened? + How does RelStorage take care of the blob storage? Hanno answered these 2 already. + Are there any details of big sites out there that use RelStorage (particularly on Oracle)? The Elkjøp intranet cluster currently runs on 4 machines with 4 clients each, plus a maintenance client on a 5th machine. Varnish and fail-over rigged load balancers complete the cluster. Currently there are 100k+ content objects and 7k active users using this intranet (plus another 3k inactive). -- Martijn Pieters ___ 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] Proposal: Align Zope 2 and Zope 3 permissions
On Sun, Apr 12, 2009 at 12:31, Martin Aspeli optilude+li...@gmail.com wrote: 1) Use an event handler to ensure that any permission / declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease. http://dev.plone.org/collective/browser/collective.autopermission/trunk/collective/autopermission/permissions.py Benefits: Creating new permissions becomes more predictable. Risks: None obvious. The event handler will not override permissions that already exist. 2) Emit a warning instead of an error in Five's handler for the class / directive when set_attributes or set_schema are used. Benefits: Easier to re-use existing packages Risks: The attributes won't actually be protected. However, since Zope 2 doesn't have the concept of protecting 'set' (or security proxies) then I'm not sure there's a problem of expectation. I like, +1. 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere. Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice. I'm sure we can do some performance comparisons on this one. I'd say it's worth the cost, but hard numbers would help. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Mon, Apr 6, 2009 at 10:32, Chris Withers ch...@simplistix.co.uk wrote: Just beware, 1.5 sucks: http://subversion.tigris.org/issues/show_bug.cgi?id=3242 http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/focus=84019 http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/focus=87525 It sucks for very specific cases, namely tight access control on sub-paths. I don't see such cases, and I see speed improvements instead. Note that we are now up to svn 1.6. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Mon, Apr 6, 2009 at 10:39, Chris Withers ch...@simplistix.co.uk wrote: I'm more worried about the lack of merging working and random errors when adding files. Those are pretty serious failures from where I'm sitting... The merging is due to lack of merging info when branching, the 'random errors' are not random but due to svn info being out-of-date after a commit. svn up has always solved that for me. Yes, the latter is a bug, but I suspect it is already solved in 1.6 (didn't test that yet though). -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman wich...@wiggy.net wrote: Note that we are now up to svn 1.6. Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths. Bugger, that is indeed correct. I may not have any problems (and a workaround for svn bug 3119) but that doesn't mean we can ask other people that need access to more tightly ACL-ed repositories to put up with subversion 1.5 and 1.6. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Fri, Apr 3, 2009 at 14:41, Jim Fulton j...@zope.com wrote: Should we all just use that? It's running trac 0.10. I'd love to see trac 0.11, which has additional features that I miss every time I use a 0.10 trac instance, such as the annotate view. Also, I'd include the subversion location plugin, which includes a link to the http:// or svn+ssh:// url for the currently viewed location, for easy checking out. -- Martijn Pieters ___ 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] [ZF] Zope Source Code Repository
On Thu, Apr 2, 2009 at 20:31, Chris Withers ch...@simplistix.co.uk wrote: For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I volunteer to help with any/all of the above. My offer to set up Trac as a buildout still stands too. Jens, have your concerns about dependencies been answered? -- Martijn Pieters ___ 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] [ZF] Zope Source Code Repository
On Thu, Apr 2, 2009 at 20:39, Jim Fulton j...@zope.com wrote: On Apr 2, 2009, at 2:31 PM, Chris Withers wrote: For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing. This is no longer the case for subversion 1.6 and up, the password is now stored encrypted, and subversion now supports KWallet, GNOME Keyring, Mac OS Keychain, and Windows CryptoAPI for storage. See: http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvements -- Martijn Pieters ___ 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] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev nad...@gmail.com wrote:
I don't think they are, according to PEP 3107 they are stored in the
func_annotations attribute of the function.
No, they are stored in __annotations__. Look here:
http://docs.python.org/3.0/whatsnew/3.0.html#new-syntax
Also:
n...@seasaw:~$ python3
Python 3.0.1+ (r301:69556, Feb 24 2009, 13:51:44)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
def hello(who:'name') - None:
... print('Hello, {0}!'.format(who))
...
hello.__annotations__
{'who': 'name', 'return': None}
Interesting! Perhaps we should file a bug to have the PEP updated with
reality then. ;-)
Note that even if the name *where* the same, attribute annotations
only work on classes and instances, while function annotations only
apply to functions, not?
Good point. Looks like it is added automatically only for functions/methods.
:)
However, we can't be sure there won't be annotations for any callable
object, because even PEP says that ``we say function, we mean callable
object``, so one day we certainly will conflict with something. Also,
as Gary pointed out, we mis-use the __*__ name pattern that is now
intended for defining special names that have special meaning for
python interpreter. And we'll certainly will mis-use the
__annotations__ name as it's clearly defined in python 3k.
So, after Gary reminded about __*__ names, I think we shoud use
something like _z_annotations.
Semi-agreed. Tools that access ZODB objects and expect __annotations__
to follow the PEP 3107 conventions will be quite surprised. I doubt
that there will be many tools to do so though.
Then again, if Python is now explicitly claiming the __*__ naming
convention, Zope better avoid it's usage. This means we'll have to fix
__parent__ and __name__ usage as well. This will be painful, me
thinks..
--
Martijn Pieters
___
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] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 22:20, Dan Korostelev nad...@gmail.com wrote: As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things. But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict. I don't think they are, according to PEP 3107 they are stored in the func_annotations attribute of the function. Note that even if the name *where* the same, attribute annotations only work on classes and instances, while function annotations only apply to functions, not? -- Martijn Pieters ___ 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] the Zope Framework project
I find this thread quite ironic. Martijn Faassen recognizes a problem, namely that there is no direction in Zope development. Instead, when ideas are put forth lots of people put in their oar with +1s and -1s and stop energy and cheer leading one direction or another. In the end the ideas either get pushed through by determined contributors or (more often) they die. The irony is that the proposed solution, organized leadership, is going to suffer the same fate as the aforementioned ideas. Everyone is putting in their oar, +1s and -1s are flying right, left and centre, and this idea is either going to die, or Martijn will have to push it through and implement it. No one else seems enthusiastic enough to make this happen outright, there is no clear direction. So to me, the least this thread does is to prove that the flagged problem does exist. And so far I haven't heard any better ideas than what Martijn is proposing (no, leaving the status quo, deny there is a problem and steer by majority is not a counter proposal in my view). It may be that the idea needs some tweaking, but that's just details. Would it be possible to focus this discussion around clearer lines? Create counter proposals if you have to, discuss things on their merits, but if you cannot add more than a vague +1 and -1, please refrain. -- Martijn Pieters ___ 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-Checkins] SVN: Zope/branches/2.11/configure python 2.4.6 has been out for a while
Log message for revision 96311: python 2.4.6 has been out for a while Changed: U Zope/branches/2.11/configure -=- Modified: Zope/branches/2.11/configure === --- Zope/branches/2.11/configure2009-02-09 13:23:23 UTC (rev 96310) +++ Zope/branches/2.11/configure2009-02-09 13:26:42 UTC (rev 96311) @@ -12,13 +12,13 @@ # Place the optimal target version number for Zope (as returned by sys.version) # below -TARGET=2.4.5 +TARGET=2.4.6 # Order a list of acceptable python version numbers (as returned by # sys.version) below in best to worst order, not including the # target version. Up to six acceptable python versions are allowed. # Do not include the target version number in this list! -ACCEPTABLE=2.4.4 +ACCEPTABLE=2.4.5 2.4.4 # provide the executable names for all the acceptable versions # (and the target version) below ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Copy the entry id into the event log as well; this lets you correlate between
Log message for revision 96315:
Copy the entry id into the event log as well; this lets you correlate between
eventlog entries and their corresponding entry in the SiteErrorLog. Needed
when
a user reports the entry id after seeing an error and the server has since
restarted.
Changed:
U Zope/trunk/doc/CHANGES.txt
U Zope/trunk/src/Products/SiteErrorLog/SiteErrorLog.py
U Zope/trunk/src/Products/SiteErrorLog/tests/testSiteErrorLog.py
-=-
Modified: Zope/trunk/doc/CHANGES.txt
===
--- Zope/trunk/doc/CHANGES.txt 2009-02-09 14:28:13 UTC (rev 96314)
+++ Zope/trunk/doc/CHANGES.txt 2009-02-09 14:43:57 UTC (rev 96315)
@@ -269,6 +269,12 @@
for more time zones and up to date daylight saving time
information.
+ - SiteErrorLog now includes the entry id in the information copied to
+the event log. This allowes you to correlate a user error report with
+the event log after a restart, or let's you find the REQUEST
+information in the SiteErrorLog when looking at a traceback in the
+event log.
+
Bugs Fixed
- Specified height/width of icons in ZMI listings so the table doesn't
Modified: Zope/trunk/src/Products/SiteErrorLog/SiteErrorLog.py
===
--- Zope/trunk/src/Products/SiteErrorLog/SiteErrorLog.py2009-02-09
14:28:13 UTC (rev 96314)
+++ Zope/trunk/src/Products/SiteErrorLog/SiteErrorLog.py2009-02-09
14:43:57 UTC (rev 96315)
@@ -216,18 +216,18 @@
LOG.error('Error while logging', exc_info=sys.exc_info())
else:
if self.copy_to_zlog:
-self._do_copy_to_zlog(now,strtype,str(url),tb_text)
+
self._do_copy_to_zlog(now,strtype,entry_id,str(url),tb_text)
return '%s/showEntry?id=%s' % (self.absolute_url(), entry_id)
finally:
info = None
-def _do_copy_to_zlog(self,now,strtype,url,tb_text):
+def _do_copy_to_zlog(self,now,strtype,entry_id,url,tb_text):
when = _rate_restrict_pool.get(strtype,0)
if nowwhen:
next_when = max(when,
now-_rate_restrict_burst*_rate_restrict_period)
next_when += _rate_restrict_period
_rate_restrict_pool[strtype] = next_when
-LOG.error('%s\n%s' % (url, tb_text.rstrip()))
+LOG.error('%s %s\n%s' % (entry_id, url, tb_text.rstrip()))
security.declareProtected(use_error_logging, 'getProperties')
def getProperties(self):
Modified: Zope/trunk/src/Products/SiteErrorLog/tests/testSiteErrorLog.py
===
--- Zope/trunk/src/Products/SiteErrorLog/tests/testSiteErrorLog.py
2009-02-09 14:28:13 UTC (rev 96314)
+++ Zope/trunk/src/Products/SiteErrorLog/tests/testSiteErrorLog.py
2009-02-09 14:43:57 UTC (rev 96315)
@@ -14,6 +14,7 @@
import sys
import unittest
+import logging
class SiteErrorLogTests(unittest.TestCase):
@@ -27,10 +28,18 @@
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
self.app._setObject('error_log', SiteErrorLog())
self.app.manage_addDTMLMethod('doc', '')
+
+self.logger = logging.getLogger('Zope.SiteErrorLog')
+self.log = logging.handlers.BufferingHandler(sys.maxint)
+self.logger.addHandler(self.log)
+self.old_level = self.logger.level
+self.logger.setLevel(logging.ERROR)
except:
self.tearDown()
def tearDown(self):
+self.logger.removeHandler(self.log)
+self.logger.setLevel(self.old_level)
transaction.abort()
self.app._p_jar.close()
@@ -121,6 +130,22 @@
# log entries
self.assertEquals(len(sel_ob.getLogEntries()), previous_log_length)
+def testEntryID(self):
+elog = self.app.error_log
+
+# Create a predictable error
+try:
+raise AttributeError, DummyAttribute
+except AttributeError:
+info = sys.exc_info()
+elog.raising(info)
+
+entries = elog.getLogEntries()
+entry_id = entries[0]['id']
+
+self.assertTrue(entry_id in self.log.buffer[-1].msg,
+(entry_id, self.log.buffer[-1].msg))
+
def testCleanup(self):
# Need to make sure that the __error_log__ hook gets cleaned up
self.app._delObject('error_log')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/ Merge r96315 from trunk: copy entry_id to the event log too
Log message for revision 96316:
Merge r96315 from trunk: copy entry_id to the event log too
Changed:
U Zope/branches/2.11/doc/CHANGES.txt
U Zope/branches/2.11/lib/python/Products/SiteErrorLog/SiteErrorLog.py
U
Zope/branches/2.11/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
-=-
Modified: Zope/branches/2.11/doc/CHANGES.txt
===
--- Zope/branches/2.11/doc/CHANGES.txt 2009-02-09 14:43:57 UTC (rev 96315)
+++ Zope/branches/2.11/doc/CHANGES.txt 2009-02-09 14:52:36 UTC (rev 96316)
@@ -6,6 +6,14 @@
Zope 2.11.3 (unreleased)
+Features added
+
+ - SiteErrorLog now includes the entry id in the information copied to
+the event log. This allowes you to correlate a user error report with
+the event log after a restart, or let's you find the REQUEST
+information in the SiteErrorLog when looking at a traceback in the
+event log.
+
Restructuring
- Added 'InitializeClass' alias in 'App.class_init' to ease migration.
Modified: Zope/branches/2.11/lib/python/Products/SiteErrorLog/SiteErrorLog.py
===
--- Zope/branches/2.11/lib/python/Products/SiteErrorLog/SiteErrorLog.py
2009-02-09 14:43:57 UTC (rev 96315)
+++ Zope/branches/2.11/lib/python/Products/SiteErrorLog/SiteErrorLog.py
2009-02-09 14:52:36 UTC (rev 96316)
@@ -213,18 +213,18 @@
LOG.error('Error while logging', exc_info=sys.exc_info())
else:
if self.copy_to_zlog:
-self._do_copy_to_zlog(now,strtype,str(url),tb_text)
+
self._do_copy_to_zlog(now,strtype,entry_id,str(url),tb_text)
return '%s/showEntry?id=%s' % (self.absolute_url(), entry_id)
finally:
info = None
-def _do_copy_to_zlog(self,now,strtype,url,tb_text):
+def _do_copy_to_zlog(self,now,strtype,entry_id,url,tb_text):
when = _rate_restrict_pool.get(strtype,0)
if nowwhen:
next_when = max(when,
now-_rate_restrict_burst*_rate_restrict_period)
next_when += _rate_restrict_period
_rate_restrict_pool[strtype] = next_when
-LOG.error('%s\n%s' % (url, tb_text.rstrip()))
+LOG.error('%s %s\n%s' % (entry_id, url, tb_text.rstrip()))
security.declareProtected(use_error_logging, 'getProperties')
def getProperties(self):
Modified:
Zope/branches/2.11/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
===
---
Zope/branches/2.11/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
2009-02-09 14:43:57 UTC (rev 96315)
+++
Zope/branches/2.11/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
2009-02-09 14:52:36 UTC (rev 96316)
@@ -14,6 +14,7 @@
import sys
import unittest
+import logging
class SiteErrorLogTests(unittest.TestCase):
@@ -27,10 +28,18 @@
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
self.app._setObject('error_log', SiteErrorLog())
self.app.manage_addDTMLMethod('doc', '')
+
+self.logger = logging.getLogger('Zope.SiteErrorLog')
+self.log = logging.handlers.BufferingHandler(sys.maxint)
+self.logger.addHandler(self.log)
+self.old_level = self.logger.level
+self.logger.setLevel(logging.ERROR)
except:
self.tearDown()
def tearDown(self):
+self.logger.removeHandler(self.log)
+self.logger.setLevel(self.old_level)
transaction.abort()
self.app._p_jar.close()
@@ -121,6 +130,22 @@
# log entries
self.assertEquals(len(sel_ob.getLogEntries()), previous_log_length)
+def testEntryID(self):
+elog = self.app.error_log
+
+# Create a predictable error
+try:
+raise AttributeError, DummyAttribute
+except AttributeError:
+info = sys.exc_info()
+elog.raising(info)
+
+entries = elog.getLogEntries()
+entry_id = entries[0]['id']
+
+self.assertTrue(entry_id in self.log.buffer[-1].msg,
+(entry_id, self.log.buffer[-1].msg))
+
def testCleanup(self):
# Need to make sure that the __error_log__ hook gets cleaned up
self.app._delObject('error_log')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/ Merge r96315 from trunk: copy entry_id to the event log too
Log message for revision 96319:
Merge r96315 from trunk: copy entry_id to the event log too
Changed:
U Zope/branches/2.10/doc/CHANGES.txt
U Zope/branches/2.10/lib/python/Products/SiteErrorLog/SiteErrorLog.py
U
Zope/branches/2.10/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
-=-
Modified: Zope/branches/2.10/doc/CHANGES.txt
===
--- Zope/branches/2.10/doc/CHANGES.txt 2009-02-09 14:59:06 UTC (rev 96318)
+++ Zope/branches/2.10/doc/CHANGES.txt 2009-02-09 15:03:38 UTC (rev 96319)
@@ -6,6 +6,14 @@
Zope 2.10.8 (unreleased)
+Features added
+
+ - SiteErrorLog now includes the entry id in the information copied to
+the event log. This allowes you to correlate a user error report with
+the event log after a restart, or let's you find the REQUEST
+information in the SiteErrorLog when looking at a traceback in the
+event log.
+
Restructuring
- Added 'InitializeClass' alias in 'App.class_init' to ease migration.
Modified: Zope/branches/2.10/lib/python/Products/SiteErrorLog/SiteErrorLog.py
===
--- Zope/branches/2.10/lib/python/Products/SiteErrorLog/SiteErrorLog.py
2009-02-09 14:59:06 UTC (rev 96318)
+++ Zope/branches/2.10/lib/python/Products/SiteErrorLog/SiteErrorLog.py
2009-02-09 15:03:38 UTC (rev 96319)
@@ -213,18 +213,18 @@
LOG.error('Error while logging', exc_info=sys.exc_info())
else:
if self.copy_to_zlog:
-self._do_copy_to_zlog(now,strtype,str(url),tb_text)
+
self._do_copy_to_zlog(now,strtype,entry_id,str(url),tb_text)
return '%s/showEntry?id=%s' % (self.absolute_url(), entry_id)
finally:
info = None
-def _do_copy_to_zlog(self,now,strtype,url,tb_text):
+def _do_copy_to_zlog(self,now,strtype,entry_id,url,tb_text):
when = _rate_restrict_pool.get(strtype,0)
if nowwhen:
next_when = max(when,
now-_rate_restrict_burst*_rate_restrict_period)
next_when += _rate_restrict_period
_rate_restrict_pool[strtype] = next_when
-LOG.error('%s\n%s' % (url, tb_text.rstrip()))
+LOG.error('%s %s\n%s' % (entry_id, url, tb_text.rstrip()))
security.declareProtected(use_error_logging, 'getProperties')
def getProperties(self):
Modified:
Zope/branches/2.10/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
===
---
Zope/branches/2.10/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
2009-02-09 14:59:06 UTC (rev 96318)
+++
Zope/branches/2.10/lib/python/Products/SiteErrorLog/tests/testSiteErrorLog.py
2009-02-09 15:03:38 UTC (rev 96319)
@@ -14,6 +14,7 @@
import sys
import unittest
+import logging
class SiteErrorLogTests(unittest.TestCase):
@@ -27,10 +28,18 @@
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
self.app._setObject('error_log', SiteErrorLog())
self.app.manage_addDTMLMethod('doc', '')
+
+self.logger = logging.getLogger('Zope.SiteErrorLog')
+self.log = logging.handlers.BufferingHandler(sys.maxint)
+self.logger.addHandler(self.log)
+self.old_level = self.logger.level
+self.logger.setLevel(logging.ERROR)
except:
self.tearDown()
def tearDown(self):
+self.logger.removeHandler(self.log)
+self.logger.setLevel(self.old_level)
transaction.abort()
self.app._p_jar.close()
@@ -121,6 +130,22 @@
# log entries
self.assertEquals(len(sel_ob.getLogEntries()), previous_log_length)
+def testEntryID(self):
+elog = self.app.error_log
+
+# Create a predictable error
+try:
+raise AttributeError, DummyAttribute
+except AttributeError:
+info = sys.exc_info()
+elog.raising(info)
+
+entries = elog.getLogEntries()
+entry_id = entries[0]['id']
+
+self.assertTrue(entry_id in self.log.buffer[-1].msg,
+(entry_id, self.log.buffer[-1].msg))
+
def testCleanup(self):
# Need to make sure that the __error_log__ hook gets cleaned up
self.app._delObject('error_log')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope] declarePublic function
On Tue, Jan 27, 2009 at 14:06, Milos Prudek pru...@bvx.cz wrote:
I would like to upgrade my site from Zope 2.7.x to Zope 2.10.x
When I try to run my site under Zope 2.10.x, I get this exception:
class JMZPTMacros:
File /home/orl/Zope/Products/JMZPTMacros/JMZPTMacros.py, line 28, in
JMZPTMacros
security.declarePublic()
TypeError: declarePublic() takes at least 2 arguments (1 given)
I need to use JMZPTMacros. It is an old product that seems to require a patch
to line 28. I can see that Zope 2.7.x defines declarePublic() as:
def declarePublic(self, *names):
and that Zope 2.10.x defines declarePublic() as:
def declarePublic(self, name, *names):
therefore I understand that one parameter is obligatory. But I cannot guess
what parameter it should be for JMZPTMacros. I tried to look how
declarePublic is used inside Zope but it gave me no clue.
declarePublic was never meant to be called without any names, hence
the signature change. Calling it without names is a bug in
JMZPTMacros. Most likely, the author meant to protect the method right
below that line.
To illustrate, the code probably looks something like:
security.declarePublic()
def someMethod(self, REQUEST):
Whatever
You put the name of that method in a string:
security.declarePublic('someMethod')
It could also be that the author assumed that not putting in a method
name meant that *all* methods on the class would be public. In that
case, you'll need to use declareObjectPublic() instead.
--
Martijn Pieters
___
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] declarePublic function
On Tue, Jan 27, 2009 at 16:31, Milos Prudek pru...@bvx.cz wrote: Actually, it does not look like that. It is not followed by method definition. Here is all the context: class JMZPTMacros: #All the ZPT Objects will be loaded as attributes of my #JMZPTMacros class security=ClassSecurityInfo() security.declarePublic() snip So, since there are many correct calls of declarePublic(), what does the incorrect (paremeter-less) call near the top of the class do? As the bottom of my email stated, use declareObjectPublic() in this case. The rest of the security calls are then somewhat redundant, probably put in because the first declarePublic didn't do what the author expected of it.. -- Martijn Pieters ___ 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-dev] Plans for Zope 2.12
On Sun, Jan 25, 2009 at 12:56, Dieter Maurer die...@handshake.de wrote: I plan to provide such a package as dm.ZClasses or (maybe) Zope2.ZClasses -- of course with some complaints against the Zope release management in the documentation: * cutting away useful features without any serious need * lacking commitment wrt backward compatibility * enforcing philosophical opinions (applications should be created programmatically not via configuration only (such as with ZClasses)) Oh, please come off it. You have checkin rights and could have stepped up to maintain the code. This is not about enforcing philosophical choices, this is about being pragmatic. If the feature was truely useful, more developers would be maintaining and fixing it. Obviously the complexity of keeping it working is outweighing it's usefulness. -- Martijn Pieters ___ 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-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Reverse searching order; start with the presumably smaller specific set and work our way up to larger and large
Log message for revision 94047:
Reverse searching order; start with the presumably smaller specific set and
work our way up to larger and larger docid sets. This makes intersecting faster
for most common index distributions.
Changed:
U Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 23:01:27 UTC (rev 94046)
+++ Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 10:42:56 UTC (rev 94047)
@@ -178,7 +178,7 @@
return IISet(self._unindex.keys())
results = None
-for i, comp in enumerate(comps):
+for i, comp in reversed(list(enumerate(comps))):
if not self._index.get(comp, {}).has_key(level+i): return IISet()
results = intersection(results, self._index[comp][level+i])
return results
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Merge r94047 from trunk: speed optimisation in path index searching order
Log message for revision 94048:
Merge r94047 from trunk: speed optimisation in path index searching order
Changed:
U
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified:
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 10:42:56 UTC (rev 94047)
+++ Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 10:44:26 UTC (rev 94048)
@@ -181,7 +181,7 @@
return IISet(self._unindex.keys())
results = None
-for i, comp in enumerate(comps):
+for i, comp in reversed(list(enumerate(comps))):
if not self._index.get(comp, {}).has_key(level+i): return IISet()
results = intersection(results, self._index[comp][level+i])
return results
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Merge r94047 from trunk: speed optimisation in path index searching order
Log message for revision 94049:
Merge r94047 from trunk: speed optimisation in path index searching order
Changed:
U
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified:
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 10:44:26 UTC (rev 94048)
+++ Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 10:45:29 UTC (rev 94049)
@@ -184,7 +184,7 @@
return IISet(self._unindex.keys())
results = None
-for i, comp in enumerate(comps):
+for i, comp in reversed(list(enumerate(comps))):
if not self._index.get(comp, {}).has_key(level+i): return IISet()
results = intersection(results, self._index[comp][level+i])
return results
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Shortcut the case where the path searched for is longer than anything indexed.
Log message for revision 94050:
Shortcut the case where the path searched for is longer than anything
indexed.
Changed:
U Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 10:45:29 UTC (rev 94049)
+++ Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 13:25:30 UTC (rev 94050)
@@ -173,6 +173,10 @@
for level in xrange(self._depth + 1)])
comps = filter(None, path.split('/'))
+
+if level + len(comps) - 1 self._depth:
+# Our search is for a path longer than anything in the index
+return IISet()
if len(comps) == 0:
return IISet(self._unindex.keys())
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Merge r94050 from trunk: shortcut for path-longer-than-anything-indexed case
Log message for revision 94051:
Merge r94050 from trunk: shortcut for path-longer-than-anything-indexed case
Changed:
U
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified:
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 13:25:30 UTC (rev 94050)
+++ Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 13:27:14 UTC (rev 94051)
@@ -176,6 +176,10 @@
for level in xrange(self._depth + 1)])
comps = filter(None, path.split('/'))
+
+if level + len(comps) - 1 self._depth:
+# Our search is for a path longer than anything in the index
+return IISet()
if len(comps) == 0:
return IISet(self._unindex.keys())
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Merge r94050 from trunk: shortcut for path-longer-than-anything-indexed case
Log message for revision 94052:
Merge r94050 from trunk: shortcut for path-longer-than-anything-indexed case
Changed:
U
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified:
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 13:27:14 UTC (rev 94051)
+++ Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-14 13:27:33 UTC (rev 94052)
@@ -179,6 +179,10 @@
for level in xrange(self._depth + 1)])
comps = filter(None, path.split('/'))
+
+if level + len(comps) - 1 self._depth:
+# Our search is for a path longer than anything in the index
+return IISet()
if len(comps) == 0:
return IISet(self._unindex.keys())
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py Simplify and cleanup the tests, including removing a double definition of the same test.
Log message for revision 94053:
Simplify and cleanup the tests, including removing a double definition of the
same test.
Changed:
U
Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
-=-
Modified:
Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
===
---
Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
2008-12-14 13:27:33 UTC (rev 94052)
+++
Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
2008-12-14 14:25:52 UTC (rev 94053)
@@ -24,21 +24,13 @@
class Dummy:
-
-meta_type=foo
-
def __init__( self, path):
self.path = path
def getPhysicalPath(self):
return self.path.split('/')
-def __str__( self ):
-return 'Dummy: %s' % self.path
-__repr__ = __str__
-
-
class PathIndexTests(unittest.TestCase):
Test PathIndex objects
@@ -81,7 +73,7 @@
self.assertEqual(self._index.numObjects() ,0)
self.assertEqual(self._index.getEntryForObject(1234), None)
self._index.unindex_object( 1234 ) # nothrow
-self.assertEqual(self._index._apply_index({suxpath:xxx}), None)
+self.assertEqual(self._index._apply_index(dict(suxpath=xxx)), None)
def testUnIndex(self):
self._populateIndex()
@@ -114,79 +106,49 @@
self._index.unindex_object(1)
def testRoot(self):
-
self._populateIndex()
-tests = ( (/,0, range(1,19)), )
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
+queries = (
+dict(path=dict(query='/', level=0)),
+dict(path=(('/', 0),)),
+)
+for q in queries:
+res = self._index._apply_index(q)
+self.assertEqual(list(res[0].keys()), range(1,19))
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':( (path,level),)}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
-def testRoot(self):
-
-self._populateIndex()
-tests = ( (/,0, range(1,19)), )
-
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':( (path,level),)}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
def testSimpleTests(self):
-
self._populateIndex()
tests = [
+# component, level, expected results
(aa, 0, [1,2,3,4,5,6,7,8,9]),
(aa, 1, [1,2,3,10,11,12] ),
(bb, 0, [10,11,12,13,14,15,16,17,18]),
-(bb, 1, [4,5,6,13,14,15] ),
-(bb/cc, 0, [16,17,18] ),
-(bb/cc, 1, [6,15] ),
-(bb/aa, 0, [10,11,12] ),
-(bb/aa, 1, [4,13] ),
-(aa/cc, -1, [3,7,8,9,12] ),
-(bb/bb, -1, [5,13,14,15] ),
-(18.html, 3, [18] ),
-(18.html, -1, [18] ),
-(cc/18.html, -1, [18] ),
-(cc/18.html, 2, [18] ),
+(bb, 1, [4,5,6,13,14,15]),
+(bb/cc, 0, [16,17,18]),
+(bb/cc, 1, [6,15]),
+(bb/aa, 0, [10,11,12]),
+(bb/aa, 1, [4,13]),
+(aa/cc, -1, [3,7,8,9,12]),
+(bb/bb, -1, [5,13,14,15]),
+(18.html, 3, [18]),
+(18.html, -1, [18]),
+(cc/18.html, -1, [18]),
+(cc/18.html, 2, [18]),
]
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
+for comp, level, results in tests:
+for path in [comp, /+comp, /+comp+/]:
+# Test with the level passed in as separate parameter
+res = self._index._apply_index(dict(path=
+dict(query=path, level=level)))
+self.assertEqual(list(res[0].keys()), results)
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res =
[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py Test cleanups from the trunk
Log message for revision 94054:
Test cleanups from the trunk
Changed:
U
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
-=-
Modified:
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
===
---
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
2008-12-14 14:25:52 UTC (rev 94053)
+++
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
2008-12-14 14:29:32 UTC (rev 94054)
@@ -24,21 +24,13 @@
class Dummy:
-
-meta_type=foo
-
def __init__( self, path):
self.path = path
def getPhysicalPath(self):
return self.path.split('/')
-def __str__( self ):
-return 'Dummy: %s' % self.path
-__repr__ = __str__
-
-
class PathIndexTests(unittest.TestCase):
Test PathIndex objects
@@ -81,7 +73,7 @@
self.assertEqual(self._index.numObjects() ,0)
self.assertEqual(self._index.getEntryForObject(1234), None)
self._index.unindex_object( 1234 ) # nothrow
-self.assertEqual(self._index._apply_index({suxpath:xxx}), None)
+self.assertEqual(self._index._apply_index(dict(suxpath=xxx)), None)
def testUnIndex(self):
self._populateIndex()
@@ -114,79 +106,49 @@
self._index.unindex_object(1)
def testRoot(self):
-
self._populateIndex()
-tests = ( (/,0, range(1,19)), )
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
+queries = (
+dict(path=dict(query='/', level=0)),
+dict(path=(('/', 0),)),
+)
+for q in queries:
+res = self._index._apply_index(q)
+self.assertEqual(list(res[0].keys()), range(1,19))
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':( (path,level),)}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
-def testRoot(self):
-
-self._populateIndex()
-tests = ( (/,0, range(1,19)), )
-
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':( (path,level),)}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
def testSimpleTests(self):
-
self._populateIndex()
tests = [
+# component, level, expected results
(aa, 0, [1,2,3,4,5,6,7,8,9]),
(aa, 1, [1,2,3,10,11,12] ),
(bb, 0, [10,11,12,13,14,15,16,17,18]),
-(bb, 1, [4,5,6,13,14,15] ),
-(bb/cc, 0, [16,17,18] ),
-(bb/cc, 1, [6,15] ),
-(bb/aa, 0, [10,11,12] ),
-(bb/aa, 1, [4,13] ),
-(aa/cc, -1, [3,7,8,9,12] ),
-(bb/bb, -1, [5,13,14,15] ),
-(18.html, 3, [18] ),
-(18.html, -1, [18] ),
-(cc/18.html, -1, [18] ),
-(cc/18.html, 2, [18] ),
+(bb, 1, [4,5,6,13,14,15]),
+(bb/cc, 0, [16,17,18]),
+(bb/cc, 1, [6,15]),
+(bb/aa, 0, [10,11,12]),
+(bb/aa, 1, [4,13]),
+(aa/cc, -1, [3,7,8,9,12]),
+(bb/bb, -1, [5,13,14,15]),
+(18.html, 3, [18]),
+(18.html, -1, [18]),
+(cc/18.html, -1, [18]),
+(cc/18.html, 2, [18]),
]
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
+for comp, level, results in tests:
+for path in [comp, /+comp, /+comp+/]:
+# Test with the level passed in as separate parameter
+res = self._index._apply_index(dict(path=
+dict(query=path, level=level)))
+self.assertEqual(list(res[0].keys()), results)
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py Test cleanups from the trunk
Log message for revision 94055:
Test cleanups from the trunk
Changed:
U
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
-=-
Modified:
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
===
---
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
2008-12-14 14:29:32 UTC (rev 94054)
+++
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/tests/testPathIndex.py
2008-12-14 14:30:03 UTC (rev 94055)
@@ -24,21 +24,13 @@
class Dummy:
-
-meta_type=foo
-
def __init__( self, path):
self.path = path
def getPhysicalPath(self):
return self.path.split('/')
-def __str__( self ):
-return 'Dummy: %s' % self.path
-__repr__ = __str__
-
-
class PathIndexTests(unittest.TestCase):
Test PathIndex objects
@@ -81,7 +73,7 @@
self.assertEqual(self._index.numObjects() ,0)
self.assertEqual(self._index.getEntryForObject(1234), None)
self._index.unindex_object( 1234 ) # nothrow
-self.assertEqual(self._index._apply_index({suxpath:xxx}), None)
+self.assertEqual(self._index._apply_index(dict(suxpath=xxx)), None)
def testUnIndex(self):
self._populateIndex()
@@ -114,79 +106,49 @@
self._index.unindex_object(1)
def testRoot(self):
-
self._populateIndex()
-tests = ( (/,0, range(1,19)), )
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
+queries = (
+dict(path=dict(query='/', level=0)),
+dict(path=(('/', 0),)),
+)
+for q in queries:
+res = self._index._apply_index(q)
+self.assertEqual(list(res[0].keys()), range(1,19))
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':( (path,level),)}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
-def testRoot(self):
-
-self._populateIndex()
-tests = ( (/,0, range(1,19)), )
-
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':( (path,level),)}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
-
def testSimpleTests(self):
-
self._populateIndex()
tests = [
+# component, level, expected results
(aa, 0, [1,2,3,4,5,6,7,8,9]),
(aa, 1, [1,2,3,10,11,12] ),
(bb, 0, [10,11,12,13,14,15,16,17,18]),
-(bb, 1, [4,5,6,13,14,15] ),
-(bb/cc, 0, [16,17,18] ),
-(bb/cc, 1, [6,15] ),
-(bb/aa, 0, [10,11,12] ),
-(bb/aa, 1, [4,13] ),
-(aa/cc, -1, [3,7,8,9,12] ),
-(bb/bb, -1, [5,13,14,15] ),
-(18.html, 3, [18] ),
-(18.html, -1, [18] ),
-(cc/18.html, -1, [18] ),
-(cc/18.html, 2, [18] ),
+(bb, 1, [4,5,6,13,14,15]),
+(bb/cc, 0, [16,17,18]),
+(bb/cc, 1, [6,15]),
+(bb/aa, 0, [10,11,12]),
+(bb/aa, 1, [4,13]),
+(aa/cc, -1, [3,7,8,9,12]),
+(bb/bb, -1, [5,13,14,15]),
+(18.html, 3, [18]),
+(18.html, -1, [18]),
+(cc/18.html, -1, [18]),
+(cc/18.html, 2, [18]),
]
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-{path:{'query':path,level:level}})
-lst = list(res[0].keys())
-self.assertEqual(lst,results)
+for comp, level, results in tests:
+for path in [comp, /+comp, /+comp+/]:
+# Test with the level passed in as separate parameter
+res = self._index._apply_index(dict(path=
+dict(query=path, level=level)))
+self.assertEqual(list(res[0].keys()), results)
-for comp,level,results in tests:
-for path in [comp,/+comp,/+comp+/]:
-res = self._index._apply_index(
-
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Obviously the level 0 case has been implemented before the index was merged into CVS trunk 8 years ago..
Log message for revision 94019: Obviously the level 0 case has been implemented before the index was merged into CVS trunk 8 years ago.. Changed: U Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py -=- Modified: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py === --- Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py 2008-12-13 13:46:17 UTC (rev 94018) +++ Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py 2008-12-13 14:12:47 UTC (rev 94019) @@ -158,7 +158,7 @@ a tuple (path,level). level = 0 starts searching at the given level -level 0 not implemented yet +level 0 match at *any* level if isinstance(path, str): level = default_level ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py bviously the level 0 case has been implemented before the index was merged
Log message for revision 94020: bviously the level 0 case has been implemented before the index was merged into CVS trunk 8 years ago.. Changed: U Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py -=- Modified: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py === --- Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py 2008-12-13 14:12:47 UTC (rev 94019) +++ Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py 2008-12-13 14:14:05 UTC (rev 94020) @@ -161,7 +161,7 @@ a tuple (path,level). level = 0 starts searching at the given level -level 0 not implemented yet +level 0 match at *any* level if isinstance(path, str): level = default_level ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Obviously the level 0 case has been implemented before the index was merged
Log message for revision 94021: Obviously the level 0 case has been implemented before the index was merged into CVS trunk 8 years ago.. Changed: U Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py -=- Modified: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py === --- Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py 2008-12-13 14:14:05 UTC (rev 94020) +++ Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py 2008-12-13 14:14:38 UTC (rev 94021) @@ -163,7 +163,7 @@ a tuple (path,level). level = 0 starts searching at the given level -level 0 not implemented yet +level 0 match at *any* level if isinstance(path, StringType): ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml Remove incorrect statement; the whole path is indexed, including the object id.
Log message for revision 94030: Remove incorrect statement; the whole path is indexed, including the object id. Changed: U Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml -=- Modified: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml === --- Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml 2008-12-13 15:17:09 UTC (rev 94029) +++ Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml 2008-12-13 15:29:03 UTC (rev 94030) @@ -9,7 +9,7 @@ a catalog. It allows you to search for objects beginning or containing a special path component or a set of path component. A path component is defined as em/lt;component1gt;/lt;component2gt;//lt;object_idgt; -/em. Note: the emobject_id/em will unot/u be indexed by the PathIndex. +/em. /p ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml Remove incorrect statement; the whole path is indexed, including the object id.
Log message for revision 94031: Remove incorrect statement; the whole path is indexed, including the object id. Changed: U Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml -=- Modified: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml === --- Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml 2008-12-13 15:29:03 UTC (rev 94030) +++ Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml 2008-12-13 15:30:01 UTC (rev 94031) @@ -9,7 +9,7 @@ a catalog. It allows you to search for objects beginning or containing a special path component or a set of path component. A path component is defined as em/lt;component1gt;/lt;component2gt;//lt;object_idgt; -/em. Note: the emobject_id/em will unot/u be indexed by the PathIndex. +/em. /p ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml Remove incorrect statement; the whole path is indexed, including the object id.
Log message for revision 94032: Remove incorrect statement; the whole path is indexed, including the object id. Changed: U Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml -=- Modified: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml === --- Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml 2008-12-13 15:30:01 UTC (rev 94031) +++ Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/dtml/addPathIndex.dtml 2008-12-13 15:30:35 UTC (rev 94032) @@ -9,7 +9,7 @@ a catalog. It allows you to search for objects beginning or containing a special path component or a set of path component. A path component is defined as em/lt;component1gt;/lt;component2gt;//lt;object_idgt; -/em. Note: the emobject_id/em will unot/u be indexed by the PathIndex. +/em. /p ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Port improvements from ExtendedPathIndex:
Log message for revision 94034:
Port improvements from ExtendedPathIndex:
- The level 0 case is basically the union of all searches for levels 0
through to max. Just call search() for each level and use multiunion on all the
results.
- Shorten the 'no-such-path' detection to one test.
Changed:
U Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified: Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 18:00:10 UTC (rev 94033)
+++ Zope/trunk/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 18:46:10 UTC (rev 94034)
@@ -21,7 +21,7 @@
from OFS.SimpleItem import SimpleItem
from BTrees.IOBTree import IOBTree
from BTrees.OOBTree import OOBTree
-from BTrees.IIBTree import IITreeSet, IISet, intersection, union
+from BTrees.IIBTree import IITreeSet, IISet, intersection, union, multiunion
from BTrees.Length import Length
from zope.interface import implements
@@ -165,6 +165,12 @@
else:
level = int(path[1])
path = path[0]
+
+if level 0:
+# Search at every level, return the union of all results
+return multiunion(
+[self.search(path, level)
+ for level in xrange(self._depth + 1)])
comps = filter(None, path.split('/'))
@@ -172,22 +178,9 @@
return IISet(self._unindex.keys())
results = None
-if level = 0:
-for i, comp in enumerate(comps):
-if not self._index.has_key(comp): return IISet()
-if not self._index[comp].has_key(level+i): return IISet()
-results = intersection(results, self._index[comp][level+i])
-
-else:
-for level in range(self._depth + 1):
-ids = None
-for i, comp in enumerate(comps):
-try:
-ids = intersection(ids, self._index[comp][level+i])
-except KeyError:
-break
-else:
-results = union(results, ids)
+for i, comp in enumerate(comps):
+if not self._index.get(comp, {}).has_key(level+i): return IISet()
+results = intersection(results, self._index[comp][level+i])
return results
def numObjects(self):
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Port improvements from ExtendedPathIndex:
Log message for revision 94035:
Port improvements from ExtendedPathIndex:
- The level 0 case is basically the union of all searches for levels 0
through to max. Just call search() for each level and use multiunion on all
the results.
- Shorten the 'no-such-path' detection to one test.
Changed:
U
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified:
Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 18:46:10 UTC (rev 94034)
+++ Zope/branches/2.11/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 18:48:01 UTC (rev 94035)
@@ -21,7 +21,7 @@
from OFS.SimpleItem import SimpleItem
from BTrees.IOBTree import IOBTree
from BTrees.OOBTree import OOBTree
-from BTrees.IIBTree import IITreeSet, IISet, intersection, union
+from BTrees.IIBTree import IITreeSet, IISet, intersection, union, multiunion
from BTrees.Length import Length
from zope.interface import implements
@@ -168,6 +168,12 @@
else:
level = int(path[1])
path = path[0]
+
+if level 0:
+# Search at every level, return the union of all results
+return multiunion(
+[self.search(path, level)
+ for level in xrange(self._depth + 1)])
comps = filter(None, path.split('/'))
@@ -175,22 +181,9 @@
return IISet(self._unindex.keys())
results = None
-if level = 0:
-for i, comp in enumerate(comps):
-if not self._index.has_key(comp): return IISet()
-if not self._index[comp].has_key(level+i): return IISet()
-results = intersection(results, self._index[comp][level+i])
-
-else:
-for level in range(self._depth + 1):
-ids = None
-for i, comp in enumerate(comps):
-try:
-ids = intersection(ids, self._index[comp][level+i])
-except KeyError:
-break
-else:
-results = union(results, ids)
+for i, comp in enumerate(comps):
+if not self._index.get(comp, {}).has_key(level+i): return IISet()
+results = intersection(results, self._index[comp][level+i])
return results
def numObjects(self):
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py Port improvements from ExtendedPathIndex:
Log message for revision 94036:
Port improvements from ExtendedPathIndex:
- The level 0 case is basically the union of all searches for levels 0
through to max. Just call search() for each level and use multiunion on all
the results.
- Shorten the 'no-such-path' detection to one test.
Changed:
U
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
-=-
Modified:
Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
===
--- Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 18:48:01 UTC (rev 94035)
+++ Zope/branches/2.10/lib/python/Products/PluginIndexes/PathIndex/PathIndex.py
2008-12-13 18:48:34 UTC (rev 94036)
@@ -22,7 +22,7 @@
from OFS.SimpleItem import SimpleItem
from BTrees.IOBTree import IOBTree
from BTrees.OOBTree import OOBTree
-from BTrees.IIBTree import IITreeSet, IISet, intersection, union
+from BTrees.IIBTree import IITreeSet, IISet, intersection, union, multiunion
from BTrees.Length import Length
from zope.interface import implements
@@ -171,6 +171,12 @@
else:
level = int(path[1])
path = path[0]
+
+if level 0:
+# Search at every level, return the union of all results
+return multiunion(
+[self.search(path, level)
+ for level in xrange(self._depth + 1)])
comps = filter(None, path.split('/'))
@@ -178,22 +184,9 @@
return IISet(self._unindex.keys())
results = None
-if level = 0:
-for i, comp in enumerate(comps):
-if not self._index.has_key(comp): return IISet()
-if not self._index[comp].has_key(level+i): return IISet()
-results = intersection(results, self._index[comp][level+i])
-
-else:
-for level in range(self._depth + 1):
-ids = None
-for i, comp in enumerate(comps):
-try:
-ids = intersection(ids, self._index[comp][level+i])
-except KeyError:
-break
-else:
-results = union(results, ids)
+for i, comp in enumerate(comps):
+if not self._index.get(comp, {}).has_key(level+i): return IISet()
+results = intersection(results, self._index[comp][level+i])
return results
def numObjects(self):
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 11:28, Malthe Borch mbo...@gmail.com wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. The C extension is required to make messageids immutable. Because they are immutable, the security machinery can treat them as rocks, e.g. safe to pass around. Removing the C-extension undoes this, as you cannot make truely immutable. See the original proposal: http://wiki.zope.org/zope3/TurningMessageIDsIntoRocks I'm sure Phillip and Jim can clarify the security implications of undoing this work. -- Martijn Pieters ___ 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] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 17:01, Jim Fulton j...@zope.com wrote: On Dec 12, 2008, at 6:28 AM, Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. I object. Please drop it. I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. -- Martijn Pieters ___ 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] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 18:51, Martijn Faassen faas...@startifact.com wrote: Unless it can be clearly demonstrated that the new method is equivalent in both performance and security, talk of dropping the C extension seems somewhat premature. A pure Python fallback for this module would however be interesting to everybody, I think. There is one already. However, it isn't immutable and thus a security risk. -- Martijn Pieters ___ 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] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 18:37, Zvezdan Petkovic [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 2:22 AM, Michael Howitz [EMAIL PROTECTED] wrote: Log message for revision 93766: color by default This setting apparently causes problems for people who use Emacs, so for zope. and zc. packages at least, we don't use --auto-color. That argument is really lame. Should we now go back to VT100 terminals because _some_ Emacs users are annoyed that ANSI colors break their shell window display? Is there no way auto-color can set as be a local default in a configuration file in your $HOME or something? Then everyone can make their own choices instead of having them made for them. -- Martijn Pieters ___ 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] Building a site tree with the ZCatalog
On Tue, Oct 21, 2008 at 17:22, Andreas Jung [EMAIL PROTECTED] wrote: Look at the ExtendedPathIndex implementation of Plone (can be used outside Plone). And how do you think ExtendedPathIndex help with sorting here? In this case, some custom sorting would be required in a python method or view. -- Martijn Pieters ___ 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] Building a site tree with the ZCatalog
On Tue, Oct 21, 2008 at 17:50, Andreas Jung [EMAIL PROTECTED] wrote: Code-solving-everything does not fall from the sky. EPI likely the best starting point for solving the problem. But what the EPI offers over the regular path index has no bearing on Nico's problem. -- Martijn Pieters ___ 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] Building a site tree with the ZCatalog
On Tue, Oct 21, 2008 at 18:10, Andreas Jung [EMAIL PROTECTED] wrote: You have to split the complete processing over several EPI queries where a single query returns all elements with level=1 for a particular subfolder. You can sort_on='position' within each query. And paste the results in some way together. Nobody said that EPI would solve the problem out-of-the-box :-) Right, so with sufficient levels you end up with a *lot* of queries. Why not just query for the whole lot and use one method that returns a (path, position) tuple for a given item, and pass that to the sort function as the key keyword? Should be a lot better performing. -- Martijn Pieters ___ 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-dev] Failing Zope 2.8 / Python 2.3 tests on your box
On Fri, Aug 29, 2008 at 14:05, Stefan H. Holek [EMAIL PROTECTED] wrote: What I have found out now is that in my Python 2.3.6 encodings/ __init__.py does not contain 'import aliases' at module level, whereas the Python 2.4 lib has this import. The patch does this: import encodings encodings._aliases = encoding.aliases.aliases which does therefore not work in 2.3. So, now I am curious how your Python 2.3 differs, and why you don't see the error locally :-) The 1.1 version of the hotfix corrected this. -- Martijn Pieters ___ 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] CorruptedDataError: How to fix a corrupted
On Fri, Aug 1, 2008 at 7:01 PM, Remy Pinsonnault [EMAIL PROTECTED] wrote: I tried fsdump but it did not work I got a FileStorageFormatError... You only get that error if a) the first four bytes of the file are not 'FS21', or b) the file is smaller than 4 bytes. Are you sure you were trying this on the corrupted Data.fs? If so, you may have a bigger problem on your hands. Is there any other way I can obtain the needed paramater (position) for the truncate function where the CorruptedDataError occured? The exception included the position: 10020462. I just advised you to double-check it. Another question, is there a way of extracting all data or transaction between two dates? Take a look at what fsdump.py does, it uses a FileIterator to list all transactions in the Data.fs. The returned objects (RecordIterators) represent the transactions and you can iterate over these to pull out all data associated with the transaction. Each transaction id is based on the timestamp (use ZODB.TimeStamp.TimeStamp to decode it) so it should be but a small job to extract everything between two given dates. See the sourcecode for fsdump.py and FileStorage.py in ZODB/FileStorage. -- Martijn Pieters ___ 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] CorruptedDataError: How to fix a corrupted
On Thu, Jul 31, 2008 at 10:48 PM, Remy Pinsonnault [EMAIL PROTECTED] wrote: For an unknown reason, it seems our data.fs got corrupted last night. In the event.log I can see the following: CorruptedDataError: Error reading oid 0x086540. Found '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' at 10020462 You have 2 pieces of info there, the oid and the file position. You could use fsdump to verify the oid and position, then truncate the file at that position. Short recipe (may be outdated a bit) of the procedure: http://kelpi.com/script/018315 I certainly have performed truncations like that in the past. -- Martijn Pieters ___ 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] VirtualHostMonster: access to all content in instance
On Fri, Jul 4, 2008 at 3:03 PM, Jonas Meurer [EMAIL PROTECTED] wrote: But both project1 and project3 are also accessible through project2.com over the URLs http://www.project2.com/project1; and http://www.project3.com/project3;. Is this a known issue? I consider that as a quite serious bug, as both project1 and project3 might be private and should not be published over the globally available apache rewriterule. This is expected behaviour, you are seeing Acquisition at work. Do not rely on VirtualHostMonster to provide security, it only provides URL rewriting services. -- Martijn Pieters ___ 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] zopectlsock missing
On Wed, Jun 11, 2008 at 3:28 PM, Peter Bengtsson [EMAIL PROTECTED] wrote: This happens from time to time and I've never really understood how it ends up like this. There's no zopeinstance/var/zopectlsock socket which means that zopectl stop|restart|start just spits out daemon manager not running When in fact, Zope is running. It's there when you run `netstat -nptl` and you can go to the. If I do go in to http://localhost:8080/Control_Panel/manage_main and Shutdown the next time I'll be able to use zopectl happily. Does anybody know what's going on with and why it goes missing? I have a vague suspicion that it might have something to do with my init.d restart script and rebooting of the server but I could be wrong. If this in a buildout, then you you ran bin/buildout which nuked your parts/instance directory with the socket. This is a bug in zope2instance where it sets the CLIENT_HOME to parts/instance instead of a part-specific subdirectory of var/ -- Martijn Pieters ___ 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] zopectlsock missing
On Wed, Jun 11, 2008 at 4:34 PM, Martijn Pieters [EMAIL PROTECTED] wrote: If this in a buildout, then you you ran bin/buildout which nuked your parts/instance directory with the socket. This is a bug in zope2instance where it sets the CLIENT_HOME to parts/instance instead of a part-specific subdirectory of var/ To clarify, recent versions of zope2instance do set CLIENT_HOME correctly, as well as set specific pid-filename and lock-filename options outside of the parts/instance directory. -- Martijn Pieters ___ 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] Squid ESI
On Sun, Jun 1, 2008 at 7:37 AM, Luciano Ramalho [EMAIL PROTECTED] wrote: I'm reviving this thread from 2006 hoping to hear news about current ESI usage in the Zope community. Has anyone since then had success deploying sites with ESI-enabled caching? Using Squid, Varnish or any other product? Lovely systems did a talk touching upon this subject about this last year at EP2007: http://plone.tv/media/689203036/view http://www.zope.de/redaktion/dzug/tagung/potsdam-2007/folien/potsdam-zope3-performance.pdf/download They also blogged about their SSI solution: http://valentinewebsystems.com/topics/ssi Here's the relevant README (pretty parse): http://svn.zope.org/lovely.remoteinclude/trunk/src/lovely/remoteinclude/README.txt?rev=76474view=auto -- Martijn Pieters ___ 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-dev] Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On Tue, May 20, 2008 at 3:39 PM, Christian Zagrodnick [EMAIL PROTECTED] wrote: If you determine beforehand which strings are translatable (end up as msgid objects) it should be trivial to extract these. You will have to update i18ndude to add new zcml tags though. What's translatable and what not is defined by the schema of the configuration which can be extended by any package. So adding this information to the extractor would duplicate it. Not good. But extracting that information may be prohibitively difficult and expensive to do. -- Martijn Pieters ___ 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: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On Sat, May 10, 2008 at 3:40 PM, Hanno Schlichting [EMAIL PROTECTED] wrote: Currently i18ndude doesn't extract any messages from ZCML. It is used for extraction of all messages for the Plone project which happens to use lots of ZCML. But none of the messages defined in ZCML are actually used in any user visible part of the whole application. So even if you are a Zope project, I think there's very good reasons not to require ZCML extraction. Although the ZMI may not count as a 'user visible' part, Generic Setup profile titles do show up there, which are defined in ZCML and should be translatable. Also, these days it is possible to register content views (such as the default view for a folder) through ZCML, using a menu directive for the title. Again these titles should be translatable. -- Martijn Pieters ___ 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: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: zcml is a pretty simple format though: xml with only human readable text in title and description attributes (and perhaps a few others) and the translation domain specified in a i18n_domain attribute. It should be quite trivial to extract that data without having to pull all of zope in. If you determine beforehand which strings are translatable (end up as msgid objects) it should be trivial to extract these. You will have to update i18ndude to add new zcml tags though. -- Martijn Pieters ___ 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] first attempt to use RELSTORAGE
On Fri, May 9, 2008 at 6:05 PM, David Bear [EMAIL PROTECTED] wrote: I installed relstorage using the instructions for easy_setup, i.e. 'easy_install RelStorage'. I realized as I read through more of the instructions that this likely put the relstorage modules in my python home rather than in my zope software home. I don't know if this would have caused the error I am seeing. Probably. RelStorage declares a dependency on ZODB, and likely an incompatible version has been installed in your python's site-packages directory. Remove the RelStorage, ZODB and any zope-related eggs from your python site-packages directory to remove. Better to not use easy_install for your Zope2 install, as Zope2 doesn't (yet) declare that it already *has* ZODB included. Just install RelStorage in your instance home lib/python directory. Note that RelStorage requires you to patch your Zope installation! -- Martijn Pieters ___ 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] AJAX / HTML Fragment
On Mon, Apr 21, 2008 at 8:17 PM, SpiderX [EMAIL PROTECTED] wrote: I'm writing my website to use AJAX for form posting and displaying content, and instead of using AJAX to parse XML and then update the DOM, I'm using Zope to create an HTML fragment and AJAX just writes it to the correct location on the page. It works really great for what I'm doing, but the only problem is that I get an error message: Error: no element found Source File: http://myzopesite:8080/mywebsite/zz/NewNote Line: 1 Use Firefox and Firebug or LiveHTTPHeaders to see exactly what is going over the wire; you can also use command line tools like curl to recreate the request to debug what is going on on the zope and browser sides. Zope itself has very little to do with Javascript; once it serves the JS all the requests look the same to Zope regardless of how they were generated. -- Martijn Pieters ___ 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-dev] Proposal: Merge philikon-aq branch into Zope trunk
On Thu, Apr 17, 2008 at 12:27 PM, Hanno Schlichting [EMAIL PROTECTED] wrote: I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems. Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. Opinions, votes? +sys.maxint! Thanks, Hanno, for carrying this to it's completion! -- Martijn Pieters ___ 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] straighting out the SQLAlchemy integration mess
On Tue, Apr 8, 2008 at 11:54 PM, Martijn Faassen [EMAIL PROTECTED] wrote: All of these are in various states of brokenness. z3c.zalchemy doesn't work with SQLAlchemy trunk. collective.lead works with it, but only if you check out a particular branch, and not with sqlite. Quite possibly z3c.sqlalchemy has a release that actually works. One out of three is not bad... :) We are going into production with collective.lead and are committed to releasing the 1.0 branch as 1.0. sqlite works just great for us, we use it to run unit tests and for developers that just need to adjust the styling and such. The production environment will run against Oracle. There must be a reason for this proliferation of approaches. What is it? We all get along, don't we? I know that the various packages are taking code and approaches from each other too. Different use-cases and philosophies of development. In the end, I hope we will end up with just *one* integration layer, that is released, that works with Zope 2 and Zope 3 and a recent release of SQLAlchemy, that is documented, and that people know about. We can then offer packages on top of this that offer extra features. Sounds like a good idea. -- Martijn Pieters ___ 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] Non-ASCII characters in URLs
On Mon, Apr 7, 2008 at 1:37 AM, Alexander Limi [EMAIL PROTECTED] wrote: Is there a good technical explanation for why Zope doesn't allow non-ASCII characters in URLs? Because URLs don't allow non-ASCII characters? I'd like to be able to let URLs work like this example from Wikipedia: http://ja.wikipedia.org/wiki/メインページ Your browser translates that into http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 Is there a fundamental reason (ie. Python objects can only be ASCII) or is it simply bugs that need to be fixed? RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) doesn't allow non-ascii characters in URLs. No corresponding graphic US-ASCII: URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded. Now, Zope could well support UTF-8 ids, and translate URLs appropriately, but in the meantime you could use the same scheme? -- Martijn Pieters ___ 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: zope.sendmail Retry fixes and new state machine.
On Mon, Mar 10, 2008 at 6:09 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: The fact that something is popular does not necessarily mean it is the right thing :) Lack of isolation is a very convincing argument to me. Perhaps more personal taste but I also find python unittests to be much more readable. You don't suffer from mixing lots of test setup/teardown being repeated through the file. As Tres mentioned this is especially true when testing corner cases. Being able to debug tests by stepping over them with pdb is incredibly useful. With doctests that doesn't work. Being able to run a single test easily allows for quick testing and debugging. I can't tell the testrunner 'start running at line 52 but also include all the test setup magic from before, but skip the rest'. With unittests I can simple run zopectl test -s module -t test function. doctests hurt my productivity badly. I completely agree with Tres' and Wichert's statements on this. I only use doctests where they actually would make sense as documentation, the corner cases I always write as unit tests. The tools for dealing with pure Python code are so much more powerful than for python-embedded-in-text-with-prefixes, as well. -- Martijn Pieters ___ 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] Cant access 'real' root folder in ZMI
On Jan 30, 2008 4:07 AM, [EMAIL PROTECTED] wrote: However, both these methods lead me straight to the plone website, not to the Zope Quick Start page and while i can access the ZMI from plone, serverA:8080/manage or www.me.com/managae, the root folder shown there is the plone site's root folder. Even when i stop apache and access through servera:8080 i still get the plone site. Sounds like either an AccessRule or the VirtualHostMonster (VHM) is putting you into Plone directly. You can disable both AccessRules and the VHM by an environment variable or with a URL path element: - set the SUPPRESS_ACCESSRULE environment var - add _SUPPRESS_ACCESSRULE to your URL. So http://servera:8080/_SUPPRESS_ACCESSRULE should solve this for you; double check your VHM configuration if this works, it should be empty. -- Martijn Pieters ___ 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] ZMI in zope 2.10.5 broken
On Jan 28, 2008 4:54 PM, quizzical [EMAIL PROTECTED] wrote: Module TreeDisplay.TreeTag, line 337, in tpRenderTABLE Module zlib, line 38, in compress NameError: global name 'util' is not defined The error occurs in the 'zlib' module, which is not part of Zope, but a python library. Moreover, on my python installs, this is a C extension library, not pure python.. From what I can tell from this traceback, it appears you have a rogue zlib library on your path somewhere, Zope 2.10.5 certainly doesn't include it. -- Martijn Pieters ___ 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 )
