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 <[email protected]> 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=1294792&query=gsoc+Rajula+&days=0> >> >> . 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-tp4952918.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >
