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 <akgrant0...@gmail.com> 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 <akgrant0...@gmail.com> >> 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 < >> stepharo.s...@gmail.com> >> > 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 < >> a.suna...@gmail.com> >> > 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 >
