[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 124 Blamelist: ctheune,schwendinger,zagy BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Shall I upload the release? Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
Am Donnerstag, den 19.04.2007, 05:59 -0400 schrieb [EMAIL PROTECTED]: The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 124 Blamelist: ctheune,schwendinger,zagy :( I see those errors on Zagy's Mac OS X machine and a couple of Linuxes. I also see the test runner crash with Total: 9615 tests, 1 failures, 0 errors Error in atexit._run_exitfuncs: Traceback (most recent call last): File /sw/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /sw/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /sw/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() ValueError: I/O operation on closed file Error in sys.exitfunc: Traceback (most recent call last): File /sw/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /sw/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /sw/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() ValueError: I/O operation on closed file Every now and then. I have prepared a release file and a tag for Zope 3.4.0a1. Question: Do we want to release the alpha with those issues known? Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Shall I upload the release? Re: buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
Christian Theune wrote: I also see the test runner crash with Total: 9615 tests, 1 failures, 0 errors Error in atexit._run_exitfuncs: Traceback (most recent call last): File /sw/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /sw/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /sw/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() ValueError: I/O operation on closed file Error in sys.exitfunc: Traceback (most recent call last): File /sw/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /sw/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /sw/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() ValueError: I/O operation on closed file Every now and then. I have prepared a release file and a tag for Zope 3.4.0a1. Question: Do we want to release the alpha with those issues known? Yeah. It's an alpha, so we still got time to fix this bug for the beta. By the way, does this error also occur, when you run the tests from said tarball? -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.4.0a1 released
19 April 2007 - The Zope 3 development team announces the Zope 3.4.0a1 release This release introduces support for binary large objects in the ZODB, provides a new postprocessing hook for publishing results and makes all Zope packages available as Python eggs. Development release and feedback This is a development release with alpha quality. It is intended for developers to check their applications for compatibility with the new features. This release *is not intended to be used in production environments*. We'd love to hear about any bugs you encounter. Please use our bug tracker, the mailing lists, and the IRC channel to contact us in case you encounter any problems. This alpha release will be succeeded by a beta which is expected to be available by 3rd May 2007. For status updates on our roadmap check: https://launchpad.net/zope3/3.4/+milestones What is Zope 3? --- Zope 3 is a web application server that continues to build on the heritage of Zope. It was rewritten from scratch based on the latest software design patterns and the experiences of Zope 2. The component architecture is the very core of Zope 3 that allows developers to create flexible and powerful web applications. Compatibility with Zope 2 -- We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2 use more and more of the Zope 3 packages. But we're not there yet. **You can't run Zope 2 applications in Zope 3.** New features and important changes -- - Updated the shipped ZODB to version 3.8 and introduced optimized handling for large files in conjunction with ZODB Blob support. Most Blob operations can be handled with O(1) effort now providing a scalable approach to handling large files. - Introduced IResult hook for postprocessing of publishing results. This replaces a similar private IResult hook from previous releases. It is a hook point into which a variety of interesting policies, including in-Zope pipelining, can be placed. See zope/publisher/httpresults.txt for more details, which itself points to the full details for IResult and IHTTPResponse.setResult in zope/publisher/interfaces/http.py. - zope.app.testing.functional.ZCMLLayer supports in-process tearDown. For backwards compatibility, this feature is disabled by default. You can enable it by passing ``allow_teardown=True`` to ``ZCMLLayer()`` or to ``defineLayer()``. - Removed unused and untested SFTP code from zope.app.twisted along with all the SSH keys. Removed all the SSL keys also. - Added new Decimal field type to zope.schema (and DecimalWidget in zope.app.form) and added security declarations for decimal.Decimal objects - Added new Time field type to zope.schema - Change the publication object to abort the current transaction if the transaction was doomed. Related to: http://www.zope.org/Collectors/Zope3-dev/655. There were many more features, restructurings and bugs fixed. Please consult the file `doc/CHANGES.txt` in the release for more information. Downloads - Zope 3 can be downloaded from: http://zope.org/Products/Zope3 Installation instructions for both Windows and Un*x/Linux are now available in the top level README.txt file of the distribution. The binary installer is recommended for Windows. Zope 3.4 requires Python 2.4.3 to run. You must also have zlib installed on your system. Resources - - Zope 3 Development Web Site: http://wiki.zope.org/zope3 - Zope 3 Developers Mailing List: http://mail.zope.org/mailman/listinfo/zope3-dev - Zope 3 Users Mailing List: http://mail.zope.org/mailman/listinfo/zope3-users - Bug tracker at launchpad: https://launchpad.net/zope3 - IRC Channel: #zope3-dev at irc.freenode.net Acknowledgments --- Much thanks to everyone who contributed to this release: Jim Fulton, Dmitry Vasiliev, Martijn Faassen, Christian Theune, Wolfgang Schnerring, Fred Drake, Marius Gedminas, Baiju M, Brian Sutherland, Gary Poster signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.4.0a1 released
Does it make sense to tag and release 3.4.0a1 eggs now? I would say so.
I think we should
* tag each individual project
* update the svn:external on each project to point to the 3.4.0a1 tag of
the Zope3 tree
* update each project's setup.py
* create an egg
* upload an egg
Martin Aspeli provided a script based upon which we can probably
automate a lot of those steps. I'm willing to look into this, if the
consensus is to ahead with this. Note that according to setuptool's
version semantics, '3.4.0a1' is a more recent version than '3.4dev':
from pkg_resources import parse_version as v
v('3.4.0a1') v('3.4dev')
True
That means easy_install will consider the alpha eggs more recent than
any dev egg, which seems logical.
Oh, and I'll need upload rights to download.zope.org :).
--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] a bug in the Zope 3 (and 2) page template engine
Hi there, I just tracked down what I believe is a bug in the Zope 3 page template engine. I didn't know it was a bug in the Zope 3 page template engine as I was tracking down a bug in Silva with Zope 2.10, which of course uses the Zope 3 page template engine. For the proposed solution, see the bottom of the mail. Let's consider the following code fragment: img tal:replace=structure python:'foo' tal:attributes=title python:'bar' / In Zope 2 before Zope 2.10, this line works without error. The tal:attributes line of course is pretty useless, as the whole img tag gets replaced anyway, but it doesn't bail out with an error. In Zope 2.10 and Zope 3.3, this gives us the following error [taken from Zope 3]: File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 271, in __call__ self.interpret(self.program) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 534, in do_optTag_tal self.no_tag(stuff[-2], stuff[-1]) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 516, in no_tag self.interpret(program) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 760, in do_insertStructure_tal self.insertHTMLStructure(text, repldict) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 784, in insertHTMLStructure gen = AltTALGenerator(repldict, self.engine, 0) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 65, in __init__ TALGenerator.__init__(self, expressionCompiler, xml) File /home/faassen/buildout/z331/lib/python/zope/tal/talgenerator.py, line 41, in __init__ self.CompilerError = expressionCompiler.getCompilerError() AttributeError: 'ZopeContext' object has no attribute 'getCompilerError' The difference between Zope 2 and Zope 3 is that ZopeContext is defined somewhere else, but that is irrelevant to this error. Let's take a look at talgenerator.py, line 41: self.CompilerError = expressionCompiler.getCompilerError() An AttributeError occurs here as getCompilerError does not exist. That's correct, as ZopeContext doesn't define one, nor should it. We should've gotten a ZopeEngine instance here, and in other code paths, that's what we get. This provides the interface ITALExpressionCompiler, which has getCompilerError. What is calling talgenerator with the wrong argument for expressionCompiler? Let's go to talinterpreter, around line 784: def insertHTMLStructure(self, text, repldict): from zope.tal.htmltalparser import HTMLTALParser gen = AltTALGenerator(repldict, self.engine, 0) That looks innocent enough. 'self.engine' is passed into AltTALGenerator (which in turns ends up in __init__ of TALGenerator). Unfortunately self.engine is very very badly named and is in fact a ZopeContext instance! Why does this bug not happen more often? Because insertHTMLStructure is *only* called if tal:attributes there. Let's go to the relevant section, do_insertStructure_tal in talinterpreter.py: def do_insertStructure_tal(self, (expr, repldict, block)): ... if not (repldict or self.strictinsert): # Take a shortcut, no error checking self.stream_write(text) return if self.html: self.insertHTMLStructure(text, repldict) else: self.insertXMLStructure(text, repldict) What is going on here is that normally, if no repldict exists (this is generated by tal:attributes), stream_write(text) is called. This works just fine. In the case where there *is* a repldict, the broken version of insertHTMLStructure is called, leading to this error. Now what's the hacky fix? It turns out that self.engine has an attribute _engine, that *is* the expression compiler. We can therefore fix the broken insertHTMLStructure like this: def insertHTMLStructure(self, text, repldict): from zope.tal.htmltalparser import HTMLTALParser gen = AltTALGenerator(repldict, self.engine._engine, 0) That's ugly however. I looked at the old Zope 2 implementation, and that looks prettier: def insertHTMLStructure(self, text, repldict): from zope.tal.htmltalparser import HTMLTALParser gen = AltTALGenerator(repldict, self.engine.getCompiler(), 0) Unfortunately, 'getCompiler' doesn't exist in Zope 3, so that won't work unless we add it again to the appropriate interface. I imagine adding this back would be the best way to go. Anyone have any objections? I will go and fix this in Zope 3.3 and trunk. I will add a test. I will need to make sure the interface also has getCompiler() added. This might
[Zope3-dev] zope.app.pluggableauth missing from download.zope.org
Hi, my recent buildout is not picking up pluggableauth. Looks like it got missed on download.zope.org. I took a look and it's not in the listing. Can someone put the egg there please. Many thanks. Getting distribution for zope.app.pluggableauth Error: Couldn't find a distribution for zope.app.pluggableauth. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.pluggableauth missing from download.zope.org
It's all good. I can live without it. Thanks Gary for the help just the same. Regards, David. Gary Poster wrote: (Resending--sorry David, meant to go to list) Huh. Just a thought, but I'm reasonably sure pluggableauth is effectively deprecated, replaced by zope.app.authentication. What's depending on this? Is my memory or understanding faulty about this? Gary On Apr 19, 2007, at 8:45 PM, David Pratt wrote: Hi, my recent buildout is not picking up pluggableauth. Looks like it got missed on download.zope.org. I took a look and it's not in the listing. Can someone put the egg there please. Many thanks. Getting distribution for zope.app.pluggableauth Error: Couldn't find a distribution for zope.app.pluggableauth. Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/gary%40zope.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a bug in the Zope 3 (and 2) page template engine
2007/4/19, Martijn Faassen [EMAIL PROTECTED]: Hi there, I just tracked down what I believe is a bug in the Zope 3 page template engine. I didn't know it was a bug in the Zope 3 page template engine as I was tracking down a bug in Silva with Zope 2.10, which of course uses the Zope 3 page template engine. For the proposed solution, see the bottom of the mail. Let's consider the following code fragment: img tal:replace=structure python:'foo' tal:attributes=title python:'bar' / In Zope 2 before Zope 2.10, this line works without error. The tal:attributes line of course is pretty useless, as the whole img tag gets replaced anyway, but it doesn't bail out with an error. But those attributes *do* work. If you call that image without the attributes, it won't have a title attribute. If you keep the tag as it is, it will have a title attribute. In fact, you can override an attribute that is provided by the replace, since the attributes are executed later. For instance you can override the alt attribute, which in the replace might be taken from the image's title, with some other string that's more informative. In Zope 2.10 and Zope 3.3, this gives us the following error [taken from Zope 3]: File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 271, in __call__ self.interpret(self.program) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 534, in do_optTag_tal self.no_tag(stuff[-2], stuff[-1]) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 516, in no_tag self.interpret(program) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 346, in interpret handlers[opcode](self, args) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 760, in do_insertStructure_tal self.insertHTMLStructure(text, repldict) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 784, in insertHTMLStructure gen = AltTALGenerator(repldict, self.engine, 0) File /home/faassen/buildout/z331/lib/python/zope/tal/talinterpreter.py, line 65, in __init__ TALGenerator.__init__(self, expressionCompiler, xml) File /home/faassen/buildout/z331/lib/python/zope/tal/talgenerator.py, line 41, in __init__ self.CompilerError = expressionCompiler.getCompilerError() AttributeError: 'ZopeContext' object has no attribute 'getCompilerError' The difference between Zope 2 and Zope 3 is that ZopeContext is defined somewhere else, but that is irrelevant to this error. Let's take a look at talgenerator.py, line 41: self.CompilerError = expressionCompiler.getCompilerError() An AttributeError occurs here as getCompilerError does not exist. That's correct, as ZopeContext doesn't define one, nor should it. We should've gotten a ZopeEngine instance here, and in other code paths, that's what we get. This provides the interface ITALExpressionCompiler, which has getCompilerError. What is calling talgenerator with the wrong argument for expressionCompiler? Let's go to talinterpreter, around line 784: def insertHTMLStructure(self, text, repldict): from zope.tal.htmltalparser import HTMLTALParser gen = AltTALGenerator(repldict, self.engine, 0) That looks innocent enough. 'self.engine' is passed into AltTALGenerator (which in turns ends up in __init__ of TALGenerator). Unfortunately self.engine is very very badly named and is in fact a ZopeContext instance! Why does this bug not happen more often? Because insertHTMLStructure is *only* called if tal:attributes there. Let's go to the relevant section, do_insertStructure_tal in talinterpreter.py: def do_insertStructure_tal(self, (expr, repldict, block)): ... if not (repldict or self.strictinsert): # Take a shortcut, no error checking self.stream_write(text) return if self.html: self.insertHTMLStructure(text, repldict) else: self.insertXMLStructure(text, repldict) What is going on here is that normally, if no repldict exists (this is generated by tal:attributes), stream_write(text) is called. This works just fine. In the case where there *is* a repldict, the broken version of insertHTMLStructure is called, leading to this error. Now what's the hacky fix? It turns out that self.engine has an attribute _engine, that *is* the expression compiler. We can therefore fix the broken insertHTMLStructure like this: def insertHTMLStructure(self, text, repldict): from zope.tal.htmltalparser import HTMLTALParser gen = AltTALGenerator(repldict, self.engine._engine, 0) That's ugly however. I looked at the old Zope 2 implementation, and that looks prettier: def insertHTMLStructure(self, text, repldict): from
Re: [Zope3-dev] a bug in the Zope 3 (and 2) page template engine
On 4/20/07, kit BLAKE [EMAIL PROTECTED] wrote: But those attributes *do* work. If you call that image without the attributes, it won't have a title attribute. If you keep the tag as it is, it will have a title attribute. This is some pretty freaky behavior for page templates, I think, but was by design. (I don't remember the driving use-case though; sorry.) The problem is that Martijn's replacement doesn't start with an element, so the attribute insertion fails. There should probably be a more explanatory error message in this case. I don't really like this behavior, and wouldn't miss it if it were disallowed, but the current expectation is that it work when the replacement starts with an element. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
