OA, New VM soon?

I hate to harass OA, but I was wondering if a new Dolphin VM was still
coming soon?  I recall Blair mentioned that it might be within two weeks of
3/5 if all went well.  I have not seen any further announcement.  I am just
wondering if this is still on the slate as I have some 3rd party packages
that will require me to start from a fresh image, and I was hoping to kill
two birds with one stone.

FYI: I am not talking about Dolphin 6, just a D5 update, unless of course OA
wants to surprise us. ;)

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:b62qk4$1a518$[hidden email]...

> I am just
> wondering if this is still on the slate as I have some 3rd party packages
> that will require me to start from a fresh image, and I was hoping to kill
> two birds with one stone.

Is starting from a fresh image a problem? I seem to need to do it once or
twice a week. Do you have some kind of setup package?

(BTW, I use and enjoy your lookup tool.)

Mark Wilden wrote:

>Is starting from a fresh image a problem? I seem to need to do it once or
>twice a week. Do you have some kind of setup package?
>
Great idea. We know that Dolphin (image) keeps track
of package dependencies. The problem is that if I start
with a fresh image, I need to re-install all my packages,
one-by-one, in the correct order. This is hard to do when
there are several packages and lots of dependencies.

But since Dolphin knows the dependencies already,
it should be easy for the package system to write
out a script that - when executed - loads all packages
back, in the correct order. Right!?

The script-file should be named based on the image-name,
since it would need to be specific to each image.

What you think?
-Panu Viljamaa

"panu" <panu@fcc.net_zerospam> wrote in message
news:[hidden email]...
> >
> Great idea. We know that Dolphin (image) keeps track
> of package dependencies. The problem is that if I start
> with a fresh image, I need to re-install all my packages,
> one-by-one, in the correct order. This is hard to do when
> there are several packages and lots of dependencies.

My system (currently) is a lot simpler, so the order I load packages (which
are all just programming tools) doesn't matter.

So I am way the wrong guy to talk about this. :) I know that Bill Schwab has
a tool called Migrate that sounds like it might do what you're thinking.

panu wrote:

> Great idea. We know that Dolphin (image) keeps track
> of package dependencies. The problem is that if I start
> with a fresh image, I need to re-install all my packages,
> one-by-one, in the correct order. This is hard to do when
> there are several packages and lots of dependencies.

I don't understand this.  If you try to load a package that has
prerequisites that are not already installed in the image then these
prerequisites are automatically loaded for you.  The order in which you
choose to install packages is usually immaterial.

> But since Dolphin knows the dependencies already,
> it should be easy for the package system to write
> out a script that - when executed - loads all packages
> back, in the correct order. Right!?

The simplest solution is to maintain a folder tree that only contains
packages that you wish to be installed into your clean image.  You can
then just evaluate something like.

File for: '*.pac' inAndBelow: ''yourFolderBase' do: [:folder :file |
| package |
package := PackageManager current loadPackage: file path.
(PackageManager current includesPackageNamed: package name)
ifFalse: [PackageManager current install: file path]]

If you don't want to maintain a separate folder tree then you will have
to replace the loop with one that iterates over an explicit list of path
names.

I suppose it might also be possible to export a list of required
packages from a current image so that it could be used as the basis for
the file list in the above script.  The problem would be removing
packages that you don't want to reinstall - all the OA ones for example.

--
Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:Nddha.2688$[hidden email]...
>
> If you don't want to maintain a separate folder tree then you will have
> to replace the loop with one that iterates over an explicit list of path
> names.

For instance, here's one of my package setup methods:

installIanBartholomew

#(#('Shared' #('IDB Common' 'IDB CurrencyToText' 'IDB Duration' 'IDB
DateAndTime' 'IDB DeviceIndependentBitmap' 'IDB FileSystem' 'IDB
MultipleFileOpenDialog' 'IDB RadioButtonGroup' 'IDB SelectorParser' 'IDB
Spinner'))

#('IDE Extensions' #('IDB IDE Extension' 'IDB IDE Method History' 'IDB IDE
Undefined Check' 'IDB IDE View Composer'))

#('Chunk Browser' #('IDB Chunk Browser'))

#('File Browser' #('IDB File Browser'))

#('Profiler' #('IDB Profiler'))

#('OS XP SP1' #('IDB RichEdit' 'IDB Printer' 'IDB Reports' 'IDB IDE Printer'
'IDB IDE Reports')))

do: [:each | self installGroup: each second from: 'Ian Bartholomew\' , each
first]

Chris,

> I hate to harass OA, but I was wondering if a new Dolphin VM was still
> coming soon?  I recall Blair mentioned that it might be within two weeks
of
> 3/5 if all went well.  I have not seen any further announcement.  I am
just
> wondering if this is still on the slate as I have some 3rd party packages
> that will require me to start from a fresh image, and I was hoping to kill
> two birds with one stone.

We have Dolphin 5.1 just about ready for release and this includes the new
VM.
I sincerely hope that it can be in the public domain by the end of next
week.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Surely you meant "in the public's hands", not "in the public domain" ;>

jlo

"Andy Bower" <[hidden email]> wrote in message
news:3e85a294$[hidden email]...
> Chris,
>
> > I hate to harass OA, but I was wondering if a new Dolphin VM was still
> > coming soon?  I recall Blair mentioned that it might be within two weeks
> of
> > 3/5 if all went well.  I have not seen any further announcement.  I am
> just
> > wondering if this is still on the slate as I have some 3rd party
packages
> > that will require me to start from a fresh image, and I was hoping to
kill

Andy Bower wrote:
Nice to hear this.
Will msmask32.ocx supplied with the new release?
I get the following message in the System Transcript:
"Resource library msmask32.ocx could not be opened ('msmask32.ocx' (16r2:
Das System kann die angegebene Datei nicht finden.))"

Andreas

Andreas,

> Will msmask32.ocx supplied with the new release?

Unless things have changed recently msmask32 is a licensed dll and is
only distributable by Microsoft bundled with a MS tool.  The Dolphin
wrapper to the dll can only be used if you have one of those MS tools
installed.

Have a look at the MaskedEdit class comment for a little more detail

--
Ian

"panu" <panu@fcc.net_zerospam> wrote in message
news:[hidden email]...
The Dolphin package system has always loaded pre-requisite packages
automatically, therefore you can load the packages in any order. With older
versions the prerequisite information stored in the packages didn't include
pathing, so sometimes one got prompted to locate the pre-requisite packages,
but even that wasn't really "hard".

Blair

"Mark Wilden" <[hidden email]> wrote in message
news:[hidden email]...
> "Christopher J. Demers" <[hidden email]> wrote in
> message news:b62qk4$1a518$[hidden email]...
>
> > I am just
> > wondering if this is still on the slate as I have some 3rd party
packages
> > that will require me to start from a fresh image, and I was hoping to
kill
> > two birds with one stone.
>
> Is starting from a fresh image a problem? I seem to need to do it once or
> twice a week. Do you have some kind of setup package?

Starting from a new image is not really a problem, but in my case it is
slightly more involved than it is perhaps for most.  I have some packages
with cyclic prerequisites.  The package manager does not like those.  I use
STS (Source Tracking System) to get around the limitations of the packager.
However using STS means I have to version all of my packages and make sure
the latest versions are in an STS Project.  I have developed some code to
automate this a bit.  However I always half expect something to get messed
up and make my life more complicated.  So far it has worked, so maybe I am
just paranoid.  I just don't like doing it too often.

However when I deploy my application I always start from a virgin image.
For that I use my code extractor tool (
http://www.mitchellscientific.com/smalltalk/ ) to make a "super package" to
load into a virgin image.

 > (BTW, I use and enjoy your lookup tool.)

I am really glad that it is of use to people.  I feel guilty though, I have
continued to develop it and I think I am using a better version than I think
I have on my site.  My latest version will search all methods in the system
if it can not determine the object type.  I wanted to clean up some quirks
before posting it though.  I wish I were more like Ian regarding the way he
maintains his goodies.  I also have some great experimental stuff.
Hopefully I will post and document my code before it becomes obsolete. ;)

Chris

"Christopher J. Demers" wrote:
It is straight-forward to modify a loader that handles potentially
circular prerequisites.  VisualWorks' parcel loader was fixed in 7.0 to
handle same.  Our loader uses exceptions to check whenever a
prerequisite us about to be loaded if in fact it is already in the
process of loading further down the stack.  Here's the one method that
needed to be modified.  The first use of QueryNotification checks for a
prerequisite already being loaded; the second use provides the handler
for a query.


    loadParcelCachedFrom: aStringOrFilename
        "Load the required parcel, using the info cache to locate the parcel
and any prerequisites."

        | loadedParcel loadTag |
        "First see if this parcel is already in the process of being loaded."
        loadedParcel := QueryNotification newSignal
                            parameter: (loadTag := #parcel -> aStringOrFilename asString);
                            valueWithDefault: [nil].
        loadedParcel notNil ifTrue: [^loadedParcel].
        loadedParcel := self new.
        [loadedParcel startLoad.
         ["If the parcel is being reloaded loadFrom: will return the old
parcel."
          [loadedParcel := loadedParcel loadFrom: aStringOrFilename]
              on: QueryNotification
              do: [:ex|
                loadTag = ex parameter ifTrue: [ex resume: loadedParcel].
                ex pass].
         self replaceParcel: loadedParcel]
            on: self abortedActionSignal
            do: [:ex|
                Dialog warn: ex errorString.
                ex parameter first isNil ifFalse:
                    [ex parameter first unload].
                ^nil].
         self loadUninstalledCodePostLoadOf: loadedParcel]
            ensure: [loadedParcel endLoad].

        ^loadedParcel


--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Ian Bartholomew wrote:

> ...
>
>I don't understand this.  If you try to load a package that has
>prerequisites that are not already installed in the image then these
>prerequisites are automatically loaded for you.  The order in which you
>choose to install packages is usually immaterial.
>
I want to load *all* of my packages into a clean image,
so I can better see what's available, and manage them
'in image'. I'd want to do this with the minimum of effort.

>I suppose it might also be possible to export a list of required
>packages from a current image so that it could be used as the basis for
>the file list in the above script.  The problem would be removing
>packages that you don't want to reinstall - all the OA ones for example.
>
A good point.  Yet if the system generated the script for me,
it would be easy to remove the packages I don't want from it.

But if such OA packages were good enough for me in my previous
image, I'd probably appreciate them being around this time as well.

Thanks
-Panu Viljamaa

Panu,

Actually, the OA packages are no longer a problem (at least IMHO), since
Dolphin started shipping with all packages loaded.

<shamelessPlug>Look at Migrate in my D5 goodies.</shamelessPlug>  Feel free
to use it as-is or modify as you see fit.  The package manager has come a
long way over time, but given that I have roughly 200 packages in my image,
I like having something that decides which packages need to be loaded.

Have a good one,

Bill

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

Bill Schwab wrote:

> ..
>
>I have roughly 200 packages in my image,
>I like having something that decides which packages need to be loaded.
>

I've worked with "hierarchical package managers".
By that I mean a package can have 'sub-packages'.

I can decide to load a given version of a sub-package.
OR if I load a specific version of a container package,
it means a set of sub-packages will be loaded as well,
having versions associated with the version of
the container package being loaded.

Does your package-manager do something similar,
or do you see reasons why not?

Thanks
-Panu Viljamaa

Panu,

> >I have roughly 200 packages in my image,
> >I like having something that decides which packages need to be loaded.
> >
> I've worked with "hierarchical package managers".
> By that I mean a package can have 'sub-packages'.

Just so we know that we're talking about the same things... which version of
Dolphin are you using?
The Dolphin 5 package browser is significantly different from the one in
earlier versions.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy Bower wrote:

> ....Just so we know that we're talking about the same things... which
> version of Dolphin are you using? The Dolphin 5 package browser is
> significantly different from the one in earlier versions.


I'm using D4. My main point is not the Package Manager,
but that I think it should be easy, almost automatic, to
rebuild an image from a clean one, after a crash or other
anomaly - or even an upgrade to the next Dolphin version.

Version control would be great, perhaps as the next step.
I know there are 3rd party solutions, but the problem with
them is that they often break when the version of the main
product goes up.

A related issue is that I've done a set of GUI customizations
to my D4 environment, laboriously so in the ResourceManager.
If I start from a clean image, I will have to redo them.

Which is also a reason for me *not to* upgrade to D5, since
I'd probably need to start with a clean (D5) image, without
a) my packages b) my GUI customizations.

Thanks
-Panu Viljamaa

Panu,

> > ....Just so we know that we're talking about the same things... which
> > version of Dolphin are you using? The Dolphin 5 package browser is
> > significantly different from the one in earlier versions.
>
> I'm using D4. My main point is not the Package Manager,
> but that I think it should be easy, almost automatic, to
> rebuild an image from a clean one, after a crash or other
> anomaly - or even an upgrade to the next Dolphin version.

Ok, but it is trivial to add what you want to the existing system (as we all
know one of the beauties of all Smalltalk IDEs is that they are readily
extensible). To this end, please find a patch at the end of this message for
D4 and D5 that will allow you to save out a package re-install script. This
took me 20 minutes to write. You use it as follows:

1) Install the patch into you image.

2) When you get to a state you want to snapshot, with all your packages
loaded, just evaluate:

Package manager saveInstallScriptForAllPackagesTo: FileSaveDialog showModal

and choose an ST filename, say "Reload.st". This saves out an ST script to
reload all the packages in the image from their respective package files. If
a package (like a base system package) is already present it will not
attempt to reload it. The script is saved out in the correct order so that
all prerequisite packages will be reloaded first (the D5 package system will
do this anyway, but in D4 prerequisites are only loaded if they are in the
same directory as the package currently being loaded).

3) When you suffer an image corruption or want to start from a fresh image
simply load in the patch and then file in your "Reload.st" file.

I'm sure one could work add a way to automate this so that on image save the
snapshot was automatically taken and on image load the reload was performed
if that is the way you like to work. Please note, that this is not a
suitable method for moving your setup from D4 to D5 since the package
structure has been vastly changed between these versions.

> Version control would be great, perhaps as the next step.
> I know there are 3rd party solutions, but the problem with
> them is that they often break when the version of the main
> product goes up.

Hmmm... I think STS has been kept up to date with the major Dolphin releases
in a fairly timely manor.

> A related issue is that I've done a set of GUI customizations
> to my D4 environment, laboriously so in the ResourceManager.
> If I start from a clean image, I will have to redo them.

Well, hopefully, you haven't made the customisations to the original views
themselves. What you should do is to load up the original views, make your
changes, and the save the views down under new names. You should place the
new view resources into a new package ("My Views" say). You can use the
System Options to tell Dolphin to use the new named views for each of the
tools (change the #defaultView for each tool to indicate the new view name).
In the Post Install script for your "My Views" package you can include the
Smalltalk code to programmatically set these system options when the package
is loaded.

Since an image is a fairly ephemeral thing one cannot rely on changes made
to it never having to be remade. You should never really make a change to
the image unless the change is saved in a package or in a script file (most
of the time you can use the pre/post install package scripts to replace
separate script files). You should always be prepared to rebuild an image
from scratch just in case disaster strikes.

> Which is also a reason for me *not to* upgrade to D5, since
> I'd probably need to start with a clean (D5) image, without
> a) my packages b) my GUI customizations.

Well with the customizations that's true but surely reloading your packages
is hardly a barrier to upgrading.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

***************************
!PackageManager methodsFor!
saveInstallScriptForAllPackagesTo: aFilenameString
    "Saves an ST script to reload all the current packages to a file
identified by aFilenameString"
    self saveInstallScriptFor: self packages values to: aFilenameString ! !
!PackageManager categoriesFor:
#saveInstallScriptForAllPackagesTo:!operations!public! !

!PackageManager methodsFor!
saveInstallScriptFor: aPackageCollection to: aFilenameString
    "Saves an ST script to reload the contents of aPackageCollection to a
file identified by aFilenameString"
    | stream packageList |
    stream := FileStream write: aFilenameString text: true.
    packageList := OrderedCollection new.
    aPackageCollection do: [:each | self withAllPrerequisitesOf: each addTo:
packageList ].
    stream nextPutAll: 'Package manager'.
    packageList do: [:each |
        stream cr; tab; nextPutAll: 'install: '; print: each
packageFileName; nextPutAll: ' ifPresent: []'; nextPut: $;].
    stream nextPut: $.; nextPut: $!!.
    stream close! !
!PackageManager categoriesFor: #saveInstallScriptFor:to:!operations!public!
!

!PackageManager methodsFor!
withAllPrerequisitesOf: aPackage addTo: anOrderedCollection
    "Builds a list of packages that includes aPackage and all of its
prerequisite packages in the
    correct order so that the can be loaded without dependency problems"
    | prereqs |
    prereqs := aPackage prerequisites.
    prereqs isEmpty
        ifFalse: [ prereqs do: [:each |
            self withAllPrerequisitesOf: each addTo: anOrderedCollection]].
    (anOrderedCollection anySatisfy: [:each | each name=aPackage name])
ifFalse: [
        anOrderedCollection add: aPackage].
    ^anOrderedCollection! !
!PackageManager categoriesFor:
#withAllPrerequisitesOf:addTo:!*-unclassified!private! !

!PackageManager methodsFor!
install: packagePathname ifPresent: aBlock
    "Attempt to install a <Package> from the package file at the
<readableString> path,
    packagePathname. If the package is already present in the image then
evaluate aBlock."
    | packageName |
    packageName := File splitStemFrom: packagePathname.
    (self includesPackageNamed: packageName) ifTrue: [^aBlock value].
    ^self install: packagePathname! !
    !PackageManager categoriesFor: #install:ifPresent:!operations!public! !

***************************

Andy Bower wrote:

>  Ok, but it is trivial to add what you want to the existing system (as
> we all
>
>know one of the beauties of all Smalltalk IDEs is that they are readily
>extensible). To this end, please find a patch at the end of this message for
>D4 and D5 that will allow you to save out a package re-install script. This
>took me 20 minutes to write.  
>
Thank You very much.
I appreciate your good service.

-Panu Viljamaa