Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Tarek Ziadé wrote: Jim Fulton wrote: - Look at opprtunities for limited robust reload. Perhaps we could define reloadable modules, especially for defining adapters, with restrictions on their definitions and exports in a way that allows robust reload. This would probably be based on the

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Lennart Regebro wrote: On 5/9/06, Jim Fulton [EMAIL PROTECTED] wrote: - Speed up restart. I think there are a lot of ways that restarts can be made faster: [...] o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Stephan Richter wrote: On Tuesday 09 May 2006 07:22, Jim Fulton wrote: I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Tarek Ziadé
Jim Fulton wrote: out of curiosity, what are the things that make a reload not robust ? is it just a matter of dependencies or it's deeper ? I was hoping that someone else would answer this directly. :) Shane did largely answer it, but I'll try to be more direct and concise: When you

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Adam Groszer wrote: Hello Jim, Tuesday, May 9, 2006, 1:22:30 PM, you wrote: [snip] JF Python simply does not support a general robust reload, other than JF restart. [snip] What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same

Re: reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)

2006-05-12 Thread Jim Fulton
Shane Hathaway wrote: ... 2) Make reloadable code fundamentally different. Yes. If module X is supposed to be reloadable, and X creates a module-level global variable Y, and module Z imports Y, then Y needs to be decorated in such a way that Z's view of Y can change automatically when X is

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Dieter Maurer wrote: Jim Fulton wrote at 2006-5-9 07:22 -0400: ... Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. Moreover,

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Stephan Richter
Hi everyone, I just discussed those comments with Jim via IRC. The following comments are FYI. On Friday 12 May 2006 08:56, Jim Fulton wrote: directives have to be reviewed and it must be ensured that they are multi-site aware. The tricky part of the implementation will be to hook in

Re: reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)

2006-05-12 Thread Shane Hathaway
Jim Fulton wrote: I also think there is a real opportunity in allowing reload to fail. That is, it should be possible for reload to visibly fail so the user knows that they have to restart. Then we only reload when we *know* we can make changes safely and fail otherwise. For example, in the

Re: reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)

2006-05-10 Thread Adam Groszer
Hi Shane, Please have a look at http://www.pythomnic.org/. As I get it, it puts proxies around 'imported' modules. My idea would be, without thinking it any further/deeper is what about putting proxies before any imported stuff. Modules, callables, variables, everything and evaluate the

Re: [Zope3-dev] Re: Google SoC Project

2006-05-09 Thread Jim Fulton
whit wrote: Adam Groszer wrote: I personally am tired of restarting z3 each time I made an error even if it is just one char mistype. I'm doing now a wx based app, and the problem is the same... made an error, restart, click 10 times... It would be also a way to have a developer version which

Re: [Zope3-dev] Re: Google SoC Project

2006-05-09 Thread Tarek Ziadé
Jim Fulton wrote: - Look at opprtunities for limited robust reload. Perhaps we could define reloadable modules, especially for defining adapters, with restrictions on their definitions and exports in a way that allows robust reload. This would probably be based on the

Re: [Zope3-dev] Re: Google SoC Project

2006-05-09 Thread Lennart Regebro
On 5/9/06, Jim Fulton [EMAIL PROTECTED] wrote: - Speed up restart. I think there are a lot of ways that restarts can be made faster: [...] o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full Zope 3 checkout. Just a

Re: [Zope3-dev] Re: Google SoC Project

2006-05-09 Thread Stephan Richter
On Tuesday 09 May 2006 07:22, Jim Fulton wrote: I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up restart.  I think there are

reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)

2006-05-09 Thread Shane Hathaway
Adam Groszer wrote: What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same problem, so all Python developers would benefit from the solution. As I know (that may be wrong) not many even if any language supports that, so that would

Re: [Zope3-dev] Re: Google SoC Project

2006-05-09 Thread Dieter Maurer
Jim Fulton wrote at 2006-5-9 07:22 -0400: ... Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. Moreover, if the component