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

Craig Latta craig at netjam.org
Tue Feb 12 23:24:41 UTC 2013


Hi Frank--

> Some of those circles we may never resolve. Craig Latta might have
> some insight here, because he had to deal with these issues in the
> creation of his micro-images.
>
> Craig?

     With the current technique[1], I don't have to deal with those
issues at all to make minimal object memories. I wrote a variant of the
garbage collector that collects methods not run since a certain point in
time. I reset a mark on all methods, run unit tests for the stuff I want
to keep, and everything else vanishes. It takes a few seconds.

     Before I started doing that, I was ripping things out manually with
a remote browser, so I didn't have to think about most of the
circularities (e.g., breaking the target's GUI was fine because I wasn't
using it).

     Generally, I advocate creating modules by imprinting[2] unit tests
onto a minimal memory. We can divide the work of rounding out the unit
tests using the current class categories, and prioritize by what we miss
most when using a minimal system. I expect we have lots of opinions
about that, so there should be plenty of volunteers. :)

     I volunteer to coordinate this. I'll start by making an example of
a simple "echo" network server[3]. I'll provide a package for Squeak 4.4
that installs imprinting support, and another that installs the echo
server code and an imprinting unit test. You imprint the unit test's
code onto a minimal memory, then get data echoed back to you from a
newly-created echo server running there. We can move onto more
interesting things, like graphics (or WebDAV, or...).

     I advocate a new all-live-objects module system as well[4], but the
organizational info gleaned from this work would lead to useful
artifacts with any of the other ones (e.g., Monticello).

     As for the DependencyBrowser data, I think it would be better to
express the connections directly between classes, and ignore the class
categories for now. (Actually, I'd like to drop the class categories
permanently, and use tags instead[5].) Class references are the basis of
the dependency graph, the categories are a distraction. Let's identify
the methods causing reference circularities between classes.


     thanks,

-C

[1] http://tinyurl.com/bz3eyzq (thiscontext.wordpress.com)
[2] http://tinyurl.com/ajttt52 (thiscontext.wordpress.com)
[3] https://tools.ietf.org/html/rfc862
[4] http://tinyurl.com/aoudtnq (thiscontext.wordpress.com)
[5] http://netjam.org/spoon/naiad (sorry, no pretty blog version yet)

--
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