Deployment problems

I'm trying once again to deploy.  The same problems occur.  I'm still
getting the nil.DefaultView error and the a crash.  This occurs during a
call to ResourceIdentifier>>resource, which is called from three places in
the ImageStripper.  Placing a #halt before each of these sends causes lockup
during stripping.  I cannot debug it.  Any suggestions on how to track down
this problem?

I still get the warning about the Development system early on.  How can I go
about cleaning up this aspect of the problem before debugging the second
stripping problem involving the nil.DefaultView above?  Perhaps this one
will go away, if I eliminate the initial warning.

Also, a very strange problem:  I created a new RuntimeSessionManager
subclass, and deleted the old one, whereupon I got a file-not-found
exception when I tried to save the package containing these
RuntimeSessionManagers.  The unfound file mentioned was a .pak file, but I
have always saved the package as a .pac file.  Does anyone understand what
is happening here?


Shaping

Exactly which classes in which packages are considered to be part of the
development environment?  I suppose that package Dolphin covers the
development system.


Shaping


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

> Exactly which classes in which packages are considered to be part of the
> development environment?  

All classes and loose methods in package 'Development System', found in
Object Arts\Dolphin\IDE\Base.

> I suppose that package Dolphin covers the development system.

No, only part of it, as per above.

> I still get the warning about the Development system early on.  How can I go
> about cleaning up this aspect of the problem

Check your package's prerequisites in the package browser.  Choose the
Prereqs tab, then expand the root node in the tree to show prereqs.
Presumably, Development System will be there.  Choose Development System
and look at what's in the bottom pane, which should be what your package
is referencing that's in the Dev. System.

> Also, a very strange problem:  I created a new RuntimeSessionManager
> subclass, and deleted the old one, ...

A quick look in DSDN (Do you have DSDN installed?) shows that Chris
Uppal wrote about this (12/27/04) - that might help.  There was also an
earlier post which seemed to help the person having the problem, but it
was in spanish so I'm not sure if that'd help.

-- Monolingual Louis

Shaping,

> Exactly which classes in which packages are considered to be part of the
> development environment?  I suppose that package Dolphin covers the
> development system.

Evaluating either of the following should answer the classes/methods
considered to be part of the development system (for the default stripper).

ImageStripper new developmentClasses
ImageStripper new developmentMethods

--
Ian


Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Shaping,

> I'm trying once again to deploy.  The same problems occur.  I'm still
> getting the nil.DefaultView error and the a crash.  This occurs during a
> call to ResourceIdentifier>>resource, which is called from three places in
> the ImageStripper.  Placing a #halt before each of these sends causes
> lockup during stripping.  I cannot debug it.  Any suggestions on how to
> track down this problem?

Do you get anything in the deployment log?. If so then you could post the
last few lines here to give us some idea of what the problem might be.

If the log is not available, maybe because the file is not closed?, if might
be worth temporarily patching the log generator so that it opens/closes the
log file after every entry.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Shaping wrote:

> I'm still
> getting the nil.DefaultView error and the a crash.  This occurs during a
> call to ResourceIdentifier>>resource, which is called from three places in
> the ImageStripper.  Placing a #halt before each of these sends causes
> lockup during stripping.  I cannot debug it.  Any suggestions on how to
> track down this problem?

(As I said before) Tracing, more tracing, and still more tracing after that.
You can't debug the stripping process using the debugger.  I'd use

    Trace display: '...whatever...'; flush.

and the 'DebugView' tool from www.sysinternals.com to read the tracing
information.

Incidentally, I /strongly/ recommend the above tracing tools to every Dolphin
programmer with deployed applications.


> I still get the warning about the Development system early on.  How can I
> go about cleaning up this aspect of the problem before debugging the
> second stripping problem involving the nil.DefaultView above?  Perhaps
> this one will go away, if I eliminate the initial warning.

Some suggestions:

First, ensure that you have no formal dependencies on the development packages
(see ImageStripper>>developmentPackageNames).  This isn't strictly necessary
for stripping, since it's OK to have dependencies created by references from
methods in the 'must strip' category, but it's easier to track down what's
going on if you don't have any.  Don't do anything else until you have managed
to achieve this.

Second, you /are/ deploying from a completely clean image, aren't you ?

Third, look at the stripping log carefully.  It will probably be complaining
somewhere about not removing classes because there are still outstanding
instances.  That may give you a clue.  Or maybe something else in the log will
ring a bell -- there's quite a lot of information there.

BTW, Andy or Blair mentioned some time ago that the feedback from stripping is
much improved in D6, including new tools for parsing the logs.  it may be
worthwhile waiting to see that will help.  (Unless you are pushed for time,
anyway).

Otherwise I can't think of anything but to fall back on God's Own Debugger --
tracing.


> I created a new RuntimeSessionManager
> subclass, and deleted the old one, whereupon I got a file-not-found
> exception when I tried to save the package containing these
> RuntimeSessionManagers.

See this thread:

http://groups.google.co.uk/groups?threadm=u_OdncGDwt9CaFLcRVn-jw%40nildram.net

    -- chris

Shaping wrote:
> Exactly which classes in which packages are considered to be part of the
> development environment?  I suppose that package Dolphin covers the
> development system.

Adding to the previous replies, for legal information:

    SmalltalkSystem current openUrl: 'redist.txt'

    -- chris

> I'm trying once again to deploy.  The same problems occur.  I'm still
> getting the nil.DefaultView error and the a crash.  This occurs during a
> call to ResourceIdentifier>>resource, which is called from three places in
> the ImageStripper.  Placing a #halt before each of these sends causes lockup
> during stripping.  I cannot debug it.  Any suggestions on how to track down
> this problem?

Do you have something that is not packaged?  IIRC, I've seen
nil.viewName in that situation.

Have a good one,

Bill


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

>> I still get the warning about the Development system early on.  How can I
>> go about cleaning up this aspect of the problem
>
> Check your package's prerequisites in the package browser.  Choose the
> Prereqs tab, then expand the root node in the tree to show prereqs.
> Presumably, Development System will be there.  Choose Development System
> and look at what's in the bottom pane, which should be what your package
> is referencing that's in the Dev. System.

My package requires methods, classes, and globals in Development System,
indirectly via ST3D's use of these objects.  I'm trying to straighten this
out with Chris Hayes, but haven't heard back from him recently.  I have only
a few days to do the stripping.  Has anyone deployed using ST3D, and if so,
how did you deal with these dependencies?  I have Creative Computing's
CcSt3DImageStripper and instructions, but the result is no different.

>
>> Also, a very strange problem:  I created a new RuntimeSessionManager
>> subclass, and deleted the old one, ...
>
> A quick look in DSDN (Do you have DSDN installed?) shows that Chris Uppal
> wrote about this (12/27/04) - that might help.  There was also an earlier
> post which seemed to help the person having the problem, but it was in
> spanish so I'm not sure if that'd help.

I found it. Thanks.  Chris' suggestion worked as described.  Why must we use
STB in cases such as these?


Shaping

Some of my packages extend classes in the Development system with additional
methods or override a few existing methods.  For example,
ViewComposer>>defaultGridResolution is overridden, and the override is place
in one of my packages, which is required by the package containing the app
classes.  I am assuming that I can spread my methods and classes around in
several packages, even when deploying.  The overridden method above is not
used in my app; so it shouldn't be a problem.

>
> Second, you /are/ deploying from a completely clean image, aren't you ?

No, I'm cleaning up now, and trying to reload packages.  There must be a
problem, because I cannot even /unload/ the app's package set and save the
resulting image, without creating an unlaunchable image.  Starting with a
clean image and loading the top level package would be a simpler experiment.

I start with a clean image whose default font has been change.  That's all.
I leave up my favorite windows, like Package Browser, and save this image
under a new name to test loading of my app packages.

When I load my top-level package, the compiler generates an error because it
is compiling a bad class definition (duplicate instance variable).
Apparently, I forgot to clean this up, and left it.  So I went back to the
original image, fixed it.  I now do the load a second time, and the compiler
complains about a class-side method with "nonsense at the end".  I searched
for the method in the original image, found it.  It is correct and works.  I
search for refs to it in the class in which the compiler error occurred.  I
found it.  The method is precompiled, and looks like

method1
  ^##(MyClass method2)

Why should this be problem when loading a package?
I'll unprecompile the method, for now, to get on with the stripping...


>
> Third, look at the stripping log carefully.  It will probably be
> complaining somewhere about not removing classes because there are still
> outstanding
> instances.  That may give you a clue.  Or maybe something else in the log
> will
> ring a bell -- there's quite a lot of information there.

The log stops at Removing Redundant Methods....  There is nothing after it,
and this happens presumably just before the crash.

>
> BTW, Andy or Blair mentioned some time ago that the feedback from
> stripping is much improved in D6, including new tools for parsing the
> logs.  it may be
> worthwhile waiting to see that will help.  (Unless you are pushed for
> time,
> anyway).

I am pressed for time.  But that is good news, and I look forward to a
smoother process.

>> I created a new RuntimeSessionManager
>> subclass, and deleted the old one, whereupon I got a file-not-found
>> exception when I tried to save the package containing these
>> RuntimeSessionManagers.
>
> See this thread:
>
> http://groups.google.co.uk/groups?threadm=u_OdncGDwt9CaFLcRVn-jw%40nildram.net

I found your posting.  Thanks for the thorough explanation.  I'm not
convinced that STB is an appropriate solution here.  It creates a brittle
situation that is difficult to detect, if you don't know these little, but
critical implementation details.


Shaping

Never mind.

The problem seems to be detecting MyClass' package at compile time versus
its package at load time, and allowing the system to determine the necessary
preqs.  I suppose that if this class is not already in the system, the
loading machinery has no way to determine where it is, because the method is
nonsymbolic/compiled at this point.  Another STB-like situation?


Shaping

My top-level package has a class that has a class-side method that uses a
method I have defined (on a base class) in Package1.  I have confirmed this;
yet Package1 is not listed in the Prereq list for my top-level package.
Hence, I'm getting a compiler error about use of this method when I load the
top-level package.

I am assuming that Packages update their prereqs dynamically as the image
changes.  Is this correct?  If so, how could this happen?

Shaping

My code is in eight packages.  One of these has most of it (about 300
classes).  The other seven are much smaller and are extensions or overrides
of base packages or third-party packages.

I can load the eight packages, bottom-up into the image.  Everything goes
well, and the app works correctly.  I cannot, as I thought, load the
top-level package and have it bring in the others (actually the top-level
package only needs six of the seven others).  Only one other prereq comes
in, when clearly there are methods needed from the other five packages.  I
can easily confirm this by running the app, and noting exceptions for
missing methods I know to be in the other packages.  So, why are prereqs not
working correctly?  Or, what have I likely done to screw up the system's
perception of the actual prereqs?

Shaping

I had many methods that had not been packaged.  I did not notice this until
long after it occurred.  I wrote a lot of stuff in from VW very quickly, and
let the packaging constraints go for a while.

The 'unpackaged' prereq category is great for determining what you have
created, so that you can later put it in the right package, without having
to do that as you work.  I'm not sure what the default packaging conventions
are.  Some of my unpackaged stuff was not categorized as such.  Some of it
was.  I would like to have every class created or redefined and every method
created or overriden placed in 'unpackaged', so that nothing slips through.
Is there a way?


Shaping

Well, I got a successful strip, sort of.

There was a problem at the end.  A few moments after appearance of the
one-line window saying something like "Wait while Lagoon finishes", I got a
popup saying "Blah class does not understand #onStartup.  Blah really needs
to run that method to initialize a cached on startup and on return from
snapshot.  I need to keep this method.  I placed it in category 'must not
strip', thinking that it would be retained, but it was not.  Why is this
method being removed?  #onStartup:, however, /was/ retained, according to
the log.

I tried double-clicking the .exe anyway, which was corrupt.  The last line
in the log says 'Image stripping completed'.

I still have a strange prereq situation, as described earlier, which
prevents automatic loading of all required packages, by loading the
top-level package.


Shaping

I have a working .exe, but it dumps a few errors into the .ERRORS files.
Only one of these I can explain.  The others don't relate directly to
domain-level goings-on in the app.

To get the strip to work, I had to declare as manual prereqs for the top
level package all of the remaining packages.  Must we always do this?


Shaping

[Just a few observations since I see from your later posts that you have
resolved the immediate difficulty]

Shaping wrote:

> Some of my packages extend classes in the Development system with
> additional methods or override a few existing methods.  For example,
> ViewComposer>>defaultGridResolution is overridden, and the override is
> place
> in one of my packages, which is required by the package containing the app
> classes.  I am assuming that I can spread my methods and classes around in
> several packages, even when deploying.  The overridden method above is not
> used in my app; so it shouldn't be a problem.

It sounds as if you have a rather, um, unstructured system of packages.  I
believe that the assignment of code to packages is part of the software
/design/ in much the same way (and for much the same reasons) as the assignment
of functionality to classes is part of the design.  In any case, I'd recommend
against mixing development-time code, like IDE enhancements, with deployable
code -- if only because mixing them will interfere significantly with the
effectiveness of the image stripper.   The first phase of stripping, where
unneeded packages are removed, contributes a lot to the effectiveness of the
stripper.  So "entangling" your packages (and the Dolphin ones) will reduce its
effectiveness.


> method1
>   ^##(MyClass method2)

A warning about using this technique -- if MyClass, or #method2, are in the
same package as #method1 then an expression like the above may work normally
when it's first defined, but fail when the package is next loaded.  Since the
evaluatation of the expression happens at the time when the packaged code is
compiled, there is no guarantee that the code it invokes has already been
compiled.  If not then you'll get an error.  This isn't an issue if the
expression only invokes code in other, already loaded, packages.


[From later posts in this thread]

> My top-level package has a class that has a class-side method that uses a
> method I have defined (on a base class) in Package1.  I have confirmed
> this; yet Package1 is not listed in the Prereq list for my top-level
> package. Hence, I'm getting a compiler error about use of this method
> when I load the top-level package.

Message sends are not used by the automatic dependency computation.
Class/global references are tracked, as are the contents of the known STBed
byte arrays (e.g. resources and #imageStripperBytes).  So if you know that one
of your packages uses a method that is defined in another package, but does not
use any of that package's classes/globals, then you'll have to set a manual
pre-requisite.  One good idea (which I admit I'm too lazy to use) is to add the
pre-requisite from the package's post-install script; that way you can add a
comment to say /why/ there's a manual pre-requisite.

Incidentally, if you are doing a lot of moving stuff around in packages, then
it's worth bearing in mind that a change to the automatically computed
pre-requisites of a package does /not/ result in that package being marked as
'changed' (which is probably a bug, though I don't remember anyone complaining
about being bitten by it).


> Some of my unpackaged stuff was not categorized as
> such.  Some of it was.  I would like to have every class created or
> redefined and every method created or overridden placed in 'unpackaged',
> so that nothing slips through. Is there a way?

Classes and globals are created unpackaged by default.  Methods and resources
are created in the same package as their owning class by default.  If you edit
a 'method and save it under a different name, then the new method will be in
the same package as the original method.  IIRC, copying methods by drag and
drop also preserves the owning package.  You can set a default package from the
Package Browser.  I've never used that feature myself so I don't know how it
interacts with new method definition, or with changes to existing methods'
definitions.

    -- chris

Shaping wrote:
>>...snip... Some of my unpackaged stuff was not categorized as such.  Some of it
> was.  I would like to have every class created or redefined and every method
> created or overriden placed in 'unpackaged', so that nothing slips through.
> Is there a way?

Almost - but not quite.

New classes and globals are created unpackaged, so you can
already move these to the right package whenever you want.

Now, if you add a new package named 'yourPrefix-Default'
and set it as the default package, then 'new' things
will be put in that default package. (RECOMMENDED PRACTICE).

So 'new' methods and resources are created in the default package.
If you edit a method and save it under a different name, then the
new method will be in the default package.  Copying methods by drag
and drop also puts the new copy in the default package, as will any
new methods or renames that result from a refactoring.

However, any other changes to existing methods (i.e. that do not
change the method name) stay in the original owning package.

This last bit is sometimes good, sometimes bad.

Good - when you are lazy, and the method was already in one of
        your packages. So you save the effort of moving it back
        to where it otherwise 'obviously belongs'.

Bad - when the method was/is in somebody else's package.
       In this case, you'd really like the edited method
       to go to the default package, so you can put it in
       a 'local changes to XXX package from source YYY' package.
       This is so you don't create an unmanaged 'new version' of
       someone else's package (original name and version string!!)
       by re-saving the original package, now with your changes.
       ---> This should really be fixed. <---


Note that loose methods can be moved from 'default' to 'actual'
package either one at a time, in situ, or in bulk, using the PB.

Also note that, in the system browser, you cannot edit, refactor,
or -surprise- repackage a method that is owned by a package other
than the one(s) selected in the left pane.  However, if you
double-click the method (right pane) you'll get a class browser
with no package ownership restrictions.


Regards,

-cstb

The above sentence contains a typo.  It should read "which is /not/ required
by the package containing the app class."  Sorry for the confusion.

The packages are well organized.

I want an option that forces the expulsion (or nonpackaging, if new) of
class redefinitions, new methods, and method overrides from their current
package into the unpackaged category.


Shaping