[Grok-dev] Re: The nuisance of the change/restart cycle

[Christian Theune]

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 
>> compromise.
>>
>> 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.
>>
>>
>>   @grok.interactive()
>>   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.

Christian

-- 
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