[Grok-dev] Re: The nuisance of the change/restart cycle
ct at gocept.com
Tue Jan 22 10:05:50 EST 2008
Martijn Faassen schrieb:
> Sebastian Ware wrote:
>> I find myself spending a lot of time making small changes to code,
>> restarting the application and testing the effect of the changes.
>> I understand that it is a long way until the entire Grok application
>> can be instantly changed. So I wonder if one could find a working
>> What if one could mark a method or class as interactive, thus causing
>> it to recompile if it has been updated. That way one could at least
>> solve and verify problems within the scope of that method/class
>> without lots of restarts.
>> def my_method():
>> # This code is recompiled each call.
>> Such a solution would probably reduce my restarts by a factor of ten!
> It's an interesting idea.
> I hope people (Christian? Philipp?) who worked on this feature in the
> past can speak up and indicate what fundamental difficulties exist with
> reload and whether method-only reloads would not trigger these problems.
I wrote a better reload mechanism for Zope 2 about 10 months ago
(RefreshNG). This deals with updating ZCML/configuration registries and
smart code updates. It could probably be ported. I don't remember the
exact edge cases right now.
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
More information about the Grok-dev