BUG?: [D4] Lagoon unloads Packages with methods only when they are needed

Packages that only contain methods are striped even if those methods are
needed and are referenced.

I have created a package (MitSciSystemAddOns) that only contains general
purpose methods I have added to Dolphin that I want to be able to use from a
number of different packages.

for example I have added these methods to ShellLibrary because I need to
pass parameters:

shellOpen: fileString parameters: aParameter

In my code (in another package) I send the message like this:

ShellLibrary default shellOpen: fileName parameters: params.

The problem is that MitSciSystemAddOns was being unloaded in the stripping
process.  My work around was to add a class called StripKeeperKludge to the
MitSciSystemAddOns package and then reference it from a "must not strip"
method in the package I was deploying.  I know I can turn off package
stripping, but I would rather not do that.

I understand that there might be a few ways to handle this.  Perhaps method
only packages should not be stripped, or maybe there could be a way to flag
an entire package as must not strip.  Can this be improved in Dolphin, or
should I do something differently?

Chris

Chris

You wrote in message news:96vco0$mcq2f$[hidden email]...
> Packages that only contain methods are striped even if those methods are
> needed and are referenced.
>...

True, but it is "by design". There is a tradeoff between stripping
efficiency and absolute safety, hence your reluctance to turn off the
package stripping I suppose. The purpose of the stripping of "redundant"
packages is to achieve significantly greater stripping efficiency than would
otherwise be possible; much of the the reduction from the 1.3Mb
HelloWorld.exe from Dolphin 3.0 to the 495Kb HelloWorld.exe from Dolphin 4.0
is attributable to first unloading entire packages. If the pre-requisites
included methods that *might* be sent, then an awful lot of extra stuff that
wasn't really needed would have to be retained. 95% of the time the package
pre-requisites tracking mechanism (relied upon by the image stripper) is
able to identify the precise set of packages that need to be retained.
Basically it will always do so if a class or global in that package is
referenced from the net of other packages that are required. Method only
packages are the only case I can think of where this will not be the case,
and manual intervention is required. That intervention can be done in two
basic ways:
1) The dummy reference bodge (as you have done, although I would suggest
using a global variable since it is a little less intrusive than a class).
2) Create a subclass of ImageStripper, and override #requiredPackageNames.
You'll see that this is a Set, which by default includes only the "root"
package (the one being deployed). but it can contain any list of packages
that you like.

No. 2 is the customisation mechanism intended by the design for that 5% (or
whatever) of cases, but ironically the bodge solution (No. 1) is somewhat
more satisfactory in that it is easier to do and solves another problem. The
other problem is that if the method-only package is being stripped by Lagoon
on deployment, then when the package that relies on it is loaded it won't be
automatically loading your method-only package either, because it won't be
among the pre-requisites that Dolphin has calculated.

Inspired by your posting I have put an enhancement into our system to allow
a list of pre-requisites to be explicitly specified for a package, in
addition to those established by the automatic package pre-requisites
tracing mechanism. In other words rather than relying entirely on the
automatic pre-requisite tracing, one will be able to manually specify other
packages that are pre-requisites. This will kill two birds with one stone
and both package loading and deployment will take note of the additional
prerequisite(s). Unfortunatley there probably won't be time to put this into
the 4.01 release.

Regards

Blair

Blair McGlashan <[hidden email]> wrote in message
news:9705jv$naf8h$[hidden email]...
>
> True, but it is "by design". There is a tradeoff between stripping
> efficiency and absolute safety, hence your reluctance to turn off the
>...
> Inspired by your posting I have put an enhancement into our system to
allow
> a list of pre-requisites to be explicitly specified for a package, in
> addition to those established by the automatic package pre-requisites
...

Excellent!  Thanks Blair, as usual OA has impressed me with their
responsiveness to issues that emerge from the trenches.  That is why you
guys have one of the most refined Smalltalk implementations available.

Congratulations on the new little instance. ;)

Chris

Blair,

> Inspired by your posting I have put an enhancement into our system to
allow
> a list of pre-requisites to be explicitly specified for a package, in
> addition to those established by the automatic package pre-requisites
> tracing mechanism.

This is great news.  I've been wanting that for *years*.

    -- chris