Your analysis is correct: DynamicVariables are hard to impossible to debug, the debugger always runs in another process. I don't think there is a solution here (maybe let the debugger process copy/share the binding ?) apart from what you suggest: make sure you enter the debugger after the lookup and assignment of the value to a local variable. server := ZnCurrentServer value. Still, I find DynamicVariables very useful, especially architecture/design-wise. On 23 Jun 2014, at 13:50, Norbert Hartl <norbert@hartl.name> wrote:
In my code I'm using a DynamicVariable to request a context object when needed. Until now I knew the name DynamicVariable only from seaside. There it is called WADynamicVariable and it is an exception. So I blindly assumed the pharo DynamicVariable works the same. I thought this might be a good optimization not to travel the stack all the time but put in the process. Now that I am using it I can see the difference. I find it real hard using it because I don't know how to debug/step in code. DynamicVariable is a process specific variable but as soon as a debugger opens it is very likely to be in another process. This makes stepping in method using the DynamicVariable impossible. The only way round is to set break points after the dynamic lookup and step from there. But this feels just wrong. What would be the best way to have DynamicVariable and be able to debug anything? Or is there a variant that uses the stack instead of the "active" process?
thanks,
Norbert