Re: [Zope-dev] Re: Deprecation Warning
vyshakh, vyshakh krishnan wrote: Many of the the warnings in other modules are found similar to this warning. Please enumerate them. Please read and respond to all points raised in mails. Unless I missed something, we're still waiting to see the full list of the warnings in other modules. cheers, 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: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
Stephan Richter a écrit : Log message for revision 89104: * Added latest version of zope.app.security to avoid deprecation warnings. * Added history file for the KGS to hopefully create better release notes. Did you miss the CHANGES.txt in zope.release ? We have two histories now. How did you choose the 3.4.0c5 version? I mean, where does the 5 come from? Christophe ___ 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: 5 OK
Summary of messages to the zope-tests list. Period Thu Jul 31 11:00:00 2008 UTC to Fri Aug 1 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Jul 31 20:56:10 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009940.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 31 20:57:41 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009941.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 31 20:59:11 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009942.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 31 21:00:41 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009943.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 31 21:02:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009944.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: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
On Friday 01 August 2008, Christophe Combelles wrote: Did you miss the CHANGES.txt in zope.release ? We have two histories now. Nope, but that file tracks the package -- source code -- changes of zope.release. I wanted a separate file that tracks the changes to the controlled-packages.cfg file. How did you choose the 3.4.0c5 version? I mean, where does the 5 come from? We have been doing c* KGS releases all along. See http://download.zope.org/zope3.4/intro.html I just have not bothered updating the Zope3 tree, making packages and announcements. It just costs too much time. Unless Marius or someone else signs up for producing TAR ball releases and announces them, I will only create a TAR ball and announcement for Zope 3.4.0 final. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 3.4 release policy
Hey Stephan, Thanks for doing all the work on KGS and the Zope 3.4.0 release. There are unfortunately a few things in this process that have me somewhat confused. I hope we can work out a way to clarify the process for 3.4.x and helping to clarify the process for 3.5.x. Firstly, could you add release dates to this page please? http://download.zope.org/zope3.4/intro.html I know that 3.4.0c1 was the latest release from january 31st until at least may, when we moved Grok over to that list. Then rather silently and somewhat suddenly I find out there have been 4 more release candidate releases. What is driving these changes? There's a changelog now I saw you mention, where should I look? Here I was thinking Grok was synched up to the latest and greatest 3.4.x since its latest 0.13 release, but this is now not the case anymore. We had c1 which lasted so long that I had started to treat it as the final. We have been in release candidate space for Zope 3.4 for a very long time; since january 31th. Do we really need 5 release candidates over a period of half a year? Would we really have been harmed if we'd released 3.4.0 final in, say, february, and were now doing 3.4.x releases? What's the current plan for the final? What are the conditions that need to be reached to make a final release? Regards, Martijn ___ 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: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
Stephan Richter a écrit : On Friday 01 August 2008, Christophe Combelles wrote: Did you miss the CHANGES.txt in zope.release ? We have two histories now. Nope, but that file tracks the package -- source code -- changes of zope.release. I wanted a separate file that tracks the changes to the controlled-packages.cfg file. In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt. The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope. I would tend to: - create a tag for all missing candidates - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg Christophe How did you choose the 3.4.0c5 version? I mean, where does the 5 come from? We have been doing c* KGS releases all along. See http://download.zope.org/zope3.4/intro.html I just have not bothered updating the Zope3 tree, making packages and announcements. It just costs too much time. Unless Marius or someone else signs up for producing TAR ball releases and announces them, I will only create a TAR ball and announcement for Zope 3.4.0 final. Regards, Stephan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3.4 release policy
On Friday 01 August 2008, Martijn Faassen wrote: Thanks for doing all the work on KGS and the Zope 3.4.0 release. Thank Marius for getting into it and giving me some incentive to work on it again too. :-) There are unfortunately a few things in this process that have me somewhat confused. I hope we can work out a way to clarify the process for 3.4.x and helping to clarify the process for 3.5.x. I am confused too. :-) I am struggling between too-little time and formalizing the process. ;-) Firstly, could you add release dates to this page please? I thought the same thing last night too when looking at the now rather lengthy list of releases on the intro page. Since the page is auto-generated, the generating script has to be updated. We have two options: 1. Add a release-date field to the [KGS] section in controlled-packages.cfg. 2. Parse KGS-HISTORY.txt. This would also allow us to generate change logs for each release. Thoughts? http://download.zope.org/zope3.4/intro.html I know that 3.4.0c1 was the latest release from january 31st until at least may, when we moved Grok over to that list. Then rather silently and somewhat suddenly I find out there have been 4 more release candidate releases. What is driving these changes? Marius started working on the KGS in the last week, since he is porting one of his apps from Zope 3.2 to 3.4. He needed to do a bunch of fixes to make it work. Also, he has set the goal for himself to fix the remaining failing tests. I also had some motivation to remove some deprecation warnings. So the last 4 candidates all happened in the last 2 weeks. There's a changelog now I saw you mention, where should I look? zope.release has now a `KGS-HISTORY.txt` file. Here I was thinking Grok was synched up to the latest and greatest 3.4.x since its latest 0.13 release, but this is now not the case anymore. We had c1 which lasted so long that I had started to treat it as the final. You pretty much are at the latest. :-) We have been in release candidate space for Zope 3.4 for a very long time; since january 31th. Do we really need 5 release candidates over a period of half a year? Would we really have been harmed if we'd released 3.4.0 final in, say, february, and were now doing 3.4.x releases? The only reason I did not release in February was time. I signed up with Keas early in February and have been incredibly busy since then. Now that Marius is working on the release too, I want to honor his work and let him fix tests and make sure his app runs on Zope 3.4. What's the current plan for the final? What are the conditions that need to be reached to make a final release? From my point of view, my conditions would be: - Let Marius ensure his app works with Zope 3.4. - Let Marius finish fix the final test failures. He invested already a lot of time. (I know, because I gave up on the final failing ones.) - Nice to have: Update all packages in the KGS to their latest bug fix release. My larger concern is to make the release process much smoother and automated, so that the burden of making a release becomes much smaller. I think the following scripts could be written without too much effort: - Setup a buildbot for KGS releases. I think Marius set one up already. The test output could become part of some page linked from intro.html. I am thinking in particular of the total number of tests (marketing) and the failures. - Upload the KGS-HISTORY.txt and parse it for the release date and changelog. (Note that this parser could be written to understand our CHANGES.txt format and we could even pull in Changelogs from all the updated packages!) - Add the date and changelog info to intro.html. - When uploading a new version of the KGS, automatically update the Zope 3 tree branch as well and create a release tag. Uses also the changelog information for the tree CHANGES.txt file. - Automatically create a Zope 3 tree TAR ball and upload it to zope.org. Generate a link for it in the intro page as well. - Automatically create a release E-mail and send it to zope-dev and zope-users. This should not be more than a days work for one of the core developers. With this in place, cutting a release would become a matter of calling /bin/upload from the zope.release package. What do you guys think? -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
On Friday 01 August 2008, Christophe Combelles wrote: I wanted a separate file that tracks the changes to the controlled-packages.cfg file. In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt. Okay, I am open to suggestions and want to hear others give an opinion too. The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope. It is. I and Marius simply did not create those tags. I would tend to: - create a tag for all missing candidates Cool, I take you up on that. - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg These are two tasks: - Update KGS-HISTORY.txt to contain the changes of the previous releases. (Luckily you can just look at the SVN changelog for controlled-packages.cfg.) I take you up on that one as well! :-) - Merge KGS-HISTORY.txt into CHANGES.txt. I want to hear a couple more opinions on that. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3.4 release policy
On Fri, Aug 01, 2008 at 08:26:02AM -0700, Stephan Richter wrote: We have been in release candidate space for Zope 3.4 for a very long time; since january 31th. Do we really need 5 release candidates over a period of half a year? Would we really have been harmed if we'd released 3.4.0 final in, say, february, and were now doing 3.4.x releases? The only reason I did not release in February was time. I signed up with Keas early in February and have been incredibly busy since then. Now that Marius is working on the release too, I want to honor his work and let him fix tests and make sure his app runs on Zope 3.4. My app already runs (well, all the tests do; it'd be nice to do some manual user testing, and especially test data migration from existing instances). What I feel uneasy about is declaring a 3.4.0 final when there are still broken tests. I also want to investigate the weird TALES iterator change where 'odd' and 'even' swapped meanings between 3.2 and 3.4. If that swap happened before 3.3, it's too late, but if it happened after 3.3, then I'm tempted to call it a regression and fix it. I also have inclinations to clean up the tests that don't fail, but have other downsides (random confusing output to stderr, not supporting layer teardown). I don't consider them to be release blockers, but I think these would be nice to have in a 3.4.0 final. What's the current plan for the final? What are the conditions that need to be reached to make a final release? From my point of view, my conditions would be: - Let Marius ensure his app works with Zope 3.4. - Let Marius finish fix the final test failures. He invested already a lot of time. (I know, because I gave up on the final failing ones.) - Nice to have: Update all packages in the KGS to their latest bug fix release. My larger concern is to make the release process much smoother and automated, so that the burden of making a release becomes much smaller. I think the following scripts could be written without too much effort: - Setup a buildbot for KGS releases. I think Marius set one up already. http://zope3.pov.lt/buildbot/ It assumes that the canonical way to run all the tests for the KGS packages is to use zope.release's bin/generate-buildout. You'll notice I'm only running tests on Linux (four varieties of). If anyone wants to offer a Win32/MacOS buildbot slave, email me. What you probably won't immediatelly notice on that page is that I'm running the tests with system python, with an undetermined set of packages installed in site-packages. I may change it to use a clean python some day, but that's unlikely (lack of time and interest), unless some of the test failures will be traced to problems with the system python. The test output could become part of some page linked from intro.html. I am thinking in particular of the total number of tests (marketing) and the failures. Buildbot is a flexible thing; what it lacks is a cookbook. :-/ - Upload the KGS-HISTORY.txt and parse it for the release date and changelog. (Note that this parser could be written to understand our CHANGES.txt format and we could even pull in Changelogs from all the updated packages!) - Add the date and changelog info to intro.html. - When uploading a new version of the KGS, automatically update the Zope 3 tree branch as well and create a release tag. Uses also the changelog information for the tree CHANGES.txt file. +1 for automatically updating the tree. I don't see the need for automatically creating release tags. We don't do that for smaller projects (not every bugfix made to zope.foo release branch immediately causes a new zope.foo release), so why do it for the KGS? An explicit tag and release the current tip of the KGS branch action would be sufficient, IMO. Besides, delaying a release will give people (and buildbots) a chance to test in on various platforms. - Automatically create a Zope 3 tree TAR ball and upload it to zope.org. Generate a link for it in the intro page as well. This should be automated together with the tagging. - Automatically create a release E-mail and send it to zope-dev and zope-users. This should not be more than a days work for one of the core developers. With this in place, cutting a release would become a matter of calling /bin/upload from the zope.release package. What do you guys think? Sounds reasonable. I personally have little interest in tarball releases. Things that I care about: - 3.4 branch in Subversion - 3.4 versions.cfg - having all the tests pass on Python 2.4 on several versions of Ubuntu Linux (32- and 64-bit) - having all the tests pass on Python 2.5 on several versions of Ubuntu Linux (32- and 64-bit) - having *automated* regression notifications for changes to the KGS that break one or more tests - having the tests pass cleanly with no extra output By care about I mean am willing to do work to
Re: [Zope-dev] Re: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
Stephan Richter a écrit : On Friday 01 August 2008, Christophe Combelles wrote: I wanted a separate file that tracks the changes to the controlled-packages.cfg file. In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt. Okay, I am open to suggestions and want to hear others give an opinion too. The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope. It is. I and Marius simply did not create those tags. I would tend to: - create a tag for all missing candidates Cool, I take you up on that. Done. - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg These are two tasks: - Update KGS-HISTORY.txt to contain the changes of the previous releases. (Luckily you can just look at the SVN changelog for controlled-packages.cfg.) I take you up on that one as well! :-) I've updated KGS-HISTORY.txt and CHANGES.txt. Actually KGS-HISTORY.txt is just a reformatted svn diff between successive versions. I'm not sure it has a real added value, excepted when there are explanations about the version upgrades. Christophe - Merge KGS-HISTORY.txt into CHANGES.txt. I want to hear a couple more opinions on that. Regards, Stephan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3.4 release policy
On Fri, Aug 1, 2008 at 2:06 PM, Marius Gedminas [EMAIL PROTECTED] wrote: I also want to investigate the weird TALES iterator change where 'odd' and 'even' swapped meanings between 3.2 and 3.4. If that swap happened before 3.3, it's too late, but if it happened after 3.3, then I'm tempted to call it a regression and fix it. +1 I also have inclinations to clean up the tests that don't fail, but have other downsides (random confusing output to stderr, not supporting layer teardown). I don't consider them to be release blockers, but I think these would be nice to have in a 3.4.0 final. 3.4.0 is already at rc5, right? If so, I'd be disinclined to do pure refactor-y type things to it. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] bad zope.size to remove from PyPI
Hi, could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090 This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211) Christophe ___ 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: bad zope.size to remove from PyPI
Christophe Combelles wrote: could someone remove this package from the PyPI : http://pypi.python.org/pypi/zope.size/3.4dev-r73090 This is an empty development version, considered more recent by PyPI than the latest released version 3.4.0. (which is r78211) Done. In case anybody's wondering how this complies with our no removal of any release whatsoever policy [1], be assured that a 3.4dev-r73090 thing isn't a release by our standards. This version number not only contains the 'dev' marker, meaning it must have come from a development branch (possibly the trunk), it also contains the -rXXX suffix meaning it was made right from a subversion checkout without having created a tags first (why else would you want to include the revision number). [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt ___ 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: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
Christophe Combelles wrote: Stephan Richter a écrit : On Friday 01 August 2008, Christophe Combelles wrote: Did you miss the CHANGES.txt in zope.release ? We have two histories now. Nope, but that file tracks the package -- source code -- changes of zope.release. I wanted a separate file that tracks the changes to the controlled-packages.cfg file. In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt. Exactly. The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope. I would tend to: - create a tag for all missing candidates - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg +1 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] Mouting + Logging Errors after Zope Upgrade 2.7.4 -- 2.11.1
Hello! My company wants me to upgrade the timeworn zope-2.7.4 to one of the newest ones available. I decided to take zope-2.11.1 but after installing and running it in debug-mode i get the following error-messages: 2008-08-01T09:04:39 ERROR Zope.ZODBMountPoint Failed to mount database. ZODB.lock_file.LockError (Couldn't lock 'D:\\workspace_zope\\xla-2008/var/Stdcontainer_o.fs.lock') Traceback (most recent call last): File D:\zope\2.11.1\Zope\lib\python\Products\ZODBMountPoint\MountedObject.py, line 257, in _getOrOpenObject File D:\zope\2.11.1\Zope\lib\python\Products\ZODBMountPoint\MountedObject.py, line 147, in _getMountedConnection File D:\zope\2.11.1\Zope\lib\python\Products\ZODBMountPoint\MountedObject.py, line 157, in _getDB File D:\zope\2.11.1\Zope\lib\python\Zope2\Startup\datatypes.py, line 288, in getDatabase db = factory.open(name, self.databases) File D:\zope\2.11.1\Zope\lib\python\Zope2\Startup\datatypes.py, line 186, in open DB = self.createDB(database_name, databases) File D:\zope\2.11.1\Zope\lib\python\Zope2\Startup\datatypes.py, line 183, in createDB return ZODBDatabase.open(self, databases) File D:\zope\2.11.1\Zope\lib\python\ZODB\config.py, line 97, in open File D:\zope\2.11.1\Zope\lib\python\ZODB\config.py, line 135, in open File D:\zope\2.11.1\Zope\lib\python\ZODB\FileStorage\FileStorage.py, line 113, in __init__ File D:\zope\2.11.1\Zope\lib\python\ZODB\lock_file.py, line 80, in __init__ File D:\zope\2.11.1\Zope\lib\python\ZODB\lock_file.py, line 42, in _lock_file LockError: Couldn't lock 'D:\\workspace_zope\\xla-2008/var/Stdcontainer_o.fs.lock' TypeError: not all arguments converted during string formatting Traceback (most recent call last): File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 731, in emit File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 617, in format File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 405, in format File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 276, in getMessage self.cfg.eventlog() These are not the only ones, I get the first one for 5/18 databases and the second one 6 times when running the /manage site Do I have to be worried about those error messages or not? Another thing is that those messages appear only once every restart but the functionality of the pages hostet isn't affected... Hope you can help me, -- Wolfgang___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Mouting + Logging Errors after Zope Upgrade 2.7.4 -- 2.11.1
Wolfgang Lausenhammer wrote: LockError: Couldn't lock 'D:\\workspace_zope\\xla-2008/var/Stdcontainer_o.fs.lock' Can the user the zope process is running as write to this file? (or create it, since it likely doesn't exist?) TypeError: not all arguments converted during string formatting Traceback (most recent call last): File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 731, in emit File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 617, in format File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 405, in format File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 276, in getMessage self.cfg.eventlog() This looks like a bug. Would be good to find where the incorrect logging call is and fix it :-S cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: Re: [Zope] Mouting + Logging Errors after Zope Upgrade 2.7.4 -- 2.11.1
Wolfgang Lausenhammer wrote: LockError: Couldn't lock 'D:\\workspace_zope\\xla-2008/var/Stdcontainer_o.fs.lock' Can the user the zope process is running as write to this file? (or create it, since it likely doesn't exist?) The file is existing. I tried to delete all the .index, .lock, .tmp files in the var-folder and zope re-creates them on calling the /manage site, so there shouldn't be a problem with writing-permissions TypeError: not all arguments converted during string formatting Traceback (most recent call last): File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 731, in emit File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 617, in format File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 405, in format File D:\zope\2.11.1\Python\Lib\logging\__init__.py, line 276, in getMessage self.cfg.eventlog() This looks like a bug. Would be good to find where the incorrect logging call is and fix it :-S With the old 2.7.4 version it does work. I also tried to upgrade it in steps, with zope-2.8.6 it still works and none of those two error messages appear. With zope-2.9.8 at least one of these errors appeared. Has there anything changed in the interface within those versions? The changelog of 2.9.0 says: Zope now utilizes ZODB 3.6. It had previously used ZODB 3.4. As a result, the DBTab package was removed, as ZODB 3.6 has multidatabase support that makes DBTab unnecessary. Could this cause those errors? -- Wolfgang___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Asking advice on best way to perform an interaction with an external webservice
Hi all. I need to implement an interaction with an external web service. The external webservice basically can either provide or accept messages from my zope application. The messages are either produced by my application (and need to be sent to the external application via web service) or produced by the external application, and must be processed by mine. I'm asking then for best practice for this sort of interaction. Following what I have read in other threads, I would assume that, for example for sending, I should do something like: - create a queue of objects which needs to be sent, in one transaction; - sent the objects which need to be sent, in another transaction; The problem, of course, is to minimize (if not avoid at all) the chance to have a Conflict with a double sending of the message. In some sense, this is very close to sending an email via an smtp server, therefore, I assume I should at the right products to look for inspirations. Thanks you all for your time. Marco -- Marco Bizzarri http://iliveinpisa.blogspot.com/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Asking recipe for caching objects
Hi all. I have a zope application which uses a db (postgreSQL) to store and retrieve data. I would like to cache it. It is ok for me to cache them on thread-base. Up to now I've used a simple _v_ attribute, with a dictionary. The approach works, but: - the _v_ attribute is not transactional (and transactions could be rerun due to conflicts), - the dictionary can grows indefinitively. Therefore, I'm looking to see if there is a ready solution for this problem. Thanks you all in advance for your advice Regards Marco -- Marco Bizzarri http://iliveinpisa.blogspot.com/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Asking recipe for caching objects
--On 1. August 2008 15:55:41 +0200 Marco Bizzarri [EMAIL PROTECTED] wrote: Hi all. I have a zope application which uses a db (postgreSQL) to store and retrieve data. I would like to cache it. It is ok for me to cache them on thread-base. Up to now I've used a simple _v_ attribute, with a dictionary. Therefore, I'm looking to see if there is a ready solution for this problem. gocept.cache plone memoize ? -aj pgpDpRHDJELaq.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Asking recipe for caching objects
Thanks for your suggestions, Andreas. Any chance these are going to work under Zope 2.8? Regards Marco On Fri, Aug 1, 2008 at 4:04 PM, Andreas Jung [EMAIL PROTECTED] wrote: --On 1. August 2008 15:55:41 +0200 Marco Bizzarri [EMAIL PROTECTED] wrote: Hi all. I have a zope application which uses a db (postgreSQL) to store and retrieve data. I would like to cache it. It is ok for me to cache them on thread-base. Up to now I've used a simple _v_ attribute, with a dictionary. Therefore, I'm looking to see if there is a ready solution for this problem. gocept.cache plone memoize ? -aj -- Marco Bizzarri http://iliveinpisa.blogspot.com/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Asking recipe for caching objects
My ZSQL product has a very simple feature for hooking up up to memcache but with one caveat: that you can't invalidate the cache. It only works for selects of course but it's really easy to work with. E.g. SQLSelectAverageUserAge(min=10, max=20, memcache__=True) (defaults to 5*60 seconds) ...or... SQLSelectAverageUserAge(min=10, max=20, memcache__=10) (10 seconds) I've only used it in one project but it made a huge difference. However, it only makes sense to use this when you're going to call the same SELECT many times which is something you should avoid of course if you can. 2008/8/1 Marco Bizzarri [EMAIL PROTECTED]: Hi all. I have a zope application which uses a db (postgreSQL) to store and retrieve data. I would like to cache it. It is ok for me to cache them on thread-base. Up to now I've used a simple _v_ attribute, with a dictionary. The approach works, but: - the _v_ attribute is not transactional (and transactions could be rerun due to conflicts), - the dictionary can grows indefinitively. Therefore, I'm looking to see if there is a ready solution for this problem. Thanks you all in advance for your advice Regards Marco -- Marco Bizzarri http://iliveinpisa.blogspot.com/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] CorruptedDataError: How to fix a corrupted
Thanks Martijn for your answer. I tried fsdump but it did not work I got a FileStorageFormatError... Is there any other way I can obtain the needed paramater (position) for the truncate function where the CorruptedDataError occured? Another question, is there a way of extracting all data or transaction between two dates? On Thu, Jul 31, 2008 at 4:21 PM, Martijn Pieters [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 10:48 PM, Remy Pinsonnault [EMAIL PROTECTED] wrote: For an unknown reason, it seems our data.fs got corrupted last night. In the event.log I can see the following: CorruptedDataError: Error reading oid 0x086540. Found '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' at 10020462 You have 2 pieces of info there, the oid and the file position. You could use fsdump to verify the oid and position, then truncate the file at that position. Short recipe (may be outdated a bit) of the procedure: http://kelpi.com/script/018315 I certainly have performed truncations like that in the past. -- Martijn Pieters ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] CorruptedDataError: How to fix a corrupted
On Fri, Aug 1, 2008 at 7:01 PM, Remy Pinsonnault [EMAIL PROTECTED] wrote: I tried fsdump but it did not work I got a FileStorageFormatError... You only get that error if a) the first four bytes of the file are not 'FS21', or b) the file is smaller than 4 bytes. Are you sure you were trying this on the corrupted Data.fs? If so, you may have a bigger problem on your hands. Is there any other way I can obtain the needed paramater (position) for the truncate function where the CorruptedDataError occured? The exception included the position: 10020462. I just advised you to double-check it. Another question, is there a way of extracting all data or transaction between two dates? Take a look at what fsdump.py does, it uses a FileIterator to list all transactions in the Data.fs. The returned objects (RecordIterators) represent the transactions and you can iterate over these to pull out all data associated with the transaction. Each transaction id is based on the timestamp (use ZODB.TimeStamp.TimeStamp to decode it) so it should be but a small job to extract everything between two given dates. See the sourcecode for fsdump.py and FileStorage.py in ZODB/FileStorage. -- Martijn Pieters ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
