Relocating Dolphin 6 installation including STS code repository

Hi, all,

when moving my Dolphin 6 Professional installation from
C:\Program Files\Dolphin Smalltalk 6.0
to
D:\prg\smalltalk\Dolphin Smalltalk 6.0
with the STS code repository being located at
c:\Program Files\Dolphin Smalltalk 6.0\Code Repository
without reinstalling Dolphin Smalltalk I get an error message during
start of my image that the STS code repository could not be found and
that STS is shut down.
Investigating the image file I find that the absolute path to the code
repository is hard-coded in the image.

I was able to reconnect the STS code repository by evaluating the
following code in a workspace:

StsManager startUpOn:
    (SessionManager current imageBase , 'Code Repository')

Because I think that storing such configuration information in the image
is a bad thing I would like to change the behaviour of STS to store the
code repository location in the registry or in some configuration file
external to the image and connect to the code repository based on this
configuration information at Dolphin startup.

However I was not able to find the point where STS hooks in the Dolphin
startup process and connects to the repository.
I searched the classes StsManager and SessionManager including
subclasses but didn't find what I needed.

Could somebody (perhaps from Object Arts) please shed some light on
where this happens?

Thanks very much!

Kind regards,
Florian

Florian von Walter wrote:
But storing this kind of information in the image is the Smalltalk way.
Thus, moving this information in the registry is not desirable.
What you really want to have is to make it configurable, e.g. as a user
preference.

Andreas

Florian,

Seconded.  The registry (or external files) would be prefereable for
holding a deployed exe's configuration, but for the image, the image
itself is the most readily available storage.

The exception to that would be if you have different machines with
different logical drive sizes, so that two different drive letters make
sense.  Then you might want the image to look at data stored on the
machine vs. in the image.

Thinking about it, you have effectively changed the behavior the way you
want.  All you would need to do is have the startup code look in the
registry.  However, I would urge you to do that only if machine
dependence is in fact what you need.

Have a good one,

Bill


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

On Wed, 21 Dec 2005 19:01:40 +0000, Bill Schwab wrote:

> Thinking about it, you have effectively changed the behavior the way you
> want.  All you would need to do is have the startup code look in the
> registry.  However, I would urge you to do that only if machine dependence
> is in fact what you need.
>

I found that a dose of good old     subst b: .
goes a long way to achieve this.

I copy stuff from laptop to workstation and back and always map my working
directory to the same drive letter.

s.

Andreas and Bill,

I want to be able to move around my Dolphin installation on my hard disk
as I like.
This makes especially sense when I move my Dolphin installation to an
external hard-drive or an USB stick where the drive letter is never be
granted to be the same as it was at installation time.

Generally I agree that configuration information should be stored in
that Smalltalk way you are talking of.

But in this special case I disagree. This special setting is
system-dependent and because Dolphin Smalltalk lives on Windows it makes
sense at least for me to not store it in the image unless there is a way
to resolve the problem of a moved code repository automatically or at
least interactively at startup. As far as I can see the design of
StsManager is already somewhat system-independent when looking up the
definition of StsManager>>defaultRepositoryPath. There is only a small
step to have the desired behaviour by enhancing StsManager>>startUpOn:
which seems to be triggered by SessionManager>>onStartup:.

Regards,
Florian

On Wed, 21 Dec 2005 21:21:15 +0100, Stefan Schmiedl wrote:

> I found that a dose of good old     subst b: . goes a long way to achieve
> this.
>
> I copy stuff from laptop to workstation and back and always map my working
> directory to the same drive letter.
>

... and I have some useful stuff saved in a scratch file, which
usually stays open in the main IdeaSpace. 1- to 3-liners like

!
"deploy"
PackageManager current defaultPackage saveChanges.
ShellLibrary default shellOpen: 'b:\dp\deploy.bat' directory: 'b:\dp'.
StsManager current versionPackage: PackageManager current defaultPackage.
!
"run"
ShellLibrary default shellOpen: 'b:\theApp.exe' directory: 'b:\'
!
"connect STS on g64"
StsManager startUpOn: 'b:\'


s.

Andreas Wacknitz wrote:

The problem is not WHERE the config info is stored,
but rather WHAT is being stored:

As you yourself point out,
     "the absolute path to the code repository
      is hard-coded in the image"
which is just plain *wrong*, regardless of how common it is.

However, you've targeted the wrong place as needing a fix.
The reference to an absolute pathname in
     StsManager>>startUpOn: someAbsolutePathname
is correct--one does literally want the source manager to
     startUpOn: someAbsolutePathname.

The fix is to use (basepath + baseRelative) addressing
for everything else (everything EXCEPT the actual launch).

Thus, as you almost said,

     StsManager>>defaultRepositoryPath
         ^(SessionManager current imageBase , 'Code Repository')

would seem to be the solution, assuming that startup triggers
   startupOn: self defaultRepositoryPath.

Or something with similar effect, if needed--I can't see the
actual source right now.


Regards,

-cstb

cstb wrote:

> As you yourself point out,
>     "the absolute path to the code repository
>      is hard-coded in the image"
> which is just plain *wrong*, regardless of how common it is.

You are right. I used the wrong term. In fact I intended to say "the
absolute path to the code repository is stored in the image".

Just evaluate

StsManager current inspect

in a workspace and inspect the instance variables.
Variable 'repositoryPath' has the absolute path (at least in my image).

Well, that's basically how StsManager>>defaultRepositoryPath is
implemented already. It just removes the trailing backslash in addition
to that.

> Or something with similar effect, if needed--I can't see the
> actual source right now.

For me extending StsManager>>connectToDatabase has done it.
I just added

(File exists: repositoryPath)
        ifFalse: [repositoryPath := self chooseRepository].

as the first statement of the method.

Regards,
Florian