The new implementation of current working directory
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. 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.
Rajula, thanks for your write-up. As the person who pushed Rajula to send his email I feel I should respond. While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on: '../init/mystartup.st' asFileReference fileIn to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like: (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn Cheers, Alistair
On 30 Jun 2017, at 09:56, Alistair Grant <akgrant0710@gmail.com> wrote:
Rajula, thanks for your write-up.
As the person who pushed Rajula to send his email I feel I should respond.
While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on:
'../init/mystartup.st' asFileReference fileIn
to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like:
(FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn
I haven't read everything (sorry), but we do have FileLocator workingDirectory So the question is, what should be the default when no known location is used ? Also, it feels to me as if, when file paths are passed via command line, it would make sense to use the workingDirectory as default.
Cheers, Alistair
On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Rajula, thanks for your write-up.
As the person who pushed Rajula to send his email I feel I should respond.
While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on:
'../init/mystartup.st' asFileReference fileIn
to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like:
(FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn
That's not true. It depends from where the image is launched. If you're running from the command line, $ pharo Pharo.image eval " 'someFile' asFileReference fullName " will be a file relative to the path of the image, if you open the image from where it is located (ie, working directory = image directory). This is yes different when you're 1) deploying the image in one directory, but you're using it from another one $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' asFileReference fullName " But then, why working directory should be image directory and not VM directory? Just historical reasons? That's a buggy convention. And people who know what a working directory is will perceive it as even buggier. 2) starting the process from a graphical environment (ie, double click in an executable app) In that case, the OS usually sets as working directory the current user home directory, or the user "desktop" directory. In any case, - we should have a good default, I think that following the principle of least surprise we should use as working directory what the OS means by working directory. - Applications in general should be explicit with their file management. Each OS has different locations to store different things (data, settings, libraries, executables)... FileLocator helps by reducing the noise between different OSs, but we should use it!
Cheers, Alistair
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Hi Guillermo, On Fri, Jun 30, 2017 at 10:12:32AM +0200, Guillermo Polito wrote:
On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Rajula, thanks for your write-up.
As the person who pushed Rajula to send his email I feel I should respond.
While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on:
'../init/mystartup.st' asFileReference fileIn
to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like:
(FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn
That's not true. It depends from where the image is launched. If you're running from the command line,
$ pharo Pharo.image eval " 'someFile' asFileReference fullName "
will be a file relative to the path of the image, if you open the image from where it is located (ie, working directory = image directory).
Feel free to ignore this section, it isn't important to the conclusion... But that's my point - it depends on where the image is launched. If I want to be sure that the file will be found, I need to resolve from the image directory, not the process current working directory. Using the current definition of defaultWorkingDirectory I don't need to worry about this.
This is yes different when you're 1) deploying the image in one directory, but you're using it from another one $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' asFileReference fullName "
But then, why working directory should be image directory and not VM directory? Just historical reasons? That's a buggy convention. And people who know what a working directory is will perceive it as even buggier.
2) starting the process from a graphical environment (ie, double click in an executable app) In that case, the OS usually sets as working directory the current user home directory, or the user "desktop" directory.
In any case, - we should have a good default, I think that following the principle of least surprise we should use as working directory what the OS means by working directory.
This is the important bit on which we all seem to agree. :-)
- Applications in general should be explicit with their file management. Each OS has different locations to store different things (data, settings, libraries, executables)... FileLocator helps by reducing the noise between different OSs, but we should use it!
:-) Cheers, Alistair
On Fri, Jun 30, 2017 at 4:12 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Rajula, thanks for your write-up.
As the person who pushed Rajula to send his email I feel I should respond.
While I'm in favour of Rajula's proposed changes, scripting in particular will be much easier, I think we need to make the change generally known as it will not always be obvious, e.g. at the moment I can rely on:
'../init/mystartup.st' asFileReference fileIn
to always work with the current definition since my init directory is always next to the image directory. After Rajula's changes I will need to do something like:
(FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn
That's not true. It depends from where the image is launched. If you're running from the command line,
$ pharo Pharo.image eval " 'someFile' asFileReference fullName "
will be a file relative to the path of the image, if you open the image from where it is located (ie, working directory = image directory).
This is yes different when you're 1) deploying the image in one directory, but you're using it from another one $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' asFileReference fullName "
But then, why working directory should be image directory and not VM directory?
I feel the analogy is that the VM is like WinWord.exe and the Image is like a document. The working directory would never be where WinWord.exe is located. Its where the document was opened from. cheers -ben
Just historical reasons? That's a buggy convention. And people who know what a working directory is will perceive it as even buggier.
2) starting the process from a graphical environment (ie, double click in an executable app) In that case, the OS usually sets as working directory the current user home directory, or the user "desktop" directory.
In any case, - we should have a good default, I think that following the principle of least surprise we should use as working directory what the OS means by working directory.
- Applications in general should be explicit with their file management. Each OS has different locations to store different things (data, settings, libraries, executables)... FileLocator helps by reducing the noise between different OSs, but we should use it!
Cheers, Alistair
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
Thanks for the detailed explanation Rajula. I think it makes perfect sense to separate working and image directories from each other. What you didn't mention is how the current working directory is resolved when an image is not started from the command line but by using the operating systems file browser (e.g. double clicking). There's also the special case of the one-click image: should the working directory be the image directory (which on OS X would be inside of the application bundle (which sucks))? Could you elaborate on that? Cheers, Max
On 29 Jun 2017, at 14:42, Rajula Vineet <Vineet.Reddy@iiitb.org> 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.
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.
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.
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.
I've just realised an important difference which maybe accentuates this thread - my image is actually a v7 vm with a Pharo 6 image and the iceberg update instructions that Esteban sent around. Is it possible the working dir changes are in that new vm? If so, the problem I'm getting might be exactly what you were calling out Alasdair? Tim Sent from my iPhone
On 9 Jul 2017, at 08:55, Tim Mackinnon <tim@testit.works> wrote:
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.
Hey Tim, The new implementation hasn`t been merged into the pharo code base. This error is not related to the new implementation. Probably it is related to your local directories. Are you using a linux? Are you running from the image directory? If you don`t, the path changes and pharo can not find the cache directory. 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.
Ok - that should rule out those changes, however it may be a sign of things to come (or maybe not - its just the discussions here made me think of what Iâm seeing). I am running the image from the command line on OSX Sierra, using 64 bit. If I run System reporter it nicely shows the problem where I have run from a directory "Pharo-6.0-64-7vmâ using .pharo-ui Pharo.image, However look at the first Monticello repository - its referencing another one of my directories - an older image that I havenât used a for a few weeks. Iâm pretty sure this current image was a fresh one downloaded with zeroconf as I was following Estebans instructions to use the 7 vm with a pharo6 image, and I had to do it a particular way as I quizzed him on it just a few days ago. I guess I will go and try it with a new image and see if I get the same results - but Iâm wondering if there is a latent problem in here somehow? Image ----- /Users/macta/Dev/Smalltalk/Pharo/Pharo-6.0-64-7vm/Pharo.image Pharo6.0 Latest update: #60506 Unnamed Monticello Repositories ----------------------- /Users/macta/Dev/Smalltalk/Pharo/Pharo-6-60495-c/pharo-local/package-cache http://smalltalkhub.com/mc/Pharo/Athens/main/ http://smalltalkhub.com/mc/PharoExtras/CatalogBrowser/main/ http://smalltalkhub.com/mc/PharoExtras/Tool-DependencyAnalyser/main/ http://smalltalkhub.com/mc/MartinDias/Epicea/main/ http://smalltalkhub.com/mc/estebanlm/FastTable/main/ http://smalltalkhub.com/mc/YuriyTymchuk/ScrapYard/main/ http://smalltalkhub.com/mc/Pharo/Fuel/main/ http://smalltalkhub.com/mc/Moose/GToolkit/main/ http://smalltalkhub.com/mc/Moose/Glamour/main/ http://smalltalkhub.com/mc/Pharo/OSWindow/main/ http://smalltalkhub.com/mc/NicolaiHess/Playground/main/ http://smalltalkhub.com/mc/StephaneDucasse/AutomaticMethodCategorizer/main/ http://smalltalkhub.com/mc/Pharo/SessionManager/main/ http://smalltalkhub.com/mc/dalsat/ShoreLine-Reporter/main/ http://ss3.gemstone.com/ss/STON http://smalltalkhub.com/mc/Pharo/TxText/main/ http://smalltalkhub.com/mc/Pharo/FFI-NB/main/ http://smalltalkhub.com/mc/PharoExtras/Versionner/main/ http://smalltalkhub.com/mc/PharoExtras/BitmapCharacterSet/main/ http://smalltalkhub.com/mc/PharoExtras/XMLParser/main/ http://smalltalkhub.com/mc/Pharo/XMLWriter/main/ http://mc.stfx.eu/ZincHTTPComponents http://smalltalkhub.com/mc/Pharo/Pharo60/main http://smalltalkhub.com/mc/Pharo/Pharo60Inbox/main github://pharo-vcs/iceberg:master github://pharo-vcs/libgit2-pharo-bindings:v0.25.1 https://github.com/svenvc/NeoJSON/tree/master/repository https://github.com/svenvc/NeoJSON https://github.com/svenvc/NeoJSON/tree http://mc.stfx.eu/Neo github://svenvc/NeoJSON:master/repository filetree:///Users/macta/Dev/Smalltalk/Pharo/Pharo-6.0-64-7vm/pharo-local/iceberg/macta/PharoLambda Virtual Machine --------------- /Users/macta/Dev/Smalltalk/Pharo/Pharo-6.0-64-7vm/pharo-vm/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 VM: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sat Jul 1 16:38:23 2017 -0700 $ Plugins: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Mac OS X built on Jul 1 2017 23:57:21 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) VMMaker versionString VM: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sat Jul 1 16:38:23 2017 -0700 $ Plugins: 201707012338 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2250 uuid: 0726505e-161b-4a23-843e-c5222917ff5e Jul 1 2017
On 10 Jul 2017, at 06:32, Rajula Vineet <Vineet.Reddy@iiitb.org> wrote:
Hey Tim,
The new implementation hasn`t been merged into the pharo code base. This error is not related to the new implementation. Probably it is related to your local directories. Are you using a linux? Are you running from the image directory? If you don`t, the path changes and pharo can not find the cache directory.
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.
Just as a side note - a quick spot check of my other recent images (1 64 bit normal 6.0 and another 32 bit 6.0, are all correct) - its just the one where I used the newer vm. Tim
On 10 Jul 2017, at 06:32, Rajula Vineet <Vineet.Reddy@iiitb.org> wrote:
Hey Tim,
The new implementation hasn`t been merged into the pharo code base. This error is not related to the new implementation. Probably it is related to your local directories. Are you using a linux? Are you running from the image directory? If you don`t, the path changes and pharo can not find the cache directory.
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.
Hi Tim, On Mon, Jul 10, 2017 at 07:32:12AM +0100, Tim Mackinnon wrote:
Just as a side note - a quick spot check of my other recent images (1 64 bit normal 6.0 and another 32 bit 6.0, are all correct) - its just the one where I used the newer vm.
I'm not aware of all the changes that have gone in to the newer VMs, but it's not the first place I'd look in trying to track this down. And I'm not familiar enough with Monticello / Metacello to make any guided suggestions, sorry. Going back to one of your earlier emails, what is the result of: self workingDirectory resolve If that confirms the problem, maybe you could use the debugger to step through and see what it is being resolved against. Cheers, Alistair
Tim
On 10 Jul 2017, at 06:32, Rajula Vineet <Vineet.Reddy@iiitb.org> wrote:
Hey Tim,
The new implementation hasn`t been merged into the pharo code base. This error is not related to the new implementation. Probably it is related to your local directories. Are you using a linux? Are you running from the image directory? If you don`t, the path changes and pharo can not find the cache directory.
Rajula
Hi Alistair, ________________________________ From: Alistair Grant [via Smalltalk] <ml+s1294792n4953299h23@n4.nabble.com> Sent: Monday, July 3, 2017 7:29 PM To: Rajula Vineet Reddy(IMT2014045) Subject: Re: The new implementation of current working directory 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. Not a problem. Indeed thanks for making me do it. I got to learn something new and improved my knowledge on this issue. 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). Yeah. Sure. I have used the same caching strategy and made changes to my pull request. Thanks again, Alistair Thank you, Rajula
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> [https://avatars1.githubusercontent.com/u/9512824?v=3&s=400]<https://github.com/rajula96reddy/pharo-cli>
rajula96reddy/pharo-cli<https://github.com/rajula96reddy/pharo-cli> github.com pharo-cli - Enhancements to pharo command line interface
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 [https://avatars1.githubusercontent.com/u/9512824?v=3&s=400]<https://github.com/pharo-project/pharo/pull/92>
05723-Default-Working-Directory by rajula96reddy · Pull Request #92 · pharo-project/pharo<https://github.com/pharo-project/pharo/pull/92> github.com This is a new pull request, the last one had unnecessary commits.
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... Pharo Smalltalk Developers - The new implementation of current working directory<http://forum.world.st/The-new-implementation-of-current-working-directory-tp...> forum.world.st The new implementation of current working directory. Hi all, As I have already been posting about my GSoC work and updates on my blog and on the mailing list . In this post, I would like to go in...
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
________________________________ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/The-new-implementation-of-current-working-directory-tp... Pharo Smalltalk Developers - The new implementation of current working directory<http://forum.world.st/The-new-implementation-of-current-working-directory-tp...> forum.world.st The new implementation of current working directory. Hi all, As I have already been posting about my GSoC work and updates on my blog and on the mailing list . In this post, I would like to go in... To unsubscribe from The new implementation of current working directory, click here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&nod...>. NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...> -- 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.
Hi Rajula, On Sun, Jul 09, 2017 at 10:38:42PM -0700, Rajula Vineet wrote:
Hi Alistair,
-------------------------------------------------------------------------------
From: Alistair Grant [via Smalltalk] <ml+[hidden email]> Sent: Monday, July 3, 2017 7:29 PM To: Rajula Vineet Reddy(IMT2014045) Subject: Re: The new implementation of current working directory
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 > <<a href="http://forum.world.st/template/NamlServlet.jtp?macro= search_page&node=1294792&query=gsoc+Rajula+&days=0" target="_top" rel="nofollow" id="LPlnk372500" previewremoved="true">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.
Not a problem. Indeed thanks for making me do it. I got to learn something new and improved my knowledge on this issue.
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).
Yeah. Sure. I have used the same caching strategy and made changes to my pull request.
Thanks again, Alistair
Thank you, Rajula
Great! I'm looking forward to updating my scripts to use this instead of my current hack. Thanks again, Alistair
participants (7)
-
Alistair Grant -
Ben Coman -
Guillermo Polito -
Max Leske -
Rajula Vineet -
Sven Van Caekenberghe -
Tim Mackinnon