[Pharo-project] A radical proposal (to cut down dead code)

Schwab,Wilhelm K bschwab at anest.ufl.edu
Mon May 30 01:11:54 CEST 2011

Options are good, but one algorithm that tries to get it all right is probably asking for trouble.  Dolphin has an elaborate stripper, but I found that slicing out unreferenced packages would typically give me a 4 MB or so executable.  I was able to strip further, but it took time and raised the possibility of runtime failures.  Which tests drive the stripping?  They could easily be broader than strictly necessary, causing otherwise unneeded things to be retained.  I agree with Stef that good packaging is the place to start.

From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Markus Fritsche [fritsche.markus at googlemail.com]
Sent: Sunday, May 29, 2011 4:57 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] A radical proposal (to cut down dead code)

2011/5/29 askoh <askoh at askoh.com>:
> Is Spoon trying to do this?

AFAIK, yes.

As far as I understand, Craig is using a modified VM to identify sent
messages and to automagically mirror them from a master to a slave
image; making testcases very crucial in the process. To make a
tailored image, you run all the testcases and the "needed" behavior
automagically gets pushed/ pulled into the slave image. Save the
slave, and you can run it indepentently.

"Spoon" way - mark each sent message (within the vm) - execute a full
test cycle - see what has been marked-
"Tinkering way" - modify all CompiledMethods to send a "self
registerAsSent: self selector object: self" by code and run a full

Two ways I could think off right now, not really deep into it.

More information about the Pharo-project mailing list