Re: [Pharo-dev] The new implementation of current working directory

Guys - I don’t know if this is useful input, but I’ve just noticed a weird issue with the default directory in a new Pharo6 image (probably related to this thread). I’m trying to write my first baselineOf: metacello method - and have been confused that when testing it out, I get a walkback where the directory referenced is not my image. e.g. this the the error message: Could not resolve: ConfigurationOfNeoJSON [ConfigurationOfNeoJSON] in /Users/name/Dev/Smalltalk/Pharo/Pharo-6-60495-c/pharo-local/package-cache However that Pharo-6-60495 is an earlier image before the release of pharo but its not the image I am using - which is a clean 6.0 image. It looks like the implementation of MCCacheRepository class>>uniqueInstance (self defaultDirectory) is returning some random directory - possibly related to the discussion here? When I inspect “self defaultDirectory” - it correctly shows: File @ pharo-local/package-cache (the relative portion) - however the default in the MCCache is as above which is wrong. Is there some error lurking in the new Pharo 6 images? Tim

On 3 Jul 2017, at 15:16, Alistair Grant <akgrant0710@gmail.com> wrote:

Hi Rajula,

On Thu, Jun 29, 2017 at 05:42:02AM -0700, Rajula Vineet wrote:

...

Hi all,

As I have already been posting about my GSoC work and updates on my blog <https://vineetreddy.wordpress.com> and on the mailing list <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=129479...> . In this post, I would like to go in depth of my work on 'the working directory' so that I can get valuable feedback and suggestions from everyone. This discussion was started on an github PR <https://github.com/pharo-project/pharo/pull/96> which was conflicting my PR.

It looks like my concerns were unfounded, but many thanks for taking the trouble to follow up on this.

It would good if you could keep a similar caching strategy to the one I introduced as the performance gains can be significant (as suggested by Cyril's comment).

Thanks again, Alistair

...

Firstly, I would like to go through the current implementation of the working directory. With this implementation, when you use the defaultWorkingDirectory method, the directory in which the running image is present in, is returned. This is not a completely good working because when you run the image from a different directory like './pharo ../Pharo.image' the working directory is the one in which your image resides. But that isn`t your actual working directory. Due to this,

1. Pharo cannot be installed as a normal application in a read-only environment. 2. Pharo wrongly reads and writes files relative to the 'working directory'. 3. It also makes scripting difficult.

In the FogBugz issue here <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there is an example which explains the problem.

Let say the Pharo VM and Image are in the directory "~/Pharo", and I wrote a script in "~/Documents/Pharo-scripts" called "perfect-numbers.st"

I have 2 possibilities:

cd ~/Pharo && pharo Pharo.image st ~/Documents/Pharo-scripts/perfect-numbers.st // works

or

cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st perfect-numbers.st // doesn't work...

It doesn't work because when pharo wants to load the file, it tries to locate it with: FileSystem disk workingDirectory !!! which is NOT the current working directory."

I hope you get the problem.

So for the new implementation <https://github.com/rajula96reddy/pharo-cli> with the help of Guille I researched about $PWD and getcwd() for a while and wrote a new implementation. This is how it goes 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI 2. And a new method currentWorkingDirectoryPath and currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the above method and gets the working directory. 3. To integrate this, I have patched the DiskStore method 'defaultWorkingDirectory' to use the new methods in OSPlatform.

I have checked all the sendors of the 'defaultWorkingDirectory' for any issue. And I also wrote some unit tests. So, the new implementation is working fine. With this, now I am able to get the right working directory. The example mentioned above works perfectly.

But, there may be a few cases where it can break interoperability between Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' directory and its methods should also be patched subsequently. In fact, these problems can be tackled by running image from its own directory itself (which is obvious ;) ) or by using the method imageDirectory in FileLocator class explicitly when necessary. But overall a good thing is this is will ensure the system will behave as in other languages.

I have completed this implementation and submitted a PR <https://github.com/pharo-project/pharo/pull/92> to github. But because of some dependency issue, it has not yet been merged. With the help of my mentor, I am working on the problem.

Thanks for reading all this. Please give your feedback and comments on this new implementation. Your suggestions help me in learning more about the project and also about the organization.

Thanks, Rajula

-- View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.