Probably nothing

Hello all,

After installing the beta on a fairly overloaded Win95 machine, I used
Migrate to export from D4 and got it happy with D5.  I'm not completely sure
how far I got (maybe I saved an image I didn't intend to save), but, now the
new D5 image is complaining of image list problems.  This particular machine
will often do similar things (under D4) when it needs to be rebooted.
However, D4 loads just fine right now.

Anyway, since this general problem (complaints re image lists on startup) is
a recurring problem, I thought I'd mention it.  Also, I wanted to see if I
could copy the call stack :)  BTW, I can't get the debugger to open to
investigate :(

Obviously, I have only minutes invested in the D5 image, and the hard work
of deciding what to load is done, so there's nothing of value lost.

I have an NT box reasonably handy, and will try using it.  However, I fear
that there's still enough Pen Windows gadgetry left to cause problems.  My
D4 image loads on 2k machines, but, I can't deploy on them because the
resources eventually want to scan dependencies involving the pen libraries.
My hunch is that the packages will require 9x to load right now.

Have a good one,

Bill

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

6:33:59 AM, Friday, January 25, 2002: 'Index: nil is not an integer'
Array(Object)>>errorAt:put:
Array(ArrayedCollection)>>at:put:
[] in IconImageManager(ImageManager)>>buildImageListWithExtent:
LookupTable>>keysAndValuesDo:
IconImageManager(ImageManager)>>buildImageListWithExtent:
IconImageManager(ImageManager)>>imageListWithExtent:
ListView>>applyImageLists
ListView(IconicListAbstract)>>onFullyCreated
ListView>>onFullyCreated
ShellView(View)>>wmParentNotify:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ListView(View)>>basicCreateAt:extent:
ListView(View)>>createAt:extent:
MessageSend>>value
[] in MessageSequence(MessageSequenceAbstract)>>value
OrderedCollection>>do:
MessageSequence>>messagesDo:
MessageSequence(MessageSequenceAbstract)>>value
ListView(View)>>state:
ViewState>>restore
[] in ViewState>>restore
OrderedCollection>>do:
ViewState>>restore
[] in DevelopmentSessionManager(GUISessionManager)>>restoreWindowState
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in DevelopmentSessionManager(GUISessionManager)>>restoreWindowState
OrderedCollection>>do:
DevelopmentSessionManager(GUISessionManager)>>restoreWindowState
[] in DevelopmentSessionManager(GUISessionManager)>>basicTertiaryStartup
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
DevelopmentSessionManager(GUISessionManager)>>basicTertiaryStartup
DevelopmentSessionManager(SessionManager)>>tertiaryStartup
DevelopmentSessionManager(GUISessionManager)>>tertiaryStartup
DevelopmentSessionManager>>tertiaryStartup
[] in DevelopmentSessionManager(SessionManager)>>onStartup:
BlockClosure>>ensure:
[] in DevelopmentSessionManager(SessionManager)>>onStartup:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
DevelopmentSessionManager(SessionManager)>>onStartup:

Hi Blair,

This is starting to look "real".  I repeated the experiment on NT4 with the
same results.  Basically, I get far enough to have Migrate start to load
packages for me, hit a problem and try to exit w/o saving.  From then on,
the image is basically fried.

If you want to try it, load Migrate into D4 and get it to write a
migrate.txt file.  Then copy the packages to a fresh D5 install, load
Migrate into it, and ask it to read the file.  Fiddle until Migrate's
"Calculate" is happy, and then save the image.  I'm not sure how you'll
generate an error, but, you might be able to just cancel the install and get
the same effect.

I'll keep playing.

Have a good one,

Bill

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

Bill

You wrote in message news:[hidden email]...
> Hello all,
>
> After installing the beta on a fairly overloaded Win95 machine, ...

As you know, Dolphin 5 is not supported on Win95 :-) (but I note your
subsequent message in which you say you are getting this problem on NT).

> Migrate to export from D4 and got it happy with D5.  I'm not completely
sure
> how far I got (maybe I saved an image I didn't intend to save), but, now
the
> new D5 image is complaining of image list problems....

 From the stack trace you kindly attached, it would appear that the list of
images in the ImageManager has somehow become damaged, and the unique
integer identifier associated with a particular image is 'nil'. I suspect an
STB conversion error may be the problem, and will investigate.

In response to your subsequent post, I cannot see how it is possible that
the image could get permanently damaged unless it has been saved. Something
must be saving it after the damage has occurred.

>...[snip]...
> I have an NT box reasonably handy, and will try using it.  However, I fear
> that there's still enough Pen Windows gadgetry left to cause problems.  My
> D4 image loads on 2k machines, but, I can't deploy on them because the
> resources eventually want to scan dependencies involving the pen
libraries.
> My hunch is that the packages will require 9x to load right now.

A couple of points to note about deployment on Win9X (I think mentioned in
the release notes):
1) Updating of the version resource is not supported (though one can do this
by directly updating the resource of the relevant stub using a third party
tool before deploying).
2) Deployment of in-process Active-X DLLs is not supported.

Regards

Blair

Blair,

> From the stack trace you kindly attached, it would appear that the list of
> images in the ImageManager has somehow become damaged, and the unique
> integer identifier associated with a particular image is 'nil'. I suspect
an
> STB conversion error may be the problem, and will investigate.

I'm somehow inducing this with Migrate.  There's some scanning of the
packages (#prepareInstall or something???).  I was fire-alarmed out of my
office at a very inconvenient time, and pretty much need to start the hunt
from the top.  Anyway, feel free to get Migrate for D4, use it to make a
migrate.txt file, and then use the calculate feature in the new version.


> In response to your subsequent post, I cannot see how it is possible that
> the image could get permanently damaged unless it has been saved.
Something
> must be saving it after the damage has occurred.

Makes sense to me too.  Any chance that the 'no' option on the prompt is
busted?  I know I didn't botch it _every_ time I've tried it.  Of course,
having something that occurs on startup is tricky enough because the
previous session is involved too.


> A couple of points to note about deployment on Win9X (I think mentioned in
> the release notes):
> 1) Updating of the version resource is not supported (though one can do
this
> by directly updating the resource of the relevant stub using a third party
> tool before deploying).

Just for calibration, that doesn't bother me in the slightest.


> 2) Deployment of in-process Active-X DLLs is not supported.

That causes a slightly unpleasant tingling, but, I'll adapt :)

Have a good one,

Bill

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

Blair,

> > From the stack trace you kindly attached, it would appear that the list
of
> > images in the ImageManager has somehow become damaged, and the unique
> > integer identifier associated with a particular image is 'nil'. I
suspect
> an
> > STB conversion error may be the problem, and will investigate.

BACKUP FIRST.  You've been warned :)

Here's how to reproduce it: load Migrate, start the shell, switch to the
"Loading Packages" tab (no need to load a migrate.txt file) and save your
image with the shell open.  The image will no longer load correctly.  The
debugger is also affected, so it's hard to tell what's happening.

Have a good one,

Bill

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

Bill

You wrote in message news:[hidden email]...
>
> > > From the stack trace you kindly attached, it would appear that the
list
I tried this on Friday in my development image, and it did not reproduce.
BTW: I was using the Migrate.pac from SchwabGoodiesDolphin4.01a.zip that I
downloaded from http://needle.anest.ufl.edu/anest4/bills/Smalltalk.htm .
I'll try again in a freshly installed beta image and see what happens.

In the meantime, there is definitely a problem with the STB conversion from
old image managers. This would only be a problem if you had a custom image
manager installed into one of your resources. I'll post a patch for that
here in the near future to be installed before loading up Migrate.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
>
> Bill wrote in message news:[hidden email]...
> >
> > Here's how to reproduce it: load Migrate, start the shell, switch to the
> > "Loading Packages" tab (no need to load a migrate.txt file) and save
your
> > image with the shell open.  The image will no longer load correctly.
The
> > debugger is also affected, so it's hard to tell what's happening.
>
> I tried this on Friday in my development image, and it did not reproduce.
> BTW: I was using the Migrate.pac from SchwabGoodiesDolphin4.01a.zip that I
> downloaded from http://needle.anest.ufl.edu/anest4/bills/Smalltalk.htm .
> I'll try again in a freshly installed beta image and see what happens.
> ...

Bill

I have now reproduced it, and have determined the problem. A sequencing
issue is uncovering a problem in the refactored <ImageManager>s.

I started to try and explain the problem, but it is a complex sequencing
issue relating to the initialisation of iconic lists (specifically TabViews)
and the singleton IconImageManager instance. It is indeed a bug, and I have
attached a patch. This is only really a workaround (I have refactored the
ImageManager/WinImageList combintation quite a bit again since I realised I
could remove two instance variables), but it should solve your problem.

Thanks for finding this, I can imagine that it would have gone unnoticed for
quite some time.

Regards

Blair



begin 666 TabView noIcons.st
M(51A8E9I97<@;65T:&]D<T9O<B$-"@T*8F%S:6-!9&0Z(&%N3V)J96-T(&%T
M26YD97@Z(&%N26YT96=E<@T*"2)0<FEV871E("T@061D<R!A;D]B:F5C="!T
M;R!T:&4@5&%B0V]N=')O;"!A=" Q(&)A<V5D(&EN9&5X+"!A;DEN=&5G97(N
M#0H)1&]E<R!N;W0@861D('1O('1H92!R96-E:79E<B=S(&-O;G1E;G1S(&-O
M;&QE8W1I;VX@*&%S<W5M97,@=&AI<R!H87,@86QR96%D>2!B965N(&1O;F4I
M(@T*#0H)?"!T8TET96T@? T*"71C271E;2 Z/2!40TE414T@;F5W+@T*"2AS
M96QF(&=E=%1E>'1";&]C:R!V86QU93H@86Y/8FIE8W0I( T*"0EI9DYO=$YI
M;#H@6SIS=')I;F<@?"!T8TET96T@=&5X=#H@<W1R:6YG72X-"@ES96QF(&AA
M<TEC;VYS( T*"0EI9E1R=64Z( T*"0D)6RAS96QF(&=E=$EM86=E0FQO8VL@
M=F%L=64Z(&%N3V)J96-T*2 -"@D)"0EI9DYO=$YI;#H@6SII;6%G94EN9&5X
M('P@=&-)=&5M(&EM86=E.B!I;6%G94EN9&5X("T@,5U=+@T*"5YS96QF('1C
M;4EN<V5R=$ET96TZ('1C271E;2!A=$]F9G-E=#H@86Y);G1E9V5R("T@,2$@
M(0T*(51A8E9I97<@8V%T96=O<FEE<T9O<CH@(V)A<VEC061D.F%T26YD97@Z
6(6%D9&EN9R%P<FEV871E(2 A#0H-"@``
`
end

Hi Blair,

> I have now reproduced it, and have determined the problem. A sequencing
> issue is uncovering a problem in the refactored <ImageManager>s.

Sounds good.  I've been away from my office for a while (jury summons
yesterday followed by car repairs this morning), so I found a beta image
that currently won't load.  I figured it would be fun to use prestart.st to
fix it; but, D5 (and D4) don't seem to find prestart.st???  Keep in mind
that I don't use the My Documents folder to any great extent, and save my
image to a different directory tee.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> > I have now reproduced it, and have determined the problem. A sequencing
> > issue is uncovering a problem in the refactored <ImageManager>s.
>
> Sounds good.  I've been away from my office for a while (jury summons
> yesterday followed by car repairs this morning), so I found a beta image
> that currently won't load.  I figured it would be fun to use prestart.st
to
> fix it; but, D5 (and D4) don't seem to find prestart.st???  Keep in mind
> that I don't use the My Documents folder to any great extent, and save my
> image to a different directory tee.

prestart.st will be loaded, but from whatever the working directory is at
the time the image is starting, not necessarily the same as the image
directory.

Regards

Blair

Blair,

> prestart.st will be loaded, but from whatever the working directory is at
> the time the image is starting, not necessarily the same as the image
> directory.

Perhaps by design, I finally resorted to setting the working directory by
editing the shortcut.  Having done that, I was prompted to load the file,
and that must have worked because the image loaded correctly.
Congratulations and thanks for the patch!

Have a good one,

Bill

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