Re: [Zope-dev] optimised python
Jens Vagelpohl wrote: On 18 Dec 2005, at 06:46, Alan Milligan wrote: I'm reconsidering the way we RPM package byte-code compiled python, and although I suspect optimised python is a bit of an anacronysm, I thought I'd check with the list ;) If one was to start Zope with python -O, then it would look for (and generate) .pyo files instead of .pyc's in all the Products right? Would there be any performance gain by this change? How much? Is it worth me doing byte-compiles with -O and starting Zope's interpreter in this mode? There is no anachronism at all. Building Python by hand will also build .pyo files alonside .pyc files. There is a speed increase running Zope with .pyos, but if I remember correctly you have to hack one of the startup files to correctly pass all python flags given upon startup. I don't know anyone who has done specific testing to quantify the speed increase, though. There is a drawback: Debugging becomes a lot harder and sometimes impossible because you get no or faulty line number information in tracebacks and when using pdb. That isn't true. Line numbers are included and valid. All -O does is: - cause __debug__ to be false - cause assert statements to be noop. ZODB, and especially ZEO, have lots of logging calls conditioned on __debug__, and running with -O can have a measurable (a few percent, If I remember correctly) impact on performance especially when lots of database access is going on. I think this effect is more pronounced for ZEO storage servers. Production Zope and ZEO servers should run with -O IMO. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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:
Summary of messages to the zope-tests list. Period Sun Dec 18 12:01:01 2005 UTC to Mon Dec 19 12:01:01 2005 UTC. There were no messages. ___ 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] optimised python
On Mon, Dec 19, 2005 at 06:50:19AM -0500, Jim Fulton wrote: | There is a drawback: Debugging becomes a lot harder and sometimes | impossible because you get no or faulty line number information in | tracebacks and when using pdb. | | That isn't true. Line numbers are included and valid. | | All -O does is: | | - cause __debug__ to be false | | - cause assert statements to be noop. I think Jens was referring to the fact that since some version (which I don't remember correctly), when run with -O python will show the line number of the function definition on tracebacks instead of the real line number where the exception occurred. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] optimised python
Sidnei da Silva wrote: On Mon, Dec 19, 2005 at 06:50:19AM -0500, Jim Fulton wrote: | There is a drawback: Debugging becomes a lot harder and sometimes | impossible because you get no or faulty line number information in | tracebacks and when using pdb. | | That isn't true. Line numbers are included and valid. | | All -O does is: | | - cause __debug__ to be false | | - cause assert statements to be noop. I think Jens was referring to the fact that since some version (which I don't remember correctly), when run with -O python will show the line number of the function definition on tracebacks instead of the real line number where the exception occurred. I don't think this is the case for recent versions of Python. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] optimised python
On Mon, Dec 19, 2005 at 07:12:44AM -0500, Jim Fulton wrote: | Sidnei da Silva wrote: | On Mon, Dec 19, 2005 at 06:50:19AM -0500, Jim Fulton wrote: | | There is a drawback: Debugging becomes a lot harder and sometimes | | impossible because you get no or faulty line number information in | | tracebacks and when using pdb. | | | | That isn't true. Line numbers are included and valid. | | | | All -O does is: | | | | - cause __debug__ to be false | | | | - cause assert statements to be noop. | | I think Jens was referring to the fact that since some version (which I | don't remember correctly), when run with -O python will show the line | number of the function definition on tracebacks instead of the real | line number where the exception occurred. | | I don't think this is the case for recent versions of Python. Indeed, was speaking from memory, and understood the SET_LINENO changes backwards. Mark help me out understand the issue: actually, when -O was first introduced, -O did magic with the SET_LINENO opcode. but in recent (even 2.3 I believe), even non-optimised Python manages to use the same perf tricks, but keep a correct lineno. This is reflected if you ever look in the debugger - a frame's f_lineno structure element is indeed only ever the function decl. Magically f_lineno as exposed to Python does get the right thing though... -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ 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] svn.zope.org borked
I get always connection closed unexpectedly when using svn update. Andreas pgpFnXKQRqPEQ.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] optimised python
On 19 Dec 2005, at 12:00, Sidnei da Silva wrote: On Mon, Dec 19, 2005 at 06:50:19AM -0500, Jim Fulton wrote: | There is a drawback: Debugging becomes a lot harder and sometimes | impossible because you get no or faulty line number information in | tracebacks and when using pdb. | | That isn't true. Line numbers are included and valid. | | All -O does is: | | - cause __debug__ to be false | | - cause assert statements to be noop. I think Jens was referring to the fact that since some version (which I don't remember correctly), when run with -O python will show the line number of the function definition on tracebacks instead of the real line number where the exception occurred. Thanks Sidnei, that's what I meant. Just didn't remember the details, something with line numbers ;) jens ___ 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] [ZPublisher] specifiying 'charset' for the content-type header
The following usecase is not handled correctly by Zope: When you call a PythonScript returning a Python unicode string then the ZPublisher/HTTPResponse code will convert the unicode response string using HTTPResponse.default_encoding to a Python string. The default encoding is configurable through zope.conf (zpublisher_default_encoding key). This works fine unless you change the encoding to utf-8. In this case Zope sends out UTF8 content without specifying the encoding in the content-type header. I propose the following changes: - Zope adds content-type: text/plain|html when no content-type is specified by the application. In this case we would add 'charset=DEFAULT_ENCODING - if the application specfies a content-type header then we would add the charset only if it is undefined Objections? Andreas pgp3Rso2INRf3.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPublisher, ZPT and XHTML
Another usecase where Zope does not play nicely: You can create a ZPT with XHTML content where the content is encoded as UTF-8 (which the corresponding encoding declaration within the XML preamble). When you redefine the zpublisher_default_encoding Zope might convert the UTF8 body of the ZPT to some other encoding. This leads to two possible problems: a) the new encoding is not available from the content-type header and b) the encoding inside the XML preamble still contains the original encoding...both is wrong...any ideas how to deal with that problem (perhaps the problem is only a constructed problem?) -aj pgpmYiDxbvl4o.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Unit Test Failures
The Zope2 unit tests have been failing for some time on buildbot.zope.com. Looks like a Five-related problem: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/109/test/0 -- 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.org borked
Jens Vagelpohl wrote: On 19 Dec 2005, at 12:23, Andreas Jung wrote: I get always connection closed unexpectedly when using svn update. Andreas That %$£@ BerkeleyDB backend was geborken again. svnadmin recover fixed it. Thanks! Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: The Zope2 unit tests have been failing for some time on buildbot.zope.com. Looks like a Five-related problem: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/109/test/0 The failing test is a functional test, not a unit test; I don't run them by default when I check in. I see a couple of problem points: the biggest is the use in the output of 'checkSiteManager.html' of a repr'ed dict, which might render differently between different machines (or even the same machine across Python versions). This is a classic case where the doctest does *not* provide clarity over a traditional 'unittest' style test, IMNSHO. I'm not sure what it is testing, either; CC'ing Phillip, whose fingerprints are on it, according the 'svn blame', for clarification. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDps5A+gerLs4ltQ4RAn2DAKDJ4PUXUGY8pGHI4RcSU6qUQm2FRgCdHTEM GNgrBRn/Y70IbuAhuJ48GGM= =0Um3 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Unit Test Failures
[Benji York] The Zope2 unit tests have been failing for some time on buildbot.zope.com. Looks like a Five-related problem: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/109/test/0 [Tres Seaver] The failing test is a functional test, not a unit test; I don't run them by default when I check in. I see a couple of problem points: the biggest is the use in the output of 'checkSiteManager.html' of a repr'ed dict, which might render differently between different machines (or even the same machine across Python versions). This is a classic case where the doctest does *not* provide clarity over a traditional 'unittest' style test, IMNSHO. Possibly, but that clearly doesn't apply to the specific failures we're seeing (True versus False outcomes, and getting lots more output than expected). I'm not sure what it is testing, either; CC'ing Phillip, whose fingerprints are on it, according the 'svn blame', for clarification. These tests have always failed, and Phillip doesn't know why. Because they were failing, he changed them to run at level 2. That's not what level 2 is for, though, and the failures became visible to everyone when the buildbot was changed to pass `--all` to test.py (--all runs tests at all levels, level 2 among them ;-)). I opened a Collector issue on this about a month ago (I always run with `--all`, so these failures are old news to me): http://www.zope.org/Collectors/Zope/1947 ___ 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: Unit Test Failures
Jim Fulton wrote: This is really just a matter of knowing how to write the test. Generally, when you want to show a dict sample, the way to do it is with: from zope.testing/doctestunit import pprint pprint(thisdict) This formats the dictionary nicely and, most importantly, sorts the items before displaying it. This is what I did in this test, btw. Philipp P.S.: My other reply got swallowed by Mailman, can someone accept the posting please? This message was sent using IMP, the Internet Messaging Program. ___ 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: Unit Test Failures
Tim Peters wrote: I'm not sure what it is testing, either; CC'ing Phillip, whose fingerprints are on it, according the 'svn blame', for clarification. These tests have always failed, and Phillip doesn't know why. Because they were failing, he changed them to run at level 2. That's not what level 2 is for, though, and the failures became visible to everyone when the buildbot was changed to pass `--all` to test.py (--all runs tests at all levels, level 2 among them ;-)). Yes, mea culpa. I opened a Collector issue on this about a month ago (I always run with `--all`, so these failures are old news to me): http://www.zope.org/Collectors/Zope/1947 Rereading that issue again, it's totally surprising to see that there's no failure on Windows, which makes its source even harder to debug. I wouldn't know where to start (having tried to debug this problem in the past). Anyone got an idea? Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
[resending this from the right address, the original posting got swallowed by Mailman] Tres Seaver wrote: Benji York wrote: The Zope2 unit tests have been failing for some time on buildbot.zope.com. Looks like a Five-related problem: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/109/test/0 The failing test is a functional test, not a unit test; I don't run them by default when I check in. Actually, I put this particular test (functional.txt) on level=2 because it would fail when run together with other Five tests. It passes fine when run by itself. This test exists identically in Five 1.2 (based on Zope 2.8) where it passes just fine when run together with other tests and by itself. During the hot phase of making the deadline on November 1st, I decided that this wasn't a big issue and could be resolved during the beta phase (after all, the test passes by itself). I obviously forgot to look into it again, but then again, I still don't know what the heck is wrong with this. I see a couple of problem points: the biggest is the use in the output of 'checkSiteManager.html' of a repr'ed dict, which might render differently between different machines (or even the same machine across Python versions). Well, if you look closer you find that it uses pprint.pformat which always outputs the same on all machines (because it provides output sorted by the dictionary key). This is a classic case where the doctest does *not* provide clarity over a traditional 'unittest' style test, IMNSHO. Comparing dictionaries is not trivial in classic javiotic tests, either. Using pprint is actually quite an elegant way, I think. I'm not sure what it is testing, either; It's testing how local site managers get found during traversal and how that affects component lookup of e.g. views (depending on which site is traversed, you would find local components or not). Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: Benji York wrote: The Zope2 unit tests have been failing for some time on buildbot.zope.com. Looks like a Five-related problem: http://buildbot.zope.org/Zope%20trunk%202.4%20Linux%20zc-buildbot/builds/109/test/0 The failing test is a functional test, not a unit test; I don't run them by default when I check in. Actually, I put this particular test (functional.txt) on level=2 because it would fail when run together with other Five tests. It passes fine when run by itself. This test exists identically in Five 1.2 (based on Zope 2.8) where it passes just fine when run together with other tests and by itself. During the hot phase of making the deadline on November 1st, I decided that this wasn't a big issue and could be resolved during the beta phase (after all, the test passes by itself). I obviously forgot to look into it again, but then again, I still don't know what the heck is wrong with this. I see a couple of problem points: the biggest is the use in the output of 'checkSiteManager.html' of a repr'ed dict, which might render differently between different machines (or even the same machine across Python versions). Well, if you look closer you find that it uses pprint.pformat which always outputs the same on all machines (because it provides output sorted by the dictionary key). I see that in the implementation; it isn't documented as part of pprint's contract, however. This is a classic case where the doctest does *not* provide clarity over a traditional 'unittest' style test, IMNSHO. Comparing dictionaries is not trivial in classic javiotic tests, either. Using pprint is actually quite an elegant way, I think. But the dictionary here is an *artifact* -- what you are really trying to do would be expressed as individual assertions in a classic unit test: self.failUnless(IFiveUtilityRegistry.providedBy(utility_service)) self.failIf(zapi.getSiteManager() is zapi.getGlobalSiteManager()) etc. If you really want to test equality of dictionaries, then 'self.assertEqual' does the trick just fine. I'm not sure what it is testing, either; It's testing how local site managers get found during traversal and how that affects component lookup of e.g. views (depending on which site is traversed, you would find local components or not). OK, thanks! Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDptfi+gerLs4ltQ4RAtfkAKCiJLa+s+8GaNxew9DcIPWrbw7qXgCeNaSj csBJ641nurB0xPwBu6xLByY= =juKw -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Unit Test Failures
[Tim] I opened a Collector issue on this about a month ago (I always run with `--all`, so these failures are old news to me): http://www.zope.org/Collectors/Zope/1947 [Philipp] Rereading that issue again, it's totally surprising to see that there's no failure on Windows, which makes its source even harder to debug. No, these tests fail on Windows too. In fact, the problem was orginally reported against Windows: see entry #2 in: http://www.zope.org/Collectors/Zope/1931 What does not fail on Windows is the specific variation you asked me to try in your comment #2 on issue 1947: When you run it by itself, it passes, though. Maybe you can confirm that. In my comment #3 on issue 1947, I confirmed that: when I ran the functional.txt test _by itself_ on Windows, it passed. I wouldn't know where to start (having tried to debug this problem in the past). Anyone got an idea? For a start, disabuse yourself of the illusion that it acts differently on Windows than on Linux ;-) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
Tres Seaver wrote: Well, if you look closer you find that it uses pprint.pformat which always outputs the same on all machines (because it provides output sorted by the dictionary key). I see that in the implementation; it isn't documented as part of pprint's contract, however. Yes it is: http://python.org/doc/current/lib/module-pprint.html But the dictionary here is an *artifact* -- what you are really trying to do would be expressed as individual assertions in a classic unit test: self.failUnless(IFiveUtilityRegistry.providedBy(utility_service)) self.failIf(zapi.getSiteManager() is zapi.getGlobalSiteManager()) etc. If you really want to test equality of dictionaries, then 'self.assertEqual' does the trick just fine. All I need is a means to get information from the view (which is our guinnea pig component that tries to look up local stuff) to the functional test. Views typically output strings, whether we're in doctests or not. So, in the end we're comparing strings. pprint'ing a dictionary is just a convenient, but perhaps misleading way of doing this. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: Unit Test Failures
Tim Peters wrote: I wouldn't know where to start (having tried to debug this problem in the past). Anyone got an idea? For a start, disabuse yourself of the illusion that it acts differently on Windows than on Linux ;-) Yup, sorry, misread the issue. Speed kills... :) Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: Unit Test Failures
Philipp von Weitershausen wrote: ... Actually, I put this particular test (functional.txt) on level=2 because it would fail when run together with other Five tests. It passes fine when run by itself. This test exists identically in Five 1.2 (based on Zope 2.8) where it passes just fine when run together with other tests and by itself. During the hot phase of making the deadline on November 1st, I decided that this wasn't a big issue and could be resolved during the beta phase (after all, the test passes by itself). I obviously forgot to look into it again, but then again, I still don't know what the heck is wrong with this. Obviously, some other test isn't cleaning up after itself. The way to debug this is by trial and error, running this test in combination with other tests until it fails. (It would be cool, in some future version of the test runner, to automate the search process. Even a simple option to run tests by number would probably help a lot, making a manual binary search pretty easy.) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: Unit Test Failures
Jim Fulton wrote: Obviously, some other test isn't cleaning up after itself. Yes, that was obvious to me too. It was confusing that the same test would pass on Five 1.2, though, and I couldn't find any obvious differences. As trial and error usually takes time, I left the issue to be resolved at a later time. And then, as I said, I just forgot, my bad. I'm investigating now, but no promises that I'll produce results soon. I won't forget it this time, though :). Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: Well, if you look closer you find that it uses pprint.pformat which always outputs the same on all machines (because it provides output sorted by the dictionary key). I see that in the implementation; it isn't documented as part of pprint's contract, however. Yes it is: http://python.org/doc/current/lib/module-pprint.html I must be blind, but I don't see any occurrence of 'sort' on that page or on the PrettyPrinter Objects page under it, nor in the pydoc output nor the module docstring. But the dictionary here is an *artifact* -- what you are really trying to do would be expressed as individual assertions in a classic unit test: self.failUnless(IFiveUtilityRegistry.providedBy(utility_service)) self.failIf(zapi.getSiteManager() is zapi.getGlobalSiteManager()) etc. If you really want to test equality of dictionaries, then 'self.assertEqual' does the trick just fine. All I need is a means to get information from the view (which is our guinnea pig component that tries to look up local stuff) to the functional test. Views typically output strings, whether we're in doctests or not. So, in the end we're comparing strings. pprint'ing a dictionary is just a convenient, but perhaps misleading way of doing this. In that case, I would have added methods to the view and asserted their return values, I think, even in a doctest. De gustibus, perhaps. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDptwT+gerLs4ltQ4RAopbAJ0UVEeeLZ0tZ4pMu2TBAAoYFy+60gCgyeUf BU+mhROlfBZ546O7hgoDZ1E= =qMNh -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 )
[Zope-dev] Re: Unit Test Failures
Tres Seaver wrote: Well, if you look closer you find that it uses pprint.pformat which always outputs the same on all machines (because it provides output sorted by the dictionary key). I see that in the implementation; it isn't documented as part of pprint's contract, however. Yes it is: http://python.org/doc/current/lib/module-pprint.html I must be blind, but I don't see any occurrence of 'sort' on that page or on the PrettyPrinter Objects page under it, nor in the pydoc output nor the module docstring. Now I see what you mean by contract. You're right, I guess it isn't documented then, but perhaps it should be. But the dictionary here is an *artifact* -- what you are really trying to do would be expressed as individual assertions in a classic unit test: self.failUnless(IFiveUtilityRegistry.providedBy(utility_service)) self.failIf(zapi.getSiteManager() is zapi.getGlobalSiteManager()) etc. If you really want to test equality of dictionaries, then 'self.assertEqual' does the trick just fine. All I need is a means to get information from the view (which is our guinnea pig component that tries to look up local stuff) to the functional test. Views typically output strings, whether we're in doctests or not. So, in the end we're comparing strings. pprint'ing a dictionary is just a convenient, but perhaps misleading way of doing this. In that case, I would have added methods to the view and asserted their return values, I think, even in a doctest. De gustibus, perhaps. Yup, I should probably do this. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: Unit Test Failures
...
[Philipp]
Well, if you look closer you find that it uses pprint.pformat which
always outputs the
same on all machines (because it provides output sorted by the
dictionary key).
[Tres Seaver]
I see that in the implementation; it isn't documented as part of
pprint's contract, however.
It's not part of the implementation either. For example,
d = {z: 1, m: 2}
pprint.pprint(d)
{'z': 1, 'm': 2}
That is, it's not true that pprint always sorts a dict for display.
Looks like Jim's suggested
from zope.testing.doctestunit import pprint
inherits this insecurity.
In the example above, two things conspire to give unsorted output:
1. pprint(dict) doesn't try to sort at all if _repr(dict) is short.
2. On my 32-bit box, hash('z') hash('m'), which leads to platform accidents
in dict insertion putting 'z' before 'm' in the natural dict
iteration order:
d
{'z': 1, 'm': 2}
Because of #1, pprint passes on that order.
On a 64-bit box, the order may differ (or across Python versions on
one box if the string hash, or dict insertion, algorithms change).
___
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: Unit Test Failures
Tim Peters wrote: ... a good lecture on pprint vs. dicts Thanks, I'll be more careful about using pprint for dicts then. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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: Unit Test Failures
Tim Peters wrote:
...
[Philipp]
Well, if you look closer you find that it uses pprint.pformat which
always outputs the
same on all machines (because it provides output sorted by the
dictionary key).
[Tres Seaver]
I see that in the implementation; it isn't documented as part of
pprint's contract, however.
It's not part of the implementation either. For example,
d = {z: 1, m: 2}
pprint.pprint(d)
{'z': 1, 'm': 2}
That is, it's not true that pprint always sorts a dict for display.
Looks like Jim's suggested
from zope.testing.doctestunit import pprint
inherits this insecurity.
No, it doesn't.
from zope.testing.doctestunit import pprint
pprint({z: 1, m: 2})
{'m': 2,
'z': 1}
Note both the sorting and the wrapping.
See below.
In the example above, two things conspire to give unsorted output:
1. pprint(dict) doesn't try to sort at all if _repr(dict) is short.
2. On my 32-bit box, hash('z') hash('m'), which leads to platform accidents
in dict insertion putting 'z' before 'm' in the natural dict
iteration order:
d
{'z': 1, 'm': 2}
Because of #1, pprint passes on that order.
On a 64-bit box, the order may differ (or across Python versions on
one box if the string hash, or dict insertion, algorithms change).
zope.doctestunit.pprint creates and uses a pretty printer with width
set to 1, so all dicts are long and thus sorted.
Note that, in Python 2.4, you can now pass a width to pprint without creating
a separate pretty printer:
from pprint import pprint
pprint({z: 1, m: 2})
{'z': 1, 'm': 2}
pprint({z: 1, m: 2}, width=1)
{'m': 2,
'z': 1}
So maybe we can phase out the use of docutestunit's pprint.)
Perhaps we should push to get the sorting behavior of pprint
documented to allay your concerns. Better yet, perhaps we can
get all dicts to be sorted.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
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: Unit Test Failures
[Tim]
Looks like Jim's suggested
from zope.testing.doctestunit import pprint
inherits this insecurity.
[Jim]
No, it doesn't.
from zope.testing.doctestunit import pprint
pprint({z: 1, m: 2})
{'m': 2,
'z': 1}
Note both the sorting and the wrapping.
See below.
Cool! I confess that the 'width' fiddling in:
def pprint(ob, **opts):
if 'width' not in opts:
opts['width'] = 1
return PrettyPrinter(**opts).pprint(ob)
was incomprehensible to me just now -- you might want to add a comment
to that ;-)
zope.doctestunit.pprint creates and uses a pretty printer with width
set to 1, so all dicts are long and thus sorted.
Well, I understand why that works, but it's not part of pprint's
contract either.
Note that, in Python 2.4, you can now pass a width to pprint without creating
a separate pretty printer:
from pprint import pprint
pprint({z: 1, m: 2})
{'z': 1, 'm': 2}
pprint({z: 1, m: 2}, width=1)
{'m': 2,
'z': 1}
So maybe we can phase out the use of docutestunit's pprint.)
Perhaps we should push to get the sorting behavior of pprint
documented to allay your concerns.
I think it's harder than you yet realize: dicts don't require that
keys be orderable, so pprint can't promise to sort dict displays.
As-is, pprint simply blows up if, e.g., you pass it a big dict using
complex numbers as keys. Could be nobody has noticed that yet, but
since the trend in Python is to raise exceptions for non-equality
comparisons of objects of different types, this kind of failure is
bound to become more common. In the end, I wouldn't be surprised if
pprint(dict) got changed to sort on the repr of the keys instead of on
the keys themselves.
Better yet, perhaps we can get all dicts to be sorted.
As above.
___
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: Unit Test Failures
Tim Peters wrote:
...
Well, I understand why that works, but it's not part of pprint's
contract either.
What contract. :)
Aren't you always telling me to read the source?
Note that, in Python 2.4, you can now pass a width to pprint without creating
a separate pretty printer:
from pprint import pprint
pprint({z: 1, m: 2})
{'z': 1, 'm': 2}
pprint({z: 1, m: 2}, width=1)
{'m': 2,
'z': 1}
So maybe we can phase out the use of docutestunit's pprint.)
Perhaps we should push to get the sorting behavior of pprint
documented to allay your concerns.
I think it's harder than you yet realize: dicts don't require that
keys be orderable, so pprint can't promise to sort dict displays.
As-is, pprint simply blows up if, e.g., you pass it a big dict using
complex numbers as keys. Could be nobody has noticed that yet, but
since the trend in Python is to raise exceptions for non-equality
comparisons of objects of different types, this kind of failure is
bound to become more common.
That's fine. In practice, when we do this sort of thing, the keys
are almost always strings.
In the end, I wouldn't be surprised if
pprint(dict) got changed to sort on the repr of the keys instead of on
the keys themselves.
That wouldn't be bad.
Anyway, I guess we should make an issue of this on python-dev,
so that either we can count on documented behavior
going forward or so that we write our pwn pretty printer for
use in doctest.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
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: Unit Test Failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tim Peters wrote: ... Well, I understand why that works, but it's not part of pprint's contract either. What contract. :) The documented behavior, e.g. from '$ pydoc pprint' or the online equivalent, http://python.org/doc/current/lib/module-pprint.html ? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpunX+gerLs4ltQ4RAoyfAJ9rRJHNhppGcNebCC94JOnHv+R/cQCggL9R Fejtd3mKGZzbE8XFWhf8SJg= =8arR -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] RFV: Unicode in Zope 2
On Mon, December 19, 2005 17:44, Andreas Jung wrote: --On 9. Dezember 2005 10:11:42 -0500 Jim Fulton [EMAIL PROTECTED] wrote: I forgot a very important need: - Common approach to Unicode We need to migrate Zope 2 to use a similar strategy. We need volunteers to brainstorm how this can be done and make one or more proposals. This is likely a prerequisite for finishing the publisher and ZPT work. I think there are two approaches. Textual content can be produced by nearly every Zope object (and its methods). Content can be composed by the basic Zope functionalities like DTML, ZPT, PyScripts and external methods (in the sense that these functionalities are able to call other objects and their methods). a) one could enforce all objects to return unicode (which would be a very hard requirement) and possibly break any application hi all! i think, a) is surely the cleaner solution. actually i always... - inlcude an content-type header and set the charset for all forms to utf8 - use :utf8:ustring/utext/ulines/utokens converters on all forms this way i always have unicode strings in my db. up to now i never had any unicode problems, expect when interfacing external systems and not doing the proper unicode conversion dance there... why not design a migration script that converts all non-ascii strings in the db to unicode strings, based on the default encoding, etc... also just some thoughts :) jürgen herrmann ps: what's especially critical here is code that handles filenames. some filesystems just don't handle unicode filenames, already had some headache there :) b) convert non-unicode content produced by Zope objects from where they are called (DTMl, ZPT, PyScript, Extmethods) to unicode. This would limit the number of places where we need to change code. The encoding of the non-unicode content could be from the 'content-type: XXX; charset=' header (if set) or as fallback from the configured zpublisher_default_encoding. An object could also set a property my_output_encoding (or so)... just-some-thoughts... -aj ___ 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 ) ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ 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: Unit Test Failures
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tim Peters wrote: ... Well, I understand why that works, but it's not part of pprint's contract either. What contract. :) The documented behavior, e.g. from '$ pydoc pprint' or the online equivalent, http://python.org/doc/current/lib/module-pprint.html ? The Python documentation is incomplete in lots of places. It can hardly be considered a complete contract. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tim Peters wrote: ... Well, I understand why that works, but it's not part of pprint's contract either. What contract. :) The documented behavior, e.g. from '$ pydoc pprint' or the online equivalent, http://python.org/doc/current/lib/module-pprint.html ? The Python documentation is incomplete in lots of places. It can hardly be considered a complete contract. (Pulling numbers out of the air) ... 97% of Zope3 has less well-specified contracts than the Python standard library. Relying on implementation details beyond the documented API is risky, period. As Tim notes, there isn't even any guarantee that dictionary keys are *ordereable*. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpv3P+gerLs4ltQ4RAslWAKClKbqWIzHLobI1zb9+ciFhJgZkEACcDzQR htZpQ+RaaeBAeujqPQxG9nI= =B8fr -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Unit Test Failures
... [Tim] Well, I understand why that works, but it's not part of pprint's contract either. [Jim] What contract. :) pprint's docs. Aren't you always telling me to read the source? Indeed, if you hadn't, you wouldn't have known that forcing width=1 forces dict sorting ;-) It's common as mud to close a bug report in Pythonland too when it's just griping about changes in undocumented behavior. ... I think it's harder than you yet realize: dicts don't require that keys be orderable, so pprint can't promise to sort dict displays. As-is, pprint simply blows up if, e.g., you pass it a big dict using complex numbers as keys. Could be nobody has noticed that yet, but since the trend in Python is to raise exceptions for non-equality comparisons of objects of different types, this kind of failure is bound to become more common. That's fine. In practice, when we do this sort of thing, the keys are almost always strings. My point is that you're relying on undocumented behavior now, and so there's no guarantee it will continue to behave that way. To the contrary, because sorting dicts _started_ creating problems when Python gave up its original any pair of objects can be compared behavior, and Python continues moving away from that, there's reason to worry that pprint may give up sorting dict displays entirely. Sorting isn't free, is currently a source of bugs in pprint, and adds a large memory burden (to materialize a giant dict.items() list) when pprint'ing a large dict. An obvious alternative is for pprint to change to do dict.iteritems() when building a display, which is much better on all those counts. If I have anything to say about it, it will continue to sort, but nobody listens to me anymore ;-) In the end, I wouldn't be surprised if pprint(dict) got changed to sort on the repr of the keys instead of on the keys themselves. That wouldn't be bad. It's debatable for sure. Anyway, I guess we should make an issue of this on python-dev, so that either we can count on documented behavior going forward or so that we write our pwn pretty printer for use in doctest. I'll try to make time for this next week (I'm on vacation then). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unit Test Failures
Philipp von Weitershausen wrote: Jim Fulton wrote: Obviously, some other test isn't cleaning up after itself. Yes, that was obvious to me too. It was confusing that the same test would pass on Five 1.2, though, and I couldn't find any obvious differences. As trial and error usually takes time, I left the issue to be resolved at a later time. And then, as I said, I just forgot, my bad. I'm investigating now, but no promises that I'll produce results soon. I won't forget it this time, though :). I found the problem. I remembered how Zope X3 3.0 and 3.1+ handle the setup of the local component hooks differently (local component hooks make sure that zapi.getSiteManager() would actually look in the thread-local for a site and not just default to the global site). So, in the end the problem was actually that previous tests would clean up too much, not too little. I've checked in a fix in the Five repository, but haven't merged that the Zope repository yet. Will do that tomorrow as my eyes are slowly closing to sleep and the matches won't hold any longer ;). G'night Philipp ___ 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: Unit Test Failures
On 12/19/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Now I see what you mean by contract. You're right, I guess it isn't documented then, but perhaps it should be. That's never been part of the contract and, as Tres notes, it's inconsistent. The implmentation will only sort when it uses the multi-line representation of the dict, not the single-line form. I don't oppose adding this to the contract and fixing it for the single-line representation for Python 2.5, but I'd rather think more about what the right interface is between displayed objects and the formatter. This is where a component architecture would really come in handy in the standard library. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: svn.zope.org borked
Perhaps the backend should be switched from bdb to fsfs (native subversion backend type) ? I know it does away with a lot of these, issues. - Rocky Jim Fulton wrote: Jens Vagelpohl wrote: On 19 Dec 2005, at 12:23, Andreas Jung wrote: I get always connection closed unexpectedly when using svn update. Andreas That %$£@ BerkeleyDB backend was geborken again. svnadmin recover fixed it. Thanks! Jim -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
Rocky Burt wrote: Perhaps the backend should be switched from bdb to fsfs (native subversion backend type) ? I know it does away with a lot of these, issues. Yup, when someone has time to do it. AFAIK, it will involve dumping the repository and reloading it. Past experience suggests that this will take several hours. This involves scheduled downtime, testing, dealing with the inevitable misshap I expect the Zope Foundation will probably establish a new repository. That would probably be a good time to make the switch. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
On 19 Dec 2005, at 20:02, Jim Fulton wrote: Rocky Burt wrote: Perhaps the backend should be switched from bdb to fsfs (native subversion backend type) ? I know it does away with a lot of these, issues. Yup, when someone has time to do it. AFAIK, it will involve dumping the repository and reloading it. Past experience suggests that this will take several hours. This involves scheduled downtime, testing, dealing with the inevitable misshap IMHO the process is straightforward and easy (except for the time it will take), and there is no problem reverting to the previous state: - run svnadmin dump on the old repository - move the old repository aside - create a new repository with fsfs backend - run svnadmin load to load the data into the new repository At no point would any data be in danger. The problem I see on the current box is hard drive space. I'm not sure the remaining space is enough to hold a complete dump *and* the new repository along with the old one. jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
Jens Vagelpohl wrote: On 19 Dec 2005, at 20:02, Jim Fulton wrote: Rocky Burt wrote: Perhaps the backend should be switched from bdb to fsfs (native subversion backend type) ? I know it does away with a lot of these, issues. Yup, when someone has time to do it. AFAIK, it will involve dumping the repository and reloading it. Past experience suggests that this will take several hours. This involves scheduled downtime, testing, dealing with the inevitable misshap IMHO the process is straightforward and easy (except for the time it will take), That fact alone adds complication, as that down time needs to be scheduled. and there is no problem reverting to the previous state: - run svnadmin dump on the old repository - move the old repository aside - create a new repository with fsfs backend - run svnadmin load to load the data into the new repository I presume you also need to disable access to the repository while this is going on. That means there are three input paths (viewcvs, svn:, svn+ssh:) that need to be disabled. Maybe that's just a matter of renaming the repo. At no point would any data be in danger. The problem I see on the current box is hard drive space. I'm not sure the remaining space is enough to hold a complete dump *and* the new repository along with the old one. The whole repository is only about 800 megs. There are over 8 gigs free. Are the dump file or the file-based repo much larger in size the the Berkeley database? BTW, thanks for volunteering for this! It will be great not to fool with the Berkeley DB anymore. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
On 19 Dec 2005, at 21:27, Jim Fulton wrote: IMHO the process is straightforward and easy (except for the time it will take), That fact alone adds complication, as that down time needs to be scheduled. OK, well, the only complication is setting a date really. Someone decides and publishes it on the different lists, end of story. and there is no problem reverting to the previous state: - run svnadmin dump on the old repository - move the old repository aside - create a new repository with fsfs backend - run svnadmin load to load the data into the new repository I presume you also need to disable access to the repository while this is going on. That means there are three input paths (viewcvs, svn:, svn+ssh:) that need to be disabled. Maybe that's just a matter of renaming the repo. viewcvs is disabled by either shutting down Apache or putting up some meaningful error page. svn access is disabled by editing /etc/ xinetd.d/svn and restarting xinetd. svn+ssh can be disabled by editing /etc/ssh/sshd_config to restrict access. This is a matter of minutes, really. At no point would any data be in danger. The problem I see on the current box is hard drive space. I'm not sure the remaining space is enough to hold a complete dump *and* the new repository along with the old one. The whole repository is only about 800 megs. There are over 8 gigs free. Are the dump file or the file-based repo much larger in size the the Berkeley database? I'm not sure, really, but knowing the current size (which I had not checked) makes me confident we're fine on that front. BTW, thanks for volunteering for this! It will be great not to fool with the Berkeley DB anymore. :) Umh, more like force-volunteered now ;) Which is fine, but in return I'd like someone else (maybe you?) to herd the cats and come up with a time frame where this can be done, and communicating it. I'll do everything on the technical side. Sound like a deal? jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
On 19 Dec 2005, at 21:37, Jens Vagelpohl wrote: BTW, thanks for volunteering for this! It will be great not to fool with the Berkeley DB anymore. :) Umh, more like force-volunteered now ;) Which is fine, but in return I'd like someone else (maybe you?) to herd the cats and come up with a time frame where this can be done, and communicating it. I'll do everything on the technical side. Sound like a deal? P.S.: The best time for me is between 12/25 and 12/30 since I'll be at home in Germany. jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
Jens Vagelpohl wrote: On 19 Dec 2005, at 21:27, Jim Fulton wrote: IMHO the process is straightforward and easy (except for the time it will take), That fact alone adds complication, as that down time needs to be scheduled. OK, well, the only complication is setting a date really. Someone decides and publishes it on the different lists, end of story. and there is no problem reverting to the previous state: - run svnadmin dump on the old repository - move the old repository aside - create a new repository with fsfs backend - run svnadmin load to load the data into the new repository I presume you also need to disable access to the repository while this is going on. That means there are three input paths (viewcvs, svn:, svn+ssh:) that need to be disabled. Maybe that's just a matter of renaming the repo. viewcvs is disabled by either shutting down Apache It's also used for CVS. (Maybe mailman too?) or putting up some meaningful error page. Which has to be written. svn access is disabled by editing /etc/ xinetd.d/svn and restarting xinetd. Uh huh. svn+ssh can be disabled by editing /etc/ssh/sshd_config to restrict access. This is a matter of minutes, really. I didn't think you could use sshd_config to restrict use of a single program. ssh access is still needed for CVS and for people logging in to do other work (e.g. mailman admin). Moving the repo seems a lot easier. :) At no point would any data be in danger. The problem I see on the current box is hard drive space. I'm not sure the remaining space is enough to hold a complete dump *and* the new repository along with the old one. The whole repository is only about 800 megs. There are over 8 gigs free. Are the dump file or the file-based repo much larger in size the the Berkeley database? I'm not sure, really, but knowing the current size (which I had not checked) makes me confident we're fine on that front. Of course, you'll want to do a dry run to make sure. BTW, thanks for volunteering for this! It will be great not to fool with the Berkeley DB anymore. :) Umh, more like force-volunteered now ;) :) Which is fine, but in return I'd like someone else (maybe you?) to herd the cats and come up with a time frame where this can be done, and communicating it. I'll do everything on the technical side. Sound like a deal? Sure. Thanks again. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
Jens Vagelpohl wrote: On 19 Dec 2005, at 21:37, Jens Vagelpohl wrote: BTW, thanks for volunteering for this! It will be great not to fool with the Berkeley DB anymore. :) Umh, more like force-volunteered now ;) Which is fine, but in return I'd like someone else (maybe you?) to herd the cats and come up with a time frame where this can be done, and communicating it. I'll do everything on the technical side. Sound like a deal? P.S.: The best time for me is between 12/25 and 12/30 since I'll be at home in Germany. Pick a date and I'll propose it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
On 19 Dec 2005, at 21:44, Jim Fulton wrote: Umh, more like force-volunteered now ;) Which is fine, but in return I'd like someone else (maybe you?) to herd the cats and come up with a time frame where this can be done, and communicating it. I'll do everything on the technical side. Sound like a deal? P.S.: The best time for me is between 12/25 and 12/30 since I'll be at home in Germany. Pick a date and I'll propose it. Since traffic will probably be low and I'll definitely be around Sunday 12/25 would be my choice. I'd probably be starting on it at noon (6 AM EST). Testing disk space usage by running a full dump and load can be done at any time. The dump can be done on the live repository without ill effect and the loading can be done somewhere else on the file system, again with no side effects (apart from slowing down the machine due to disk access). I can kick that off any day this week in the morning, any preference? jens ___ 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] Modifying a ZPT state based on a certain parameter
Hi guys, I am running on Zope 2.7.6 with Plone 2.0.5. I am currently building a dynamic application using MySQL as the backend database. I'd like to be able to change a ZPT's state based on a parameter passed by the db. For example, I have a ZPT that displays information for a particular course. However, if this courses active field is set to NO, then I would like to be able to have the ZPT's state be visible. If the courses active field is set to yes then I would like to modify the state so that the ZPT is published. I'm thinking I'd probably have to use the wf_tool in conjunction with portal_workflow? A call similar to something like so: tal:condition=python:records.active=='yes' ...then implement the necessary call to modify the workflow and make the ZPT published and vice versa. Any help is greatly appreciated. Thanks, Mike ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
[Jim] ... The whole repository is only about 800 megs. There are over 8 gigs free. Are the dump file or the file-based repo much larger in size the the Berkeley database? FYI, if you don't want to read the code ;-), the book says an FSFS repository is slightly smaller than the same thing under BDB: http://svnbook.red-bean.com/en/1.1/ch05.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] Re: svn.zope.org borked
Jens Vagelpohl wrote: On 19 Dec 2005, at 21:44, Jim Fulton wrote: Umh, more like force-volunteered now ;) Which is fine, but in return I'd like someone else (maybe you?) to herd the cats and come up with a time frame where this can be done, and communicating it. I'll do everything on the technical side. Sound like a deal? P.S.: The best time for me is between 12/25 and 12/30 since I'll be at home in Germany. Pick a date and I'll propose it. Since traffic will probably be low and I'll definitely be around Sunday 12/25 would be my choice. I'd probably be starting on it at noon (6 AM EST). Testing disk space usage by running a full dump and load can be done at any time. The dump can be done on the live repository without ill effect and the loading can be done somewhere else on the file system, again with no side effects (apart from slowing down the machine due to disk access). I can kick that off any day this week in the morning, any preference? Sounds good. I'll announce that the repo will be down for maintenance on the 25th, Thanks again! Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: svn.zope.org borked
On 19 Dec 2005, at 22:08, Tim Peters wrote: [Jim] ... The whole repository is only about 800 megs. There are over 8 gigs free. Are the dump file or the file-based repo much larger in size the the Berkeley database? FYI, if you don't want to read the code ;-), the book says an FSFS repository is slightly smaller than the same thing under BDB: http://svnbook.red-bean.com/en/1.1/ch05.html Sounds good. Now as long as the dump file isn't over 6 GB in size we should be OK ;) jens ___ 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] Announcement: the Zope Subversion repository will be down for maintenance on December 25th, 2005
Jens Vagelpihl has graciously offered to convert the subversion repository to use a file-system back end. The repsository will be inaccessable for some portion of December 25. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Announcement: the Zope Subversion repository will be down for maintenance on December 25th, 2005
Jim Fulton wrote: Jens Vagelpihl has graciously offered to convert the subversion repository to use a file-system back end. Jim groans, That's Jens Vagelpohl. Thanks again Jens! Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Announcement: the Zope Subversion repository will be down for maintenance on December 25th, 2005
Jim Fulton wrote: Jens Vagelpihl has graciously offered to convert the subversion repository to use a file-system back end. Yay! I'll reserve further adulation until it comes back up intact. :) -- 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.org borked
On 19 Dec 2005, at 22:38, Sebastien Douche wrote: On 12/19/05, Jens Vagelpohl [EMAIL PROTECTED] wrote: That %$£@ BerkeleyDB backend was geborken again. svnadmin recover fixed it. Hi Jens! Does Zope server use svn server ? I had many problems with it (with the need to recover it each time). Generally, I recommand to use Subversion with Apache. Since, no problem. I appreciate the suggestion but this change is limited to the data backend switchover. Setting up anonymous access via HTTP is a separate activity for another day. You are right, though, access (at least anonymous access) via HTTP is preferable for a lot of reasons. jens ___ 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] Modifying a ZPT state based on a certain parameter
Mike, this is not a task for zpt but for a python script. I would suggest you write a script that gets all courses with a given db-state and check them to be in the corresponding workflow state. If not change the workflow state. this script you call regularly (daily, hourly, when ever the db has changed ..) Robert Takahashi, Michael wrote: Hi guys, I am running on Zope 2.7.6 with Plone 2.0.5. I am currently building a dynamic application using MySQL as the backend database. I'd like to be able to change a ZPT's state based on a parameter passed by the db. For example, I have a ZPT that displays information for a particular course. However, if this courses active field is set to NO, then I would like to be able to have the ZPT's state be visible. If the courses active field is set to yes then I would like to modify the state so that the ZPT is published. I'm thinking I'd probably have to use the wf_tool in conjunction with portal_workflow? A call similar to something like so: tal:condition=python:records.active=='yes' ...then implement the necessary call to modify the workflow and make the ZPT published and vice versa. Any help is greatly appreciated. Thanks, Mike ___ 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 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: sessions in the presence of conflicts
Chris McDonough identified a persistence problem with the routine(s) that
manage sessions variables. (Thanks Chris) I have put the correction in
place which resolved some (but not all) of the problems.
There are still problems which are apparently due conflicts in accessing
the session variables. To minimize frequency of conflicts, I am rewriting
several routines using Dieter's rules of the thumb (Thanks Dieter).
One routine being modified is a Script(Python) that initializes a number
of session variables. I am collecting the session values in a dictionary
and then use update to set their value, for example:
s = {}
s['alpha'] = 'a'
s['beta'] = 'b'
request['SESSION'].update(s)
Is the persistence machinery smart enough to detect this as a change? I
suspect that it has to be flagged since the assignment won't be seen.
Usually this means setting the _p_changed=1 attribute, but it is not clear
to me where to set it in this particular context.
--
___
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] Re: [Zope-dev] Re: sessions in the presence of conflicts
The interaction between sessions, conflicts, and persistence is a bit
confusing. I am still trying to understand the code in depth.
One thing is for sure, request.SESSION and/or request['SESSION'] must be
persistent for things to work. Mutable objects in the session variable
set (dictionaries and lists) have to be handled specially to get the
persistence machinery to recognize they have been changed.
In this case, I am trying to ensure that the session variables get
identified as persistent. My question is whether using update (an
implicit assignment) triggers the persistence mechanism. It is the
moral equivalent of writing
request['SESSION']['alpha'] = 'a'B
request['SESSION']['beta'] = 'b'
but I am unsure whether the persistence mechanism will recognize it as
such.
Doing session variable initialization in a Script(Python) object has a
downside because one cannot set a _p_changed attribute and so must rely on
the assignment paradigm. Perhaps the interface should be in a Product or
External Method which is less constrained.
Anyhow, David, thanks for the assist.
On Mon, 19 Dec 2005, David H wrote:
Dennis Allison wrote:
Chris McDonough identified a persistence problem with the routine(s) that
manage sessions variables. (Thanks Chris) I have put the correction in
place which resolved some (but not all) of the problems.
There are still problems which are apparently due conflicts in accessing
the session variables. To minimize frequency of conflicts, I am rewriting
several routines using Dieter's rules of the thumb (Thanks Dieter).
One routine being modified is a Script(Python) that initializes a number
of session variables. I am collecting the session values in a dictionary
and then use update to set their value, for example:
s = {}
s['alpha'] = 'a'
s['beta'] = 'b'
request['SESSION'].update(s)
Is the persistence machinery smart enough to detect this as a change? I
suspect that it has to be flagged since the assignment won't be seen.
Usually this means setting the _p_changed=1 attribute, but it is not clear
to me where to set it in this particular context.
Dennis,
Did you means request['SESSION']['someDictionary'].update(s)?
Anyway your idea seems correct - The SESSIONS chapter (at least on
plope.com) addresses SESSION staleness and mutable objects.
1) someDict = SESSION['someDict']
2) someDict['someKey'] = newValue
But (2) does not guarentee that a subsequent lookups like:
SESSION['someDict'] will return newValue.
But this WILL:
3) SESSION['someDict'] = someDict.
Which looks like your example. How this connect to your primary issue:
*conflicts* is not clear to me. :-\
David
--
___
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] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2337 Blamelist: andreasjung,chrisw,jim,poster BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2338 Blamelist: andreasjung,chrisw,jim,poster BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2339 Blamelist: andreasjung BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2340 Blamelist: andreasjung BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] [RfC] Removal of old stuff in Zope 2.10
Hi, for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy: - ZopeTutorial (could be ripped off without implications and made available for download on zope.org) - HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers) - Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org. And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list). -aj pgphfscQ9SYaC.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [RfC] Removal of old stuff in Zope 2.10
+1 on the lot if you are looking for votes. On Tue, 20 Dec 2005, Andreas Jung wrote: Hi, for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy: - ZopeTutorial (could be ripped off without implications and made available for download on zope.org) - HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers) - Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org. And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list). -aj -- ___ 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 )
