Hello Craig

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

On 2/12/13, Craig Latta <craig at netjam.org> wrote:
>
> 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.

Is thei garbage collector available as a loadable package?


>      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. :)

OK, fine.

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

Good

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?

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

With graphics you mean an image which executes graphics commands?

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

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

Makes sense to me

Regards
--Hannes

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