Aaaaaaarrrggg!!! Broken Image?

Hi,

Yesterday I made a few 'experiments' that caused infinite recursions.
This morning my image decided it had enough and refuses to work. It
loads fine, but whenever I try to accept a mehtod it has a seizure:

-------------------------------------------------------------------
Index 33373 is out of bounds

Process(Object)>>errorSubscriptBounds:
Process(Object)>>errorAt:
Process>>at:
StackFrame>>method
[] in Debugger>>markMethodAsUnbound:
OrderedCollection>>from:to:keysAndValuesDo:
OrderedCollection(SequenceableCollection)>>from:keysAndValuesDo:
OrderedCollection(SequenceableCollection)>>keysAndValuesDo:
ListModel>>keysAndValuesDo:
Debugger>>markMethodAsUnbound:
Debugger>>onMethodUpdated:
EventMessageSend>>forwardTo:withArguments:
EventMessageSend(MessageSendAbstract)>>valueWithArguments:
[] in
EventMessageSequence(MessageSequenceAbstract)>>valueWithArguments:
EventMessageSequence>>messagesDo:
EventMessageSequence(MessageSequenceAbstract)>>valueWithArguments:
EventsCollection>>triggerEvent:with:
RefactoringSmalltalkSystem(Object)>>trigger:with:
RefactoringSmalltalkSystem(SmalltalkSystem)>>onMethodUpdated:
EventMessageSend>>forwardTo:withArguments:
EventMessageSend(MessageSendAbstract)>>valueWithArguments:
[] in
EventMessageSequence(MessageSequenceAbstract)>>valueWithArguments:
EventMessageSequence>>messagesDo:
EventMessageSequence(MessageSequenceAbstract)>>valueWithArguments:
EventsCollection>>triggerEvent:with:
SystemDictionary(Object)>>trigger:with:
CompilationResult>>fireSystemUpdateEvent
Object class(ClassDescription)>>compile:categories:package:
[] in MethodBrowser>>saveMethod:in:categories:package:
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
MethodBrowser>>saveMethod:in:categories:package:
MethodBrowser>>saveMethod:fromOriginal:
ClassBrowserShell(ClassBrowserAbstract)>>saveNewMethod:
ClassBrowserShell(ClassBrowserAbstract)>>saveNewMethod
ClassBrowserShell(ClassBrowserAbstract)>>accept
Symbol>>forwardTo:
CommandDescription>>performAgainst:
[] in Command>>value
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Command>>value
ShellView>>performCommand:
ClassBrowserShell(Shell)>>performCommand:
CommandQuery>>perform
DelegatingCommandPolicy(CommandPolicy)>>route:
-------------------------------------------------------------

Anybody knows what might be wrong and how I can fix it?  Is thsi sort
of image-fit a common danger and if yes, how can you make sure your
code survives it?

Thanks

"Fernando" <[hidden email]> wrote in message
news:[hidden email]... This is almost certainly recoverable. Here are a few things to try (and in
this order):

1) Try a "panic" (the scream button on the system folder toolbar)
2) Debugger allInstances do: [:each | each view destroy]
3) Debugger allInstances do: [:each | Smalltalk developmentSystem
removeEventsTriggeredFor: each]
4) Open the Process Monitor, if any processes are listed as being in state
'debug', terminate them using the command on the context menu.

>
> Anybody knows what might be wrong and how I can fix it?  Is thsi sort
> of image-fit a common danger and if yes, how can you make sure your
> code survives it?

Its not that common, depending on what you are doing. In Smalltalk you are
not protected from damaging the system, so it is possible to mess up the
image. As you gain more experience, you will be less likely to damage the
image by mistake. Even if you do damage your image, the change log records
most of what you have done so you will be able to restore it at the cost of
some time. Ian Bartholomew's Chunk Browser tool is excellent for this
purpose. To avoid having to fire up the Chunk Browser, you should:

1) Ensure that all your work is packaged. Regularly save your packages. I
can't stress enough how important this is.
2) Regularly backup your image. I have a little batch file to do this that
copies the .img, .chg, and .sml files into a directory. I believe there are
also goodies available that do this automatically. You should be careful,
however, to maintain a reasonable history of backups to avoid overwriting a
good backup with a damaged image.
3) It is a good discipline to regularly "rebuild" your image. This involves
making a backup of your current working image. then start from a freshly
installed and patched image, and load your packages. This is essential to
ensure that your packages contain all your work, and pass your tests on
reload.

Lastly it is worth remembering that almost all apparently damaged images are
recoverable. Sometimes it requires a good deal of knowledge to achieve, and
it frequently makes more sense to start with ones latest backup and reapply
changes from the change log using the chunk browser. The decision as to
whether to recover, or rebuild from a backup, depends on the relative effort
involved. Each case will be different. If you do want to attempt recovery
then it is useful to know that if you put a file called 'postfix.st' into
the image directory, that the system will attempt to file this in (as a
chunked Smalltalk script) at a very early stage in the startup. This can be
useful for repairing damage that prevents the image from even starting up. A
very useful expression to insert in it in that circumstance is:

    View allSubinstances do: [:each | each destroy]

This performs a "stronger" version of the panic command, and indeed is
sometimes useful in a running image when that command fails to get rid of a
lurking hidden view.

Regards

Blair

>This is almost certainly recoverable. Here are a few things to try
(and in
>this order):

>1) Try a "panic" (the scream button on the system folder toolbar)
>2) Debugger allInstances do: [:each | each view destroy]
>3) Debugger allInstances do: [:each | Smalltalk developmentSystem
>removeEventsTriggeredFor: each]
>4) Open the Process Monitor, if any processes are listed as being in
state
>'debug', terminate them using the command on the context menu.


Unfortunately, I already created a new image with the 'fresh install'
option.
It was some misbehaving debugger view?

>image by mistake. Even if you do damage your image, the change log
records
>most of what you have done so you will be able to restore it at the
cost of
>some time. Ian Bartholomew's Chunk Browser tool is excellent for this
>purpose. To avoid having to fire up the Chunk Browser, you should:

>1) Ensure that all your work is packaged. Regularly save your
packages. I
>can't stress enough how important this is.

I just found that out. ;-)   When you modify a class that is a given
package
and save the image, is the package updated with the new version of the
class?

If not, is there a way to automate saving all user-defined packages?
Right now, I
only have 3 packages, so it's easy to remember saving them every now
and then,
but as soon as the number of packages increases...

Fernando,

> Unfortunately, I already created a new image with the 'fresh install'
> option.
> It was some misbehaving debugger view?

I use zip files to save source/image/changes at "regular intervals" -
the gap in time between them varies with the amount of time I spend
programming.  That can mean weeks or hours.

I will even save images I fear lost, clearly marked as such.  If nothing
else, the change log should be valuable.


> If not, is there a way to automate saving all user-defined packages?
> Right now, I
> only have 3 packages, so it's easy to remember saving them every now
> and then,
> but as soon as the number of packages increases...

Migrate can do just that.  It is also worth mentioning that the package
browser can sort on modified packages.  I have a love/hate relationship
with Dolphin's package loading.  It does a very good job of finding and
loading what it needs; it's almost too good, because it can mask flaws
in a load script.  OTOH, since Dolphin does such a nice job of loading
packages, are the flawed scripts really flawed??  It would be nice to
have the option to suppress automagic loading of prerequisites, if only
to ensure that one knows exactly what is loaded and in what order, but I
think it makes sense only for programmatic uses.  The PB GUI "just
works" whenever possible, and it should stay that way.

Have a good one,

Bill


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

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

I think you meant to say 'prestart.st' rather than 'postfix.st', unless
there is another early load file I have not discovered yet.

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:[hidden email]...
Thanks Chris, you're right, I did mean "prestart.st". I'm confusing it with
one of the files we use in booting the image initially.

Regards

Blair

"Fernando" <[hidden email]> wrote in message
news:[hidden email]...
Not misbehaving as such, but just hanging around when it should have gone
away. Debuggers observe method changes so that they can mark methods that
they might be running as "unbound" - this is make it obvious when code seen
in the debugger stack is out of date. The debugger's response to the change
event will fail in a partially closed debugger or one attached to a process
that has terminated or resumed execution.

>...When you modify a class that is a given
> package
> and save the image, is the package updated with the new version of the
> class?

No, not by default. Not everyone will necessarily agree with this, but we
view the image as a temporary workspace in which one makes changes. As one
progresses, one can save the image to preserve those changes and come back
to work on them again later - this is analagous to hibernating one'scomputer
with programs open in which one have made changes that have not been saved
down to files. At some point one may decide that one is happy with the work
to date and "commit" it by saving out the packages.

Remember the changes are preserved in the change log in any case - its like
an audit trail of what has been done, so one can almost always recover any
changes from there at any time. Before attempting any recovery first copy
off the apparently damaged image and supporting files (change log and
sources) just in case it is necessary to go back to them later.

>
> If not, is there a way to automate saving all user-defined packages?
> Right now, I
> only have 3 packages, so it's easy to remember saving them every now
> and then,
> but as soon as the number of packages increases...
>

As I say, we regard the saved package form as the more permanent
representation and consequently do not want the packages to be updated every
time we save the image. However there are some people with a different
viewpoint, and you may find they have written "goodies" that support such a
mode of working. It's not terribly difficult to do.

Regards

Blair

Blair,

> As I say, we regard the saved package form as the more permanent
> representation and consequently do not want the packages to be updated every
> time we save the image. However there are some people with a different
> viewpoint, and you may find they have written "goodies" that support such a
> mode of working. It's not terribly difficult to do.

You raise an important point - just because Migrate has a handy way to
save all unsaved packages, one should _not_ conclude that I consider
this something that should happen automatically.

Looking at the times I've been clobbered, it has almost always been
because I saved something bad, and very seldom because I failed to save
something good.

Have a good one,

Bill

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

Bill, et al,
"Bill Schwab" <[hidden email]> wrote in message
news:cv398m$rbe$[hidden email]...
Ian B's goodies include an IDE Extension that makes versioned back-ups of
packages when you save them.  I think that might substantially mitigate the
problem of routinely saving all packages.  While I personally use (and
heartily recommend!) David Gorisek's STS for most packages, Ian's back-up
versioning has proven really handy for those few packages that I just save
as PAC files.

HTH,

Don