Login  Register

Re: Re: printing collections

Posted by Eliot Miranda-2 on Nov 04, 2009; 5:26pm
URL: https://forum.world.st/printing-collections-tp360853p420550.html



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