MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) (08/16/90)
After completing an application, an image is a mixture of development
oriented parts and parts needed by the application. The former occupies
the larger fraction, I guess. Are there any easy ways to check for those
classes/methods/objects which are not addressed by an application and can
therefore be removed? Best way would be an automatic solution which is
not trivial: All application procedures have to be simulated, crossreferences
have to be established. The cloning mechanisms in ST V need the explicit
mentioning of the classes/methods to be removed.
Any help is welcome -
Thomas
-------
Thomas Muhr, Technical University of Berlin, BITNET: muhrth@db0tui11
Project ATLAS - Computer Based Tools for Qualitative Research
"Computers, like every technology, are a vehicle
for the transformation of tradition." (WINOGRAD/FLORES)timm@runxtsa.runx.oz.au (Tim Menzies) (08/18/90)
In article <90228.105114MUHRTH@DB0TUI11.BITNET> MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) writes: >After completing an application, an image is a mixture of development >oriented parts and parts needed by the application. The former occupies >the larger fraction, I guess. Are there any easy ways to check for those >classes/methods/objects which are not addressed by an application and can >therefore be removed? Best way would be an automatic solution which is >not trivial: All application procedures have to be simulated, crossreferences >have to be established. The cloning mechanisms in ST V need the explicit >mentioning of the classes/methods to be removed. >Any help is welcome - WARNING, WARNING. I once rang up the technical department of Digitalk about some problem I was having with the cloner. After dancing around my question for a while, there was a little silence, then the techo I was talking to said that the cloner was a very flaky bit of software and that different runs of the cloner would come up with different errors. So I stopped using the cloner. I thought a bit about what bits of the system I would throw away prior to releasing a Smalltalk/V application. Here's my list. Would the net like to add to t? Class HierarchyBrowser: delete class ClassbROWSER: delete class ClassReader: delete class Debuuger: delete class Inspector: delete class DictionaryInspector: delete class Compiler: delete class Behavior: remove sourceCodeAt: nothing can now be explored. souce code is fixed and can't be checked. ScreenDispatcher: change the initialize class method so that your application main menu was "the" main menu (then actually perform the initialization). SystemDictionary: change the start-up method to throw the user into your application at start up. Object: change the error: instance method to write the error to a file, then exit with "Smalltalk forgetImage" All this should happen after a "Smalltalk compressSources". Also, for total security, I'd like to remove sources.sml. Does anyone on the net know if I can run a Smalltalk/V system with an empty sources.sml?