>
>
> On Wed, Nov 4, 2009 at 12:51 AM, Nicolas Cellier
> <[hidden email]> wrote:
>>
>> 2009/11/4 Andreas Raab <[hidden email]>:
>> > Nicolas Cellier wrote:
>> >>
>> >> The main use I see is to quickly modify in an inspector, especially in
>> >> the debugger.
>> >
>> > Fair enough. But in this case, wouldn't it be better if we had a "copy
>> > storeString" item in the inspector (we already have "copy name" for the
>> > name
>> > of the variable)? Or even "show storeString"? I really dislike the idea
>> > to
>> > clutter something that everyone needs to understand every single time
>> > they
>> > look at with stuff that only a few people may use in even fewer
>> > situations.
>> >
>> > Cheers,
>> >  - Andreas
>> >
>> >
>>
>> I don't buy this one. The feature would be usefull for simple objects
>> only, and I prefer to stay away from instVarAt: 1 put: (...) and
>> infinite loop on cyclic object graphs as proposed by current
>> implementation of storeString for any other Object.
>> A traditional inspector window does a better job.
>>
>> Maybe we should better close this subject :)
>
> No.  Actually the abilities I want are to open inspectors on "distant"
> objects and compare them.  For example right now I'm developing a
> "refactored" virtual machine in which the ObjectMemory is an instance
> variable of the CoInterpreterSE instead of a superclass of the
> CoInterpreter.  Thing is, this is more than a refactoring and my
> CoInterpreterSE doesn't fully work yet.  I'm running both the new VM and the
> old VM until they diverge and trying to account for that divergence.  Things
> that are difficult:
> - getting both VMs in the same inspector.  Right now I have to e.g. in one
> debugger assign the interpreter to a global.  in the other debugger open an
> inspector on an array of the VM assigned to the global and the local VM.
> - comparing instance variables and their state in the two interpreters.
>  Some generic object graph comparer that could display a partial walk over
> the two object graphs would be fantastic.
> - better still is the ability to run the two VMs in lock-step, halting when
> they diverge.  Difficult in my case because lots of the computation happens
> in primitives that are executing generated machine code.
> So I think the needs aren't for good print strings.  The needs are actually
> for much higher-level tools that allow one to
> - compare object graphs with a richer result than merely equal or not, i.e.
> explore the comparison
> - trace the evolution of object graphs during computation, ideally
> supporting evolution in lock-step of more than one graph, perhaps simply
> allowing one to record the sequence of evolutions such that one can compare
> one trace to another
> How general is this kind of thing?  Do others find themselves looking at
> this kind of thing often?  I fear not.
> eliot
>