more fun with System>>Local directory settings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

more fun with System>>Local directory settings

Dale Henrichs-3

... the last time we talked[1], I was wondering why my System >> Local directory setting was pointing to a location that dated back to a project I abandoned 6 months ago and learned that that path was stashed in $HOME/.config/pharo ...

I've finally found the cycles to work on the Pharo portion of my project.

I've deleted the whole $HOME/.config/pharo and re-downloaded a fresh set of image and changes files (the previous image and changes files had been polluted by the previously cached values) and discovered that the act of starting the image automagically populates the System >> local directory with a full path to a directory in my current directory ... which is not quite as bad as pointing off to a "local directory" located in "outer space" ... but I assume that I will have the same problem that I had before[2] which is a walkback when attempting  to use the .image file on a machine where the saved local directory path will not exist (similar stack BTW as already reported against pharo in this bug report[3].

What I want to do is create a Pharo.image (i.e., load some code into the image) in such a way that I can ship the image file to users on a completely different system and have them successfully execute the code in the image ...

I assume there is a way to do this, since the images I download don't suffer from this problem ...

I naively cleared the Local directory field in the system browser, saved and quit the image and then got this error:

which is presumably a relative of this error[3].

I used the folder icon to select my local directory again ... saved the image and restarted only to get the same walkback:

Keep in mind the ultimate goal ... shipping an image to another user and making it possible for them to use it ...

Thanks in advance for any help,

Dale

[1] http://forum.world.st/where-are-system-settings-stored-td5101501.html
[2] https://travis-ci.org/dalehenrich/st_launcher/builds/561863077#L603
[3] https://github.com/pharo-project/pharo-launcher/issues/37

Reply | Threaded
Open this post in threaded view
|

Re: more fun with System>>Local directory settings

Dale Henrichs-3

I found SystemResolver class >> userLocalDirectory and the presence of settingsOn: lead me to believe that I had stumbled upon the right place ... through an experiment [1], I have confirmed that "just because you see something in the Local Directory field of the settings browesr and have been burned by that field before ... it does not mean that you will always be burned  since the class variable is nil in a fresh image" --- I was burned before because I had a stale settings save and that must have caused  the class variable to be set ...

As I was writing this message I remembered that there used to be a way to go from the settings browser directly to the code that was involved with the settings ... so I tried clicking around in the settings browser and voila a double click did the trick ... gotta love the modern UX where the way to discover functionality is to try clicking/dragging/wiggling in blank areas of the screen in hopes that something useful will happen --- on windows if you shake your mouse the window will disappear --- I found that out by accident ... thank goodness someone was near by to tell me how to get my window back :)

Dale

[1] https://travis-ci.org/dalehenrich/st_launcher/builds/566226359#L367

On 7/31/19 3:25 PM, Dale Henrichs wrote:

... the last time we talked[1], I was wondering why my System >> Local directory setting was pointing to a location that dated back to a project I abandoned 6 months ago and learned that that path was stashed in $HOME/.config/pharo ...

I've finally found the cycles to work on the Pharo portion of my project.

I've deleted the whole $HOME/.config/pharo and re-downloaded a fresh set of image and changes files (the previous image and changes files had been polluted by the previously cached values) and discovered that the act of starting the image automagically populates the System >> local directory with a full path to a directory in my current directory ... which is not quite as bad as pointing off to a "local directory" located in "outer space" ... but I assume that I will have the same problem that I had before[2] which is a walkback when attempting  to use the .image file on a machine where the saved local directory path will not exist (similar stack BTW as already reported against pharo in this bug report[3].

What I want to do is create a Pharo.image (i.e., load some code into the image) in such a way that I can ship the image file to users on a completely different system and have them successfully execute the code in the image ...

I assume there is a way to do this, since the images I download don't suffer from this problem ...

I naively cleared the Local directory field in the system browser, saved and quit the image and then got this error:

which is presumably a relative of this error[3].

I used the folder icon to select my local directory again ... saved the image and restarted only to get the same walkback:

Keep in mind the ultimate goal ... shipping an image to another user and making it possible for them to use it ...

Thanks in advance for any help,

Dale

[1] http://forum.world.st/where-are-system-settings-stored-td5101501.html
[2] https://travis-ci.org/dalehenrich/st_launcher/builds/561863077#L603
[3] https://github.com/pharo-project/pharo-launcher/issues/37

Reply | Threaded
Open this post in threaded view
|

Re: more fun with System>>Local directory settings

Sean P. DeNigris
Administrator
In reply to this post by Dale Henrichs-3
Dale Henrichs-3 wrote
> the act of starting the image automagically populates the System >> local
> directory with a full path to a directory in my current directory

This sounds like the same problem I've been having with absolute resolved
paths to local iceberg repos. Here is the script I use to fix them in a way
that survives image moving and renaming. It should be easy to adapt for your
needs. Obviously it would be better if Pharo didn't resolve the paths in
these cases, but at least there is a workaround.

fixIcebergRepoLocations
        "E.g. after an image is moved or renamed, its local Iceberg repos become
broken because the locations are stored as static FileReferences instead of
dynamic FileLocations following the image around. Limitation: assumes all
images are stored in flat folders under root"

        | imageRoot repos |
        imageRoot := FileLocator home / 'Dynabook' / 'Working Images'.
        repos := IceLibgitRepository allSubInstances
                select: [ :e |
                        e location isNotNil
                                and: [ (FileLocator imageDirectory contains: e location) not
                                                and: [ imageRoot contains: e location ] ] ].
        repos
                do: [ :e |
                        | oldPath newPath fixedLocation |
                        oldPath := e location relativeTo: imageRoot.
                        newPath := RelativePath withAll: oldPath segments allButFirst.
                        fixedLocation := FileLocator imageDirectory withPath: newPath.
                        e location: fixedLocation ]



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: more fun with System>>Local directory settings

Dale Henrichs-3
Thanks for the sample code! ... I keep forgetting that a scan of
allInstances is a good way to patch problems like these:) and the fixed
to relative path snippet is especially useful.

Dale

On 8/1/19 1:50 PM, Sean P. DeNigris wrote:

> Dale Henrichs-3 wrote
>> the act of starting the image automagically populates the System >> local
>> directory with a full path to a directory in my current directory
> This sounds like the same problem I've been having with absolute resolved
> paths to local iceberg repos. Here is the script I use to fix them in a way
> that survives image moving and renaming. It should be easy to adapt for your
> needs. Obviously it would be better if Pharo didn't resolve the paths in
> these cases, but at least there is a workaround.
>
> fixIcebergRepoLocations
> "E.g. after an image is moved or renamed, its local Iceberg repos become
> broken because the locations are stored as static FileReferences instead of
> dynamic FileLocations following the image around. Limitation: assumes all
> images are stored in flat folders under root"
>
> | imageRoot repos |
> imageRoot := FileLocator home / 'Dynabook' / 'Working Images'.
> repos := IceLibgitRepository allSubInstances
> select: [ :e |
> e location isNotNil
> and: [ (FileLocator imageDirectory contains: e location) not
> and: [ imageRoot contains: e location ] ] ].
> repos
> do: [ :e |
> | oldPath newPath fixedLocation |
> oldPath := e location relativeTo: imageRoot.
> newPath := RelativePath withAll: oldPath segments allButFirst.
> fixedLocation := FileLocator imageDirectory withPath: newPath.
> e location: fixedLocation ]
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>