'End of Stream' problem with Lagoon packager

Friends,

I imported a package that I had created with Dolphin 3.x, and Dolphin 4.1
warned me there might be problems, but I went ahead anyhow, since I am not
aware of another, more appropriate way to bring my old code into 4.1.

Actually, the package loaded just fine, and the app runs just fine.

However, the Lagoon packager blows up telling me that the problem is 'End of
Stream'. I have a few custom views in my package; I wonder whether Dolphin
is choking on them...

Perhaps some wise soul can tell me how to solve this problem. Any help would
be most welcome and appreciated !

Below is the top of the stack trace from the .ERROR file produced by Lagoon.


*----> Stack Back Trace <----*
{0x1692064C: cf 0x1692062D, sp 0x1692065C, bp 0x16920644, ip 10,
VMLibrary>>crashDump:}
{0x1692062C: cf 0x1692060D, sp 0x1692063C, bp 0x16920624, ip 21,
ImageStripper>>onError:}
{0x1692060C: cf 0x169205F9, sp 0x1692061C, bp 0x168BFA20, ip 266, [] in
ImageStripper>>stripAndSaveNotifying:}
{0x169205F8: cf 0x169205DD, sp 0x16920608, bp 0x0872D7B8, ip 33, [] in
RaisedSignal(Exception)>>_evaluateHandler:in:}
{0x169205DC: cf 0x169205C9, sp 0x169205F4, bp 0x168BFBE0, ip 17,
BlockClosure>>ensure:}
{0x169205C8: cf 0x169205B5, sp 0x169205D8, bp 0x0872D7B8, ip 49,
RaisedSignal(Exception)>>_evaluateHandler:in:}
{0x169205B4: cf 0x169205A1, sp 0x169205C4, bp 0x08794048, ip 44,
RaisedSignal(Exception)>>_propagateFrom:}
{0x169205A0: cf 0x16920585, sp 0x169205B0, bp 0x1692059C, ip 6,
RaisedSignal(Exception)>>_propagate}
{0x16920584: cf 0x1692056D, sp 0x16920594, bp 0x16920584, ip 12,
RaisedSignal(Exception)>>signal}
{0x1692056C: cf 0x1692054D, sp 0x1692057C, bp 0x16920564, ip 11,
RaisedSignal(Exception)>>signal:with:}
{0x1692054C: cf 0x16920531, sp 0x1692055C, bp 0x16920548, ip 5,
RaisedSignal(Exception)>>signalWith:}
{0x16920530: cf 0x16920515, sp 0x16920540, bp 0x1692052C, ip 5,
Signal>>signalWith:}
{0x16920514: cf 0x169204FD, sp 0x16920524, bp 0x16920514, ip 6,
ReadStream(Stream)>>errorEndOfStream}
{0x169204FC: cf 0x169204DD, sp 0x1692050C, bp 0x169204F4, ip 12,
ReadStream>>positionAfterNext:}
{0x169204DC: cf 0x169204B5, sp 0x169204EC, bp 0x169204CC, ip 4,
ReadStream(PositionableStream)>>next:into:startingAt:}
{0x169204B4: cf 0x16920499, sp 0x169204C4, bp 0x169204B0, ip 10,
ReadStream(Stream)>>next:}
{0x16920498: cf 0x16920481, sp 0x169204A8, bp 0x16920498, ip 5,
ReadStream(PositionableStream)>>nextSDWORD}
{0x16920480: cf 0x16920449, sp 0x16920490, bp 0x16920470, ip 3,
STBInFiler>>basicNext}
{0x16920448: cf 0x16920435, sp 0x16920468, bp 0x0872DE10, ip 97,
STBInFiler>>readObjectOfClass:}
{0x16920434: cf 0x16920409, sp 0x16920444, bp 0x16920424, ip 66,
STBInFiler>>basicNext}
{0x16920408: cf 0x169203F1, sp 0x1692041C, bp 0x16920408, ip 7,
ResourceSTBByteArrayAccessor>>hiddenObjects}
{0x169203F0: cf 0x169203DD, sp 0x16920400, bp 0x168BF470, ip 3,
ResourceSTBByteArrayAccessor(ResourceAccessor)>>hiddenClassReferences}
{0x169203DC: cf 0x169203C5, sp 0x169203EC, bp 0x169203DC, ip 4,
ViewResource(Resource)>>hiddenClassReferences}
{0x169203C4: cf 0x169203A9, sp 0x169203D4, bp 0x0872DBA8, ip 29, [] in
Package>>tracePrerequisitesOfResources:}
{0x169203A8: cf 0x16920385, sp 0x169203C0, bp 0x1692039C, ip 27, Set>>do:}
{0x16920384: cf 0x1692036D, sp 0x16920394, bp 0x0872DBA8, ip 47,
Package>>tracePrerequisitesOfResources:}

Ken

You wrote in message news:91amab$3jhg0$[hidden email]...
> ....
> I imported a package that I had created with Dolphin 3.x, and Dolphin 4.1
> warned me there might be problems, but I went ahead anyhow, since I am not
> aware of another, more appropriate way to bring my old code into 4.1.
>...
> However, the Lagoon packager blows up telling me that the problem is 'End
of
> Stream'. I have a few custom views in my package; I wonder whether Dolphin
> is choking on them...

It is possible. Which views have you subclassed? (I ask because some of the
base system views had new instance variables added in 4.0, and thus have new
STB conversions that might not be correctly handling custom subclasses).

Are you able to load all the views into the view composer? What about if you
attempt to view the dependencies of the package? If these work then Lagoon
should be able to load them since it is using the same mechanism.

Regards

Blair

Ken,

> I imported a package that I had created with Dolphin 3.x, and Dolphin 4.1
> warned me there might be problems, but I went ahead anyhow, since I am not
> aware of another, more appropriate way to bring my old code into 4.1.
>
> Actually, the package loaded just fine, and the app runs just fine.
>
> However, the Lagoon packager blows up telling me that the problem is 'End
of
> Stream'. I have a few custom views in my package; I wonder whether Dolphin
> is choking on them...

It does sound like a problem that can occur with old views containing
references to classes that have changed their shape. One thing that you
could try is opening up and resaving each of your views in the ViewComposer.
It should either refuse to open any views that are not compatible with the
new image, at least you will then know the offenders, or silently update the
view for the new image.

One other possibility is the fact that the walkback occurs with the package
trying to trace prerequisites. This sounds a bit like the problem I saw the
other day with reference views and missing/renamed classes.

Just opening and resaving all of the views is worth a try anyway.

Ian

Ken,

In some cases, I've found it helpful to export views from 3.06 VC and import
them into 4.0.  I'm not sure where the cutoff is, but "old" resources don't
always load correctly into 4.0.  As Blair mentioned, views with this kind of
problem will cause a walkback in the VC in 4.0; when that happens, export
from 3.06 and import into 4.0.

Have a good one,

Bill

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

Hi Ken,

Ditto to what the others have said.

If you did make use of Reference Views, then I used this code fragment (in
ClassHierachyBrowser , and added a menu command from the classes presenter)
to search out references to them when moving from v3 to v4.

swInspectHidden
    (Presenter withAllSubclasses select: [ :each |
        (SmalltalkSystem current viewResourcesForClass: each)
            values anySatisfy: [:res | res hiddenClassReferences includes:
self selectedClass]]) inspect.

This helped me tidy up my presenters.  It is possible for a Presenter class
to have no references in an image, and yet still be needed since it is
buried in a ReferenceView. As Ian mentioned I normally first notice this in
the ViewComposer, but the walkback looks similar.

Things have changed in v4, but is it possible you did not bring over a
resource you needed?

Steve

Blair -

> It is possible. Which views have you subclassed? (I ask because some
of the
> base system views had new instance variables added in 4.0, and thus
have new
> STB conversions that might not be correctly handling custom
subclasses).

My custom view class is a direct child of View.

> Are you able to load all the views into the view composer?

Yes.

> What about if you
> attempt to view the dependencies of the package? If these work then
Lagoon
> should be able to load them since it is using the same mechanism.

When I try to view the prerequisites, I get walkbacks that declare an
"End of Stream" message, and then the image crashes. Dr. Watson detects
a protection violation, and down it all goes.

- Ken

Bill -

> In some cases, I've found it helpful to export views from 3.06 VC and
import
> them into 4.0.  I'm not sure where the cutoff is, but "old" resources
don't
> always load correctly into 4.0.  As Blair mentioned, views with this
kind of
> problem will cause a walkback in the VC in 4.0; when that happens,
export
> from 3.06 and import into 4.0.

 By this do you mean to file out and file in, one class at a time ?

(I can do that, but just want to make sure there isnt some other
mechanism I may have overlooked.)

Thanks,

Ken

Steve -

> swInspectHidden
>     (Presenter withAllSubclasses select: [ :each |
>         (SmalltalkSystem current viewResourcesForClass: each)
>             values anySatisfy: [:res | res hiddenClassReferences
includes:
> self selectedClass]]) inspect.

I tried this code in a workspace in 4.0, and I get 'End of Stream'
walkbacks, and an eventual image crash.

- Ken

Hi Ken,

"Ken Lee" <[hidden email]> wrote in message
news:91btdt$3jskh$[hidden email]...
I think Bill suggests to save the views and load them into version 4. Go
into the version 3 view composer, then File - Export view. This will create
a .vu file, which you can then import (File - Import view) in the view
composer in version 4.

Ted

Hello all,

> >  By this do you mean to file out and file in, one class at a time ?
> >
> > (I can do that, but just want to make sure there isnt some other
> > mechanism I may have overlooked.)
>
> I think Bill suggests to save the views and load them into version 4. Go
> into the version 3 view composer, then File - Export view. This will
create
> a .vu file, which you can then import (File - Import view) in the view
> composer in version 4.

Ted is correct: I'm suggesting exporting (from 3.06) and importing (into
4.0) only view resources as .vu files, and in fact, only those view
resources that cause problems.  You should not find it necessary to file
out/in any classes.

Have a good one,

Bill

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

Bill -

> Ted is correct: I'm suggesting exporting (from 3.06) and importing
(into
> 4.0) only view resources as .vu files, and in fact, only those view
> resources that cause problems.  You should not find it necessary to
file
> out/in any classes.

That did the trick.

I had a custom subclass of Presenter that went along with the subclass
of View. It was somehow the culprit.

I recreated it, then exported it, then imported it into 4.1.

Thanks to you and to all the others who helped.

You guys are the best !

- Ken Lee