[Zope-dev] Zope Tests: 3 OK, 3 Failed
Summary of messages to the zope-tests list. Period Sun Dec 7 12:00:00 2008 UTC to Mon Dec 8 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=7) : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 7 20:29:11 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010612.html Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 7 20:30:42 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010613.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sun Dec 7 20:32:12 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010614.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sun Dec 7 20:24:41 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010609.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 7 20:26:11 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010610.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 7 20:27:41 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010611.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plone/Zeocluster performances problems
Hi, Configuration of Zope is a pain. Take a first look there: http://blip.tv/file/315714 Apache in your case is not the problem. I think this is your zope configuration (only one thread per instance is a good thing). Try a different configuration for session. you can expect to see a ConflictError if your page take more than 20 seconds to be computed. zserver-threads 1 maximum-number-of-session-objects 1 session-timeout-minutes 60 session-resolution-seconds 600 For the portal_transform, lynx is used to make html2text and index the content of type like document. Its better to get it but it this kind of log doesn't matter. I have never seen instance stop by themselve without logs i can't help you on that point. JeanMichel FRANCOIS Service TICE a écrit : Hello After many searches I’m stuck on several problems, I hope you guys can help me :) I’m using Plone as institutional webportal (Zope 2.9.8-final, python 2.4.4) with python 2.4.4. The portal runs a zeocluster with 4 production instances, 3 threads each, and 1 admin instance (in debug mode). All instances share the same ZODB and data.fs on local drive. We use Apache 2 and a STICKY_ROUTE cookie to redirect user to the instance he's logged to. We use SSO authentification (CAS) with PloneCASLogin 2.5.0. Apache configuration: ## Default Virtual Host Configuration Listen xxx.xxx.xxx:80 NameVirtualHost xxx.xxx.xxx:80 VirtualHost xxx.xxx.xxx:80 ServerName xxx.xxx.xxx ServerAdmin [EMAIL PROTECTED] Proxy balancer://lb BalancerMember http://xxx.xxx.xxx:8080 route=8080 BalancerMember http://xxx.xxx.xxx:8081 route=8081 BalancerMember http://xxx.xxx.xxx:8082 route=8082 BalancerMember http://xxx.xxx.xxx:8083 route=8083 /Proxy # conditional proxy pass ProxyPass / balancer://lb/VirtualHostBase/http/xxx.xxx.xxx: 80/plone/VirtualHostRoot/ stickysession=STICKY_ROUTE #LOGS #LogLevel debug ServerAlias * CustomLog /opt/apache2/xxx.xxx.xxx.log combined /VirtualHost We noticed that, sometimes, users are not redirected to right instance, so we decided to use the same temporary_folder for all instances and users are connected to the 4 instances at same time. But this modification causes errors like this one from my event.log file: 2008-11-26T10:45:23 INFO ZPublisher.Conflict ConflictError at / VirtualHostBase/http/X.fr:80//VirtualHostRoot/Cours/ Cours.X.4424/fichiersan_X.2530/cours_supports_affichage: database conflict error (oid 0x2571, class BTrees._OOBTree.OOBTree, serial this txn started with 0x037a24a416ae79bb 2008-11-26 09:40:05.315987, serial currently committed 0x037a24a95ee0d788 2008-11-26 09:45:22.237099) (1 conflicts (0 unresolved) since startup at Wed Nov 26 10:43:19 2008) and this one from plone's error_log: Request URL http://XX.fr/Members/X/Cours/Cours.X.4648/cours_attacher_template Exception Type database conflict error (oid 0x1247, class BTrees._OOBTree.OOBTree, serial this txn started with 0x037a1ffe66682b66 2008-11-25 13:50:24.001620, serial currently committed 0x037a1ffeae62ca44 2008-11-25 13:50:40.871695) Exception Value database conflict error (oid 0x1247, class BTrees._OOBTree.OOBTree, serial this txn started with 0x037a1ffe66682b66 2008-11-25 13:50:24.001620, serial currently committed 0x037a1ffeae62ca44 2008-11-25 13:50:40.871695) Traceback (innermost last): * Module Zope2.App.startup, line 173, in zpublisher_exception_hook * Module ZPublisher.Publish, line 121, in publish * Module Zope2.App.startup, line 240, in commit * Module transaction._manager, line 96, in commit * Module transaction._transaction, line 380, in commit * Module transaction._transaction, line 378, in commit * Module transaction._transaction, line 436, in _commitResources * Module ZODB.Connection, line 665, in tpc_vote * Module ZEO.ClientStorage, line 893, in tpc_vote * Module ZEO.ClientStorage, line 877, in _check_serials ConflictError: database conflict error (oid 0x1247, class BTrees._OOBTree.OOBTree, serial this txn started with 0x037a1ffe66682b66 2008-11-25 13:50:24.001620, serial currently committed 0x037a1ffeae62ca44 2008-11-25 13:50:40.871695) From what I understand, there's a conflict in my database when user wants to access an object. I assume it's related to the temporary_folder sharing modification because errors appeared after it. Is there a way to resolve this error? Is there inconvenient to share temporary_folder? Should I stop it? My second problem, found in the event.log: 2008-11-26T10:45:28 ERROR PortalTransforms Cannot register transform lynx_dump, using BrokenTransform: Error Unable
Re: [Zope-dev] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. The revision also disabled nailed versions which is required to keep the buildout reproducible. I've fixed all this in r93784. -- Benji York Senior Software Engineer Zope Corporation ___ 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: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 8, 2008, at 9:02 AM, Benji York wrote: On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Gary ___ 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] z3c.form 2.0 release
Hello,
Coverage seems to burp on chameleon
File /home/adi/z3c.form/src/z3c/form/tests/../adding.txt, line 13, in
adding.txt
Failed example:
testing.setupFormDefaults()
Exception raised:
Traceback (most recent call last):
File
/home/adi/.buildout/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/doctest.py,
line 1356, in __run
compileflags, 1) in test.globs
File doctest adding.txt[1], line 1, in module
testing.setupFormDefaults()
File /home/adi/z3c.form/src/z3c/form/testing.py, line 226, in
setupFormDefaults
widget.WidgetTemplateFactory(getPath('text_input.pt'), 'text/html'),
File /home/adi/z3c.form/src/z3c/form/widget.py, line 399, in __init__
filename, content_type=contentType)
File
/home/adi/.buildout/eggs/z3c.pt-1.0b4-py2.5.egg/z3c/pt/pagetemplate.py, line
70, in __init__
self, filename, **kwargs)
File
/home/adi/.buildout/eggs/chameleon.zpt-1.0b4-py2.5.egg/chameleon/zpt/template.py,
line 25, in __init__
doctype, **kwargs)
File
/home/adi/.buildout/eggs/chameleon.core-1.0b9-py2.5.egg/chameleon/core/template.py,
line 124, in __init__
self.registry = filecache.TemplateCache(filename)
File
/home/adi/.buildout/eggs/chameleon.core-1.0b9-py2.5.egg/chameleon/core/filecache.py,
line 9, in __init__
self.load()
File
/home/adi/.buildout/eggs/chameleon.core-1.0b9-py2.5.egg/chameleon/core/filecache.py,
line 37, in load
self.registry = pickle.load(f)
ImportError: No module named translation
Monday, December 8, 2008, 8:27:01 AM, you wrote:
SR On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a
list with textline value type), and are wondering whether to roll our
own or wait for a new z3c.form release.
SR I am considering the code feature complete. I would like to get confirmation
SR from people that (a) the z3c.pt integration works well and (b) the object
SR widget is useful. Oh yes, and since I have not done the development, are we
SR 100% test covered?
SR BTW, at Keas we are currently using z3c.form trunk and it all looks okay.
SR Regards,
SR Stephan
--
Best regards,
Adam GROSZERmailto:[EMAIL PROTECTED]
--
Quote of the day:
Our scientific power has outrun our spiritual power. We have guided missiles
and misguided men.
- Martin Luther King, Jr.
___
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] z3c.form 2.0 release
2008/12/8 Adam GROSZER [EMAIL PROTECTED]: Coverage seems to burp on chameleon I just tried a buildout in newest mode and I did not see the error you pasted. It's important that the CHAMELEON_CACHE flag be set to '0' in an automated test setup (this is set in the buildout for the test runner). Note that I did get some test errors when running the tests, one seems to happen with and without z3c.pt enabled, but some others are output-related. \malthe ___ 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: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster [EMAIL PROTECTED] wrote: On Dec 8, 2008, at 9:02 AM, Benji York wrote: On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Nope, the tests will pass in the zope.testbrowser buildout. However, if a testbrowser user for some reason run the testbrowser tests outside of its buildout, then you're right, they may see a failure if their versions aren't new enough. At that point I would hope they would read the CHANGES.txt and see that a new version is required. The trade off is in requiring people to upgrade a dependency in order to get a bug fix that they may not care about. In the large, this is the problem with specifying versions in setup.py. Doing so assumes too much about how people are using all the dependencies involved. Here's a scenario: I fix a bug in some package, it depends on a newer version of say, zope.publisher. I put that requirement in my package's setup.py. A user of my package upgrades to get an unrelated bug fix and is forced to use the newer zope.publisher. It so happens that that the new version of zope.publisher has a different bug that bites them. They now are in a bad spot. If the setup.py hadn't specified a version then the programmer could have constructed a set of versions that didn't exhibit any bugs that bite them, but they're precluded from doing that. -- Benji York Senior Software Engineer Zope Corporation ___ 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 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. Changed: U zc.sourcefactory/trunk/buildout.cfg -=- Modified: zc.sourcefactory/trunk/buildout.cfg === --- zc.sourcefactory/trunk/buildout.cfg 2008-12-08 07:21:10 UTC (rev 93765) +++ zc.sourcefactory/trunk/buildout.cfg 2008-12-08 07:22:06 UTC (rev 93766) @@ -4,4 +4,5 @@ [test] recipe = zc.recipe.testrunner +defaults = [--auto-color] eggs = zc.sourcefactory [test] -- Benji York Senior Software Engineer Zope Corporation ___ 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: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Monday 08 December 2008, Benji York wrote: Nope, the tests will pass in the zope.testbrowser buildout. However, if a testbrowser user for some reason run the testbrowser tests outside of its buildout, then you're right, they may see a failure if their versions aren't new enough. At that point I would hope they would read the CHANGES.txt and see that a new version is required. The trade off is in requiring people to upgrade a dependency in order to get a bug fix that they may not care about. In the large, this is the problem with specifying versions in setup.py. Doing so assumes too much about how people are using all the dependencies involved. Yep, I could not agree more. :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 Tests: 3 OK, 3 Failed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zope Tests Summarizer wrote:
Summary of messages to the zope-tests list.
Period Sun Dec 7 12:00:00 2008 UTC to Mon Dec 8 12:00:00 2008 UTC.
There were 6 messages: 6 from Zope Tests.
Test failures
-
Subject: FAILED (failures=7) : Zope-2.11 Python-2.4.5 : Linux
From: Zope Tests
Date: Sun Dec 7 20:29:11 EST 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010612.html
I have fixed this one as follows:
- I upgraded the mechanize external to the vendor-imported 0.10
version.
- I upgraded the 'zope.testbrowser' external to the Zope2-specific
version which suppresses the 'over-the-wire.txt' tests (which should
*never* run automatically, BTW).
- I updated 'Products.Five.testbrowser' to strip out the '_seek'
handler, which was never part of the relased version of 'mechanize'
on which our internal fork was based.
Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux
From: Zope Tests
Date: Sun Dec 7 20:30:42 EST 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010613.html
Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux
From: Zope Tests
Date: Sun Dec 7 20:32:12 EST 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010614.html
For the trunk I have spelunked the 'zope.testbrowser' failure, which is
due to a difference between Zope2 and Zope3 requests: the Z3 versions
have empty 'processInputs' methods, while the Z2 version drains the
input stream for non-GET methods, creating a cgi.FieldStorage. I would
just as soon disable the test under Zope2 (e.g., with something like the
attached patch), rather than care about the different semantics. I
could create another Z2-specific tag for this, if needed.
I still don't have a clue why the 'aqlegacy_ftest.txt' tests fail. Ideas?
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJPVT9+gerLs4ltQ4RAgWBAJ9VSV1vaC32Mj3EIy+fy8SpszLnJACeL+Pp
sjhqfFsU6QDQ4dyZuSGDzbc=
=Ecve
-END PGP SIGNATURE-
Index: zope/testbrowser/tests.py
===
--- zope/testbrowser/tests.py (revision 93787)
+++ zope/testbrowser/tests.py (working copy)
@@ -391,6 +391,14 @@
def test_suite():
flags = doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS
+try:
+# The doctests make Zope3-specifc assumptions about how the
+# publisher works; skip them if running inside a Zope2 environment
+import ZPublisher
+except ImportError:
+pass
+else:
+return unittest.TestSuite()
readme = FunctionalDocFileSuite('README.txt', optionflags=flags,
checker=checker)
___
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: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster [EMAIL PROTECTED] wrote: On Dec 8, 2008, at 9:02 AM, Benji York wrote: On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Nope, the tests will pass in the zope.testbrowser buildout. Having tests which pass only in that buildout is an attractive nuisance: I'm seeing test failures in the version of zope.testbrowser linked into the Zope2 trunk, for instance. If the behavior of zope.testbrowser is broken in the absence of a sufficiently-recent version of ClientForm, then that behavior should be spelled out in setup.py's dependencies: that is what they are for. However, if a testbrowser user for some reason run the testbrowser tests outside of its buildout, then you're right, they may see a failure if their versions aren't new enough. At that point I would hope they would read the CHANGES.txt and see that a new version is required. The trade off is in requiring people to upgrade a dependency in order to get a bug fix that they may not care about. In the large, this is the problem with specifying versions in setup.py. Doing so assumes too much about how people are using all the dependencies involved. Here's a scenario: I fix a bug in some package, it depends on a newer version of say, zope.publisher. I put that requirement in my package's setup.py. A user of my package upgrades to get an unrelated bug fix and is forced to use the newer zope.publisher. It so happens that that the new version of zope.publisher has a different bug that bites them. They now are in a bad spot. A user of your package cannot rely on automatic dependency resolution in this case: your package is broken without the new version of its own dependency, so they can't upgrade to it. Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: at that point, forking the egg to drop the manually-resolved extra dependency is a minor nuisance. If the setup.py hadn't specified a version then the programmer could have constructed a set of versions that didn't exhibit any bugs that bite them, but they're precluded from doing that. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPVgV+gerLs4ltQ4RAof1AJ49K2CxxaJv18rm1U9rHtRjLxLHbQCdGAVu xjQLdJ5ceRek83aNa6R3fag= =tFoW -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 8, 2008, at 12:23 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster [EMAIL PROTECTED] wrote: On Dec 8, 2008, at 9:02 AM, Benji York wrote: On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Log message for revision 93722: - Switched to Zope 3.4 KGS. - New lines are no longer stripped in XML and HTML code contained in a textarea; requires ClientForm = 0.2.10 (LP #268139). This revision make the buildout fail with Error: Couldn't find a distribution for 'ClientForm=0.2.10'. I suspect you had that version of ClientForm in your cache and didn't realize that it is not available in the KGS index. Even if we fixed that, I don't want to require a particular version of ClientForm in testbrowser. There's no need to impose a newer version on people who don't need it. Anyone who does need the bug fix can specify the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Nope, the tests will pass in the zope.testbrowser buildout. Having tests which pass only in that buildout is an attractive nuisance: I'm seeing test failures in the version of zope.testbrowser linked into the Zope2 trunk, for instance. If the behavior of zope.testbrowser is broken in the absence of a sufficiently-recent version of ClientForm, then that behavior should be spelled out in setup.py's dependencies: that is what they are for. However, if a testbrowser user for some reason run the testbrowser tests outside of its buildout, then you're right, they may see a failure if their versions aren't new enough. At that point I would hope they would read the CHANGES.txt and see that a new version is required. The trade off is in requiring people to upgrade a dependency in order to get a bug fix that they may not care about. In the large, this is the problem with specifying versions in setup.py. Doing so assumes too much about how people are using all the dependencies involved. Here's a scenario: I fix a bug in some package, it depends on a newer version of say, zope.publisher. I put that requirement in my package's setup.py. A user of my package upgrades to get an unrelated bug fix and is forced to use the newer zope.publisher. It so happens that that the new version of zope.publisher has a different bug that bites them. They now are in a bad spot. A user of your package cannot rely on automatic dependency resolution in this case: your package is broken without the new version of its own dependency, so they can't upgrade to it. Stripping all versions from the dependencies in setup.py only works if users are willing to run their own package indexes, and figure out edge cases such as the ones you describe by themselves: at that point, forking the egg to drop the manually-resolved extra dependency is a minor nuisance. Thank you for taking the time to think through and clearly describe the position I share, Tres. Gary ___ 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] SVN: zope.tal/trunk/src/zope/tal/dummyengine.py assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Wilkes wrote: Log message for revision 93717: assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true. Changed: U zope.tal/trunk/src/zope/tal/dummyengine.py -=- Modified: zope.tal/trunk/src/zope/tal/dummyengine.py === --- zope.tal/trunk/src/zope/tal/dummyengine.py2008-12-06 12:09:53 UTC (rev 93716) +++ zope.tal/trunk/src/zope/tal/dummyengine.py2008-12-06 13:25:25 UTC (rev 93717) @@ -85,8 +85,8 @@ return value def evaluate(self, expression): -assert (expression.startswith($) and expression.endswith($), -expression) +assert expression.startswith($) and expression.endswith($), \ +expression expression = expression[1:-1] m = name_match(expression) if m: @@ -152,8 +152,8 @@ return self.evaluate(expr) def evaluateMacro(self, macroName): -assert (macroName.startswith($) and macroName.endswith($), -macroName) +assert macroName.startswith($) and macroName.endswith($), \ +macroName macroName = macroName[1:-1] file, localName = self.findMacroFile(macroName) if not file: A better fix would be to strip outthe 'assert' keyword everywhere, and use 'self.failUnless' / 'self.failIf' instead: that would allow getting rid of the backsplash, as well. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPVjG+gerLs4ltQ4RAjZKAKDSJ2alTo+X6JjUypulCCB1cryn3QCfUktE Unhlfp28gYNPB3pyyHl+iM4= =n6K5 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Dec 8, 2008, at 10:56 AM, Benji York 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? They should read about ansi-color-for-comint-mode-on and add-hook. There are probably other ways to do this. It is equally annoying when _some_ Emacs users leave lines filled with nothing but spaces all over the Zope code base. Yet, nobody asked for a rule that would somehow prevent that. The Emacs users can easily prevent these spaces by setting show-trailing-whitespace in python-mode-hook or simply using delete-trailing-whitespace from time to time. Setting next-line-add-newlines to nil in the .emacs file is also a good idea. Anyway, why enforce an ancient terminal style on all of us when Emacs users could actually set their shell window style? ___ 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] Plone/Zeocluster performances problems
Jean-Michel FRANCOIS wrote at 2008-12-8 11:17 +0100: Configuration of Zope is a pain. Take a first look there: http://blip.tv/file/315714 Apache in your case is not the problem. I think this is your zope configuration (only one thread per instance is a good thing). I do not think that the sentence inside the (...) is correct. There may be cases where one thread per instance can be recommended but in general the default (4 threads per instance) is not that bad. This is especially true when you have a bit more expensive queries against a relational database. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 12:37 PM, Zvezdan Petkovic [EMAIL PROTECTED] wrote: On Dec 8, 2008, at 10:56 AM, Benji York 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. It may be, but I'm not much persuaded by fix your tools arguments. If it causes other people pain and doesn't convey a huge benefit, then there's no need to impose on others. -- Benji York Senior Software Engineer Zope Corporation ___ 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] SVN: zope.tal/trunk/src/zope/tal/dummyengine.py assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true.
On Mon, Dec 8, 2008 at 12:26 PM, Tres Seaver [EMAIL PROTECTED] wrote: A better fix would be to strip outthe 'assert' keyword everywhere, and use 'self.failUnless' / 'self.failIf' instead: that would allow getting rid of the backsplash, as well. Yep. Another reason not to use assert in tests is that if the tests are run with Python's -O or -OO switches, the asserts will be optimized away. -- Benji York Senior Software Engineer Zope Corporation ___ 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] SVN: zope.tal/trunk/src/zope/tal/dummyengine.py assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true.
Tres Seaver wrote: Matthew Wilkes wrote: Log message for revision 93717: assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true. Changed: U zope.tal/trunk/src/zope/tal/dummyengine.py -=- Modified: zope.tal/trunk/src/zope/tal/dummyengine.py === --- zope.tal/trunk/src/zope/tal/dummyengine.py 2008-12-06 12:09:53 UTC (rev 93716) +++ zope.tal/trunk/src/zope/tal/dummyengine.py 2008-12-06 13:25:25 UTC (rev 93717) @@ -85,8 +85,8 @@ return value def evaluate(self, expression): -assert (expression.startswith($) and expression.endswith($), -expression) +assert expression.startswith($) and expression.endswith($), \ +expression expression = expression[1:-1] m = name_match(expression) if m: @@ -152,8 +152,8 @@ return self.evaluate(expr) def evaluateMacro(self, macroName): -assert (macroName.startswith($) and macroName.endswith($), -macroName) +assert macroName.startswith($) and macroName.endswith($), \ +macroName macroName = macroName[1:-1] file, localName = self.findMacroFile(macroName) if not file: A better fix would be to strip outthe 'assert' keyword everywhere, and use 'self.failUnless' / 'self.failIf' instead: that would allow getting rid of the backsplash, as well. Unless I'm missing something self.failUnless only works inside tests. This is in normal code, where I found assert statements just annoying for the most part. Hanno ___ 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] SVN: zope.tal/trunk/src/zope/tal/dummyengine.py assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Tres Seaver wrote: Matthew Wilkes wrote: Log message for revision 93717: assert isn't a function, using parens will cause the two arguments to be treated as a 2-tuple, hence always true. Changed: U zope.tal/trunk/src/zope/tal/dummyengine.py -=- Modified: zope.tal/trunk/src/zope/tal/dummyengine.py === --- zope.tal/trunk/src/zope/tal/dummyengine.py 2008-12-06 12:09:53 UTC (rev 93716) +++ zope.tal/trunk/src/zope/tal/dummyengine.py 2008-12-06 13:25:25 UTC (rev 93717) @@ -85,8 +85,8 @@ return value def evaluate(self, expression): -assert (expression.startswith($) and expression.endswith($), -expression) +assert expression.startswith($) and expression.endswith($), \ +expression expression = expression[1:-1] m = name_match(expression) if m: @@ -152,8 +152,8 @@ return self.evaluate(expr) def evaluateMacro(self, macroName): -assert (macroName.startswith($) and macroName.endswith($), -macroName) +assert macroName.startswith($) and macroName.endswith($), \ +macroName macroName = macroName[1:-1] file, localName = self.findMacroFile(macroName) if not file: A better fix would be to strip outthe 'assert' keyword everywhere, and use 'self.failUnless' / 'self.failIf' instead: that would allow getting rid of the backsplash, as well. Unless I'm missing something self.failUnless only works inside tests. This is in normal code, where I found assert statements just annoying for the most part. D'oh, you are correct! +1 to removing the asserts alogether. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPXIM+gerLs4ltQ4RAlVbAJ9qwQrta7+16o4+i3b1Nl8goewEtACfU0DC vOzkFTvsbGYHObJfiz3ALuI= =bY08 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [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-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 10:56 AM, Benji York [EMAIL PROTECTED] wrote: This setting apparently causes problems for people who use Emacs, so for zope. and zc. packages at least, we don't use --auto-color. I've been using this under Emacs for a while, and haven't experienced any tool-related problems with colorization. I *have* generally objected to adding settings like this in buildout.cfg: some of us (including myself!) think it makes the output harder to read. The only right way to deal with this seems to be to either: - require users wanting color to ask for it from the command line, or - add configuration support, so this can be set per-user, rather than polluting buildout.cfg for everyone. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 3:05 PM, Fred Drake [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 10:56 AM, Benji York [EMAIL PROTECTED] wrote: This setting apparently causes problems for people who use Emacs, so for zope. and zc. packages at least, we don't use --auto-color. I've been using this under Emacs for a while, and haven't experienced any tool-related problems with colorization. I *have* generally objected to adding settings like this in buildout.cfg: some of us (including myself!) think it makes the output harder to read. Good point (I really like colorized output, but typeing -c has become reflex at this point, so it doesn't bother me). The only right way to deal with this seems to be to either: - require users wanting color to ask for it from the command line, or - add configuration support, so this can be set per-user, rather than polluting buildout.cfg for everyone. +1 -- Benji York Senior Software Engineer Zope Corporation ___ 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 3:05 PM, Fred Drake [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 10:56 AM, Benji York [EMAIL PROTECTED] wrote: This setting apparently causes problems for people who use Emacs, so for zope. and zc. packages at least, we don't use --auto-color. I've been using this under Emacs for a while, and haven't experienced any tool-related problems with colorization. I *have* generally objected to adding settings like this in buildout.cfg: some of us (including myself!) think it makes the output harder to read. +1 ___ 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 )
