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

Hello Craig

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

On 2/12/13, Craig Latta craig@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)