Smalltalk › Pharo › Pharo Smalltalk Developers

The new implementation of current working directory

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Rajula Vineet

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

alistairgrant

Re: The new implementation of current working directory

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

Sven Van Caekenberghe-2

Re: The new implementation of current working directory

> On 30 Jun 2017, at 09:56, Alistair Grant <[hidden email]> 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
>

Max Leske

Re: The new implementation of current working directory

In reply to this post by Rajula Vineet

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 <[hidden email]> 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.
>
> 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.
>

Guillermo Polito

Re: The new implementation of current working directory

In reply to this post by alistairgrant

On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

alistairgrant

Re: The new implementation of current working directory

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 <[hidden email]> 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

Ben Coman

Re: The new implementation of current working directory

In reply to this post by Guillermo Polito

On Fri, Jun 30, 2017 at 4:12 PM, Guillermo Polito <[hidden email]> wrote:

On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <[hidden email]> 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

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

alistairgrant

Re: The new implementation of current working directory

In reply to this post by Rajula Vineet

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

Tim Mackinnon

Re: 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 <[hidden email]> 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.

Tim Mackinnon

Re: The new implementation of current working directory

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 <[hidden email]> 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 <[hidden email]> 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.

Rajula Vineet

Re: The new implementation of current working directory

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

Rajula Vineet

Re: The new implementation of current working directory

In reply to this post by alistairgrant

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

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

05723-Default-Working-Directory by rajula96reddy · Pull Request #92 · pharo-project/pharo

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-tp4952918.html

Pharo Smalltalk Developers - The new implementation of current working directory

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-tp4952918p4953299.html

Pharo Smalltalk Developers - The new implementation of current working directory

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

Tim Mackinnon

Re: The new implementation of current working directory

In reply to this post by Rajula Vineet

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 <[hidden email]> 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-tp4952918p4954070.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Tim Mackinnon

Re: The new implementation of current working directory

In reply to this post by Rajula Vineet

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

alistairgrant

Re: The new implementation of current working directory

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 <[hidden email]>
> > 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

alistairgrant

Re: The new implementation of current working directory

In reply to this post by Rajula Vineet

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