Re: [ZODB-Dev] Reloading product in 2.8
Jens Vagelpohl wrote at 2005-7-12 21:49 +0100: [Lennart] If it is the majoritys agreement that this answer is the best one, and that the refresh functionality should be looked at as something that may or may not work purely on luck, then I'll mark it as deprecated and up for removal in 2.10. [Jens] +1 from me [Dieter] -1 from me. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Jens Vagelpohl wrote at 2005-7-12 18:46 +0100: ... Due to the nastiness Refresh has to perform under the cover even Shane has to admit that it simply is not some make development faster panacea. Shane might (perhaps) admit it but I do not :-) There is not much nastiness that Refresh does: (Manual) refresh has only a single problem: it does not refresh dependent products automatically. But this can easily be fixed (provided product dependencies are configured correctly). -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Victor Safronovich wrote at 2005-7-12 18:17 +0600: My product has 'Auto refresh mode' option checked. I changed some source code of my product, after that autorefresh have been occured. And after autorefresh I got strange several errors: ... self._store_objects(ObjectWriter(obj), transaction) File C:\Program Files\Zope-2.8.0-final\lib\python\ZODB\Connection.py, line 534, in _store_objects self._cache[oid] = obj ValueError: Cache values may only be in one cache. I have seen this problem report for Zope 2.7 as well (in the mailing list). Obviously, the auto refresh mode implementation contains a persistency bug -- and not only since Zope 2.8... -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Savepoints are invalidated once they are used
Jeremy Hylton wrote at 2005-7-11 18:37 -0700: IIRC, the old implementation of savepoints kept a copy of the index at the time the savepoint was taken so that you could rollback to it multiple times. I don't think there's any way to avoid such a copy. Maybe, we keep the original implementation (a savepoint restore deletes this savepoint) and update the docstring? It is rare that we need to keep the savepoint. If we do, we can (usually) create a one with the state after the restore. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Lennart Regebro wrote at 2005-7-12 19:17 +0200: ... The refresh functionality has been unstable since it became a part of Zope core, and I have ended up not using it since it since then I never used auto refresh but always use the manual refresh and I am very happy with it. Recently, I implemented a RefreshTool that refreshes with a product also all the products that depend on it. With this, almost all refresh related problems disappear (exception: the persistency bugs of auto refresh mode). It greatly speeds up development and I would not want to miss it :-) ... I'm all for makeing a serious effort one day to fix this. +1 -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Lennart Regebro wrote at 2005-7-12 20:22 +0200: ... well, if it happens to work for you, then good luck, but it is actually a piece of unsupported crap that hasn't worked for years and that nobody is bothered to fix bugs in. I have the feeling that we have an easy tendency to say such things: Let a bug occur in some component and then, instead (or in addition) of fixing the bug, we say often: rip the component off Zope. That was threadened for Versions, and ZClasses and now for Refresh. For me, Refresh always was a big development time saver -- I knew that I had to refresh with a product also all dependent products. Recently, I automated this refreshing of dependent products. This made Refresh behave as expected (provided the product dependancies are described correctly) ;-) -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Dieter Maurer wrote: Jens Vagelpohl wrote at 2005-7-12 18:46 +0100: ... Due to the nastiness Refresh has to perform under the cover even Shane has to admit that it simply is not some make development faster panacea. Shane might (perhaps) admit it but I do not :-) There is not much nastiness that Refresh does: (Manual) refresh has only a single problem: it does not refresh dependent products automatically. It also doesn't handle global data properly. It tries to do something that Python modules were never designed to support, which is to load them more than once. When it fails, it does so in subtle ways that cause people to lose lots of time. 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 ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
On Thu, Jul 14, 2005 at 06:01:26PM -0400, Jim Fulton wrote: | When it fails, it does so in subtle ways that cause people | to lose lots of time. Usually when it fails I just restart. I wouldn't consider that losing lots of time comparing restarting now and then to restarting constantly. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Savepoints are invalidated once they are used
[Jeremy Hylton] IIRC, the old implementation of savepoints kept a copy of the index at the time the savepoint was taken so that you could rollback to it multiple times. I don't think there's any way to avoid such a copy. [Dieter Maurer] Maybe, we keep the original implementation (a savepoint restore deletes this savepoint) and update the docstring? It is rare that we need to keep the savepoint. All implementations (the current one in SVN, the old one, and the original one) copy the index at the time a savepoint is made, but for more reasons than Jeremy gave (I suspect his memory of the old implementation's details has faded a bit ;-)). To be usable for rollback at all (even once), a savepoint has to remember the state of the TmpStore index at the time the savepoint is made -- otherwise it couldn't restore the index to that state on a rollback. If the savepoint shares its remembered index object with TmpStore, then mutations to the latter's index effectively corrupt the savepoint's remembered index. The additional copying recently added, to support rolling back to a savepoint multiple times, occurs only when a rollback is actually performed. I don't mind that expense at all. BTW, I don't expect we can know what's rare or not with these yet. Nesting is a powerful ability subtransactions couldn't approach, so it's plausible to imagine that savepoints will get used for much more than just their RAM-freeing side effects -- and most copying here is to support nesting correctly. If we do, we can (usually) create a one with the state after the restore. Sorry, I couldn't follow that sentence. I would like to do less indexing copying when a savepoint is made, but don't see an obvious and effective way to get away with that. The current implementation has become obviously correct instead of not obviously wrong, and that's a good place to leave it for now in the absence of dire need. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Refresh was never much of a timesaver for me. Pressing ctrl-C - up arrow - return on the console from which I run Zope is my answer. I know lots of people say that this is too slow, but on my most recent project from the time I type runzope to the time I see ready to handle requests is real0m3.029s user0m1.857s sys 0m0.306s ... and I can live with that. - C On Thu, 2005-07-14 at 23:02 +0200, Dieter Maurer wrote: Lennart Regebro wrote at 2005-7-12 20:22 +0200: ... well, if it happens to work for you, then good luck, but it is actually a piece of unsupported crap that hasn't worked for years and that nobody is bothered to fix bugs in. I have the feeling that we have an easy tendency to say such things: Let a bug occur in some component and then, instead (or in addition) of fixing the bug, we say often: rip the component off Zope. That was threadened for Versions, and ZClasses and now for Refresh. For me, Refresh always was a big development time saver -- I knew that I had to refresh with a product also all dependent products. Recently, I automated this refreshing of dependent products. This made Refresh behave as expected (provided the product dependancies are described correctly) ;-) ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Reloading product in 2.8
Jim Fulton wrote: It also doesn't handle global data properly. It tries to do something that Python modules were never designed to support, which is to load them more than once. However, given the existence of the reload() builtin, someone apparently believed Python modules *were* designed to support reloading. Because reload() is a builtin, Python seems to promise that reload() is reliable, but in fact it's rarely reliable. There would be a lot less confusion if reload() were moved somewhere like the imp module. When it fails, it does so in subtle ways that cause people to lose lots of time. I agree. The right way to refresh is to detect code changes (ideally using Linux's brand new inotify mechanism, or something similar when inotify is not available), display a please wait message to the user, and restart the process. Shane ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Reloading product in 2.8
[Jim Fulton] It [reload] also doesn't handle global data properly. It tries to do something that Python modules were never designed to support, which is to load them more than once. [Shane Hathaway] However, given the existence of the reload() builtin, someone apparently believed Python modules *were* designed to support reloading. It was certainly hopeful -- other hopeful failures include the whole rexec/bastion maze, and the multiple interpreters gimmick in the C API that some people still spend their lives trying to out-guess 0.9 wink. One thing they have in common is that nobody volunteered ongoing work on them, apart from Guido, and they would have required major work to become praiseworthy. Because reload() is a builtin, Python seems to promise that reload() is reliable, but in fact it's rarely reliable. There are more words about reload() in the manual than about any other builtin, and they point out problem after problem. It's very hard to remove a builtin (has it ever been done? I don't recall a case -- although apply() is silently deprecated), and reload() was there from the start. I thought it was a bad sign when Python NEWS for version 1.0.2 remarked that there were now fewer chances of dumping core when trying to reload ... wink. There would be a lot less confusion if reload() were moved somewhere like the imp module. It's slated to disappear from Python 3000: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf I doubt it will be removed from __builtin__ before then. When it fails, it does so in subtle ways that cause people to lose lots of time. I agree. The right way to refresh is to detect code changes (ideally using Linux's brand new inotify mechanism, or something similar when inotify is not available), display a please wait message to the user, and restart the process. If you're changing more than one file, how could that know when the source code is in a globally consistent state again? (BTW, there are efficient ways to get notifications about modified files even on Win95, so that part isn't a hangup.) ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
