Erroneous User Interrupts

Every time I try to open a Class Hierarchy Browser
in my D.5.1 on W2K  image I get a User Interrupt
-dialog to pop up.

  Looking at the debugger the stack looks something
like the following:

  ProcessorScheduler>>callback: cookie evaluate: aNiladicBlock
  InputState>>wndProc: hWnd message: message wParam: wParam ...
  TreeView>>defaultWindowProcessing: message wParam: wParam lParam:  ...
  ...
  TreePresenter>>expand
  ClassBrowserShell>>updateCategories
  ...


I didn't change those classes above, so I wonder what
is going on, and what  can I do to get rid of this strange
behavior. I already went to the backup image, but the same
thing occurs there as well.

It seems the image is 'screwed up' and I have no easy
way to recover my work. I can open the change-log, but
then I cant' really choose a large section of the log
and say 'file in' because there are so many intervening
expression  evaluations which now cause an error because
variables like 'self' now refer to something else.


Also, I wonder if there's an easy way to print the stack
out on the Transcript, from within the debugger, saying
something like 'Process current stack do:   ...' etc.
I could then give you guys a better picture of what is
going on with the 'User Interrupt' above.


Thanks Again
-Panu Viljamaa

panu wrote:

> Also, I wonder if there's an easy way to print the stack
> out on the Transcript, from within the debugger, saying
> something like 'Process current stack do:   ...' etc.


Ok, I found this one out too, pretty nifty.
I evaluate: (Process allInstances  at: 5) stackTrace: 55
and out comes the following, showing the state of
the process that gives me a 'User Interrupt' -dialog
every time I try to open a class-hierarchy browser.

If anybody has any ideas what to think of this,
that would be great.

Thanks
-Panu Viljamaa

'Debugger>>suspendProcess
Process>>debug:topFrame:resumable:
Process>>walkback:topFrame:resumable:
DevelopmentSessionManager>>unhandledException:
DevelopmentSessionManager(SessionManager)>>onUnhandledError:
Signal>>defaultAction:
RaisedSignal>>defaultAction
RaisedSignal(Exception)>>_propagateFrom:
RaisedSignal(Exception)>>_propagate
RaisedSignal(Exception)>>signal
Signal>>signal
DevelopmentSessionManager(SessionManager)>>onUserBreak
ProcessorScheduler>>userBreak:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
ListView(IconicListAbstract)>>nmGetDispInfo:
ListView>>nmNotify:
ReferenceView(View)>>wmNotify:wParam:lParam:
ReferenceView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ListView(ControlView)>>defaultWindowProcessing:wParam:lParam:
ListView(ControlView)>>wmPaint:wParam:lParam:
ListView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ShellView(View)>>defaultWindowProcessing: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:
ShellView(View)>>defaultWindowProcessing: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:
InputState>>pumpMessage:
InputState>>loopWhile:
InputState>>mainLoop
[] in InputState>>forkMain
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in BlockClosure>>newProcess'

panu wrote:

> It seems the image is 'screwed up' and I have no easy
> way to recover my work. I can open the change-log, but
> then I cant' really choose a large section of the log
> and say 'file in' because there are so many intervening
> expression  evaluations which now cause an error because
> variables like 'self' now refer to something else.

I haven't looked at the stack trace you posted (not yet anyway), but here's a
tip for all Dolphin users.

If you haven't got a copy of Ian Bartholomew's "Chunk Browser" already then you
/need/ to get it.  It's a tool for looking at the contents of a change log (or
any other file in chunk format, such as .PAC files), and allows you to compare
the definitions with what's in the current image, filter the definitions in
various ways, and to file them in selectively.   It, and Ian's profiler are
/necessary/ additions to any Dolphin programmer's toolkit.  See

    http://www.idb.me.uk/goodies.html

(Ian has other good stuff too, but the above two are, quite simply,
indispensible.)

    -- chris

Panu,

Chris is right, and you should be able to use the ChunkBrowser to
import your changes into a new image (remember to save the .chg file
before overwriting it with the fresh image). make sure you read the
ChunkBrowser documentation page and use the "Last Chunk" button to only
show the latest changes in the image. You may also want to filter out
ordinary evaluation chunks to only get the code changes.

However, once you have (hopefully) got your work back, PLEASE start to
arrange it into packages so you can export it from the image. I am a
big proponent of using the image wherever possible (as regular readers
will know) but it is not safe place to store your work long term. You
MUST export stuff as packages and, ideally, check these into a change
control system. An alternative would be to use David Gorisek's STS
(www.gorisek.com) to archive changes longterm.

I'm not saying that Dolphin is buggy and liable to trash your image at
any time (as far as I'm aware it isn't). However, is is relatively easy
to make subtle accidental changes to the system (e.g. via a workspace
or via changes to the system code) that may *later* show up as a
trashed image. This is why saving a backup of the image is not
sufficient protection since the hidden damage may already have been
done when the backup is created.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

panu wrote:

> Also, I wonder if there's an easy way to print the stack
> out on the Transcript, from within the debugger, saying
> something like 'Process current stack do:   ...' etc.
> I could then give you guys a better picture of what is
> going on with the 'User Interrupt' above.

There are two ways to get a stack trace (beyond the one you've already found).
One is to press the 'Copy' button in the walkback dialog which will copy the
stack trace text to the system clipboard.  The other is to open your
<image-name>.errors (in the same folder as your image) which is just a text log
of the stack traces from every error since you started your image (or last
deleted the file).

The rest of this is pure speculation...

Looking at the two stack traces you posted, they don't seem to be the same.  I
suspect (but may be wrong) that part of what's happening is that the spurious
interrupts are (somehow) being generated and that it is just chance what
Dolphin is doing at the time when it next 'notices' them.  So the stack
trace(s) itself may not be very helpful.

A few questions:

What happens if you just resume when the interrupt happens ?  Does it continue
to work OK afterwards, or do you get an endless stream of these interrupts, or
what ?

What happens if you open some other browser/tool window ?  Especially the
System Browser ?  If that works then maybe you could use that to put your
remaining code into packages before starting a fresh image.  I suspect that it
won't work, though...

I'd be tempted to try killing the 'Idler' process from the Process Monitor tool
(the system will start a new Idler), to see if that fixes it.  I doubt it if
would, but...

Also, if you evaluate:

    UserLibrary default getAsyncKeyState: VK_CANCEL

from a workspace, does it answer 0 ?  (VK_CANCEL is defined in the
'Win32Constants' PoolConstantsDictionary which you can add to the workspace's
scope using the Workspace=>Pools... menu command.  Or just use 3 instead ;-)

    -- chris

Andy, Panu,

> However, once you have (hopefully) got your work back, PLEASE start to
> arrange it into packages so you can export it from the image. I am a
> big proponent of using the image wherever possible (as regular readers
> will know) but it is not safe place to store your work long term. You
> MUST export stuff as packages and, ideally, check these into a change
> control system. An alternative would be to use David Gorisek's STS
> (www.gorisek.com) to archive changes longterm.

If you "insist" on keeping images alive for a long period of time, then
a few things will help to keep you out of trouble:

(1) Make backups (source, image, changes together), and so so regularly.
  "Regularly" might be twice a day or once per month, depending on how
aggressively you are making changes.

(2) Learn what is most commonly dangerous, and avoid saving a problem.
In my book, those things are new/changed external interfacing code, and
anything up through and including #onViewOpenened in presenter startup.
  I recommend getting ready to test, including workspace statements to
make it go, then backup, and then carefully sneak up on the problem.  If
it fails, use the debugger to learn something, then exit w/o saving,
reload, and try to fix it.  Repeat until it works.

(3) NEVER save an image that has thrown up the (feared) primitive 2 GC
error.  I haven't seen one of those in a long time, but it means that
you have stomped on something important, and the image will likely be
useless.

The backups are big, but you can perhaps scare up an old computer
(people are tossing >500MHz machines now) with an old CDR (people seem
to have no use for those slow 4x things anymore) and an $80 hard drive
(look for cheap but bigger than you think you might need).  Mix well,
and you have bit bucket that will serve you for a while.  I have
typically used Zip drives to move files to such a machine, but $30 will
now get you a USB drive that will hold more than one zipped backup.  The
goal is to make CDs with your backups, and then disperse them as needed
(home, office, safe deposit box) to protect your work.

That is not to say that you should not pay attention to packaging.
Ensuring that they can save, and fixing them if they cannot, is part of
good maintenance too.


> I'm not saying that Dolphin is buggy and liable to trash your image at
> any time (as far as I'm aware it isn't). However, is is relatively easy
> to make subtle accidental changes to the system (e.g. via a workspace
> or via changes to the system code) that may *later* show up as a
> trashed image. This is why saving a backup of the image is not
> sufficient protection since the hidden damage may already have been
> done when the backup is created.

Very true, but if that is case, then the backup from two weeks earlier
is perhaps ok.  In the few situations that I have had to do a rollback
like that, it's been fairly easy to decide whether the backup was sound,
because I had a particular task (whatever exposed the problem) in mind.

BTW, Dophin is _not_ buggy :)

Have a good one,

Bill


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

Just adding here that you will find more information about STS on our
wiki at:

http://wiki.gorisek.com

Packages make good practice because they force you to think about
prerequisites and how to group classes into higher abstractions and
components.

Also, if you are using #perform: with class factories a lot, then it is
almost essential that you have package prerequisites right to ensure
that your code is working right when deployed.

Best regards,

David Gorisek


Andy Bower wrote:
...
> However, once you have (hopefully) got your work back, PLEASE start to
> arrange it into packages so you can export it from the image. I am a
> big proponent of using the image wherever possible (as regular readers
> will know) but it is not safe place to store your work long term. You
> MUST export stuff as packages and, ideally, check these into a change
> control system. An alternative would be to use David Gorisek's STS
> (www.gorisek.com) to archive changes longterm.
>
...

>
> Best regards
>
> Andy Bower
> Dolphin Support
> www.object-arts.com

Chris Uppal wrote:


>
> What happens if you just resume when the interrupt happens ?  Does it continue
> to work OK afterwards, or do you get an endless stream of these interrupts, or
> what ?

It did continue ok.

However, the problem went completely away after I rebooted.
I find this curious. It was not enough to exit the image
without saving and come back. The problem disappeared
only after rebooting.

I did duplicate the problem several times before rebooting though,
and indeed it seems msot od the satck was different in different
times. Whatever the GUI-code was doing, at some point this interrupt
appeared, and was interpreted by Dolphin as a "User Interrupt".

Thanks for the help
-Panu Viljamaa

Andy Bower wrote:


> However, once you have (hopefully) got your work back, PLEASE start to
> arrange it into packages so you can export it from the image.

I do have /several/ packages. I'm used to working that way,
and maybe that's the problem. When I try to start again
from a backup- or virgin image, it's hard to know which
packages I need to load, and in which order. And any way
it is a lot of work to load each of those packages
individually.

  So, maybe the best practice in Dolphin would be
  "Keep all your work in single package" !?

Some may suggest "create and maintain a script" that
loads the latest versions of all packages in the correct
order.  I actually once did this in D4, but now I have
a different set of packages, saved in different places,
and the script assumed the existence of some packages
which no longer are loaded, etc.  And why should I need
to script, when I have a Smalltalk IDE!

My point is: Users shouldn't have to re-invent
the wheel of how to make Dolphin a productive
environment that guards against loss of work
in case of crashes. It should be part of the
environment we pay for. We should be programming
other applications than 'crash recovery support'
already.

I know there are some 3rd party tools for source-code
management available. My concern with these is that
if the base platform is not very stable, what's the
effect of adding more components to it. If there
are good solutions provided by 3rd parties, O-A should
recommend these officially, to let us know which ones
are safe to use.

So pardon this little impatience from my part.
Right now, even  the 'Panic Button' no longer works
(but hangs) in my  Dolphin 5.1 image!  To exit the image,
I need to use Windows task-manager. Rebooting brings
no help.

The reason I bring these points up is not to say that
Dolphin is a bad product, but in the hope that there
will be some serious considerations to add better
stability and better, more usable tools for crash
recovery in Dolphin 6.

Thanks
-Panu Viljamaa

P.S.
I discovered this useful trick which might help others:
I modified to method #logEvaluate:  to do nothing.
Now expressions evaluated in the debugger etc. don't
go into the change-log, which makes it possible to file
in the latest set of changes without being interrupted
by attempts to evaluate expressions that no longer
work in the context of the file-in.

Panu,

> I do have /several/ packages. I'm used to working that way,
> and maybe that's the problem. When I try to start again
> from a backup- or virgin image, it's hard to know which
> packages I need to load, and in which order. And any way
> it is a lot of work to load each of those packages
> individually.

It's a lot more work when one has 140 or so packages =:0  Actually,
Dolphin's package mamagement has improved a great deal over time.  Re
robustness, they are no longer (comparatively) easily corruptable binary
data; instead, they are text that can be minded for valuable code if the
file as a whole has had it.

Re load order, Dolphin attempts to find and load prerequisiste packages.
  If anything, I would like to have an option to disable that feature
for scripting; that way, I would know when the script indeed loads all
packages and in a correct order.  When working through the package
browser, transparently loading the prerequisites is quite helpful.



I don't think you do need to script, particularly with such a small
number of packages.

A quick search of the newsgroup (keyword bonkers - sorry Andy<g>) will
reveal the polarized nature of the users.  We have very different
approaches (with half lives of our images ranging from minutes to
months), so one tool isn't going to make us all completely happy.

I have Migrate, which you are of course welcome to try.  I wrote it when
such a tool was almost essential.  Now, I'm not so certain I would
bother to create it, but since I have it, I use it.  One of its main
goals is to write a load script for the next image using the current
image as a reference.  It also keeps track of things that I didn't want
to package or had to modify.  Finally, it tweaks some things that I find
very tedious to do manually.  The latter is important because I never
which time I build the image will be the point from which I take off on
the new version.


> I know there are some 3rd party tools for source-code
> management available. My concern with these is that
> if the base platform is not very stable, what's the
> effect of adding more components to it. If there
> are good solutions provided by 3rd parties, O-A should
> recommend these officially, to let us know which ones
> are safe to use.

Dolphin is very stable.  MySQL is too, but I still take snapshots of
databases.  A big portion of my work is based on Dolphin in one way or
another, and so I protect my source code.  Others do the same, and we
have divergent opinions no how to do it.  I am not aware of an unsafe
option (other than trusting only the saved image); if people have been
burned by something, they should bring it to the attention of this group.



I have gotten into similar spots, and have had to retreat a bit at
times.  An old saying (I seem to be overflowing with them today): "The
difference between a wise man and a fool is that the fool's mistakes
never teach him anything".  I am _not_ casting you in the role of the
fool.  However, a Smalltalk system cannot be what it is (live,
interactive, reflective, open to change) without putting the programmer
at risk of learning from mistakes.

Good luck with recovering your work!

Bill


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

FWIW, a few miscellaneous comments.

>... it's hard to know which
> packages I need to load, and in which order.

It seems that Dolphin will take care of the "which order" part, i.e., it
will automatically load in pre-requisite packages (or prompt for their
location if it can't find them).

The best tip I've recently found for keeping my image stable is to make sure
there are no "hidden" windows before I save the image.  This is easily done
by choosing the Windows menu (in any Dolphin window) and clicking on any
entry that indicates it is hidden.  (The System Transcript is an exception
and is ok.)  Maybe I've been lucky or maybe I haven't been doing much fancy
programming lately, but I've been working with the same image for at least
several months.

I'm also a user - and fan - of STS.  Before I save a package I always
compare what's in the image to the most recently saved version.  This is
easily done with STS, as is looking at previous versions of a particular
method (and restoring them).  On more than one occasion I've made a zillion
changes to a package, not written unit tests (shame on me) and found the app
doesn't work right a few versions down the road.  Using STS has made it
easier to rollback the changes or compare versions and remake the changes
incrementally, isolating where the problem is.  In other words, I'm more
confident that if I break something I can find the problem and fix it.

Now, having praised STS, David, if you're reading this, I'll reask a
question from some time ago.  Is there a way to compress the STS disk files?
They do get verrry large and discourage me from backing them up as
frequently as I'd like to.  By compressing, I mean truly getting rid of
everything that isn't needed - e.g., right now if I purge a package (or even
a method), it seems to delete it from STS, but the disk files don't get any
smaller.

-- Louis

Louis Sumberg wrote:
> Now, having praised STS, David, if you're reading this, I'll reask a
> question from some time ago.  Is there a way to compress the STS disk files?
> They do get verrry large and discourage me from backing them up as
> frequently as I'd like to.  By compressing, I mean truly getting rid of
> everything that isn't needed - e.g., right now if I purge a package (or even
> a method), it seems to delete it from STS, but the disk files don't get any
> smaller.

I'm always forcing a garbage collect/reorganize on my STS repositries.
Something like:

OmniBase allInstances do: [ :each | each garbageCollect]

or even

OmniBase allInstances do: [ :each | each reorganize]


And always remember to backup first (using file copy or #createBackupOn:
  - see
http://wiki.gorisek.com/WikiDoc/WikiPage?page=OmniBase+Administration&lang=English).

However - I'm not sure whether this approach works with the
non-registered (e.g. STS-"only") OmniBase version.

CU,

Udo

Louis,

regarding STS repository size there were two problems which people
reported in the past.

1. Repository database is too big for doing backup.
2. Versioning of code becomes slow when repository is really big.

The solution to those problems is the following:


Regarding 1: Instead of backing up the whole repository I would
recommend that you only export new versions of your project(s) and
backup these. You can use repository export functionality and export a
project version as a compressed XML file (.PEZ) which contains all
versions of package in a single file. This can be done with a single
mouse click.

If you later lose your repository you can recover your code by
installing STS again, then create new repository and import the .PEZ
file which you have in your backup.

Regarding 2: The current version of STS keeps track of loaded versions
of classes in the image and does not do code comparison upon versioning
anymore. This results in significant speed improvements so that
repository growth is not a problem anymore.

Also, with today's hard disks it does not really matter if the
repository is 100 or 300 MB.

However there are still possibilities for shrinking repository. Let me
list some:

1. Run OmniBase garbage collection, this will remove all unreferenced
objects from the database plus remove old versions of objects. Because
STS is mainly adding objects and not changing or removing existing
objects this wont do much.

2. Use STS "purge" functionality to remove unused package editions. This
  will remove the package edition from the repository, but it wont
remove class and method editions because these are still referenced from
the main list of class and method editions. However, this spring we've
added an additional check to the purge function so that it will search
for all references to contained class editions and if there are none it
will remove references to class editions too. So after doing GC these
objects are removed from files. NOTE: this and 1. will only work with
full functionality version of OmniBase.

3. Rebuild the repository by creating a new repository and import the
most current versions of project from the old repository.

Best regards,

David Gorisek



Louis Sumberg wrote:

Hi Udo,

Thanks for the response.  Unfortunately, I get a DNU for both
#garbageCollect and #reorganize.  Obviously these are in the Omnibase
database product, not in the STS-only product.

-- Louis

Hi David,

Thanks for your response.  Unfortunately, it looks like what I want is only
available if I buy the full Omnibase product, which I can't justify for
myself for this one piece of functionality.  I'm surprised and a bit
disappointed though, that the 'purge' function in STS does not truly (truly
to me, at least) purge the buggers.

I agree that 100MB or 300MB is not a huge file, but my repository quickly
goes over 500MB, especially if I initially version all OA classes, which is
the STS default, and version all goodies.  When I start getting a 600MB or
bigger file, it does make backups a little slower, so I don't backup the
whole repository as often as I'd like to.

Regarding your suggestion to use .pez files, I don't often use STS
Projects - in fact, I think I've only used these when Steve Waring and I
were working on the Windows Shell packages.  More important though is that I
like the repository approach - though it's not a single file, it appears to
be one, and I don't need to be micro-managing source files.  Everything just
goes into the repository, can't get much easier than that.

What I've tended to do is that when the repository gets pretty huge, I
rebuild it, essentially following your last suggestion, importing only the
latest versions of my own packages, and in general not versioning all the OA
classes and goodies.  However, this has the drawback that when I make a
change to someone else's method, I can't really use STS' compare or easily
rollback the change.  It also means I've lost the history of my own classes,
which has bit me on more than one occasion.

One more drawback to purge not truly purging is that if I version someone
else's package, it puts my name on all the methods etc.  When I make changes
to that package, it's not necessarily obvious which version of a method is
mine or theirs.  If I try to purge the initial version and import it,
importing allowing me to specify the package author's name, STS recognizes
that the methods et al are still somewhere in the repository and unpurges
the ones I'd wanted to purge, so I'm back to where I started.

Obviously I've learned to live with this all and I recommend STS, but still,
I think purge is a little weak in what it does.

-- Louis

panu wrote:

> Some may suggest "create and maintain a script" that
> loads the latest versions of all packages in the correct
> order.  I actually once did this in D4, but now I have
> a different set of packages, saved in different places,
> and the script assumed the existence of some packages
> which no longer are loaded, etc.

So write a script that /generates/ a script.  That's what I do (though it's
actually part of one of my own tools, not a separate script).  It looks to see
what packages are loaded, arranges them in pre-requisites order, and then
writes code to install those packages files in that order.  Simple enough.  I
also have scripts (or rather, tools) that generate scripts that will check for
clashes without loading the packages.  Etc...

Or, if that's too much work, just define an empty package 'Working Set' that
includes all your working packages as (manual) pre-requisites.  Load that, and
the system will load everything else for you.


> And why should I need
> to script, when I have a Smalltalk IDE!

And why should you complain of missing "features", when you are a programmer
using one of the most highly-programmable environments in existence !


> My point is: Users shouldn't have to re-invent
> the wheel of how to make Dolphin a productive
> environment that guards against loss of work
> in case of crashes. It should be part of the
> environment we pay for. We should be programming
> other applications than 'crash recovery support'
> already.

I think it'd be a good idea to have an option on the package browser --
generate a script to load the current / the selected set of packages (in the
correct order).  Very easy for you to add the option yourself, but I think it'd
be generally useful enough for OA to consider adding it to the base system (if
anyone from OA's still reading this ;-).


> I know there are some 3rd party tools for source-code
> management available. My concern with these is that
> if the base platform is not very stable, what's the
> effect of adding more components to it.

Eh?  "not very stable" ??  It seems stable enough to /me/.


> P.S.
> I discovered this useful trick which might help others:
> I modified to method #logEvaluate:  to do nothing.
> Now expressions evaluated in the debugger etc. don't
> go into the change-log, which makes it possible to file
> in the latest set of changes without being interrupted
> by attempts to evaluate expressions that no longer
> work in the context of the file-in.

Have you /looked/ at the Chunk Browser yet ?

    -- chris

panu wrote:

> It did continue ok.
>
> However, the problem went completely away after I rebooted.
> I find this curious.

To me this sounds like a Windows/keyboard driver problem rather than a Dolphin
thing.  If Windows is convinced that the relevant key is being pressed, then
there's nothing that Dolphin can do except believe it...

(Incidentally, from experience, it is /really/ difficult for an OS/keyboard
driver to ensure that it never looses a key-up event.  You end up putting all
sorts of hacks into the software to say "well, if we've seen <such-and-such>
but we still think <some key> is down, then there must have been a key-up that
we've missed.  Even so, you can't make it completely reliable, and even modern
XP is still capable of missing a key-up.  Just a few months ago it happened to
this machine, and Window's was convinced that I was holding the <control> key
down, even though I wasn't.  It's usually sufficient to press and release the
"stuck" key again, if you can work out which it is, to bring the OS back to its
senses)

    -- chris

Chris et al,

> I think it'd be a good idea to have an option on the package browser
> -- generate a script to load the current / the selected set of
> packages (in the correct order).  Very easy for you to add the option
> yourself, but I think it'd be generally useful enough for OA to
> consider adding it to the base system (if anyone from OA's still
> reading this ;-).

Still reading...

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Chris,

> So write a script that /generates/ a script.  That's what I do (though it's
> actually part of one of my own tools, not a separate script).  

Is this something that you have or are willing to make available?


 > It looks to see
> what packages are loaded, arranges them in pre-requisites order, and then
> writes code to install those packages files in that order.  

Migrate at least attempts to do that.  I suspect that it does not work
quite correctly.  Dolphin covers for it, so I suppose the net result is
that it works :)


 > Simple enough.

Really =:0


 > I
> also have scripts (or rather, tools) that generate scripts that will check for
> clashes without loading the packages.  Etc...

That is interesting too.  I was content to do that in the "next" image,
which is arguably where it counts - OA might have changed something that
causes or fixes a name collision in D(n+1) which did not exist in Dn.

My approach is to "just try it" and let a walkback appear if there is a
problem.  I usually fix problems in the "old" image and then make
another attempt in the new image; when the latter builds cleanly,I'm
done.  On thing that I don't like is that the final state of any
version's image is usually a compromise to the get the next one to
build.  Of course, I make backups before butchering anything.

Have a good one,

Bill


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

Andy,

>>I think it'd be a good idea to have an option on the package browser
>>-- generate a script to load the current / the selected set of
>>packages (in the correct order).  Very easy for you to add the option
>>yourself, but I think it'd be generally useful enough for OA to
>>consider adding it to the base system (if anyone from OA's still
>>reading this ;-).

I would like second Chris' request, and add that there should be a way
to get it to print the script on a stream, or perphaps return a
collection of package instances.  In particular, it should not force one
to open a workspace or a particular tool to get the list of packages.
Any such tool (I look forward to seeing what you will create) would
hopefully share the forementioned entry point.

Migrate includes some testing on the package tree, complete with unit
tests - please borrow/steal as you see fit (I did<g>).  On a more
serious note, the tests are not based on any other work; they are "mine"
and you are welcome to them.  The package ordering in Migrate is a
modified version (aka stolen from) something stolen from VW, or
something like that.  There might be a layer that I am forgetting, but
the point is that I found some code and made it work.


> Still reading...

Most vendors would not be.

Have a good one,

Bill

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