Pharo 6 FileSystem>>changeDirectory: is missing

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

Pharo 6 FileSystem>>changeDirectory: is missing

Andreas Sunardi
I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been using FileSystem>>changeDirectory to make my program (Pharo 5) runs in the current working directory (thus able to find local files).

This is now broken because #changeDirectory doesn't exist anymore. The change seems intentional.

Question: Is there a different way in Pharo 6 do set working directory or is this a bug?

--
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Stephane Ducasse-3
Thanks for reporting.
I do not remember an action around me for this change.
Do you have the definition in Pharo 50 at hand?

Stef

On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <[hidden email]> wrote:

> I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
> using FileSystem>>changeDirectory to make my program (Pharo 5) runs in the
> current working directory (thus able to find local files).
>
> This is now broken because #changeDirectory doesn't exist anymore. The
> change seems intentional.
>
> Question: Is there a different way in Pharo 6 do set working directory or is
> this a bug?
>
> --
> Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Andreas Sunardi
It isn't only #changeDirectory: method that is missing. Method #workingDirectoryPath: and instance variable workingDirectory are also missing. 

FileSystem >> changeDirectory: aPath
  self workingDirectoryPath: (self resolve: aPath)

FileSystem >> workingDirectoryPath: aPath
  aPath isAbsolute
    ifFalse: [ self error: 'Cannot set the working directory to a relative path' ].
  workingDirectory := aPath


To solve my problem, I implemented those and also fixed #initializeWithStore: and changed #workingDirectoryPath

FileSystem >> initializeWithStore: aStore
  store := aStore.
  workingDirectory := store defaultWorkingDirectory

FileSystem >> workingDirectoryPath
  ^ workingDirectory


Those are from Pharo 5. However, this breaks Monticello (when opening Monticello Browser). A FileSystem instance has instance variable workingDirectory set to nil. This should be impossible. I set 'self halt' in #initializeWithStore:. It doesn't get triggered, which tells me the instance isn't created by normal way. I don't know what's going on there.


To fix it, I changed #workingDirectoryPath to

FileSystem >> workingDirectoryPath
  workingDirectory ifNil: [
    workingDirectory := store defaultWorkingDirectory ].
  ^ workingDirectory


That solves my problem, but this is a specific tool. I don't know what other problems those changes will cause. This #ifNil: guard is not in Pharo 5, so that makes me worry. In general, the change in FileSystem gives impression that the it is intentional. But I haven't found the new Pharo 6.1 way to change working directory, if there's any.


--
Andreas

On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <[hidden email]> wrote:
Thanks for reporting.
I do not remember an action around me for this change.
Do you have the definition in Pharo 50 at hand?

Stef

On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <[hidden email]> wrote:
> I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
> using FileSystem>>changeDirectory to make my program (Pharo 5) runs in the
> current working directory (thus able to find local files).
>
> This is now broken because #changeDirectory doesn't exist anymore. The
> change seems intentional.
>
> Question: Is there a different way in Pharo 6 do set working directory or is
> this a bug?
>
> --
> Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Alistair Grant
On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:

> It isn't only #changeDirectory: method that is missing. Method #
> workingDirectoryPath: and instance variable workingDirectory are also missing.
>
> FileSystem >> changeDirectory: aPath
>   self workingDirectoryPath: (self resolve: aPath)
>
> FileSystem >> workingDirectoryPath: aPath
>   aPath isAbsolute
>     ifFalse: [ self error: 'Cannot set the working directory to a relative
> path' ].
>   workingDirectory := aPath
>
>
> To solve my problem, I implemented those and also fixed #initializeWithStore:
> and changed #workingDirectoryPath
>
> FileSystem >> initializeWithStore: aStore
>   store := aStore.
>   workingDirectory := store defaultWorkingDirectory
>
> FileSystem >> workingDirectoryPath
>   ^ workingDirectory
>
>
> Those are from Pharo 5. However, this breaks Monticello (when opening
> Monticello Browser). A FileSystem instance has instance variable
> workingDirectory set to nil. This should be impossible. I set 'self halt' in #
> initializeWithStore:. It doesn't get triggered, which tells me the instance
> isn't created by normal way. I don't know what's going on there.
>
>
> To fix it, I changed #workingDirectoryPath to
>
> FileSystem >> workingDirectoryPath
>   workingDirectory ifNil: [
>     workingDirectory := store defaultWorkingDirectory ].
>   ^ workingDirectory
>
>
> That solves my problem, but this is a specific tool. I don't know what other
> problems those changes will cause. This #ifNil: guard is not in Pharo 5, so
> that makes me worry. In general, the change in FileSystem gives impression that
> the it is intentional. But I haven't found the new Pharo 6.1 way to change
> working directory, if there's any.

I couldn't find a fogbugz issue relating to this - if anyone knows the
issue, please post it here as it would be good to understand the
rationale for the change.

My interpretation of the changes are that the decision was made to hard
code the working directory to the image directory.  There are quite a
few people who don't agree with this. :-)

There is already a proposed patch to change the working directory to the
process working directory, see fogbugz #05723.
https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory

The patch is waiting on a fix to include UFFI in the kernel.

It currently doesn't allow the working directory to be changed,
but if I remember correctly, Rajula developed the code to change the
working directory.

I think this approach has the advantage that it will automtically work
with forked processes, e.g. using OSProcess / OSSubprocess.

It would be worthwhile adding a comment to the issue asking Rajula to
add the change directory functionality to the patch.

Cheers,
Alistair



> --
> Andreas
>
> On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <[hidden email]>
> wrote:
>
>     Thanks for reporting.
>     I do not remember an action around me for this change.
>     Do you have the definition in Pharo 50 at hand?
>
>     Stef
>
>     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <[hidden email]>
>     wrote:
>     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
>     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs in
>     the
>     > current working directory (thus able to find local files).
>     >
>     > This is now broken because #changeDirectory doesn't exist anymore. The
>     > change seems intentional.
>     >
>     > Question: Is there a different way in Pharo 6 do set working directory or
>     is
>     > this a bug?
>     >
>     > --
>     > Andreas
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Andreas Sunardi
Hi Alistair,

I found fogbugz #19717 where this was discussed.


The issue seems to be the current working directory is saved in instance variable workingDirectory. When the image is moved to another directory, this workingDirectory becomes incorrect. Instance variable 'store', through its #defaultWorkingDirectory, always gives the right answer (however, this answer is the image directory, not directory where the command is invoked, which is the issue in #05723 you mentioned).

Here's a snippet from fogbugz #19717 original problem on how to reproduce it:
QUOTE
1/ open an image. evaluate './pharo-local' asFileReference and keep the inspector.
2/ save and quit
3/ move the image to another directory
4/ open the image
5/ evaluate self fullName on the file reference => it will give a wrong path with a reference to the working directory used at file reference creation.
ENDQUOTE

I don't know if it's still debatable, which './pharo-local' the file reference should refer to, but I think I agree with fogbugz #19717 that it should stay as relative path.

But this is a separate issue than losing the ability to change working directory, which seems to me an unintentional side-effect in the solution. I'll see if I can jump onto $05723 to request support for changing working directory.

On a side note, is current working directory the same as image directory in Pharo? I wonder why we have these issues if they are separate things. I haven't dived into this, so I can't say much.
 
--
Andreas

On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]> wrote:
On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
> It isn't only #changeDirectory: method that is missing. Method #
> workingDirectoryPath: and instance variable workingDirectory are also missing.
>
> FileSystem >> changeDirectory: aPath
>   self workingDirectoryPath: (self resolve: aPath)
>
> FileSystem >> workingDirectoryPath: aPath
>   aPath isAbsolute
>     ifFalse: [ self error: 'Cannot set the working directory to a relative
> path' ].
>   workingDirectory := aPath
>
>
> To solve my problem, I implemented those and also fixed #initializeWithStore:
> and changed #workingDirectoryPath
>
> FileSystem >> initializeWithStore: aStore
>   store := aStore.
>   workingDirectory := store defaultWorkingDirectory
>
> FileSystem >> workingDirectoryPath
>   ^ workingDirectory
>
>
> Those are from Pharo 5. However, this breaks Monticello (when opening
> Monticello Browser). A FileSystem instance has instance variable
> workingDirectory set to nil. This should be impossible. I set 'self halt' in #
> initializeWithStore:. It doesn't get triggered, which tells me the instance
> isn't created by normal way. I don't know what's going on there.
>
>
> To fix it, I changed #workingDirectoryPath to
>
> FileSystem >> workingDirectoryPath
>   workingDirectory ifNil: [
>     workingDirectory := store defaultWorkingDirectory ].
>   ^ workingDirectory
>
>
> That solves my problem, but this is a specific tool. I don't know what other
> problems those changes will cause. This #ifNil: guard is not in Pharo 5, so
> that makes me worry. In general, the change in FileSystem gives impression that
> the it is intentional. But I haven't found the new Pharo 6.1 way to change
> working directory, if there's any.

I couldn't find a fogbugz issue relating to this - if anyone knows the
issue, please post it here as it would be good to understand the
rationale for the change.

My interpretation of the changes are that the decision was made to hard
code the working directory to the image directory.  There are quite a
few people who don't agree with this. :-)

There is already a proposed patch to change the working directory to the
process working directory, see fogbugz #05723.
https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory

The patch is waiting on a fix to include UFFI in the kernel.

It currently doesn't allow the working directory to be changed,
but if I remember correctly, Rajula developed the code to change the
working directory.

I think this approach has the advantage that it will automtically work
with forked processes, e.g. using OSProcess / OSSubprocess.

It would be worthwhile adding a comment to the issue asking Rajula to
add the change directory functionality to the patch.

Cheers,
Alistair



> --
> Andreas
>
> On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <[hidden email]>
> wrote:
>
>     Thanks for reporting.
>     I do not remember an action around me for this change.
>     Do you have the definition in Pharo 50 at hand?
>
>     Stef
>
>     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <[hidden email]>
>     wrote:
>     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've been
>     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs in
>     the
>     > current working directory (thus able to find local files).
>     >
>     > This is now broken because #changeDirectory doesn't exist anymore. The
>     > change seems intentional.
>     >
>     > Question: Is there a different way in Pharo 6 do set working directory or
>     is
>     > this a bug?
>     >
>     > --
>     > Andreas
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Stephane Ducasse-3
Thanks a lot andreas!!!!!!

On Thu, Sep 7, 2017 at 1:53 AM, Andreas Sunardi <[hidden email]> wrote:

> Hi Alistair,
>
> I found fogbugz #19717 where this was discussed.
>
> https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>
> The issue seems to be the current working directory is saved in instance
> variable workingDirectory. When the image is moved to another directory,
> this workingDirectory becomes incorrect. Instance variable 'store', through
> its #defaultWorkingDirectory, always gives the right answer (however, this
> answer is the image directory, not directory where the command is invoked,
> which is the issue in #05723 you mentioned).
>
> Here's a snippet from fogbugz #19717 original problem on how to reproduce
> it:
> QUOTE
> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
> inspector.
> 2/ save and quit
> 3/ move the image to another directory
> 4/ open the image
> 5/ evaluate self fullName on the file reference => it will give a wrong path
> with a reference to the working directory used at file reference creation.
> ENDQUOTE
>
> I don't know if it's still debatable, which './pharo-local' the file
> reference should refer to, but I think I agree with fogbugz #19717 that it
> should stay as relative path.
>
> But this is a separate issue than losing the ability to change working
> directory, which seems to me an unintentional side-effect in the solution.
> I'll see if I can jump onto $05723 to request support for changing working
> directory.
>
> On a side note, is current working directory the same as image directory in
> Pharo? I wonder why we have these issues if they are separate things. I
> haven't dived into this, so I can't say much.
>
> --
> Andreas
>
> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]>
> wrote:
>>
>> On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>> > It isn't only #changeDirectory: method that is missing. Method #
>> > workingDirectoryPath: and instance variable workingDirectory are also
>> > missing.
>> >
>> > FileSystem >> changeDirectory: aPath
>> >   self workingDirectoryPath: (self resolve: aPath)
>> >
>> > FileSystem >> workingDirectoryPath: aPath
>> >   aPath isAbsolute
>> >     ifFalse: [ self error: 'Cannot set the working directory to a
>> > relative
>> > path' ].
>> >   workingDirectory := aPath
>> >
>> >
>> > To solve my problem, I implemented those and also fixed
>> > #initializeWithStore:
>> > and changed #workingDirectoryPath
>> >
>> > FileSystem >> initializeWithStore: aStore
>> >   store := aStore.
>> >   workingDirectory := store defaultWorkingDirectory
>> >
>> > FileSystem >> workingDirectoryPath
>> >   ^ workingDirectory
>> >
>> >
>> > Those are from Pharo 5. However, this breaks Monticello (when opening
>> > Monticello Browser). A FileSystem instance has instance variable
>> > workingDirectory set to nil. This should be impossible. I set 'self
>> > halt' in #
>> > initializeWithStore:. It doesn't get triggered, which tells me the
>> > instance
>> > isn't created by normal way. I don't know what's going on there.
>> >
>> >
>> > To fix it, I changed #workingDirectoryPath to
>> >
>> > FileSystem >> workingDirectoryPath
>> >   workingDirectory ifNil: [
>> >     workingDirectory := store defaultWorkingDirectory ].
>> >   ^ workingDirectory
>> >
>> >
>> > That solves my problem, but this is a specific tool. I don't know what
>> > other
>> > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
>> > so
>> > that makes me worry. In general, the change in FileSystem gives
>> > impression that
>> > the it is intentional. But I haven't found the new Pharo 6.1 way to
>> > change
>> > working directory, if there's any.
>>
>> I couldn't find a fogbugz issue relating to this - if anyone knows the
>> issue, please post it here as it would be good to understand the
>> rationale for the change.
>>
>> My interpretation of the changes are that the decision was made to hard
>> code the working directory to the image directory.  There are quite a
>> few people who don't agree with this. :-)
>>
>> There is already a proposed patch to change the working directory to the
>> process working directory, see fogbugz #05723.
>> https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>>
>> The patch is waiting on a fix to include UFFI in the kernel.
>>
>> It currently doesn't allow the working directory to be changed,
>> but if I remember correctly, Rajula developed the code to change the
>> working directory.
>>
>> I think this approach has the advantage that it will automtically work
>> with forked processes, e.g. using OSProcess / OSSubprocess.
>>
>> It would be worthwhile adding a comment to the issue asking Rajula to
>> add the change directory functionality to the patch.
>>
>> Cheers,
>> Alistair
>>
>>
>>
>> > --
>> > Andreas
>> >
>> > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse
>> > <[hidden email]>
>> > wrote:
>> >
>> >     Thanks for reporting.
>> >     I do not remember an action around me for this change.
>> >     Do you have the definition in Pharo 50 at hand?
>> >
>> >     Stef
>> >
>> >     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi
>> > <[hidden email]>
>> >     wrote:
>> >     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've
>> > been
>> >     > using FileSystem>>changeDirectory to make my program (Pharo 5)
>> > runs in
>> >     the
>> >     > current working directory (thus able to find local files).
>> >     >
>> >     > This is now broken because #changeDirectory doesn't exist anymore.
>> > The
>> >     > change seems intentional.
>> >     >
>> >     > Question: Is there a different way in Pharo 6 do set working
>> > directory or
>> >     is
>> >     > this a bug?
>> >     >
>> >     > --
>> >     > Andreas
>> >
>> >
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Alistair Grant
In reply to this post by Andreas Sunardi
Hi Andreas,

On Wed, Sep 06, 2017 at 04:53:27PM -0700, Andreas Sunardi wrote:

> Hi Alistair,
>
> I found fogbugz #19717 where this was discussed.
>
> https://pharo.fogbugz.com/f/cases/19717/
> FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>
> The issue seems to be the current working directory is saved in instance
> variable workingDirectory. When the image is moved to another directory, this
> workingDirectory becomes incorrect. Instance variable 'store', through its #
> defaultWorkingDirectory, always gives the right answer (however, this answer is
> the image directory, not directory where the command is invoked, which is the
> issue in #05723 you mentioned).
>
> Here's a snippet from fogbugz #19717 original problem on how to reproduce it:
> QUOTE
> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
> inspector.
> 2/ save and quit
> 3/ move the image to another directory
> 4/ open the image
> 5/ evaluate self fullName on the file reference => it will give a wrong path
> with a reference to the working directory used at file reference creation.
> ENDQUOTE

Thanks for finding this!

In #20164 I reintroduced caching the working directory, but update it
when the session is stopped and started, so the above test produces the
expected results.  As you can see in the comments for the associated PR,
caching the value was a significant peformance improvement for at least
one person.
https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDirectory


> I don't know if it's still debatable, which './pharo-local' the file reference
> should refer to, but I think I agree with fogbugz #19717 that it should stay as
> relative path.
>
> But this is a separate issue than losing the ability to change working
> directory, which seems to me an unintentional side-effect in the solution. I'll
> see if I can jump onto $05723 to request support for changing working
> directory.
>
> On a side note, is current working directory the same as image directory in
> Pharo? I wonder why we have these issues if they are separate things. I haven't
> dived into this, so I can't say much.

Yes, which was the original driver for #05723.  After it is integrated
the working directory will be the process working directory.  The image
directory can of course still be accessed with FileLocator
imageDirectory.

Cheers,
Alistair


> --
> Andreas
>
> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]> wrote:
>
>     On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>     > It isn't only #changeDirectory: method that is missing. Method #
>     > workingDirectoryPath: and instance variable workingDirectory are also
>     missing.
>     >
>     > FileSystem >> changeDirectory: aPath
>     >   self workingDirectoryPath: (self resolve: aPath)
>     >
>     > FileSystem >> workingDirectoryPath: aPath
>     >   aPath isAbsolute
>     >     ifFalse: [ self error: 'Cannot set the working directory to a
>     relative
>     > path' ].
>     >   workingDirectory := aPath
>     >
>     >
>     > To solve my problem, I implemented those and also fixed #
>     initializeWithStore:
>     > and changed #workingDirectoryPath
>     >
>     > FileSystem >> initializeWithStore: aStore
>     >   store := aStore.
>     >   workingDirectory := store defaultWorkingDirectory
>     >
>     > FileSystem >> workingDirectoryPath
>     >   ^ workingDirectory
>     >
>     >
>     > Those are from Pharo 5. However, this breaks Monticello (when opening
>     > Monticello Browser). A FileSystem instance has instance variable
>     > workingDirectory set to nil. This should be impossible. I set 'self halt'
>     in #
>     > initializeWithStore:. It doesn't get triggered, which tells me the
>     instance
>     > isn't created by normal way. I don't know what's going on there.
>     >
>     >
>     > To fix it, I changed #workingDirectoryPath to
>     >
>     > FileSystem >> workingDirectoryPath
>     >   workingDirectory ifNil: [
>     >     workingDirectory := store defaultWorkingDirectory ].
>     >   ^ workingDirectory
>     >
>     >
>     > That solves my problem, but this is a specific tool. I don't know what
>     other
>     > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
>     so
>     > that makes me worry. In general, the change in FileSystem gives
>     impression that
>     > the it is intentional. But I haven't found the new Pharo 6.1 way to
>     change
>     > working directory, if there's any.
>
>     I couldn't find a fogbugz issue relating to this - if anyone knows the
>     issue, please post it here as it would be good to understand the
>     rationale for the change.
>
>     My interpretation of the changes are that the decision was made to hard
>     code the working directory to the image directory.  There are quite a
>     few people who don't agree with this. :-)
>
>     There is already a proposed patch to change the working directory to the
>     process working directory, see fogbugz #05723.
>     https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>
>     The patch is waiting on a fix to include UFFI in the kernel.
>
>     It currently doesn't allow the working directory to be changed,
>     but if I remember correctly, Rajula developed the code to change the
>     working directory.
>
>     I think this approach has the advantage that it will automtically work
>     with forked processes, e.g. using OSProcess / OSSubprocess.
>
>     It would be worthwhile adding a comment to the issue asking Rajula to
>     add the change directory functionality to the patch.
>
>     Cheers,
>     Alistair
>
>
>
>     > --
>     > Andreas
>     >
>     > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <
>     [hidden email]>
>     > wrote:
>     >
>     >     Thanks for reporting.
>     >     I do not remember an action around me for this change.
>     >     Do you have the definition in Pharo 50 at hand?
>     >
>     >     Stef
>     >
>     >     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <
>     [hidden email]>
>     >     wrote:
>     >     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've
>     been
>     >     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs
>     in
>     >     the
>     >     > current working directory (thus able to find local files).
>     >     >
>     >     > This is now broken because #changeDirectory doesn't exist anymore.
>     The
>     >     > change seems intentional.
>     >     >
>     >     > Question: Is there a different way in Pharo 6 do set working
>     directory or
>     >     is
>     >     > this a bug?
>     >     >
>     >     > --
>     >     > Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Pharo 6 FileSystem>>changeDirectory: is missing

Stephane Ducasse-3
Alistair

did I miss some pending PR to be integrated for FS?
I'm getting back to reality after a totally fun and intense ESUG conference.
Stef

On Thu, Sep 7, 2017 at 8:26 AM, Alistair Grant <[hidden email]> wrote:

> Hi Andreas,
>
> On Wed, Sep 06, 2017 at 04:53:27PM -0700, Andreas Sunardi wrote:
>> Hi Alistair,
>>
>> I found fogbugz #19717 where this was discussed.
>>
>> https://pharo.fogbugz.com/f/cases/19717/
>> FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>>
>> The issue seems to be the current working directory is saved in instance
>> variable workingDirectory. When the image is moved to another directory, this
>> workingDirectory becomes incorrect. Instance variable 'store', through its #
>> defaultWorkingDirectory, always gives the right answer (however, this answer is
>> the image directory, not directory where the command is invoked, which is the
>> issue in #05723 you mentioned).
>>
>> Here's a snippet from fogbugz #19717 original problem on how to reproduce it:
>> QUOTE
>> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
>> inspector.
>> 2/ save and quit
>> 3/ move the image to another directory
>> 4/ open the image
>> 5/ evaluate self fullName on the file reference => it will give a wrong path
>> with a reference to the working directory used at file reference creation.
>> ENDQUOTE
>
> Thanks for finding this!
>
> In #20164 I reintroduced caching the working directory, but update it
> when the session is stopped and started, so the above test produces the
> expected results.  As you can see in the comments for the associated PR,
> caching the value was a significant peformance improvement for at least
> one person.
> https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDirectory
>
>
>> I don't know if it's still debatable, which './pharo-local' the file reference
>> should refer to, but I think I agree with fogbugz #19717 that it should stay as
>> relative path.
>>
>> But this is a separate issue than losing the ability to change working
>> directory, which seems to me an unintentional side-effect in the solution. I'll
>> see if I can jump onto $05723 to request support for changing working
>> directory.
>>
>> On a side note, is current working directory the same as image directory in
>> Pharo? I wonder why we have these issues if they are separate things. I haven't
>> dived into this, so I can't say much.
>
> Yes, which was the original driver for #05723.  After it is integrated
> the working directory will be the process working directory.  The image
> directory can of course still be accessed with FileLocator
> imageDirectory.
>
> Cheers,
> Alistair
>
>
>> --
>> Andreas
>>
>> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant <[hidden email]> wrote:
>>
>>     On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>>     > It isn't only #changeDirectory: method that is missing. Method #
>>     > workingDirectoryPath: and instance variable workingDirectory are also
>>     missing.
>>     >
>>     > FileSystem >> changeDirectory: aPath
>>     >   self workingDirectoryPath: (self resolve: aPath)
>>     >
>>     > FileSystem >> workingDirectoryPath: aPath
>>     >   aPath isAbsolute
>>     >     ifFalse: [ self error: 'Cannot set the working directory to a
>>     relative
>>     > path' ].
>>     >   workingDirectory := aPath
>>     >
>>     >
>>     > To solve my problem, I implemented those and also fixed #
>>     initializeWithStore:
>>     > and changed #workingDirectoryPath
>>     >
>>     > FileSystem >> initializeWithStore: aStore
>>     >   store := aStore.
>>     >   workingDirectory := store defaultWorkingDirectory
>>     >
>>     > FileSystem >> workingDirectoryPath
>>     >   ^ workingDirectory
>>     >
>>     >
>>     > Those are from Pharo 5. However, this breaks Monticello (when opening
>>     > Monticello Browser). A FileSystem instance has instance variable
>>     > workingDirectory set to nil. This should be impossible. I set 'self halt'
>>     in #
>>     > initializeWithStore:. It doesn't get triggered, which tells me the
>>     instance
>>     > isn't created by normal way. I don't know what's going on there.
>>     >
>>     >
>>     > To fix it, I changed #workingDirectoryPath to
>>     >
>>     > FileSystem >> workingDirectoryPath
>>     >   workingDirectory ifNil: [
>>     >     workingDirectory := store defaultWorkingDirectory ].
>>     >   ^ workingDirectory
>>     >
>>     >
>>     > That solves my problem, but this is a specific tool. I don't know what
>>     other
>>     > problems those changes will cause. This #ifNil: guard is not in Pharo 5,
>>     so
>>     > that makes me worry. In general, the change in FileSystem gives
>>     impression that
>>     > the it is intentional. But I haven't found the new Pharo 6.1 way to
>>     change
>>     > working directory, if there's any.
>>
>>     I couldn't find a fogbugz issue relating to this - if anyone knows the
>>     issue, please post it here as it would be good to understand the
>>     rationale for the change.
>>
>>     My interpretation of the changes are that the decision was made to hard
>>     code the working directory to the image directory.  There are quite a
>>     few people who don't agree with this. :-)
>>
>>     There is already a proposed patch to change the working directory to the
>>     process working directory, see fogbugz #05723.
>>     https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory
>>
>>     The patch is waiting on a fix to include UFFI in the kernel.
>>
>>     It currently doesn't allow the working directory to be changed,
>>     but if I remember correctly, Rajula developed the code to change the
>>     working directory.
>>
>>     I think this approach has the advantage that it will automtically work
>>     with forked processes, e.g. using OSProcess / OSSubprocess.
>>
>>     It would be worthwhile adding a comment to the issue asking Rajula to
>>     add the change directory functionality to the patch.
>>
>>     Cheers,
>>     Alistair
>>
>>
>>
>>     > --
>>     > Andreas
>>     >
>>     > On Tue, Sep 5, 2017 at 12:46 AM, Stephane Ducasse <
>>     [hidden email]>
>>     > wrote:
>>     >
>>     >     Thanks for reporting.
>>     >     I do not remember an action around me for this change.
>>     >     Do you have the definition in Pharo 50 at hand?
>>     >
>>     >     Stef
>>     >
>>     >     On Wed, Aug 30, 2017 at 11:09 PM, Andreas Sunardi <
>>     [hidden email]>
>>     >     wrote:
>>     >     > I found FileSystem class has changed from Pharo 5 to Pharo 6. I've
>>     been
>>     >     > using FileSystem>>changeDirectory to make my program (Pharo 5) runs
>>     in
>>     >     the
>>     >     > current working directory (thus able to find local files).
>>     >     >
>>     >     > This is now broken because #changeDirectory doesn't exist anymore.
>>     The
>>     >     > change seems intentional.
>>     >     >
>>     >     > Question: Is there a different way in Pharo 6 do set working
>>     directory or
>>     >     is
>>     >     > this a bug?
>>     >     >
>>     >     > --
>>     >     > Andreas
>