Re: [Pharo-users] PharoLauncher directories

[Stephan Eggermont]

Op 8-11-2017 om 15:56 schreef stephan:
I run into all kinds of issues with the directory structure used by the 
new PharoLauncher.


When I copy an image with the launcher, how can I synchronize the 
Iceberg repositories again? Do I just need to copy the original 
directory containing them? Is that something we want to automate?


Stephan

Re: [Pharo-users] PharoLauncher directories

[Alistair Grant]

On 9 November 2017 at 10:18, Guillermo Polito  wrote:
>
> An analysis of the situation so people out of context can understand better 
> the forces in play here :)
>
>  - Working directory and files constant property: files defined using a 
> *relative path* are created relative to the working directory.
> In other words:
>File named: 'something/other/myfile.txt'
> will be created in FileSystem workingDirectory.
> This was always like this when we used the file primitives.
> The diverging behaviour was introduced actually by FileSystem: FileSystem 
> used to create by default all files relative to the image directory. And at 
> some point all tools adapted to that and the correct behaviour was hidden.
>
> - Change in working directory: Before, pharo always satisfied the following 
> property:
>FileSystem workingDirectory = FileSystem imageDirectory


I realise I'm being pedantic, so apologies in advance and I certainly
don't mean to offend anyone.

Just for completeness:

This constraint was actually introduced in Pharo 6 around March 2017.
I think it was issue #19717
(https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder).

Before that the workingDirectory was held in an instance variable and
could be changed (although it looks like no one actually did that).

#20164 
(https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDirectory)
put the workingDirectory back in to a class variable since the
performance gain is significant (one application saved 12 seconds from
the change).

>This is no longer true for every case.
>Now, the workingDirectory is aligned with the process' working directory 
> (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash).


Cheers,
Alistair



>I explained a couple of weeks ago in an email, this may break some eggs, 
> specially for those tools that wrongly assume FileSystem workingDirectory = 
> FileSystem imageDirectory.
>Tools requiring imageDirectory should use imageDirectory explicit. At 
> least that will keep backwards compatibility.
>For other cases, we should probably study them case by case and provide a 
> satisfying solution.
>
>This change does however not affect everybody, and most of the times it is 
> backwards compatible:
>
>** This does not affect in general people launching usually pharo from the 
> command line and using zeroconf:
>$ wget get.pharo.org/...
>$ ./pharo Pharo.image
>## Here, FileSystem workingDirectory = FileSystem imageDirectory 
> because I launched my image from the directory where my image is!
>
>** This does affect people that are:
>   - launching Pharo doing double click.
>   In this case, we saw with Denis and Pavel a week ago that osx 
> assigns as working directory the root directory "/"
>   Users of files should be aware of this and applications should not 
> abuse the workingDirectory. If they want to enforce the imageDirectory, they 
> should do so explicitly.
>
>  - launching Pharo from the pharo launcher (taken from this thread)
>  Apparently the pharo launcher is launching the image from a 
> directory internal to the launcher. This means that the working directory 
> will be assigned to that directory. I'd expect that the directory structure 
> is private to the launcher...
> I find even strange that the launcher puts pharo-local where the 
> image is...
>
>
> Given this, possible solutions are:
>   - On fileout, chose a correct directory when launched from double click
>   - Make the pharo launcher set a well-known working directory when launching 
> an image
>   - one possibility is to set $HOME
>   - another possibility is to set the image directory (this will keep 
> backwards compatibility)
>
> @Stef: about the #fullname. It is not there because it is not implemented :). 
> We did not have the possibility of calculating a correct full path until a 
> couple of weeks ago (and before, even if we did so, it couldn't be done 
> without introducing a dependency to a non-kernel package).
>
> On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey 
>  wrote:
>>
>> Hi Stefan,
>>
>> > Le 8 nov. 2017 à 15:56, stephan  a écrit :
>> >
>> > I run into all kinds of issues with the directory structure used by the 
>> > new PharoLauncher. pharo-local seems to be shared now for multiple images.
>>
>> I never saw this issue.
>> PharoLauncher does not have influence on the pharo-local directory of 
>> launched images. pharo-local directory is located in the same directory as 
>> the image run.
>>
>> in a Pharo 6.1 image:
>> localDirectory
>> ^ self class userLocalDirectory
>> ifNil: [ (self imageDirectory / self class 
>> defaultLocalDirectoryName) ensureCreateDirectory ]
>>
>> userLocalDirectory
>> ^ UserLocalDirectory ifNil: [
>> FileLocator workingDirectory / self 
>> defa

Re: [Pharo-users] PharoLauncher directories

[Stephane Ducasse]

Thanks Christophe!!!

On Thu, Nov 9, 2017 at 9:02 PM, Christophe Demarey
 wrote:
> thanks
>
>> Le 9 nov. 2017 à 20:10, stephan  a écrit :
>>
>> On 09-11-17 11:49, Christophe Demarey wrote:
>>> Stephan, could you open an issue for that on GH?
>>
>> https://github.com/pharo-project/pharo-launcher/issues/51
>>
>> Stephan
>>
>>
>>
>
>

Re: [Pharo-users] PharoLauncher directories

[Christophe Demarey]

thanks

> Le 9 nov. 2017 à 20:10, stephan  a écrit :
> 
> On 09-11-17 11:49, Christophe Demarey wrote:
>> Stephan, could you open an issue for that on GH?
> 
> https://github.com/pharo-project/pharo-launcher/issues/51
> 
> Stephan
> 
> 
> 

Re: [Pharo-users] PharoLauncher directories

[stephan]

On 09-11-17 11:49, Christophe Demarey wrote:

Stephan, could you open an issue for that on GH?


https://github.com/pharo-project/pharo-launcher/issues/51

Stephan

Re: [Pharo-users] PharoLauncher directories

[Christophe Demarey]

> Le 9 nov. 2017 à 10:18, Guillermo Polito  a écrit :
> 
>  - launching Pharo from the pharo launcher (taken from this thread)
>  Apparently the pharo launcher is launching the image from a 
> directory internal to the launcher.

In the Pharo launcher, I explicitly set the current working directory to the VM 
directory so that the VM can find its files.

> This means that the working directory will be assigned to that directory. I'd 
> expect that the directory structure is private to the launcher...
> I find even strange that the launcher puts pharo-local where the 
> image is…

Pharo Launcher does not choose where to put pharo-local. It just stands in the 
standard place aside the launched image.

>  Given this, possible solutions are:
>   - On fileout, chose a correct directory when launched from double click
>   - Make the pharo launcher set a well-known working directory when launching 
> an image
>   - one possibility is to set $HOME
>   - another possibility is to set the image directory (this will keep 
> backwards compatibility)

I think the last solution: set the working directory to the image directory is 
the best option.
It will require to find another way to get the vm find its files (probably with 
LD_LIBRARY_PATH, do not know if it will be enough) and a lot of testing.
I will try to work on it next week.

Stephan, could you open an issue for that on GH?

Re: [Pharo-users] PharoLauncher directories

[stephan]

On 09-11-17 10:18, Guillermo Polito wrote:
An analysis of the situation so people out of context can understand 
better the forces in play here :)


Thanks Guille, that clears up a number of my misunderstandings

Stephan

Re: [Pharo-users] PharoLauncher directories

[Guillermo Polito]

An analysis of the situation so people out of context can understand better
the forces in play here :)

 - *Working directory and files constant property:* files defined using a
*relative path* are created relative to the working directory.
In other words:
   File named: 'something/other/myfile.txt'
will be created in FileSystem workingDirectory.
This was always like this when we used the file primitives.
The diverging behaviour was introduced actually by FileSystem:
FileSystem used to create by default all files relative to the image
directory. And at some point all tools adapted to that and the correct
behaviour was hidden.

- *Change in working directory:* Before, pharo always satisfied the
following property:
   FileSystem workingDirectory = FileSystem imageDirectory

   This is no longer true for every case.
   Now, the workingDirectory is aligned with the process' working directory
(This is the equivalent to getcwd() in C, pwd command in linux, $PWD in
bash).
   I explained a couple of weeks ago in an email, this may break some eggs,
specially for those tools that wrongly assume FileSystem workingDirectory =
FileSystem imageDirectory.
   Tools requiring imageDirectory should use imageDirectory explicit. At
least that will keep backwards compatibility.
   For other cases, we should probably study them case by case and provide
a satisfying solution.

   This change does however not affect everybody, and most of the times it
is backwards compatible:

   ** This does not affect in general people launching usually pharo from
the command line and using zeroconf:
   $ wget get.pharo.org/...
   $ ./pharo Pharo.image
   ## Here, FileSystem workingDirectory *=* FileSystem imageDirectory
because I launched my image from the directory where my image is!

   ** This does affect people that are:
  - launching Pharo doing double click.
  In this case, we saw with Denis and Pavel a week ago that osx
assigns as working directory the root directory "/"
  Users of files should be aware of this and applications should
not abuse the workingDirectory. If they want to enforce the imageDirectory,
they should do so explicitly.

 - launching Pharo from the pharo launcher (taken from this thread)
 Apparently the pharo launcher is launching the image from a
directory internal to the launcher. This means that the working directory
will be assigned to that directory. I'd expect that the directory structure
is private to the launcher...
I find even strange that the launcher puts pharo-local where the
image is...


Given this, possible solutions are:
  - On fileout, chose a correct directory when launched from double click
  - Make the pharo launcher set a well-known working directory when
launching an image
  - one possibility is to set $HOME
  - another possibility is to set the image directory (this will keep
backwards compatibility)

@Stef: about the #fullname. It is not there because it is not implemented
:). We did not have the possibility of calculating a correct full path
until a couple of weeks ago (and before, even if we did so, it couldn't be
done without introducing a dependency to a non-kernel package).

On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi Stefan,
>
> > Le 8 nov. 2017 à 15:56, stephan  a écrit :
> >
> > I run into all kinds of issues with the directory structure used by the
> new PharoLauncher. pharo-local seems to be shared now for multiple images.
>
> I never saw this issue.
> PharoLauncher does not have influence on the pharo-local directory of
> launched images. pharo-local directory is located in the same directory as
> the image run.
>
> in a Pharo 6.1 image:
> localDirectory
> ^ self class userLocalDirectory
> ifNil: [ (self imageDirectory / self class
> defaultLocalDirectoryName) ensureCreateDirectory ]
>
> userLocalDirectory
> ^ UserLocalDirectory ifNil: [
> FileLocator workingDirectory / self
> defaultLocalDirectoryName  ]
>
>
> Maybe you run Pharo 7 images and this change «  Build #203:
> 05723-Default-Working-Directory »  has a side effect?
>
> > That makes using configurations practically impossible as they are not
> expecting to have to deal with pre-downloaded older and newer monticello
> files. The missing sources files is less of a problem.
> >
> > Stephan
> >
> >
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] PharoLauncher directories

[Christophe Demarey]

Hi Stefan,

> Le 8 nov. 2017 à 15:56, stephan  a écrit :
> 
> I run into all kinds of issues with the directory structure used by the new 
> PharoLauncher. pharo-local seems to be shared now for multiple images.

I never saw this issue.
PharoLauncher does not have influence on the pharo-local directory of launched 
images. pharo-local directory is located in the same directory as the image run.

in a Pharo 6.1 image:
localDirectory 
^ self class userLocalDirectory 
ifNil: [ (self imageDirectory / self class 
defaultLocalDirectoryName) ensureCreateDirectory ]

userLocalDirectory
^ UserLocalDirectory ifNil: [ 
FileLocator workingDirectory / self defaultLocalDirectoryName  ]


Maybe you run Pharo 7 images and this change «  Build #203: 
05723-Default-Working-Directory »  has a side effect?

> That makes using configurations practically impossible as they are not 
> expecting to have to deal with pre-downloaded older and newer monticello 
> files. The missing sources files is less of a problem.
> 
> Stephan
> 
> 

[Pharo-users] PharoLauncher directories

[stephan]

I run into all kinds of issues with the directory structure used by the 
new PharoLauncher. pharo-local seems to be shared now for multiple 
images. That makes using configurations practically impossible as they 
are not expecting to have to deal with pre-downloaded older and newer 
monticello files. The missing sources files is less of a problem.


Stephan