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 )
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 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. "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 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] 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 Design"http://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] 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.
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] [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] 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 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] 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 Design"http://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: 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] [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 Design"http://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] 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 Design"http://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.
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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 8, 2008, at 10:52 AM, 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. That's not what I said. :-) > 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. There are always scenarios with problems in which code depends on other packages. I disagree with your argument, but if no-one else agrees with me I'm fine. 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] [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 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] 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] 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 "", line 1, in 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] [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] [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 )
[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 > > ServerName xxx.xxx.xxx > ServerAdmin [EMAIL PROTECTED] > > 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" > > # 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 > > > > 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 > l