2008/7/2 Eliot Miranda <eliot.miranda@gmail.com>:

>
>
> This is the "mirrors" approach I alluded to.  The right approach is to
> implement the debugger with a mirror between it and the system it looks at.
>  There is a mirror for local debugging taht is fairly transparent.  then
> there is a mirror for the renoter system which is much more involved because
> it has to use peek and poke to examine the memory space of the target
> process and it has to extract meta information   from it (and in the
> presence of errors, e.g. the hard crash could have corrupted memory).
>

I have some ideas about it.
First: nobody prevents me to have image containing separate object
memories. Its only a question how to load and bootstrap it :)

Or, more specific: i think i will introduce the island model (or vats)
from the start.
So there will be a multiple islands (which can be possibly run in
parallel native threads), which don't share anything, or sharing a
protected memory region, writing to which is guarded by a lot of
checks and rules :)

Since there is nothing outside, which dictates me to have: single
heap, single GC, single object memory; it is possible to implement a
system, which could have different memory regions governed by
different memory managers and garbage collectors.

Then debugging looks much less scary than comparing to system crippled
by VM written in C :)

> Let me encourage you to think about this soon and work on it asap because it
> is a really important issue.  If you don't have a good debugging environment
> up front your progress will be slow.  No one has succeeded in bringing such
> a system for a Smalltalk-like language into production use yet (neither
> Klein nor TypedSmalltalk nor Exupery has made it to production use).  Making
> it happen would be fantastic.  You have the Spoon system to build upon.
>

Absolutely, a system without good means of debugging can't progress
fast (and its mainly just a useless artifact for serious deployment).
I'm concerned that amount of debug information to be added to method
would hit hard the memory consumption.

> You have to both provide a Smalltalk-level debugger and a machine code
> debugger which can display machine instructions, registers and memory.  It
> would be nice to be able to reuse disassemblers et al from other components
> but you might find that Smalltalk implementations are quicker to write and
> easier to understand and use.  But you will need them.
>

Heh.. right, but it would take ages :)
A teamwork is what is needed. I looking for a people who may want to
join crusade for the ultimate smalltalk self-sustaining system
implementation :)