[Zope-dev] Re: ConflictError's worthwhile to note?
Dieter Maurer wrote: Jean-Marc Orliaguet wrote at 2005-12-4 22:28 +0100: ... In the log flle I'd like to be informed about events that are unexpected. Conflict errors of this kind occur by design. This argument is not convincing: In a similar way, I could argue that MemoryErrors are there by design. While it is true that *occational* ConflictErrors are nothing to worry about, a higher rate indicates that you soon may come into trouble -- because the risk increases that the automatic retries will not be able to recover and your users will see errors. Obviously, a ConflictError is far less important than a MemoryError, but a higher rate of conflicts should be analysed and if possible avoided. The conflict rate is related to the quality of your application design. I like quality related information in my logfiles -- to be able to take action before it is too late. But aren't you looking for some sort of application profiler? or some sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, still you wouldn't want to see in the log file: INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already) Similarly if the number of cache objects is too low, the application will run slowly, do you want to see: INFO: 1000 objects loaded into the cache in the last 5 minutes So why not instead create a product that logs occasional conflict errors? there is already in the ZMI in the database management screen some information about cached objects- Why not add the information that you are looking for there instead? /JM ___ 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: AcceleratedHTTPCache and virtual hosting (collector 1447)
Paul Winkler wrote: To the other respondents: Thanks for the suggestions, but I do not consider making AcceleratedHTTPCacheManager more flexible to be a test turd. Tres outlined a real use case for changing the code (see below). I don't understand why you guys consider this more invasive than monkeypatching, which is capable of causing obscure breakage in far-flung tests. But thanks anyway. Coding for testability is quite important, and is a credo of some of the trendy methodologies these days. I consider it perfectly acceptable to have a class attribute ConnectionClass for httplib.HTTPConnection or a method like getConnection that can then be subclassed or modified during tests. Provided it does not important performance issues. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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/tags/2.9.0b1/2.9/ Zope 2.9.0 b1
Andreas Jung wrote: Log message for revision 40580: Zope 2.9.0 b1 Changed: A Zope/tags/2.9.0b1/2.9/ -=- Copied: Zope/tags/2.9.0b1/2.9 (from rev 40579, Zope/branches/2.9) Huh, did you really want to do that? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: zLOG deprecation?
Florent Guillaume wrote: Just because you don't see the use in something doesn't mean it has to go away. There's nothing to stop you defining your own log levels with the python logging module. I regularly (eg: MailingLogger) define a report level that is 1 above INFO. In my book BLATHER is used for verbose INFO and is different than DEBUG and TRACE (both levels are useful too). INFO and BLATHER are for the administrator. DEBUG and TRACE are for the developer. Well, I don't think has been consistently applied to the whole source tree ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: ConflictError's worthwhile to note? (was: Re: [Zope-dev] Please vote about conflict errors logging)
Dieter Maurer wrote: In a similar way, I could argue that MemoryErrors are there by design. While it is true that *occational* ConflictErrors are nothing to worry about, a higher rate indicates that you soon may come into trouble -- because the risk increases that the automatic retries will not be able to recover and your users will see errors. Obviously, a ConflictError is far less important than a MemoryError, but a higher rate of conflicts should be analysed and if possible avoided. The conflict rate is related to the quality of your application design. I like quality related information in my logfiles -- to be able to take action before it is too late. It's not often you get my and Dieter agreeing, but a huge +1 to all of this from me! Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Ignoring Warnings
Dieter Maurer wrote: A colleague of mine will be very happy: The hundreds of (mostly stupid deprecation) warnings prevent him to efficiently find the true problems in the test runner reports. In principle, he could fix the warnings -- but they (mostly) come not from our code but third party one. And, if possible, he would perfer not to such third party code... So be explicit about this and add warn filters to your zope.conf, they work just fine in testing. (I have a big chunk of them for Plohn 2.1 if you're interested) Using the new option will mean you don't get any warnings of problems coming from your code :-( Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: zLOG deprecation?
Philipp von Weitershausen wrote: This would probably best be handled by one person, so if you are willing to do all the grepping and updating, making zLOG deprecated would just be a minor operation :). ...but one i don't know how to perform. What code would I insert and where? I'm happy to sign up for this, but can't promise when it'll happen... In zLOG.LOG one would call warnings.warn() Ah, okay :-) and the custom zLOG logging level constants could be wrapped in a deprecation warnings (zope.deprecation.deprecate) How would I do this? Can you give me an example? Well, stupid or not, the order in which BLATHER and DEBUG are should be preserved, even if it might not make sense. Question is if we actually need BLATHER in the future. For all I care we could rip it out. Likewise. Florent's the only person who seems to care about these arcane names ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: zLOG deprecation?
Tim Peters wrote: [Dennis Allison] We probably want an ALL level as well which would map to the NOTSET of the Python logging code and log everything. Why not call it NOTSET? Then you already have it ;-) Or forget it -- TRACE gets everything anyway. Yeah, what he said ;-) Also note that the code Florent pointed at is part of ZODB, not part of Zope. Zope shouldn't use it directly. Growing its own copy would be OK, or refactoring so that ZODB and Zope both get it from a shared new mini-project. Sorry, which code are we talking about here? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: ConflictError's worthwhile to note?
Jean-Marc Orliaguet wrote: But aren't you looking for some sort of application profiler? The point is that you need information to build a profile... sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, Indeed! still you wouldn't want to see in the log file: INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already) Well, yes, you do, but maybe not so verbosely ;-) We have Apache log the time to serve in microseconds for every single request, for later analysis. If you like, I'm happy to add a binary column to Z2.log ;-) Similarly if the number of cache objects is too low, the application will run slowly, Well, I don't know if you or I understand zodb's caching to know what to log... do you want to see: INFO: 1000 objects loaded into the cache in the last 5 minutes ...but yeah, if you could quantify that having 1000 objects loaded made a significant difference to the perfomance of the request where that was logged, then I'd be all for adding it... So why not instead create a product that logs occasional conflict errors? Because it's a lot more work than leaving it like it is but with improved inforamtion, which, from the vote, is going to keep the most people happy anyway ;-) there is already in the ZMI in the database management screen some information about cached objects- Why not add the information that you are looking for there instead? That's another possibility, are you volunteering to code it though? ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Please vote about conflict errors logging
1. Do you want these ConflictErrors retried logs to be at level:INFO 2. In addition, please specify if you feel those retriedConflictErrors should have their full traceback logged? no, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are alsologged to the error_log) should be additionally explicitely logged tothe event log, and at which level:ERROR ___ 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] Please vote about conflict errors logging
How about adding a URL to the logged message? Something like See http://zope.org/ConflictError; detailing the difference between a retried and unresovled ConflictErrors and how to recognise them in the event.log. ___ 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: 7 OK, 1 Failed
Summary of messages to the zope-tests list. Period Mon Dec 5 12:01:01 2005 UTC to Tue Dec 6 12:01:01 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Test failures - Subject: FAILED : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:24:18 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html Tests passed OK --- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:15:18 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003722.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:16:48 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003723.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:18:18 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003724.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:19:48 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003725.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:21:18 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003726.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:22:48 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003727.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Mon Dec 5 22:25:48 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003729.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 )
[Zope-dev] Re: SVN: Zope/branches/2.9/ deprecated FastCGI
Andreas Jung wrote: Log message for revision 40469: deprecated FastCGI Changed: U Zope/branches/2.9/doc/CHANGES.txt U Zope/branches/2.9/doc/WEBSERVER.txt U Zope/branches/2.9/lib/python/ZServer/datatypes.py [snip] Modified: Zope/branches/2.9/lib/python/ZServer/datatypes.py === --- Zope/branches/2.9/lib/python/ZServer/datatypes.py 2005-12-02 13:45:58 UTC (rev 40468) +++ Zope/branches/2.9/lib/python/ZServer/datatypes.py 2005-12-02 13:49:55 UTC (rev 40469) @@ -132,6 +132,11 @@ class FCGIServerFactory(ServerFactory): def __init__(self, section): + +import warnings +warnings.warn(Using FastCGI is deprecated. You should use mod_proxy + to run Zope with Apache, DeprecationWarning) + import socket if section.address.family == socket.AF_INET: address = section.address.address Andreas, this checkin made the tests fail for the build-bot (http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html). Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard to see where FCGIServerFactory() is called from. Maybe tests? 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: version.txt [was: make sdist]
Philipp von Weitershausen wrote: Andreas Jung wrote: make sdist: [EMAIL PROTECTED]:~/sandboxes/Zope-2.9/2.9.0b1: make sdist zpkg -C /develop/sandboxes/Zope-2.9/2.9.0b1/releases/Zope2.cfg 'version.txt' doesn't match any files in collection (in /develop/sandboxes/Zope-2.9/2.9.0b1/lib/python/zope/app/PACKAGE.cfg) temporary files are in /tmp/zpkg-50vtPj make: *** [sdist] Error 1 This is a very recent problem and a result of Jim's inconsistent handling of the version.txt matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch. Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this. The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag. I guess this would solve the problem, since the tag does have a version.txt. By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package. And there's the fact that this is a file that really *should* be generated by the release process. So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either). I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours. I agree, this should be doen for this release. 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: SVN: Zope/branches/2.9/ deprecated FastCGI
Philipp von Weitershausen wrote: this checkin made the tests fail for the build-bot (http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html). Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard to see where FCGIServerFactory() is called from. Maybe tests? I have to take that back, it's a problem due to Fred's speling fixing of occuring. Looking-into-it-ly, 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] Please vote about conflict errors logging
1. Do you want these ConflictErrors retried logs to be at level: INFO 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? no traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: Yes, at ERROR level /dario ___ 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 ) -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. Lyrics applied to programming application design: emancipate yourself from mental slavery - redemption song, b. marley ___ 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/branches/2.9/ deprecated FastCGI
Philipp von Weitershausen wrote: Philipp von Weitershausen wrote: this checkin made the tests fail for the build-bot (http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html). Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard to see where FCGIServerFactory() is called from. Maybe tests? I have to take that back, it's a problem due to Fred's speling fixing of occuring. Fixed now. ___ 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: version.txt [was: make sdist]
Philipp von Weitershausen wrote: Jim Fulton wrote: This is a very recent problem and a result of Jim's inconsistent handling of the version.txt matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch. Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this. I wouldn't dare to mention my suggestions regarding issues like these... ;) A common tree wouldn't make a difference here. A common release process would. Actually, a suggestion of Stephan's would make a difference. It would have helped someone if releases were regularly tested. Stephan has suggested that he'd like like buildbot to build releases as part of it's tests. I'd like to get there too. Unfortunately, we still need to resolve some technical issues to make this possible. The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag. I guess this would solve the problem, since the tag does have a version.txt. Yup, it does solve the problem. By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package. And there's the fact that this is a file that really *should* be generated by the release process. Yes. It sort of is already now. When you check out a Zope 2 tag and run make sdist to create the tarball, it will first generate the version.txt and put it in the right place. Cool So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either). I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours. I agree, this should be doen for this release. Done in r40592 on Zope 2.9 branch. 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: version.txt [was: make sdist]
Jim Fulton wrote: This is a very recent problem and a result of Jim's inconsistent handling of the version.txt matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch. Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this. I wouldn't dare to mention my suggestions regarding issues like these... ;) A common tree wouldn't make a difference here. A common release process would. My feeling is that common tree = common processes. But I'm not going to get into another discussion like we've had before, so I take your point on this not making a difference for granted. Actually, a suggestion of Stephan's would make a difference. It would have helped someone if releases were regularly tested. Stephan has suggested that he'd like like buildbot to build releases as part of it's tests. I'd like to get there too. Unfortunately, we still need to resolve some technical issues to make this possible. Buildbot is awesome and Stephan's suggestion is a excellent one. However, I consider buildbot a good safety-belt, not more. It's definitely not an excuse for not testing things properly in a local sandbox before checking in. Having it tested in *some* way at least, whether buildbot or not, would already be a huge improvement, of course. 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: version.txt [was: make sdist]
Philipp von Weitershausen wrote: Jim Fulton wrote: ... Buildbot is awesome and Stephan's suggestion is a excellent one. However, I consider buildbot a good safety-belt, not more. It's definitely not an excuse for not testing things properly in a local sandbox before checking in. There's a limit to how mech we can test on every checkin. The tests we do run already take several minutes to run. It's just not practical to test everything on every checkout. Having it tested in *some* way at least, whether buildbot or not, would already be a huge improvement, of course. Yup. 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: version.txt [was: make sdist]
Jim Fulton wrote: This is a very recent problem and a result of Jim's inconsistent handling of the version.txt matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch. Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this. I wouldn't dare to mention my suggestions regarding issues like these... ;) The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag. I guess this would solve the problem, since the tag does have a version.txt. Yup, it does solve the problem. By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package. And there's the fact that this is a file that really *should* be generated by the release process. Yes. It sort of is already now. When you check out a Zope 2 tag and run make sdist to create the tarball, it will first generate the version.txt and put it in the right place. So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either). I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours. I agree, this should be doen for this release. Done in r40592 on Zope 2.9 branch. 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: zLOG deprecation?
[Tim Peters] Also note that the code Florent pointed at is part of ZODB, not part of Zope. Zope shouldn't use it directly. Growing its own copy would be OK, or refactoring so that ZODB and Zope both get it from a shared new mini-project. [Chris Withers] Sorry, which code are we talking about here? Sorry, it wasn't Florent, it was Philipp; you replied to it: http://mail.zope.org/pipermail/zope-dev/2005-December/026039.html As he says there, the comment block was taken from ZODB/loglevels.py, which (besides just documenting this mess) implements TRACE and BLATHER levels for ZODB's use. ___ 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] Windows Installer for Zope 2.9+
Just noticed a checkin talking about the Windows Installer builder. I hope to find some time soon to take a look at that, since we now require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I recall talking with Mark about it and he said it would take some time to fix the build process. -- 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] Windows Installer for Zope 2.9+
[Sidnei da Silva] Just noticed a checkin talking about the Windows Installer builder. I hope to find some time soon to take a look at that, since we now require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I recall talking with Mark about it and he said it would take some time to fix the build process. I just asked Andreas (off-list) what his Windows plans were for 2.9 -- for various reasons I assumed someone else was already looking at this, but that assumption may be wrong (and given the lack of relevant checkins recently, almost certainly wrong frown). WRT Python 2.4, I never found a sane way to just _extract_ files from an .msi installer, so that part of the build process is dead meat now. In other bundle everything Windows installers at Zope Corp (such as for ZRS), I copy Python .pyd. .dll and .exe files from my own Python 2.4.2 installation instead. These binary files are all the build-Zope-installer process really needs from the Python Windows installer; the rest (like .py and .h files) can be taken from a Python tarball. You can avoid wrestling with .msi entirely this way. Possible headache: Python 2.4.2 requires msvcr71.dll, which is a Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the C runtime for VC 7.1), and one for which the redistribution conditions are unclear (at least to me). You can't assume that all Windows boxes already have this DLL. Another: I have no idea how the new zpkg-based build process will work with a Zope2-style installer. A Zope3-style installer is different in many ways (it's a plain distutils-based installer, and requires that the end user get and install Python pywin32 first). Plan on pain-time here. ___ 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] Windows Installer for Zope 2.9+
On Tue, Dec 06, 2005 at 12:35:49PM -0500, Tim Peters wrote: | [Sidnei da Silva] | Just noticed a checkin talking about the Windows Installer builder. I | hope to find some time soon to take a look at that, since we now | require Python 2.4 and Python 2.4 uses the 'Microsoft Installer'. I | recall talking with Mark about it and he said it would take some time | to fix the build process. | | I just asked Andreas (off-list) what his Windows plans were for 2.9 -- | for various reasons I assumed someone else was already looking at | this, but that assumption may be wrong (and given the lack of relevant | checkins recently, almost certainly wrong frown). | | WRT Python 2.4, I never found a sane way to just _extract_ files from | an .msi installer, so that part of the build process is dead meat now. | In other bundle everything Windows installers at Zope Corp (such as | for ZRS), I copy Python .pyd. .dll and .exe files from my own Python | 2.4.2 installation instead. These binary files are all the | build-Zope-installer process really needs from the Python Windows | installer; the rest (like .py and .h files) can be taken from a Python | tarball. You can avoid wrestling with .msi entirely this way. Just came to the same conclusion a few minutes ago. | Possible headache: Python 2.4.2 requires msvcr71.dll, which is a | Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the | C runtime for VC 7.1), and one for which the redistribution conditions | are unclear (at least to me). You can't assume that all Windows boxes | already have this DLL. Indeed. From reading around, seems like the saner thing is to make it a bold warning in the installer that the said dll is required instead of shipping it. | Another: I have no idea how the new zpkg-based build process will | work with a Zope2-style installer. A Zope3-style installer is | different in many ways (it's a plain distutils-based installer, and | requires that the end user get and install Python pywin32 first). | Plan on pain-time here. That's something I can play with :) -- 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] Windows Installer for Zope 2.9+
... [Tim] | Possible headache: Python 2.4.2 requires msvcr71.dll, which is a | Microsoft DLL (it's akin to msvcrt.dll for Visual Studio 6 -- it's the | C runtime for VC 7.1), and one for which the redistribution conditions | are unclear (at least to me). You can't assume that all Windows boxes | already have this DLL. [Sidnei] Indeed. From reading around, seems like the saner thing is to make it a bold warning in the installer that the said dll is required instead of shipping it. If you go the Zope3-route, it becomes a non-issue: the Windows Python installer will install msvcr71.dll if needed. Redistribution there isn't a problem because the PSF builds the binaries using a duly licensed Microsoft compiler. It's much fuzzier for derivative works (do the PSF's redistribution rights pass through to them? ask two lawyers, get four answers). Zope Corp could presumably invoke the same rights because parts of Zope are compiled with a legitimately licensed VC 7.1 -- but that might depend on who does the compliing. | Another: I have no idea how the new zpkg-based build process will | work with a Zope2-style installer. A Zope3-style installer is | different in many ways (it's a plain distutils-based installer, and | requires that the end user get and install Python pywin32 first). | Plan on pain-time here. That's something I can play with :) Feedback from users hasn't been exactly glowing, but it's much easier to build an installer that way (no externals, no makefiles, no Cygwin involved, ...). Here's how it's done for Zope3; I don't know / can't guess what would need to change for Zope2: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeWindowsRelease ___ 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: ConflictError's worthwhile to note?
Jean-Marc Orliaguet wrote at 2005-12-6 10:59 +0100: ... But aren't you looking for some sort of application profiler? or some sort of benchmarker? One could argue that slowly rendered pages are sign that the application is badly designed too, still you wouldn't want to see in the log file: You err: I do want to see them in the logfile and I stole Florents idea to use threadframe (in his DeadlockDebugger) to include a traceback for long running requests in the logfile. This way, it is easy not only to identify long running requests but also to get hints where they are spending their time... You will not believe how fast this has eliminated our remaining long running requests and especially to track down a non deterministic rarely occuring apparent deadlock situation... Thus, I can *very* strongly recommend to include such logging entries :-) INFO: the request took more than 2 seconds to be fullfilled (this has occured 10 times already) I agree with you about such stupid log entries. And your argument also holds for the stupid ConflictError log entries that Zope used to emit. But, we use our own Zope. And our Zope learned very early to emit informative ConflictError log entries -- those that show *which* object caused the ConflictError. These log entries gave valuable hints on how to improve our application. It is this experience that lets me argue for INFO level ConflictError log entries. By the way, I can be quite calm: whatever the Zope community might decide: our Zope will continue to log ConflictError messages at INFO level because we are interested to get early indications that potential problems crept into our application... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ConflictError's worthwhile to note?
Jean-Marc Orliaguet wrote at 2005-12-6 21:45 +0100: ... You err: I do want to see them in the logfile and I stole Florents idea to use threadframe (in his DeadlockDebugger) to include a traceback for long running requests in the logfile. This way, it is easy not only to identify long running requests but also to get hints where they are spending their time... You will not believe how fast this has eliminated our remaining long running requests and especially to track down a non deterministic rarely occuring apparent deadlock situation... Thus, I can *very* strongly recommend to include such logging entries :-) Absolutely, this is called debugging an application (= DEBUG, TRACE). Our sysadms are not really interested in this kind of info. Ours are -- especially to hunt down non-deterministic problems that actually are mail server problems (the above mentioned apparent deadlock was caused by a mail server occationally not responding for many minutes). They want to know if some action should be taken or not and messages such as these are misleading. Long running requests (and a high rate of ConflictErrors) *ARE* instances when some action should be taken -- probably to contact the vendor/developper. ... But, we use our own Zope. And our Zope learned very early to emit informative ConflictError log entries -- those that show *which* object caused the ConflictError. These log entries gave valuable hints on how to improve our application. Sure, but I think that you are both developer and sysadm at the same time. This is not the case everywhere. True. But ConflictErrors occur non-deterministically. Whenever, you are faced with non-deterministical problems, you are quite happy when the true operational system provides enough information to guide the analysis -- because it is so difficult to reproduce the behaviour in a development environment. -- 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 )
