What's the best way to load packages automatically ?

When developing an application, you don't want to be
saving your image continually. When debuggin the application
you often make the image unsuitable for saving, because
of the processes started, data in class-variables etc.

But manually loading the latest versions  of all your packages
into the image, every time you start, seems a lot of hassle as
well. You might forget to load the latest version of a specific
package, then modify it, and when saving it lose the previous
changes completely.

What is the preferred way of the Dolphin, to make sure you
are working with the latest versions of your packages, without
risking accidentally saving a corrupt image over a good one ?

What's the easiest way to specify that a set of packages should
be loaded programmatically, automatically, after the image has
loaded ?

Or is there a better way of solving this problem in Dolphin ?
Perhaps in Dolphin 5?

Thanks
- Panu Viljamaa

"Panu Viljamaa" <panu@fcc.net_theresmuchspam> wrote in message
news:3CD112F3.93DD78B0@fcc.net_theresmuchspam...

> What's the easiest way to specify that a set of packages should
> be loaded programmatically, automatically, after the image has
> loaded ?

well, you could have one pro-forma package which has all packages needed for
application as prereuisites, so you would load just this package into the
fresh image.

or have an .st file like:

path := 'g:\burza\testzwei\feed\dolphin\'.

PackageManager current

install: path, 'xw1.pac';

install: path,'xdom1.pac';

install: path,'xmldolp.pac';

install: path,'ZORBLog.pac';

install: path,'ZORBSOCK.pac';

install: path,'zorbdolp.pac';

install: path,'OrderList.pac';

install: path,'Ifr2.pac'.



Davorin Rusevljan

Panu,

I don't think there is a "best" way as it depends a lot on the way you like
to work.  A few comments...

Dolphin 5 is cleverer in the way it locates prerequisite packages, making it
easier to install a number of interconnected packages with no subsequent
user interaction.

If you have a large number of packages and/or scratch code that needs to set
up the image then creating a single st script file that programmatically
loads packages makes thing a lot easier. For example, I have a single script
that I run to convert a distributed image into my "normal" working image,
which involves tweaking a number of image settings and loading about 15
packages.

As regards overwriting packages or losing changes when you forget to save a
package and don't save the image.  I don't think there is a foolproof way of
beating this that doesn't also cause an excessive amount of "annoyance", but
that may be just me and a dislike of too many prompts.  I know Chris Uppal
did some work on this, with warnings when a package wasn't saved or a
possibly incorrect overwrite (in or out of the image) was going to take
place, but I don't know the current state of his changes? FWIW I tend to
address it from the other point of view - make it easier to recover if you
do something silly.  I've got tools that make the change log more
accessible, in it's entirety using the ChunkBrowser or on individual methods
from a normal browser.  I also have a simple patch that automatically saves
a copy of a package file when it is about to get overwritten - a bit
profligate with disk space I know  but I have got 40Gb free so it's not
really a problem :-).

One other thing that is probably just me but worth a comment ...  I only
save an image when I am debugging code, to save a specific state when I am
about to do something that is likely to break. At all other times I work
from packages and never rely on the state of the image to save changes. I
know that others work differently, using the image as the primary repository
for changes and only save to packages, albeit quite often, as a backup. It
seems to me that you have to choose one way of the other, any sort of
halfway system where sometimes you save packages and sometimes use the image
save is asking for trouble.

Final point (honestly). There are a number of SCS available for Dolphin
which, I imagine, would also get around some of the problems you describe. I
don't personally use them so I can't really say much more that but it might
be an area you should investigate

--
Ian
reply-to address is valid and mail is read - until it starts getting spammed

Panu,

> What's the easiest way to specify that a set of packages should
> be loaded programmatically, automatically, after the image has
> loaded ?

I won't claim to have the easiest/best solution, but you might have a look
at Migrate, which is my evolving solution the problem.  At a minimum, you
should be able to use it as a basis to build something that works the way
you want.

There are currently two, and soon will be three versions of Migrate on my
web site.  I've recently split it up to simplify the UI for the current
image, and created a separate loader for the "next" image.  The D4-D5
version has some quirks that I'm fixing for D5; even as-is, it will give you
and idea of where I'm going with the image builder side, which sounds like
the part that interests you.

Have a good one,

Bill

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

Panu Viljamaa <panu@fcc.net_theresmuchspam> wrote in message
news:3CD112F3.93DD78B0@fcc.net_theresmuchspam...
...
> What is the preferred way of the Dolphin, to make sure you
> are working with the latest versions of your packages, without
> risking accidentally saving a corrupt image over a good one ?

In Options\System Folder you could turn on the backupOnImageSave setting.  I
am not sure how many levels of backup this maintains.  You could probably do
a little hacking to extend it if desired.

I currently use the image to save my code more than I use packages.  I have
only truly lost an image on a few occasions.  Most times I can recover an
image with some tricks if I can get a debugger open.  If I have an image
crash that had unsaved code (not a corrupt image) I have used Ian's totally
awesome ChunckBrowser to load the changes back in.  I also use David
Gorisek's Source Tracking System ( http://www.gorisek.com/ ) , so I can use
that to recover versioned packages or methods.  I really like being able to
see the history of changes to methods, and it is well integrated into the
Dolphin browsers.

> What's the easiest way to specify that a set of packages should
> be loaded programmatically, automatically, after the image has
> loaded ?

STS introduces the concept of a Project that can contain different packages.
When I have to use a new virgin image I load the STS package, then import my
Projects from my source repository.

I don't know if any of this is preferred or easy, but it works for me.
There is some room for improvement, but I really like having a separate
source repository I can just load back into a virgin image.

Chris

Thanks for the answers, everybody.

Now I know how to load packages via script ,
e.g., PackageManager current install: path, 'xw1.pac';
Great.

A second  ingredient I'd like to understand:  Which
method to modify, to change what happens just after
the image has loaded ?

I'm thinking of creating a script that loads  the packages
I need, and have this script be called automatically every
time the image has been loaded.

Thirdly,  is there a way to compare  the timestamp
of a package in the image to the time-stamp of the file
on disk. (This would allow the 'autoloader' to only
load those packages that are newer on disk).

Thanks again
Panu



"Christopher J. Demers" wrote:

Panu Viljamaa <panu@fcc.net_theresmuchspam> wrote in message
news:3CD32A2A.AB73A036@fcc.net_theresmuchspam...

> A second  ingredient I'd like to understand:  Which
> method to modify, to change what happens just after
> the image has loaded ?

I think it would be better to use an event than to modify a method.  You can
register interest in one of the events in SessionManager, perhaps
#sessionStarted.  You could do something like this:

SessionManager current when: #sessionStarted send: #loadNewerPackages to:
self.

Another thought that occurred to me was that there is a method
DevelopmentSessionManager<<preStart that looks like it loads a file named
preStart.st if it exists in the current directory.  This file could get the
ball rolling for a package import.  I am not sure if this is a good idea, as
OA might expect to use the preStart.st file for some special update in the
future.  The best bet is probably to use the events described above.

> Thirdly,  is there a way to compare  the timestamp
> of a package in the image to the time-stamp of the file
> on disk. (This would allow the 'autoloader' to only
> load those packages that are newer on disk).

I don't think Packages have a time-stamp.  I think the best you could do is
use the isChanged message on a package to find out if it has unsaved changes
in the image (red triangle will show if it has).  Perhaps you could extend
Package to include a time stamp, if you do it the same way isChanged is
done, using propertyAt: it probably would not interfere with anything.  You
could modify isChanged: to also set the time-stamp.

Chris

"Christopher J. Demers" wrote:

> ... Perhaps you could extend
> Package to include a time stamp, if you do it the same way isChanged is
> done, using propertyAt: it probably would not interfere with anything.  You
> could modify isChanged: to also set the time-stamp.

Thanks for the ideas, Chris .  It makes me think - when you save a Package,
are you really *persisting* an instance of Package, or are you simply
saving a set of Smalltalk code. In other words, do the properties of
the  package object get saved along with it - the associated source code
being just one of its properties ?

My guess is *not*, but I'd be happily surprised if yes.

-Panu

"Christopher J. Demers" wrote:

> ... Perhaps you could extend
> Package to include a time stamp, if you do it the same way isChanged is
> done, using propertyAt: it probably would not interfere with anything.  You
> could modify isChanged: to also set the time-stamp.

Thanks for the ideas, Chris .  It makes me think - when you save a Package,
are you really *persisting* an instance of Package, or are you simply
saving a set of Smalltalk code. In other words, do the properties of
the  package object get saved along with it - the associated source code
being just one of its properties ?

My guess is *not*, but I'd be happily surprised if yes.

-Panu

Panu Viljamaa <panu@fcc.net_theresmuchspam> wrote in message
news:3CD3FD8F.D1D1D0FE@fcc.net_theresmuchspam...

> Thanks for the ideas, Chris .  It makes me think - when you save a
Package,
> are you really *persisting* an instance of Package, or are you simply
> saving a set of Smalltalk code. In other words, do the properties of
> the  package object get saved along with it - the associated source code
> being just one of its properties ?

No, I don't believe packages will automatically store "propertyAt:"
properties, they will however store regular "package properties".  If you
look at a saved package file you can see that it is just Smalltalk code that
recreates the package.  I imagine you could extend some Package 'source
filing' category methods to save the last modified date as code that would
recreate the property, or just put it in a comment depending upon what you
want to do with it.  If it is done carefully I don't think it would break
package compatibility.

Dolphin version 4 also has some features designed to interface with
traditional file based source control systems.  That might be worth looking
at.  I don't use those since I use STS.  Bob Jarvis has a goodie for that
here http://www.nls.net/mp/jarvis/Bob/DolphinGoodies.htm , see RCS Source
Control Integration.

Chris

Ian, Panu,

> As regards overwriting packages or losing changes when you forget to save
a
> package and don't save the image.  I don't think there is a foolproof way
of
> beating this that doesn't also cause an excessive amount of "annoyance",
but
> that may be just me and a dislike of too many prompts.  I know Chris Uppal
> did some work on this, with warnings when a package wasn't saved or a
> possibly incorrect overwrite (in or out of the image) was going to take
> place, but I don't know the current state of his changes?

I have stuff for Dolphin 4 (and 3 and 2...) that tags packages as they are
loaded and/or saved with the timestamp of the corresponding external .pac
file.  It requires mods to the load/save logic for packages and -- as
such -- is *very* version dependent.  Layered on top of that I have some
extra code that checks that I'm not overwriting a newer version of a .pac
file with an older one and prompts me if the operation looks potentially
dangerous.

I *think* I have a version for D5, but I'm having problems with Digibuy and
can't actually purchase the upgrade (which I'm pissed off about *Big Time*,
but that's off topic here).

I've asked a couple of times (and posted code) for some such facility to be
added to the base product, but OA don't seem to be interested.  Presumably
because they don't use packages the way that I do  (for them, I think, the
package files are just an artefact of the communication between the source
code control system and Dolphin, and are not otherwise interesting).  For
me, and the way *I* work, the addition is absolutely essential.

If anyone wants a copy then please feel free to drop me a line.

    -- chris