Naiad says hello

Phew. I have Naiad (Spoon’s change management system) running in a small headless memory which is using another small headless memory as its edit history. I call the first one the “subject” memory, and the second one the “history” memory. I’m browsing the subject memory from a kitchen-sink memory that has Naiad support. I can install class and method editions into the subject memory from the browsing memory, and the subject memory keeps track of edits in the history memory, all without referring to class names. Naiad finally works! Yay!

Eventually, the headless subject memory will be the basis of a new distribution of Squeak… one where there is no bloat, everything is organized sanely, and everything is documented. :)

We can port the Naiad support to other memories (other versions of Squeak, and other Smalltalks). So, for example, one will be able to browse a Pharo memory from a VisualWorks memory and vice-versa.

Right now I’m doing another manual removal pass through the headless subject memory, using visualization data from the simulator as my guide.

This is fun!

2 Responses to “Naiad says hello”

  1. Chris Cunnington Says:

    Hmm, let me see if I understand.

    You have three object memories on your computer. Two are headless. The third is the io to the subject and history memory. None of the classes in these headless images have names: symbols that refer to them. That cuts down on size, I guess. You can do the pruning of the object memory, because of these powerful visualization tools you’ve created, which allow you to poke a node and see it’s references.

    So, in short, this is MicroSqueak with a simulator and visualization tools attached to the simulator. The end result is to be able to program an image small enough to work on an embedded system, while doing it live. MicroSqueak has MClasses and you compile. And once you’ve compiled, that’s it. Spoon do it in real time.

    Have I got that right?
    It’s pretty cool.

    Like

    • Craig Latta Says:

      That’s almost right. The browsing memory is only connected to the subject memory; the connection between the subject and history memories is private. The classes actually do still have names, it’s just that names are never mentioned when referring to classes. The names are only for the convenience of humans. And the main benefit of this is not to save space, it’s to allow complete flexibility in the name of each class, without affecting how classes and methods are referenced and transferred between object memories (or within a single object memory at different points in time).

      Yes, Spoon can make changes to an embedded-sized object memory in real time. It’s also worth mentioning that the compilation of these changes happens in the browser memory; the subject and history memories need not have a compiler present. So source code becomes another artifact which is around only for human convenience. You don’t need it in order to distribute your code.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: