Deploying

Must I somehow prepare the packages containing my application's classes,
before running the Lagoon Wizard?
Doesn't the image stripper have to know the statement I evaluate to launch
my shell ('MyShell show'), to determine what to save/strip, and as a
starting point for the exe?

I got the following error

No such resource: nil.DefaultView.




Shaping

Shaping wrote:

> Doesn't the image stripper have to know the statement I evaluate to launch
> my shell ('MyShell show'), to determine what to save/strip, and as a
> starting point for the exe?

The normal thing is for you to use a custom subclass of RuntimeSessionManager,
or of ConsoleSessionManager for console apps.  There are several simple
examples in the image.

The #main method of the session manager is invoked as the deployed .exe starts
up.

You can tell lagoon which session manager to install and run on the third page
of the wizard ("Step 2"), but I think that if the session manager is directly
in the package you are deploying then Lagoon will find it automatically.

The examples in the image are perhaps a bit /too/ simple.  They work, and
should be enough to get you started, but they don't exhibit some of the
complexities that most people seem to need to handle.  Check the archives for
#keepAlive, #shouldWaitForServers, and #defaultResLibPath for more background.

    -- chris

Thanks.  I wish these instructions (about the #main) also appeared in the
text of the Lagoon Wizard.  The explanations there are otherwise clear and
thorough.

I created my own RuntimeSessionManager subclass.  Stripping runs for a bit,
gives the warning about non-distributable dependencies, continues stripping,
and then crashes, stating something like


"An error occurred.  The image will now crash."

and

No such resource: nil.DefaultView.

ResourceIdentifier>>resource produces this last statement.  #resource is
called from three methods in ImageStripper.  Does anyone know what is wrong
here?  I have four layers of presenters from the Shell down to the OGL
presenter.  Each has its own saved view resource.


Shaping

Shaping wrote:

> I created my own RuntimeSessionManager subclass.  Stripping runs for a
> bit, gives the warning about non-distributable dependencies,

That warning is nearly always symptomatic of another problem, rather than being
something you just routinely ignore.  It's probably worth tracking down here.
It could be something as simple as having created your own
#publishableAspects[OfInstances] methods and forgetting to put them into the
'must strip' category, but the cause might be something more sinister...


> No such resource: nil.DefaultView.
>
> ResourceIdentifier>>resource produces this last statement.  #resource is
> called from three methods in ImageStripper.  Does anyone know what is
> wrong here?  I have four layers of presenters from the Shell down to the
> OGL presenter.  Each has its own saved view resource.

This is just speculation, but it may be that your pluggable architecture is
defeating the image stripper's built-in cross-reference tracing.  If so then
you should be able to see the wrong classes and/or resources being removed
(recorded in the log).

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:42298b7d$0$38039$[hidden email]...
The #publishableAspects[OfInstances] problem does not exist, but I cannot
see the dependency on Development System.  There are three references to it,
and it all cases I am not using the methods in question directly or
indirectly from my top-level shell.

I looked in the log, and none of my Presenter classes are being removed.

Is DefaultView above in 'nil.DefaultView' a class variable or view resource?


Shaping

Shaping wrote:

> The #publishableAspects[OfInstances] problem does not exist, but I cannot
> see the dependency on Development System.  There are three references to
> it, and it all cases I am not using the methods in question directly or
> indirectly from my top-level shell.

Unless the stipping process has /already/ realised that those methods cannot be
reached, then they'll still be there, pulling the dev. stuff in.  That check
happens quite early in the stripping process, IIRC, so there's a good chance
that they will still be there.  I suggest putting them into the 'must strip'
category, so that they'll be discarded very early on, or ensuring that
references to dev. classes are always indirect:

    Smalltalk at: #ADevClassName

so they won't cause problems.  BTW, it's not just a matter of suppressing an
irritating warning, the stripper works best when it can eliminate whole swathes
of stuff by removing the packages entirely, so allowing it to discard the dev.
packages will help it work effectively.


> Is DefaultView above in 'nil.DefaultView' a class variable or view
> resource?

Sounds like a view resource to me.  It also sounds as if you are in for a
tedious bit of debugging.  Unfortunately, that's not easy; I'd start by
sticking /lots/ of tracing into the image stripper, especially into
#resourcesForClasses:.

    -- chris