Lagoon suggestions

Andy,

I'm noticing a pattern in my stripping problems.  Based on my experience,
it's common to have application specific hierarchies of classes that should
not be stripped.  One app might glue together instances based on user
selections (so there might be no hard references to the classes) and another
might get an STB blob that it has to read, again without any hard references
to the classes.

It would help to have a way for the class itself to "say" something like
"don't strip me or my subclasses" and "don't strip any of my methods".  As
it is, I'm having to look around for classes that need to be hard
referenced, and I even have a small script to write a period/cr separated
list of sub-class names - it would be easier and more robust to let the
super class flag itself and its subclasses as being required.  It might also
be useful to say "don't strip much of anything from package XYZ", though it
might be more than enough to tag a few super classes.

It should be fairly easy to build a custom image stripper to do basically
the same thing given collections of classes.  Unless you have a better
suggestion I'll probably start on that shortly.  At present, I **almost**
have 4.0 apps in service, with two of the server-side apps temporarily
unable to strip classes.

Not meaning to nag, but I once again had need for a hack to show the class
name when the class locator can't find a class.  So far, every time I've
encountered that, the "bug" has been that a required (but not referenced)
class was stripped - knowing that a class wasn't found and its identity is
usually enough to fix the problem.  My experience has been that crash dumps
don't reveal the class name.  This has been particularly relevant to the
plugin, because I have a would-be applet that works when debugged and fails
when "deployed".

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:919tqa$39so9$[hidden email]...
>
> I'm noticing a pattern in my stripping problems.  Based on my experience,
> it's common to have application specific hierarchies of classes that
should
> not be stripped.  One app might glue together instances based on user
> selections (so there might be no hard references to the classes) and
another
> might get an STB blob that it has to read, again without any hard
references
> to the classes.

That sounds similar to the plugin, and the most sensible option in this case
(bearing in mind one cannot predict in advance what is going to be required
in the application) is to:

a) turn off stripping of redundant classes and methods altogether, and just
rely on package stripping to remove development stuff, etc, (as the plugin
does)
b) consider making use of binary package loading to dynamically extend the
deployed application.

It sounds like you'd really get more flexibility from a dynamically
extensible image, than one which simply has all the stuff in it that you
decided was necessary when it was originally deployed. You are stepping
outside the design parameters of the image stripper's identification of
redundant code, because it relies on having full information as to what will
be needed. I fear that if you step outside this and attempt to introduce too
much manual configuration of what you think is likely to be required in your
dynamic run-time environment, that you will be creating a considerable
maintenance burden for yourself. Furthermore you'll also be completely
reliant on effective coverage testing to know that the application is
complete, without getting very much assistance from the system. In those
circumstances it would seem to be most sensible to just disable the "tree
shaking" algorithm, because there isn't really sufficient information
available at deployment time for it to produce reliable applications.

>.. It should be fairly easy to build a custom image stripper to do
basically
> the same thing given collections of classes.  Unless you have a better
> suggestion I'll probably start on that shortly. ...

By all means do that if you wish, but I would simply rely on package
stripping. This works very effectively if the application is partitioned to
a fine enough level of granularity (in fact this is one of the primary
contributor to the considerably smaller applications that can be deployed
from 4.0). You might find you need to do a custom image stripper anyway in
order to specify the set of root packages completely, but that should be
much easier to maintain.

>...
> Not meaning to nag, but I once again had need for a hack to show the class
> name when the class locator can't find a class.  So far, every time I've
> encountered that, the "bug" has been that a required (but not referenced)
> class was stripped - knowing that a class wasn't found and its identity is
> usually enough to fix the problem.  My experience has been that crash
dumps
> don't reveal the class name.  This has been particularly relevant to the
> plugin, because I have a would-be applet that works when debugged and
fails
> when "deployed".

I agree that it should be much clearer (i.e. in the error message), but you
can determine the missing class from the crash dump because it includes data
as well as walkback, the latter . Look down the raw stack trace you will
find the string name of the class sandwiched in between
STBInFiler>>readClassData: and STBInFiler>>basicNext, for example:
...
[0x0E3B04DC: 294]-->nil
[0x0E3B04D8: 293]-->a ClassLocator
[0x0E3B04D4: 292]-->119374420
[0x0E3B04D0: 291]-->STBInFiler>>readClassData:
[0x0E3B04CC: 290]-->119374442
[0x0E3B04C8: 289]-->26
[0x0E3B04C4: 288]-->119374408
[0x0E3B04C0: 287]-->nil
[0x0E3B04BC: 286]-->nil
[0x0E3B04B8: 285]-->nil
[0x0E3B04B4: 284]-->'Blah'
[0x0E3B04B0: 283]-->nil
[0x0E3B04AC: 282]-->0
[0x0E3B04A8: 281]-->262150
[0x0E3B04A4: 280]-->a STBInFiler
[0x0E3B04A0: 279]-->119374400
[0x0E3B049C: 278]-->STBInFiler>>basicNext
[0x0E3B0498: 277]-->119374416
...

In this case my missing class was 'Blah'. Without the WDK installed this
will be about 75 slots away from the top of the stack.

I will put improved error reporting in the case on missing classes on the
list for PL2. I hope it will be possible to patch it without changing too
much, but it may turn out to be unsuitable for a patch modification.

Regards

Blair

Blair,

> It sounds like you'd really get more flexibility from a dynamically
> extensible image, than one which simply has all the stuff in it that you
> decided was necessary when it was originally deployed.

Binary packages probably add a level of complexity that I don't really need
right now - that will change eventually though.  You might recall my failed
attempt to compile methods in a deployed app; binary packages are the answer
for that particular task.


> You are stepping
> outside the design parameters of the image stripper's identification of
> redundant code, because it relies on having full information as to what
will
> be needed.

Thanks for the heads-up.


> I fear that if you step outside this and attempt to introduce too
> much manual configuration of what you think is likely to be required in
your
> dynamic run-time environment, that you will be creating a considerable
> maintenance burden for yourself. Furthermore you'll also be completely
> reliant on effective coverage testing to know that the application is
> complete, without getting very much assistance from the system. In those
> circumstances it would seem to be most sensible to just disable the "tree
> shaking" algorithm, because there isn't really sufficient information
> available at deployment time for it to produce reliable applications.

Sounds like good advice.


> By all means do that if you wish, but I would simply rely on package
> stripping. This works very effectively if the application is partitioned
to
> a fine enough level of granularity (in fact this is one of the primary
> contributor to the considerably smaller applications that can be deployed
> from 4.0). You might find you need to do a custom image stripper anyway in
> order to specify the set of root packages completely, but that should be
> much easier to maintain.

Your point about granularity is well taken.  If this becomes a motivation to
create even more packages, it might be helpful to have their icons reflect
their status, if only to identify which packages have non-trivial image
strippers.


> In this case my missing class was 'Blah'. Without the WDK installed this
> will be about 75 slots away from the top of the stack.

Ok, I'll have another look - at 75 lines down, I probably did simply miss
it.


> I will put improved error reporting in the case on missing classes on the
> list for PL2. I hope it will be possible to patch it without changing too
> much, but it may turn out to be unsuitable for a patch modification.

If it's a big hassle, it can, of course, wait for a larger release.
Whenever it appears, I'm confident that it will be helpful.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]