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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091104/e4f64ac1/attachment.htm