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 > > >
