2009/11/4 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Wed, Nov 4, 2009 at 12:51 AM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>> 2009/11/4 Andreas Raab <andreas.raab at gmx.de>:
>> > 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
>

As long as there is no Collection (minor problem) and no changes in
intermediate hierarchy levels (big problem), i see no difficulty in
comparing two snapshots, but UI definition and efficiency... Cycles
have to be detected, but that seems doable.

Collections are a bit annoying because elements have no strong
signature unlike instVars (but Dictionaries which have strong
signature thanks to keys).
How to compare {1 at 0. 2 at 1. 2 at -1} with {1 at 0. 2 at -1} ?
How to evaluate longest match in complex trees ?
Collections also can be unordered, and partial longest match of
unordered Collection smells like combinatorial...

If you want to handle changes in hierarchy levels, like for example
comparing (ValueHolder with: 1 at 2) versus (1 at 2), you are in trouble.  I
had such a problem 10 years ago for comparing block diagrams with
changes in hierarchy... I never found the courage to handle it (though
my problem had a "simple" solution consisting in eliminating the
hierarchy - that is aggregating all leafs in a flat hierarchy).

Comparing two movies (I mean dynamic evolutions of the graph as a
serie of snapshots) is way more demanding, maybe one process will
arrive to the same result in four steps versus five... So how to
control advance of the two ? Plus how to store evolutions in the
graphs efficiently ? we wouldn't make a copy of each snapshot, would
we ?

You have the ability to turn trivial threads into tough subjects indeed...