I'm sure this has been addressed many times, but there is no good source of documentation at the swiki. With the changes in 2.8 and 2.9a things have probably changed enough that this question is worth revisiting in the context of the 'ship it with squeak' discussion.
I would love to be able to ship a squeak image that had only morphic, the necessary programming classes and the classes necessary for my application. Is there a semi-magical method? Failing that, how do I go about doing this systematically (that is without simply wiping out classes sequentially and checking to see what fails.) Finally, compared to the base image (say 2.8) - what are reasonable expectations for a reduced image size (with morphic, without MVC (is this possible?), with the network support, Scamper, Celeste, the morphic widgets and toolkit classes but without the 3D stuff, Wonderland, speech, music and all those nifty toys etc.)
Michael Cole broccole@panix.com
I'm sure this has been addressed many times, but there is no good source of documentation at the swiki. With the changes in 2.8 and 2.9a things have probably changed enough that this question is worth revisiting in the context of the 'ship it with squeak' discussion.
I would love to be able to ship a squeak image that had only morphic, the necessary programming classes and the classes necessary for my application. Is there a semi-magical method? Failing that, how do I go about doing this systematically (that is without simply wiping out classes sequentially and checking to see what fails.) Finally, compared to the base image (say 2.8) - what are reasonable expectations for a reduced image size (with morphic, without MVC (is this possible?), with the network support, Scamper, Celeste, the morphic widgets and toolkit classes but without the 3D stuff, Wonderland, speech, music and all those nifty toys etc.)
Michael -
This has to be readressed every few versions and, at this point, the various inclusions and exclusions are not reliably modular. It's not hard to get down around 700k with development system but without sound, network or Morphic. With Morphic (less scripting), tools, Network and the two apps you mention, my guess is you'll come in around 1.8-2Mb plus or minus depending on whether you want sound and, if so, how much.
You should certainly try the various discardX methods and at least read majorShrink in SystemDictionary. As you point out, we need more documentation about this.
I once started on a web page that would describe everything in the image (ie what you need to know besides all the classes and their methods), how to search for various subtle things and, finally, how to successfully shrink an image. If anyone else wants to tackle this job with me as a tutor, it might happen sooner, judging from my current to-do list.
I think Stefan Aust recently got pretty deeply into this, and I think Jerry Archibald has also.
People will tell you this is the problem with the unified image approach, but I disagree. The problem is simply that we haven't drawn appropriate lines between the various parts of the system, so when you cut one out, you're left with dangling dependences. I think that real value would come from declaring this as a project, with a goal of having maybe 20 discardX methods that really worked and that wouldn't get out of date in the next month. This project would also overlap with or feed into the Environments project. That one's actually on my to-do list, so maybe this is a good way to go at it.
- Dan
PS it's also related to the problem of what to do about error dialogs in a headless system (a headless system is just one in which you have run the discardGraphics method ;-).
Dan Ingalls wrote:
PS it's also related to the problem of what to do about error dialogs in a headless system (a headless system is just one in which you have run the discardGraphics method ;-).
Many of those dialogs (like for missing files on FileStream>>readOnlyFileNamed:) shouldn't be there in the first place.
They should just raise exceptions. If the lower level classes raised exceptions, and the GUI was responsible for interacting with the user, it would be easier.
So menu choices or interactions with the browser would be protected by exception handling and could pop up dialogs, while the real functionality would raise exceptions while necessary.
One of the big problems with making a headless image _and_ discarding the graphics is all the calls to raise dialogs and popup menus.
Dan Ingalls wrote:
[Mention of difficulties slimming image]
People will tell you this is the problem with the unified image approach, but I disagree. The problem is simply that we haven't drawn appropriate lines between the various parts of the system, so when you cut one out, you're left with dangling dependences.
The deeper issue is management of complexity. In a Smalltalk sense, it is that a "module" providing a certain functionality typically consists of multiple classes that need to cooperate to get things done (thus a Smalltalk class really isn't a "module" in any meaningful sense).
Of course this is made worse by the fact that subclassing or copying a whole bunch of classes in Smalltalk is a lot of work, so it is easier to patch new functionality directly into the old classes as a practical matter, as was done with the C code generation stuff added to the parser classes.
One can manage complexity by hand in Smalltalk (being very careful about how modules are created). You can do it in assembler or C by hand as well. Modula or modern Lisps or even Delphi Pascal at least address this issue somewhat by having modules or units providing some sort of defined functionality and having defines interfaces. One can also do somethign like this by using something like ENVY (with its application and the extension concepts).
But in practice it is very hard to do it in Smalltalk by hand when a lot of developers are working together -- see my "SystemDictionary>>version" post where I cite: SystemDictionary>>version "Answer the version of this release." ^ EToySystem version , ' of ' , EToySystem versionDate
The issues were put very eloquently by Les Tyrrell and others (esp. in his Re: Belling the cat of complexity (was: Ship it with Squeak) Resent-Date: 30 Jun 2000 23:20:05 -0000) As long as a monolithic big image is what people download and what is supported as part of the mainline, testing for a shippable app is a nightmare, because a pruned image is a new (untested) image and has to be retested. Building up from a solid core is the only realistic path to reliability.
I feel strongly on this complexity management issue -- enough to start wondering whether it would be better for my own efforts to pick another cross-platform solution that has a stable core (MzScheme?) and add on Squeak like functionality. I guess "SystemDictionary>>version" is making me despair at realizing how deep the Squeak complexity problem has grown. Squeak has lots of great ideas and great work, but it's the "building your house on sand" concept. If you want your house to stand, either move it onto rocks or put in deep piles underneath. Either is a lot of work. It's easier to just add on to a house someone else already built on a rock.
I understand the value to SqueakC to have everyone banging on the big image SqueakC uses its own work. But I think in the end you and many other Squeakers would be better served by having a slim image as the mainline system, with everything possible (including Morphic) being loaded as needed. A convenience kitchen sink image is OK; just always build it from the slim core for each release.
(And ideally that core image should be built via the ANSI declarative approach but that is another rant.)
I think that real value would come from declaring this as a project, with a goal of having maybe 20 discardX methods that really worked and that wouldn't get out of date in the next month.
I just can't see this really being a good solution. It will get out of date immediately in a new release and produce lots of difficult to maintain code. This is because every remove method will have to be written by an expert (or someone becoming one) on that subsystem (and every other subsystem that uses it).
-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
Dan Ingalls wrote:
The problem is simply that we haven't drawn appropriate lines between the various parts of the system, so when you cut one out, you're left with dangling dependences.
Amen to that--and the best example of this is the scripting system, aka eToy ;)
Here are a few hints for shrinking Morphic from my own experience:
Currently "Morphic" is a huge 2.8 MB chunk of the image, but with just an hour of work I got it down to 1M or by 1M, I don't remember which. The main part of the time was spent on at all being able to remove the scripting system from the rest. The biggest part was refactoring the Forms dictionary out of there and into somewhere else--I think I put it in ImageMorph but that may not be the ultimate placement.
In all, "Morphic" is too vaguely defined even as a concept, wrt shrinking & separation. The bulk of it (apart from obvious things like 3D) is taken up by non-essential things like widgets, various tools, etc.--these aren't really part of Morphic.
Eventually, I decided to put this off until the project swapping mechanism was in full effect for this type of job. But drats, I threw away the refactored code too!
Henrik
Paul-
I wouldn't count on this for your own needs since you are trying to do something in the near future and I have only a limited amount of time to work on this. But, it seems to me that building a modular Squeak is a really good use case for me right now, as it puts just the right kinds of stresses on the tools I've been building. This will take a while, as I really need the third and final piece of Oasis in place to do this easily, and I will be devoting most of my effort on building that and merely using the "modular Squeak" use case as a motivating example. But the end result is that one would be able to pick any of the Squeak versions, as well as several other dialects, and then assemble the class libraries in a controlled manner for your deliverable.
I've done enough of this so far to know that there will be some tough problems to crack- but I think it can be done. The case for optimism rests on my currently being able to execute code written for Squeak that is sitting on top of PocketSmalltalk's core class library, running within VisualWorks. Not that I have every little problem taken care of and a totally seamless solution, but that I can indeed execute the code and use regular programming tools on it- just like we've grown used to doing in regular Smalltalk image land. On the pessimistic side, there is still a fair amount of substantial and at times difficult work to be done before seamless operation is routine.
Take care!
- les
I've just tripped over a quite good example of the problems we face in using a 'remove what you don't want' approach. It illustrates how tricky it can be to keep everything up to date.
I want to make a small image with Morphic left in (and lots of other stuff in or out, but irrelevant, I think) so I've been looking at various discard* methods and trying them out. This afternoon I doit'd the chunk of code in majorShrink that dumps all the changes (because I was trying to automatically get rid of projects, there were some still sitting around because some change records were holding on to methods with projects mumble, mumble) and accidentally included the phrase "ScriptingSystem _ nil" Boom. Dead system. Because ScriptingSystem, the global instance of StandardScriptingSystem, has a FormDictionary which is where the icon Form for SystemWindow>addMenuControl is found. No ScriptingSystem, no icon, no understand message, raise exception, try to open notiifer which... you guessed it, wants the same icon!
If you remove Morphic, IconicButton goes and so the problem probably won't occur.
Is the FormDictionary class var of StandardScriptingSystem really the best place for this kind of Form? Maybe the #labelGraphic: code should be able to cope with nil.
Just another little pebble in the path of progress.
tim
Attached is a tidyup of the shrink code (mainly folding the stuff in discardFor2.7 back to the'right' places) thats shrinks a 2.8 image to ~930Kb.
tim
cole@griffoninc.com wrote:
I'm sure this has been addressed many times, but there is no good source of documentation at the swiki. With the changes in 2.8 and 2.9a things have probably changed enough that this question is worth revisiting in the context of the 'ship it with squeak' discussion.
Actually, there is some information on the Swiki, if you look at the Squeak FAQ under the question: "How do you make a Squeak executable that can be distributed? (Including end-user bulletproofing, and stripping out unused code?)"
Basically, the answer comes down to using SystemDictionary>>majorShrink or some subset of the methods inside it. I just tried running majorShrink in 2.8, and it seems to generally work, with a few quirks such as changesorters not working.
- Doug Way dway@mat.net, @riskmetrics.com RiskMetrics Group, Ann Arbor, MI http://www.riskmetrics.com
I would love to be able to ship a squeak image that had only morphic, the necessary programming classes and the classes necessary for my application. Is there a semi-magical method? Failing that, how do I go about doing this systematically (that is without simply wiping out classes sequentially and checking to see what fails.) Finally, compared to the base image (say 2.8) - what are reasonable expectations for a reduced image size (with morphic, without MVC (is this possible?), with the network support, Scamper, Celeste, the morphic widgets and toolkit classes but without the 3D stuff, Wonderland, speech, music and all those nifty toys etc.)
Michael Cole broccole@panix.com
squeak-dev@lists.squeakfoundation.org
-
cole＠griffoninc.com -
Dan Ingalls -
Doug Way -
Henrik Gedenryd -
Les Tyrrell -
Ned Konz -
Paul Fernhout -
Tim Rowledge