Greetings to you, PhiHo--

=> 3/2/01 10:39:53 PM EST, phiho.hoang at home.com =>
<< Greetings,
 
I am trying to add FFI functionality to the majorShrinked Squeak3.0.image 
(latest update #3552), VM 3.0 (release build 2). >>
 
What's the real objective here? Why are you adding to majorShrinked image?

I presume you need this for some "small" application destination. And what is 
needed is a "shunken" image + some facilities (restored from the original 
unshrunken image). If it is not something like this, do whatever you are up 
to in the full system. Save majorShrink activities for solving delivery 
problems (space, delivery band-width, etc.), as it is somewhat a trial to get 
what you need working.

In general, what you might find the quickest way to get what you need is to:

    (1) Figure out what are the primary facilities you want in the new 
shrunken image (the "some" facilities restored).
    (2) Iteratively figure out what is needed (dependencies) to make these 
work.
    (3) Remove the appropriate "delete" statements from the "majorShrink" 
code.
    (4) Perform #majorShrink (leave out #abandonSources and #lastRemoval)
    (5) Test
    (6) Go back (iterate) and re-evaluate #1 and #2 above.

<< When 'FFI-Kernel.st' (this was filed out from the full Squeak3.0.image) 
was filed in, I got a walkback 'MessageNotUnderstood: allSubInstancesDo:'. 
(The file 'Filein_FFI-Kernel.log' is attached) >>

The relevant thing here is the missing #allSubInstancesDo:. This is because 
it is not called in the shrunken image. I can't tell exactly what's going on 
from your walk-back, but my guess is that it may be similar to one of the 
"clever" things that Morphic facilities do -- often out-guessing the compiler 
to get some specialized (non-standard) Smalltalk behavior. Something in your 
needed classes is calling routines that mess with the instance variables 
(look up the walk-back to see this).

<< Is this because of the order of the classes in a fileout, must they be 
sorted according to the hierarchy ? >

That is an important consideration, but not really relevant here. majorShrink 
removes anything not used. If you deliberately remove something and then 
restore it by fileIn, you will need to file it back in in appropriate 
hierarchical order (top down). This is exactly the way I create Mini Swiki 
systems; I file out relevant classes, shrink, and then file relevant classes 
back in. Normally this is not needed, but Swiki is special (see below).
 
<< During the process of transfering the FFI functionality  to the 
majorShrinked image, I had to look at the hierarchy browser and manually file 
out and in, in a proper order. Followings are the files and order that were 
filed in: >>

Again this may be necessary, but the above suggested scenario would have you 
figure out how to remove these classes from the "shrink" process so you don't 
have to add them back in. (Also removing them before enables majorShrink to 
shrink those additional facilities (classes) also, removing unneeded methods 
from their signatures.)

Of course, there are many sub-systems (components) which have a lot of 
"blind" methods (a good example is PWS), which are needed by the facility, 
but are not called by methods contained in the facility. Much of the PWS 
functionality is driven by method references which are contained in the 
"pages" on the server, and typically all called ONLY from there.

Start by adjusting "shrink" code (#majorShink and methods called from it) to 
leave these in where they are removed. As an example, Behavior, 
ClassDescription and Metaclass are not going to be removed, but methods 
within them are being "shrunk" out of the image when other classes are 
removed. So change SystemDictionary>>#majorShrink to remove the line sending

    Smalltalk discardFFI.  "33k" 

(BTW, the space saved figures are quite old, and can only be depended on for 
relative estimates.). Then attempt to Shrink as see how close you get. 
Iterate.
 
<<     VMConstruction.Plugins.InterpreterPlugin        OK
         VMConstruction.Plugins.FFIPlugin                    OK
 
         Kernel.Classes.Behavior                                    OK
         Kernel.Classes.ClassDescription                        OK
         Kernel.Classes.Metaclass                                    OK
 
         FFI-Kernel-> MessageNotUnderstood: allSubInstancesDo: (ExternalType,
 ExternalStructure, ExternalData not filed in)
         FFI.Kernel.ExternalType                                    OK
         FFI.Kernel.ExternalStructure                             OK
         FFI.Kernel.ExternalData                                    OK
 
         FFI-Plugin                                                        OK
         FFI-Examples-MacOS                                    OK
         FFI-Examples-Win32                                    OK
         FFI-Examples-X11                                        OK >>

<< Is there an easier way to do this ?>>

Unfortunately not. At least, not yet.  I have been working on some 
componentizing tools, but they are not ready for prime time yeT.
 
<<Thanks for your help,
 
     PhiHo >>

You are welcome. Hope this helps,
Jerry.
____________________________

Jerry L. Archibald
systemObjectivesIncorporated
____________________________