[squeak-dev] re: Toward SqueakCore (including alternative plan)

Craig Latta craig at netjam.org
Fri Feb 15 10:52:21 UTC 2013


Hi--

     Hannes writes:

> Thank you for your mail which gives a lot of useful detailed
> explanations.

     Sure thing.

> Is the garbage collector available as a loadable package?

     No, I haven't separated that from the rest of the Spoon VM changes,
which are in the mainstream image included in recent Spoon releases.

> > You imprint the unit test's code onto a minimal memory,
>
> With 'minimal memory' I assume you mean a minimal image while it is
> in memory?

     I'm using "memory" as shorthand for "object memory". I avoid using
the word "image" as much as I can, because it often confuses newcomers
when I explain Smalltalk to them. They think it has something to do with
graphics. It's especially problematic when I'm explaining my object
memory visualization work, which is heavily graphical.

     I've had better results by evoking the model of a virtual processor
with its own memory, especially now that many people are familiar with
things like VMWare.

> > [After a minimal imprinting unit test] we can move onto more
> > interesting things, like graphics (or WebDAV, or...).
>
> With graphics you mean an [object memory] which executes graphics
> commands?

     Sure, I mean the library support for a GUI. The minimal memory is
headless.

> Yes, what other candidates do you propose as a test?

     I think the minimal echo-server unit test is the only test we need,
then we should get on to doing real work. We'll probably want some sort
of user interface as a top priority, so I imagine support for a
simplified Morphic, or MVC, or wxWidgets would be likely, as would
remote text-editor access via WebDAV (and I've already written that code).

     Beyond that, as now, it's up to all us motivated people to decide
the priorities and do the work. I think I would work on the VM simulator
next, and I'd like to get all the vm-making stuff installing,
generating, and executing this way.


     Frank writes:

> I half and half have a problem with dissolving, just in the sense
> that if you don't use it it's gone, only that might be, say, UI
> wiring.

     But that's fine if your goal is a minimal object memory, yes?

> ...we have discussed Spoon's tech before - last time was, IIRC, "how
> can you diff two arbitrary binary blobs?"

     Sorry, I don't recall the context. Can you point me to messages in
the squeak-dev archives, or summarize with a bit more detail?


     Colin writes:

> The system is too big to look at all the class-level dependencies all
> at once.

     Okay, I think we disagree here. After my experience with
interactively visualizing and exploring the entire reference graph of an
object memory in 3D (even though it was a relatively small memory), I
don't think the problem is too big. For those reading along who may not
have seen my visualization work, please check out:

     http://tinyurl.com/aky2gwa (thiscontext.wordpress.com)

> Of course, to actually break the dependencies, yeah, we'll have to go
> down to the level of classes and methods. But the high-level overview
> can help us sort out priorities.

     That makes sense.

> Also, note that PackageInfo and class categories aren't the same
> thing.

     I know they aren't identical. My understanding was that PackageInfo
has its basis in class categories, with some important elaborations.
This understanding was reinforced when I saw Tobias's graphs full of
familiar class category names. I hadn't looked at the implementation
since it first came out, I'm reading it now.

     Regardless of the subtleties, I do use Monticello (although more to
install things, VMMaker in particular :).


     thanks again,

-C

--
Craig Latta
www.netjam.org/resume
+31   6 2757 7177 (SMS ok)
+ 1 415	 287 3547 (no SMS)





More information about the Squeak-dev mailing list