
Visible Lisp Computer - lispm
http://www.technoblogy.com/show?2ODQ
======
tonyg
Craig Latta did something very similar in software for visualising the object
memory of a running Smalltalk: [https://thiscontext.com/a-detailed-
description-of-spoons-obj...](https://thiscontext.com/a-detailed-description-
of-spoons-object-memory-visualization-tools/)

"When I got the current [Smalltalk image] down to about 450 kilobytes, I
realized that I could render it as a reasonably-sized picture (within 800 by
600 pixels). I was interested in doing this mostly because I’d never seen a
graphical representation of the Smalltalk object memory before. As I
proceeded, I found it enabled some pretty useful things."

There's a video
([https://www.youtube.com/watch?v=1Uh8v7IzXJk](https://www.youtube.com/watch?v=1Uh8v7IzXJk))
and even a 3D visualization of the object graph.

~~~
westoncb
Interesting how many different directions people have gone in doing something
along these lines...

Since 2014 I've been building a system with a similar objective, but focusing
on 1) visualizing at (hopefully) the most useful level of abstraction 2)
making the time-evolution of objects in memory clear and navigable.

Video and details here:
[http://symbolflux.com/projects/avd](http://symbolflux.com/projects/avd)

My system works by monitoring/rendering explicitly defined data structures
(something like `Lucidity.monitor(my_tree_data_structure)`), but more
generally I think of the tool that we're missing as a kind of
'abstractoscope'\--some means of automatically transforming the contents of a
running program's representation in memory into something comprehensible by
humans.

The problem feels to me sort of like needing a microscope--we need a
relatively passive instrument in order to monitor the behavior of running
programs (which are not visible to the naked eye). The problem in this case is
that we have too _much_ information instead of too little though, so our
instrument needs to automatically discard irrelevant information (i.e.
abstract) for us, rather than magnifying.

------
msla
It's like a modern version of what computers with Williams-Kilburn tubes could
do:

[https://www.computerhistory.org/revolution/memory-
storage/8/...](https://www.computerhistory.org/revolution/memory-
storage/8/308)

[https://en.wikipedia.org/wiki/Williams_tube](https://en.wikipedia.org/wiki/Williams_tube)

> The Williams tube works by displaying a grid of dots on a cathode ray tube
> (CRT). Due to the way CRTs work, this creates a small charge of static
> electricity over each dot. The charge at the location of each of the dots is
> read by a thin metal sheet just in front of the display.

[snip]

> Some Williams tubes were made from radar-type cathode ray tubes with a
> phosphor coating that made the data visible, while other tubes were purpose-
> built without such a coating. The presence or absence of this coating had no
> effect on the operation of the tube, and was of no importance to the
> operators, since the face of the tube was covered by the pickup plate. If a
> visible output was needed, a second tube connected in parallel with the
> storage tube, with a phosphor coating, but without a pickup plate, was used
> as a display device.

So the tube the users could see wasn't the memory, which was covered by a
metal plate, but it showed exactly the same dots as the memory.

------
carapace
That is cute!

I love the idea of visible RAM.

The Oberon OS & computer has a memory-mapped raster display. Emulator puts
some "magic" bytes at the start (or end, I forget) of display RAM and you can
see them on the screen before the boot sequence gets to drawing the
background.

~~~
cr0sh
>I love the idea of visible RAM.

Have you ever heard of the old game "Core War"? You might enjoy it:

[https://en.wikipedia.org/wiki/Core_War](https://en.wikipedia.org/wiki/Core_War)

------
jgwil2
Could this be used to illustrate the space efficiency gain with `fib-iter`
over the recursive `fib` implementation?

------
jjwiseman
It'd be great if there were a video available.

