there is a really nice discussion on supporting (not having an inspector breaking) when browsing proxy. Can you have a look? http://code.google.com/p/pharo/issues/detail?id=1970 "What happens is the inspector asks for "self class allInstVarNames" and then tries to get each value with "self instVarNamed: aName". The problem is, self class allInstVarNames answers the instVars of the future class, but "self instVarNamed: aName" gets passed up to the MIMEDocument by #doesNotUnderstand: and the MIMEDocument throws an error because of course it doesn't have the correct instant vars. The old inspectors weren't as intrusive and worked, these new tools clearly still have some bugs. Since ProtoObject, the superclass for any such proxies doesn't do #instVarNamed:, such code in the inspector will blow up anytime one attempts to inspect any kind of proxy. I would report this as a bug to whoever is maintaining the new inspector tools." So the only way I know to produce the 'bug' is to load the SFuture class he describes in the blogpost I mention above then run the example I posted in step two. If this is the wrong place to report this then let me know and I'll keep looking for the correct place. Delete commentComment 4 by pdebruic, Today (14 hours ago) The default, I think. I haven't changed anything. SystemBrowser default Ctrl-p gives OBSystemBrowserAdaptor Delete commentComment 5 by marcus.denker, Today (11 hours ago) I think the problem is this: -> ProtoObject implements a *minimal* object. This way, Proxies or Futures can use #doesNotUnderstand to implement what they implement. That is, for the example of the Proxy, every message is forwarded to the remote object. -> Now we do not know what exactly you want to forward. Should an inspector inspect the local proxy? Ot the remote object? You decide. Your subclass of ProtoObject copies as many objects from Object as you want. (often all that are needed to inspect the *proxy* vs. the remote object). I think Ramon fine-tuned his implementation for the normal old inspector. Now when you use another one, it uses other methods in addition to the one implemented in the Future --> confusion. Chaos. Bug. But: We can not fix this. this is purely the responsibility of the implementor of the subclass of ProtoObject. So. next action: -> We fix (uhm, remove) the croquet Future code that is just plain confusing. -> We think hard if it's really a problem in the new inspector vs. a missing method on the Future. (and, yes, all this sucks anyway.... we are hard at work to make reflection better and solve all this in a *much* nicer way... but that's research...) Delete commentComment 6 by ramon.leon, Today (10 hours ago) It's not just the Future proxy that'll have problems, it's proxies in general. The way the current inspector is written won't work with any proxy I see in my image, SoapHref, SFuture, MAProxyObject, MADynamicObject, probably the Glorp record proxy, because it assume it can use #instVarNamed: on an instance using values from "anInstance class allInstVarNames" which in the case of *any* proxy won't work unless the proxy implements a version of #instVarNamed:. This is confusing because now the proxy is no longer behaving as a proxy, now reflectively it's answering values for itself rather than the instance being proxied. Another solution would be if the proxy overrode #class to return the class of the proxied instance, but I've always assumed all hell would break loose if you overrode #class, I didn't think it safe to do, and I've not seen any other proxy class do this. Regardless of the ultimate solution, the inspector shouldn't blow up, it should catch the exception and have some default rendering behavior for when it can't inspect an object for some reason. Do you not agree? Delete commentComment 7 by stephane.ducasse, Today (moments ago) Yes I agree. We should contact frederick. I think that the inspector should know that it is browsing a proxy and pay attention.