Preventiong resource from beeing stripped?

Hi How do I prevent resource from being stripped? I am using
ChoicePresenter, and its resource:

ChoicePresenter.Multi-selection list box

gets stripped. I have tried adding ChoicePrompter in requiredClasses for the
stripper but it does not help.

Thanks,

rush
--
http://www.templatetamer.com/

rush wrote:

> Hi How do I prevent resource from being stripped? I am using
> ChoicePresenter, and its resource:
>
> ChoicePresenter.Multi-selection list box
>
> gets stripped.

I don't know if this will help, but if ImageStripper>>resourcesForClasses: does
what its comment claims, then it should be sufficient to have a String literal
'Multi-selection list box' in some method somewhere (that is not stripped).
BTW, it looks as if it has to /be/ a String literal, not an element of a
literal Array.

Failing that you could always turn off #stripRedundantResources (but that's
taking a light battle-cruiser to crack a nut), or use a custom ImageStripper
that overrides #resourcesForClasses: to include the relevant resource.  But I'd
/hope/ that wouldn't be necessary.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...

Thanks Chris!

I am either doing something patently stupid, or there is something spookey
going on. First the string with name of the resource is present in method,
but it does not help. I have also added it to one of my methods but that did
not help either. Then I have overided #resourcesForClasses: in my image
stripper to add ChoicePrompter.Multi-selection choice prompter by force.
Still no do. Then I have clicked in deployment wizard that it does not strip
resources. Nope. It works only when I disable each and every kind of
stripping, including strip redundant packages. Anyway that brings my exe
from elegant 625 K  (hey even dos could handle that! ;) to bit more beefy
1.8M

rush
--
http://www.templatetamer.com/

Rush,

> I am either doing something patently stupid, or there is something spookey
> going on. First the string with name of the resource is present in method,
> but it does not help. I have also added it to one of my methods but that did
> not help either. Then I have overided #resourcesForClasses: in my image
> stripper to add ChoicePrompter.Multi-selection choice prompter by force.

Dumb question: are you certain you are using the customized image
stripper?  I would hope that a custom stripper would not be necessary,
but better to ponder that while you have the problem solved with
reasonable exe size.


> Still no do. Then I have clicked in deployment wizard that it does not strip
> resources. Nope. It works only when I disable each and every kind of
> stripping, including strip redundant packages. Anyway that brings my exe
> from elegant 625 K  (hey even dos could handle that! ;) to bit more beefy
> 1.8M

My first thought is that the resource is disappearing with a package,
but that is hard to envision (Dolphin MVP Base would be difficult to
lose).  Could you have repackaged it by mistake?

Perhaps a better theory: your original post references both
ChoicePresenter and ChoicePrompter, which have slightly different
multi-selection resource names.  Could you have pinned down one and used
the other?  Even then, I would expect things to fail in the IDE too, but
it can't hurt to look.

Have a good one,

Bill


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

> Dumb question: are you certain you are using the customized image
> stripper?  I would hope that a custom stripper would not be necessary,
> but better to ponder that while you have the problem solved with
> reasonable exe size.

yes, I have allready had my ImageStripper in place to write versions into
the exe, and the deployed exe does have correct version numbers in it, so I
am sure it has been used.

> My first thought is that the resource is disappearing with a package,
> but that is hard to envision (Dolphin MVP Base would be difficult to
> lose).  Could you have repackaged it by mistake?

I have checked ChoicePrompter class and all instance and class methods, and
they are in Dolphin MVP base package. Anyway, after some poking with Lagoon,
I have found out that problems go away if I do not click "strip redundant
packages" at the beginning. If I leave it unchecked, then I can use some of
the stripping options later, like strip redundant classes. This leaves me
with 900K exe, which is much better than 1.8M, but it still puzzles me why.

> Perhaps a better theory: your original post references both
> ChoicePresenter and ChoicePrompter, which have slightly different
> multi-selection resource names.  Could you have pinned down one and used
> the other?

Sorry for confussion in my first post, I am using ChoicePrompter like this:

ChoicePrompter multipleChoices: allGrabbers caption: 'Choose file aspects to
show'.

Thanks for helping me,

rush
--
http://www.templatetamer.com/

On Fri, 1 Oct 2004 08:06:10 +0200, rush <[hidden email]> wrote:

Sorry if this sounds redundant and silly, did you check if you have  
changed the package of the missing _resource_?

--
Regards
HweeBoon
MotionObj

"Yar Hwee Boon" <[hidden email]> wrote in message
news:[hidden email]...
> Sorry if this sounds redundant and silly, did you check if you have
> changed the package of the missing _resource_?

It is not silly at all, thanks. I have not changed it, but now when I look
at it, ChoicePrompter is in "Dolphin MVP Base", while resources for it are
in "Dolphin Common Controls" . Anyway Dolphin Common Controls does not seem
to be a prerequiste for Dolphin MVP base, and therefore everything from it
gets striped out if I choose to strip redundant packages.

So, I have added Dolphin Common Controls as manual prerequisite to my
package, choosed strip redundant packages in Lagoon, and it works, and exe
is back to 620K!

Andy-Blair maybe it would be a good idea to either improves stripping to
recognize such cases, or package these things more conviently, or at least
to add Dolphin Common Controls as prerequesite for Dolphin MVP Base. Maybe
there are also some other similar cases in the image.

Thanks to everyone who helped me out.

rush
--
http://www.templatetamer.com/

"rush" <[hidden email]> wrote in message
news:cjj704$s90$[hidden email]...
Well the whole point of the package stripping is that it is less
conservative than the other image stripping mechanisms. It is this less
conservative approach that allows much smaller applications to be deployed
from Dolphin 5.x (as you have experienced, based on the application sizes
you report with and without package stripping enabled). When experiencing
stripping problems such as this its a good idea to first turn off the
package stripping to see if that solves it. Another approach (which I
prefer) is to go and look at the log and see whether the package owning the
object was regarded as a "required" package, or a "redundant" package.If the
latter, and you are using objects from that package, then this must be
because the dependency is not visible to the automatic package prerequisites
tracing mechanism.  Remember that everything in the "redundant" packages
will be unloaded, regardless of whether actually needed, so it is essential
to make sure that the package dependencies reported in the package browser
are complete. This will be the case, except where loose resources or loose
methods are involved, or where a soft reference is involved (i.e. a symbolic
reference such as 'Smalltalk at: #Blah', or a programmatically constructed
reference).

As an aside the decision to use string names to reference view resources
that was made early in the Dolphin development cycle makes it very difficult
to perform effective detection of references to view resources. The image
stripper itself has to assume that any string literal in the image which
matches the name of a view resource might possibly be a reference to that
view resource. This is a conservative approach (which works reasonably well
in practice as long as views tend to have reasonably long unique names), but
since this comes into play only after redundant packages have been removed,
it won't help identify references to loose resources. Just as with loose
methods, the package prerequisites mechanism makes no attempt to identify
references to loose resources because we thought (and still think) it would
be too expensive, and probably couldn't be 100% accurate anyway.

'Dolphin Common Controls' is deliberately not a prerequisite of MVP Base,
because it extends the latter to add support for the "modern" Windows common
controls. It is itself dependent on MVP Base, and so could not be one of its
pre-requisites. The view resource in question has to be packaged loosely in
the common controls package, even though it defines a resource on a
presenter in MVP Base, because it uses a class in the common controls
package. If it were packaged otherwise, then a cyclic dependency would
exist, or we'd have to lump it all in one package and end up with a much
fatter base package.

Although it might not be much comfort to you, :-), this particular problem
is rare in practice. In fact this is the first time we've had such a report.
Most GUI applications that use the common controls at all will likely have
visible dependencies on the Common Controls package, because they will use
ListViews, TreeViews, etc, in the resources defined within their own
presenters, so you've been rather unlucky to have created an invisible
dependency on it.

A much more common problem in practice is finding that loose methods are
removed. The solution again is to first disable stripping of redundant
packages. This should at least give you working .exe and a fallback
position. You can then investigate which methods are being removed and why.

Lastly I'll just say that Dolphin 6 will provide some tools that will help
diagnosing deployment problems and in optimising the deployment process too.
The Lagoon deployment log is now an XML file that includes a complete
manifest of the content of the deployed application. This manifest can be
used to configure a new browser that is capable of showing any slice across
the system, and performing searches across that slice only. It includes a
facility to browse sent but not implemented messages in that subset of the
image that constitutes the application. This makes identification of some
missing methods (not those which have other implementations elsewhere in the
class hierarchy) considerably easier, and one can also quickly see where
they are referenced in the application. The same facility to browse
unimplemented messages is also available in the package browser. This
identifies messages that are sent but not implemented in a selected package
(or packages) and its (or their) prerequisites. This is a useful check
before deployment to help identify undetected dependencies on loose methods,
but its not as accurate as browsing the content of the actual application.
On the other side of the coin viewing the application content is a
significant aid in helping one discover and eliminate dependencies that are
not really required in order to produce minimally sized applications.

Regards

Blair

Blair,

> Although it might not be much comfort to you, :-), this particular problem
> is rare in practice. In fact this is the first time we've had such a report.
> Most GUI applications that use the common controls at all will likely have
> visible dependencies on the Common Controls package, because they will use
> ListViews, TreeViews, etc, in the resources defined within their own
> presenters, so you've been rather unlucky to have created an invisible
> dependency on it.

A small resulting suggestion: the CHB view/edit menus for resources
could do something (add a leading * or something) to emphasize that a
resource is not in the class' package, analogous to the coloring (also
an option) of loose methods.

Have a good one,

Bill


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

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
> Well the whole point of the package stripping is that it is less
> conservative than the other image stripping mechanisms. It is this less
> conservative approach that allows much smaller applications to be deployed
> from Dolphin 5.x (as you have experienced, based on the application sizes
> you report with and without package stripping enabled). When experiencing
> stripping problems such as this its a good idea to first turn off the
> package stripping to see if that solves it. Another approach (which I
> prefer) is to go and look at the log and see whether the package owning
the
> object was regarded as a "required" package, or a "redundant" package.If
the
> latter, and you are using objects from that package, then this must be
> because the dependency is not visible to the automatic package
prerequisites
> tracing mechanism.  Remember that everything in the "redundant" packages
> will be unloaded, regardless of whether actually needed, so it is
essential
> to make sure that the package dependencies reported in the package browser
> are complete. This will be the case, except where loose resources or loose
> methods are involved, or where a soft reference is involved (i.e. a
symbolic
> reference such as 'Smalltalk at: #Blah', or a programmatically constructed
> reference).

Blair thanks.

You obviously have several orders of magintude more insight than me of what
is possible during stripping and what is not.

Anyway, here is one idea from "bird eye perspective" of mine.  So we have 2
ways of stripping normal, more reliable, but less efficient, since its
effectivness gets clobbered in too large tree and too many constraints to
start with. There is also a more efficient, more agressive one which chops
off whole packages in start, but it may also chop of something that is
needed.

Us the users, frugal as we are, we would all like to reap results of more
efficient method, but without risks of failures in application. Ones that
can be spotted immediately are easy, but one could allways wonder if
something rare but important has been choped off.

So how about turning things other way around, instead starting with more
conservative settings, how about adding sanity check step after the
agressive deployment. For instance in my case I think lagoon could figure
out that I am actually potentially using the resource, and that this
resource is definitely not in the stripped image. So it coud say to me, I
have tried agressive method, but resource XYZ, from package ABC is missing.
Either make this package a manual prerequisite, or use some less agressive
method.

That would have a benefit that people could use more agressive method
without worrying of some spookey errors in deployed app.

Anyway, just a though, about your great product!

rush
--
http://www.templatetamer.com/

"rush" <[hidden email]> wrote in message
news:cju2l8$cr3$[hidden email]...
Thanks for your suggestion. The Dolphin 6 deployment log does tell you this
for methods (there is a section of the XML that lists any messages which
were implemented in the image before stripping begun, and which are still
apparently sent in the final executable), and as I said one can "browse the
executable" too to see this. The log could certainly list resources that
might have been inavertantly stripped too, although there are likely to be
more false positives in this list, and it may not help in cases where the
resource uses a common name such as 'Default view' - my advice is using
overly generic names for resources, just as it is a good idea to do so when
naming methods. Nevertheless I will put it on the list and if there is time
it will get done.

Regards

Blair