Re: [Zope-dev] configuration error
Bristow Thankachan wrote at 2008-8-23 15:53 +0530: We are stuck with a configuration error in porting zope2 to python2.5. Can anybody help us in fixing configuration error in the module Zope2. The full log of error message is given below. ... File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 57, in parse section = self.end_section(section, line[2:-1]) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 112, in end_section self.error(e[0]) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 177, in error raise ZConfig.ConfigurationSyntaxError(message, self.url, self.lineno) ConfigurationSyntaxError: invalid warning category: 'Zope2.Startup.tests.test_warnfilter.TestSchemaWarning' (line 8) I can only partially help you. Unfortunately, ZConfig is *VERY* bad with respect to the help it provides to understand the causes of so called configuration problems: It turns all exceptions (configuration problems or else) into ConfigurationErrors and in this process cuts of valuable tracebacks. Thus, we have heavy loss of information that would be helpful to analyse problems occuring during configuration but that are not configuration errors (but some import problems, or incompatibilities with the Python version as in your case). Very bad design in this respect When I meet such a case (ZConfig stupidly tells me about a ConfigurationError which is not (primarily) a configuration error), I temporarily change the ZConfig source: At places try: except : raise ...ConfigurationError(...) I add a raise line before the raise ...ConfigurationError(). By this, I get the original exception and especially the original traceback and then can usually quickly find the original problem. In your special case, some quessing may give a faster result. It is likely that the original problem comes from Zope2.Startup.warnfilter.warn_category. You can put a breakpoint there and then determine by single stepping the cause. An additional guess may give even a faster result. Problably the following lines are to blame: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise ValueError(invalid warning category: %s % `category`) Almost surely, Python made its Warning class a new style class such that isinstance(cat, types.ClassType) fails now. -- 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] Zope Tests: 4 OK, 1 Unknown
Summary of messages to the zope-tests list. Period Sat Aug 23 11:00:00 2008 UTC to Sun Aug 24 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Unknown --- Subject: UNKNOWN : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sat Aug 23 20:39:50 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010055.html Tests passed OK --- Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 23 20:41:20 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010056.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 23 20:42:50 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010057.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 23 20:44:20 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010058.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 23 20:45:51 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010059.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] bfg + vudo IRC chat Monday 8/25 4pm EST
Tomorrow, Monday 8/25 at 4pm EST we will be chatting on IRC about the future of the repoze.bfg web application framework (see http:// static.repoze.org/bfgdocs) and the Vudo project (see http:// groups.google.com/group/vudo), which is a system for point and spray web authoring. All are invited. Time: 8/25/2008 4pm EST Place: irc://freenode.net/#repoze - C ___ 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] configuration error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bristow Thankachan wrote: hi all, We are stuck with a configuration error in porting zope2 to python2.5. Can anybody help us in fixing configuration error in the module Zope2. The full log of error message is given below. Running tests at level 1 /home/zope/ztrunk25/lib/python/ZPublisher/HTTPResponse.py:19: RuntimeWarning: Python C API version mismatch for module zlib: This Python has API version 1013, module zlib has version 1012. import zlib, struct Running unit tests: Running: 6/43 (14.0%) testStringException1 (testExceptionHook.ExceptionHookTest)/home/zope/ztrunk25/lib/python/Zope2/App/tests/testExceptionHook.py:120: DeprecationWarning: raising a string exception is deprecated raise 'unauthorized', 'x' /home/zope/ztrunk25/lib/python/Zope2/App/startup.py:182: DeprecationWarning: raising a string exception is deprecated raise 7/43 (16.3%) testStringException2 (testExceptionHook.ExceptionHookTest)/home/zope/ztrunk25/lib/python/Zope2/App/tests/testExceptionHook.py:125: DeprecationWarning: raising a string exception is deprecated raise 'redirect', 'x' 41/43 (95.3%) test_behavior (...artup.tests.test_warnfilter.TestWarnFilter) Error in test test_behavior (Zope2.Startup.tests.test_warnfilter.TestWarnFilter) Traceback (most recent call last): File /home/zope/usr/lib/python2.5/unittest.py, line 260, in run testMethod() File /home/zope/ztrunk25/lib/python/Zope2/Startup/tests/test_warnfilter.py, line 90, in test_behavior ) File /home/zope/ztrunk25/lib/python/Zope2/Startup/tests/test_warnfilter.py, line 69, in load_config_text conf, handler = ZConfig.loadConfigFile(schema, sio) File /home/zope/ztrunk25/lib/python/ZConfig/loader.py, line 41, in loadConfigFile return _get_config_loader(schema, overrides).loadFile(file, url) File /home/zope/ztrunk25/lib/python/ZConfig/loader.py, line 75, in loadFile return self.loadResource(r) File /home/zope/ztrunk25/lib/python/ZConfig/loader.py, line 229, in loadResource self._parse_resource(sm, resource) File /home/zope/ztrunk25/lib/python/ZConfig/loader.py, line 280, in _parse_resource parser.parse(matcher) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 57, in parse section = self.end_section(section, line[2:-1]) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 112, in end_section self.error(e[0]) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 177, in error raise ZConfig.ConfigurationSyntaxError(message, self.url, self.lineno) ConfigurationSyntaxError: invalid warning category: 'Zope2.Startup.tests.test_warnfilter.TestSchemaWarning' (line 8) Ran 43 tests with 0 failures and 1 errors in 15.046 seconds. Tests with errors: test_behavior (Zope2.Startup.tests.test_warnfilter.TestWarnFilter) Because Warning shifts from being an old-style class in 2.4 to a new-style class in 2.5, the check for 'isinstance(w, types.ClassType))' won't work. Instead:: - --- % - --- lib/python/Zope2/Startup/warnfilter.py(revision 90174) +++ lib/python/Zope2/Startup/warnfilter.py (working copy) @@ -35,7 +35,7 @@ cat = getattr(m, klass) except AttributeError: raise ValueError(unknown warning category: %s % `category`) - -if (not isinstance(cat, types.ClassType) or +if (not isinstance(cat, type(Warning)) or not issubclass(cat, Warning)): raise ValueError(invalid warning category: %s % `category`) return cat - --- % I have checked this in on the trunk: http://svn.zope.org/Zope/trunk/?rev=90177view=rev Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIsaUN+gerLs4ltQ4RAgwTAJ9roddcaighZb1IUIz8EVBeaFBe7wCfQ5h6 pvNolvSZCYczQMileZ8aDvc= =tRMb -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] z3c.formwidget.query - incorrect interface implementation?
Hi, I'm trying to build a widget that allows for auto-complete of items in a vocabulary, but also allows additional (string) values to be added. To understand how that works, I am digging into z3c.formwidget.query, and it looks to me like it's making incorrect assumptions about its own interfaces. In its interfaces.py, we have: from zope.schema.interfaces import ISource, IVocabularyTokenized class IQuerySource(ISource, IVocabularyTokenized): def search(query_string): Return values that match query. so, an IQuerySource is an ISource, which is: class ISource(Interface): def __contains__(value): Return whether the value is available in this source and also an IVocabularyTokenized, which is: class IBaseVocabulary(ISource): def getTerm(value): Return the ITerm object for the term 'value'. If 'value' is not a valid term, this method raises LookupError. # BBB vocabularies are pending deprecation, hopefully in 3.3 class IIterableVocabulary(Interface): def __iter__(): Return an iterator which provides the terms from the vocabulary. def __len__(): Return the number of valid terms, or sys.maxint. class IVocabulary(IIterableVocabulary, IBaseVocabulary): Vocabulary which is iterable. class IVocabularyTokenized(IVocabulary): def getTermByToken(token): Return an ITokenizedTerm for the passed-in token. If `token` is not represented in the vocabulary, `LookupError` is raised. First of all, it seems strange then that IQuerySource should explicitly need to say it's derived from ISource since IVocabularyTokenized already promises that. However, more importantly, in the README.txt of z3c.formwidget.query we have this: ... def getTermByValue(self, value): ... return self.vocabulary.by_value[value] and similarly, in widget.py: map(terms.add, map(source.getTermByValue, filter(lambda value: value and value not in values, selection))) If I'm not reading this wrong, it seems to me that z3c.formwidget.query is using getTermByValue() (which I can't find anywhere else) instead of getTermByToken() as defined by IVocabularyTokenized. Is this correct? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.formwidget.query - incorrect interface implementation?
Martin Aspeli wrote: I'm trying to build a widget that allows for auto-complete of items in a vocabulary, but also allows additional (string) values to be added. To understand how that works, I am digging into z3c.formwidget.query, and it looks to me like it's making incorrect assumptions about its own interfaces. This can very well be; the defense would be that the entire vocabulary code is full of odd interfaces that don't really form a complete story. If I'm not reading this wrong, it seems to me that z3c.formwidget.query is using getTermByValue() (which I can't find anywhere else) instead of getTermByToken() as defined by IVocabularyTokenized. I don't remember the details, but the implementation may be incorrect although functional. Certainly, it's made to good use by ``plone.app.z3cform`` and a number of other modules. You're more than welcome to improve or devise an alternative implementation. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.formwidget.query - incorrect interface implementation?
Malthe Borch wrote: Martin Aspeli wrote: I'm trying to build a widget that allows for auto-complete of items in a vocabulary, but also allows additional (string) values to be added. To understand how that works, I am digging into z3c.formwidget.query, and it looks to me like it's making incorrect assumptions about its own interfaces. This can very well be; the defense would be that the entire vocabulary code is full of odd interfaces that don't really form a complete story. For what it's worth, I agree. :-) If I'm not reading this wrong, it seems to me that z3c.formwidget.query is using getTermByValue() (which I can't find anywhere else) instead of getTermByToken() as defined by IVocabularyTokenized. I don't remember the details, but the implementation may be incorrect although functional. Certainly, it's made to good use by ``plone.app.z3cform`` and a number of other modules. You're more than welcome to improve or devise an alternative implementation. Have you ever tested it with a source other than the one in queryselect's example code and the one in plone.app.z3cform.queryselect? Those are the only places I can see getTermByValue(). The fix would probably be to make sure it uses tokens everywhere and implement getTermByToken. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.formwidget.query - incorrect interface implementation?
On Sun, Aug 24, 2008 at 07:30:24PM +0100, Martin Aspeli wrote: I'm trying to build a widget that allows for auto-complete of items in a vocabulary, but also allows additional (string) values to be added. To understand how that works, I am digging into z3c.formwidget.query, and it looks to me like it's making incorrect assumptions about its own interfaces. snip class IBaseVocabulary(ISource): def getTerm(value): Return the ITerm object for the term 'value'. If 'value' is not a valid term, this method raises LookupError. snip class IVocabularyTokenized(IVocabulary): def getTermByToken(token): Return an ITokenizedTerm for the passed-in token. If `token` is not represented in the vocabulary, `LookupError` is raised. snip However, more importantly, in the README.txt of z3c.formwidget.query we have this: ... def getTermByValue(self, value): ... return self.vocabulary.by_value[value] and similarly, in widget.py: map(terms.add, map(source.getTermByValue, filter(lambda value: value and value not in values, selection))) If I'm not reading this wrong, it seems to me that z3c.formwidget.query is using getTermByValue() (which I can't find anywhere else) instead of getTermByToken() as defined by IVocabularyTokenized. That does look like a bug. However, without looking very deeply at the code,the fix would be to use getTerm, not getTermByToken. I wouldn't mind seeing getTerm renamed to getTermByValue, but that's probably difficult to do without breaking backwards-compatibility. Marius Gedminas -- I used to think I was indecisive, but now I'm not so sure. signature.asc Description: Digital 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 )
