Norbert, I share the same feelings you have. And couldn't find any other way of dealing with them, other than doing the same thing Sven suggests.
Regards! Esteban A. Maringolo 2014-06-23 9:03 GMT-03:00 Sven Van Caekenberghe <s...@stfx.eu>: > 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 <norb...@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 > >
