In P3:
FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared In P7: FileSystem disk workingDirectory =>File @ /home/hilaire Is it a bug? -- Dr. Geo http://drgeo.eu |
Le 15/12/2017 à 21:24, Hilaire a écrit :
> In P3: > > FileSystem disk workingDirectory > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared > > In P7: > > FileSystem disk workingDirectory > =>File @ /home/hilaire > > Is it a bug? > In Pharo 3 workingDirectory = imageDirectory. In Pharo 7 workingDirectory = directory from where Pharo was launched. Maybe you launched Pharo from the terminal with this command like this one? Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`. This change was done because, not getting the real working directory make it really hard to script things in Pharo. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France signature.asc (836 bytes) Download Attachment |
In reply to this post by HilaireFernandes
Oh, in a build for a DrGeo app based on P7, the working directory is one
level highter to the image folder. So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir. What's the context? Where to look at? -- Dr. Geo http://drgeo.eu Capture du 2017-12-15 21-30-11.png (82K) Download Attachment |
In reply to this post by CyrilFerlicot
Thanks for the update
Le 15/12/2017 à 21:34, Cyril Ferlicot D. a écrit : > If you wish to use the old behaviour, you can replace `FileSystem disk > workingDirectory` by `FileLocator imageDirectory asFileReference`. > > This change was done because, not getting the real working directory > make it really hard to script things in Pharo. -- Dr. Geo http://drgeo.eu |
In reply to this post by CyrilFerlicot
On 16 December 2017 at 04:34, Cyril Ferlicot D. <[hidden email]> wrote: Le 15/12/2017 à 21:24, Hilaire a écrit : just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ? I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries. cheers -ben
|
Hi ben
We should think about it. Indeed. Now about the names. I'm wondering if they cover well enough the situation. In fact I would like to have imageDirectory (it exists but not in FileSystem) and workingDirectory (I would prefer startupDirectory or something like that). For me workingDirectory is totally unclear. Now this change is super important for making Pharo a good platform for script execution. So let me make it even nicer. Stef On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <[hidden email]> wrote: > > > On 16 December 2017 at 04:34, Cyril Ferlicot D. <[hidden email]> > wrote: >> >> Le 15/12/2017 à 21:24, Hilaire a écrit : >> > In P3: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >> > >> > In P7: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire >> > >> > Is it a bug? >> > >> >> Hi! >> >> In Pharo 3 >> >> workingDirectory = imageDirectory. >> >> In Pharo 7 >> >> workingDirectory = directory from where Pharo was launched. > > > just double-checking... > with equivalent shell commands... > $ DIR1 = `pwd` > $ $DIR2/pharo $DIR3/Pharo.image > > Pharo 3 ==> workingDirectory = $DIR3 > Pharo 7 ==> workingDirectory = $DIR1 > ? > > I wonder for such a semantic API change it might be good to > introduce #workDirectory and deprecate #workingDirectory > so the need for user-devs to change their code is more explicit. > It might make easier to have an auto-conversion rule #workingDirectory ==> > #imageDirectory, > and make it harder to shoot yourself in the foot producing cross-platform > libraries. > > cheers -ben > > >> >> >> Maybe you launched Pharo from the terminal with this command like this >> one? >> >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image >> >> If you wish to use the old behaviour, you can replace `FileSystem disk >> workingDirectory` by `FileLocator imageDirectory asFileReference`. >> >> This change was done because, not getting the real working directory >> make it really hard to script things in Pharo. >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques Prévert 01, >> 59650 Villeneuve d'ascq France >> > |
On 16 December 2017 at 16:02, Stephane Ducasse <[hidden email]> wrote: Hi ben startupDirectory sounds like its where the startup scripts are kept, and common across many Images. For me workingDirectory is totally unclear. Its a fairly well defined concept. Its starts as the shell directory where you type the command to run a program. https://en.wikipedia.org/wiki/Working_directory We should align with the operating system since file access is ultimately through system calls like fopen() where relative paths are ultimately affected by what the operating system considers to be the working directory (or do we *always* fully resolve paths in-Image and only pass absolute paths to fopen() ?) Here is a demonstration of working directory on Unix ... $ mkdir temp && cd temp $ cat << 'EOF' > testcwd.c #include <unistd.h> #include <stdio.h> char buf[1000]; int main() { printf("MYCWD=%s\n", getcwd(buf,1000)); } EOF $ gcc testcwd.c -o testcwd $ ./testcwd MYCWD=/home/ben/dev/temp $ cd .. $ temp/testcwd MYCWD=/home/ben/dev i.e. its the directory where the command was typed in to run the program. Since we build on Windows using Cygwin/Ming, its basically the same semantic for Windows. and even Win32 has similar function GetCurrentDirectory().... Now I guess confusion may arise when in Pharo you want to "change the working directory". if we only modify some in-Image instance variable? Then a difference of opinion might arise between Pharo and operating system calls as to what is the working-directory" when relative paths are used. Perhaps we should only refer to the operating system's current working directory. (Sorry I'm not in a position to dig into that right now) cheers -ben
|
On Sat, Dec 16, 2017 at 12:01 PM, Ben Coman <[hidden email]> wrote:
> > > On 16 December 2017 at 16:02, Stephane Ducasse <[hidden email]> > wrote: >> >> Hi ben >> >> We should think about it. Indeed. >> Now about the names. I'm wondering if they cover well enough the >> situation. >> In fact I would like to have imageDirectory (it exists but not in >> FileSystem) and workingDirectory (I would prefer startupDirectory or >> something like that). > > > startupDirectory sounds like its where the startup scripts are kept, > and common across many Images. > >> For me workingDirectory is totally unclear. > > > Its a fairly well defined concept. Its starts as the shell directory where > you > type the command to run a program. > https://en.wikipedia.org/wiki/Working_directory then we keep it. > We should align with the operating system since file access is ultimately > through system calls like fopen() where relative paths are ultimately affected by > what the operating > system considers to be the working directory (or do we *always* fully > resolve paths > in-Image and only pass absolute paths to fopen() ?) > > Here is a demonstration of working directory on Unix ... > > > $ mkdir temp && cd temp > > $ cat << 'EOF' > testcwd.c > #include <unistd.h> > #include <stdio.h> > char buf[1000]; > int main() > { printf("MYCWD=%s\n", getcwd(buf,1000)); > } > EOF > > $ gcc testcwd.c -o testcwd > > $ ./testcwd > MYCWD=/home/ben/dev/temp > > $ cd .. > > $ temp/testcwd > MYCWD=/home/ben/dev > > > i.e. its the directory where the command was typed in to run the program. > > Since we build on Windows using Cygwin/Ming, its basically the same semantic > for Windows. > and even Win32 has similar function GetCurrentDirectory().... > https://msdn.microsoft.com/en-us/library/windows/desktop/aa364934(v=vs.85).aspx > > > Now I guess confusion may arise when in Pharo you want to "change the > working directory". > if we only modify some in-Image instance variable? Then a difference of > opinion might arise > between Pharo and operating system calls as to what is the > working-directory" when > relative paths are used. > > Perhaps we should only refer to the operating system's current working > directory. > (Sorry I'm not in a position to dig into that right now) > > > cheers -ben > >> >> >> Now this change is super important for making Pharo >> a good platform for script execution. So let me make it even nicer. >> >> Stef >> >> >> On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <[hidden email]> wrote: >> > >> > >> > On 16 December 2017 at 04:34, Cyril Ferlicot D. >> > <[hidden email]> >> > wrote: >> >> >> >> Le 15/12/2017 à 21:24, Hilaire a écrit : >> >> > In P3: >> >> > >> >> > FileSystem disk workingDirectory >> >> > =>File @ >> >> > /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >> >> > >> >> > In P7: >> >> > >> >> > FileSystem disk workingDirectory >> >> > =>File @ /home/hilaire >> >> > >> >> > Is it a bug? >> >> > >> >> >> >> Hi! >> >> >> >> In Pharo 3 >> >> >> >> workingDirectory = imageDirectory. >> >> >> >> In Pharo 7 >> >> >> >> workingDirectory = directory from where Pharo was launched. >> > >> > >> > just double-checking... >> > with equivalent shell commands... >> > $ DIR1 = `pwd` >> > $ $DIR2/pharo $DIR3/Pharo.image >> > >> > Pharo 3 ==> workingDirectory = $DIR3 >> > Pharo 7 ==> workingDirectory = $DIR1 >> > ? >> > >> > I wonder for such a semantic API change it might be good to >> > introduce #workDirectory and deprecate #workingDirectory >> > so the need for user-devs to change their code is more explicit. >> > It might make easier to have an auto-conversion rule #workingDirectory >> > ==> >> > #imageDirectory, >> > and make it harder to shoot yourself in the foot producing >> > cross-platform >> > libraries. >> > >> > cheers -ben >> > >> > >> >> >> >> >> >> Maybe you launched Pharo from the terminal with this command like this >> >> one? >> >> >> >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui >> >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image >> >> >> >> If you wish to use the old behaviour, you can replace `FileSystem disk >> >> workingDirectory` by `FileLocator imageDirectory asFileReference`. >> >> >> >> This change was done because, not getting the real working directory >> >> make it really hard to script things in Pharo. >> >> >> >> -- >> >> Cyril Ferlicot >> >> https://ferlicot.fr >> >> >> >> http://www.synectique.eu >> >> 2 rue Jacques Prévert 01, >> >> 59650 Villeneuve d'ascq France >> >> >> > >> > |
In reply to this post by Ben Coman
Hi Ben,
On 15 December 2017 at 22:14, Ben Coman <[hidden email]> wrote: > > > On 16 December 2017 at 04:34, Cyril Ferlicot D. <[hidden email]> > wrote: >> >> Le 15/12/2017 à 21:24, Hilaire a écrit : >> > In P3: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >> > >> > In P7: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire >> > >> > Is it a bug? >> > >> >> Hi! >> >> In Pharo 3 >> >> workingDirectory = imageDirectory. >> >> In Pharo 7 >> >> workingDirectory = directory from where Pharo was launched. > > > just double-checking... > with equivalent shell commands... > $ DIR1 = `pwd` > $ $DIR2/pharo $DIR3/Pharo.image > > Pharo 3 ==> workingDirectory = $DIR3 > Pharo 7 ==> workingDirectory = $DIR1 > ? > > I wonder for such a semantic API change it might be good to > introduce #workDirectory and deprecate #workingDirectory > so the need for user-devs to change their code is more explicit. > It might make easier to have an auto-conversion rule #workingDirectory ==> > #imageDirectory, > and make it harder to shoot yourself in the foot producing cross-platform > libraries. > > cheers -ben I raised this concern when the change was first proposed. The only responses I saw were that it doesn't matter. Also, prior to Pharo 6, it was possible to change the working directory, so programs shouldn't have assumed that workingDirectory = imageDirectory. > Perhaps we should only refer to the operating system's current working directory. > (Sorry I'm not in a position to dig into that right now) Rajula wrote the code to allow the working directory to be updated, i.e. calling setwd(). I don't think it made it in to the submitted patch, but it obviously could be added in future. The working directory is cached (in DiskStore DefaultWorkingDirectory), but currently there is no way of changing the value, so effectively it is always the OS cwd. Cheers, Alistair |
Now introducing a new name means that all the documentation, books,
videos are obsolete. And this is a cost too. On Sat, Dec 16, 2017 at 5:03 PM, Alistair Grant <[hidden email]> wrote: > Hi Ben, > > On 15 December 2017 at 22:14, Ben Coman <[hidden email]> wrote: >> >> >> On 16 December 2017 at 04:34, Cyril Ferlicot D. <[hidden email]> >> wrote: >>> >>> Le 15/12/2017 à 21:24, Hilaire a écrit : >>> > In P3: >>> > >>> > FileSystem disk workingDirectory >>> > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >>> > >>> > In P7: >>> > >>> > FileSystem disk workingDirectory >>> > =>File @ /home/hilaire >>> > >>> > Is it a bug? >>> > >>> >>> Hi! >>> >>> In Pharo 3 >>> >>> workingDirectory = imageDirectory. >>> >>> In Pharo 7 >>> >>> workingDirectory = directory from where Pharo was launched. >> >> >> just double-checking... >> with equivalent shell commands... >> $ DIR1 = `pwd` >> $ $DIR2/pharo $DIR3/Pharo.image >> >> Pharo 3 ==> workingDirectory = $DIR3 >> Pharo 7 ==> workingDirectory = $DIR1 >> ? >> >> I wonder for such a semantic API change it might be good to >> introduce #workDirectory and deprecate #workingDirectory >> so the need for user-devs to change their code is more explicit. >> It might make easier to have an auto-conversion rule #workingDirectory ==> >> #imageDirectory, >> and make it harder to shoot yourself in the foot producing cross-platform >> libraries. >> >> cheers -ben > > I raised this concern when the change was first proposed. The only > responses I saw were that it doesn't matter. > > Also, prior to Pharo 6, it was possible to change the working > directory, so programs shouldn't have assumed that workingDirectory = > imageDirectory. > > >> Perhaps we should only refer to the operating system's current working directory. >> (Sorry I'm not in a position to dig into that right now) > > Rajula wrote the code to allow the working directory to be updated, > i.e. calling setwd(). I don't think it made it in to the submitted > patch, but it obviously could be added in future. > > The working directory is cached (in DiskStore > DefaultWorkingDirectory), but currently there is no way of changing > the value, so effectively it is always the OS cwd. > > Cheers, > Alistair > |
In reply to this post by Ben Coman
Hi Ben,
2017-12-16 8:01 GMT-03:00 Ben Coman <[hidden email]>: > > > On 16 December 2017 at 16:02, Stephane Ducasse <[hidden email]> > wrote: >> >> Hi ben >> >> We should think about it. Indeed. >> Now about the names. I'm wondering if they cover well enough the >> situation. >> In fact I would like to have imageDirectory (it exists but not in >> FileSystem) and workingDirectory (I would prefer startupDirectory or >> something like that). > > > startupDirectory sounds like its where the startup scripts are kept, > and common across many Images. > >> For me workingDirectory is totally unclear. > > > Its a fairly well defined concept. Its starts as the shell directory where > you > type the command to run a program. > https://en.wikipedia.org/wiki/Working_directory > Note that in R you can set the current working directory with setwd() and this is very common in R scripts. I like the idea around #imageDirectory and #vmStartupDirectory or just #vmDirectory. And maybe renaming #workingDirectory to #userWorkingDirectory would be more clear? Assuming 1 image = 1 user? Cheers, Hernán |
Hi Hernán,
On 18 January 2018 at 05:41, Hernán Morales Durand <[hidden email]> wrote: > > Note that in R you can set the current working directory with setwd() > and this is very common in R scripts. > > I like the idea around #imageDirectory and #vmStartupDirectory or just > #vmDirectory. > And maybe renaming #workingDirectory to #userWorkingDirectory would be > more clear? Assuming 1 image = 1 user? In Pharo 7: FileLocator workingDirectory = C getcwd() # same as R and most languages FileLocator imageDirectory = the directory where the image is located FileLocator vmDirectory = the directory where the vm is located + several others FileLocator class>>workingDirectory: (i.e. setwd()) doesn't exist, but is straightforward to add. Pharo 6 has the same, but workingDirectory = imageDirectory. Cheers, Alistair |
In reply to this post by HilaireFernandes
Also notice that OS can give program very surprising working directory when you run it using UI tools. For example in MacOS drag image to the vm using Finder assigns root (/) as working directory. 2017-12-15 21:38 GMT+01:00 Hilaire <[hidden email]>: Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder. |
Hi Hilaire & Denis,
On 18 January 2018 at 09:38, Denis Kudriashov <[hidden email]> wrote: > Also notice that OS can give program very surprising working directory when > you run it using UI tools. > For example in MacOS drag image to the vm using Finder assigns root (/) as > working directory. > > > 2017-12-15 21:38 GMT+01:00 Hilaire <[hidden email]>: >> >> Oh, in a build for a DrGeo app based on P7, the working directory is one >> level highter to the image folder. >> >> So in P7, there are two different results for the working directory: the >> user home directory, and one level hight to image dir. >> >> What's the context? Where to look at? For Pharo 7: The working directory is C getcwd(). The differences you are seeing will be the result of how Pharo is launched. If you run it from the command line, it will be the current directory of the shell. I don't use MacOS, but it sounds like dragging a file to an executable always uses the root directory as cwd. The working directory is cached in DiskStore DefaultWorkingDirectory. It's set at session startup to DiskStore class>>defaultWorkingDirectory, which ultimately calls getcwd(). HTH, Alistair |
Tx alistair
this is great that we made progress on this point. May be we should update the fileSystem chapter Stef On Thu, Jan 18, 2018 at 9:51 AM, Alistair Grant <[hidden email]> wrote: > Hi Hilaire & Denis, > > On 18 January 2018 at 09:38, Denis Kudriashov <[hidden email]> wrote: >> Also notice that OS can give program very surprising working directory when >> you run it using UI tools. >> For example in MacOS drag image to the vm using Finder assigns root (/) as >> working directory. >> >> >> 2017-12-15 21:38 GMT+01:00 Hilaire <[hidden email]>: >>> >>> Oh, in a build for a DrGeo app based on P7, the working directory is one >>> level highter to the image folder. >>> >>> So in P7, there are two different results for the working directory: the >>> user home directory, and one level hight to image dir. >>> >>> What's the context? Where to look at? > > For Pharo 7: > > The working directory is C getcwd(). The differences you are seeing > will be the result of how Pharo is launched. If you run it from the > command line, it will be the current directory of the shell. I don't > use MacOS, but it sounds like dragging a file to an executable always > uses the root directory as cwd. > > The working directory is cached in DiskStore DefaultWorkingDirectory. > It's set at session startup to DiskStore > class>>defaultWorkingDirectory, which ultimately calls getcwd(). > > HTH, > Alistair > |
Hi Stef,
On 18 January 2018 at 18:43, Stephane Ducasse <[hidden email]> wrote: > Tx alistair > > this is great that we made progress on this point. > May be we should update the fileSystem chapter Yep. Can you point me to the source? I will try and take a look. I also think I'll add #workingDirectory: (be able to set the working directory). I know Rajula did the work, but it didn't make it in to the PR for some reason. Hopefully I can dig it up. Cheers, Alistair > On Thu, Jan 18, 2018 at 9:51 AM, Alistair Grant <[hidden email]> wrote: >> Hi Hilaire & Denis, >> >> On 18 January 2018 at 09:38, Denis Kudriashov <[hidden email]> wrote: >>> Also notice that OS can give program very surprising working directory when >>> you run it using UI tools. >>> For example in MacOS drag image to the vm using Finder assigns root (/) as >>> working directory. >>> >>> >>> 2017-12-15 21:38 GMT+01:00 Hilaire <[hidden email]>: >>>> >>>> Oh, in a build for a DrGeo app based on P7, the working directory is one >>>> level highter to the image folder. >>>> >>>> So in P7, there are two different results for the working directory: the >>>> user home directory, and one level hight to image dir. >>>> >>>> What's the context? Where to look at? >> >> For Pharo 7: >> >> The working directory is C getcwd(). The differences you are seeing >> will be the result of how Pharo is launched. If you run it from the >> command line, it will be the current directory of the shell. I don't >> use MacOS, but it sounds like dragging a file to an executable always >> uses the root directory as cwd. >> >> The working directory is cached in DiskStore DefaultWorkingDirectory. >> It's set at session startup to DiskStore >> class>>defaultWorkingDirectory, which ultimately calls getcwd(). >> >> HTH, >> Alistair >> > |
https://github.com/SquareBracketAssociates/DeepIntoPharo
I will wait for the new version of pillar to port it. Right now I cannot latex it on my machine. Stef On Thu, Jan 18, 2018 at 7:25 PM, Alistair Grant <[hidden email]> wrote: > Hi Stef, > > On 18 January 2018 at 18:43, Stephane Ducasse <[hidden email]> wrote: >> Tx alistair >> >> this is great that we made progress on this point. >> May be we should update the fileSystem chapter > > Yep. Can you point me to the source? I will try and take a look. > > I also think I'll add #workingDirectory: (be able to set the working > directory). I know Rajula did the work, but it didn't make it in to > the PR for some reason. Hopefully I can dig it up. > > Cheers, > Alistair > > > > >> On Thu, Jan 18, 2018 at 9:51 AM, Alistair Grant <[hidden email]> wrote: >>> Hi Hilaire & Denis, >>> >>> On 18 January 2018 at 09:38, Denis Kudriashov <[hidden email]> wrote: >>>> Also notice that OS can give program very surprising working directory when >>>> you run it using UI tools. >>>> For example in MacOS drag image to the vm using Finder assigns root (/) as >>>> working directory. >>>> >>>> >>>> 2017-12-15 21:38 GMT+01:00 Hilaire <[hidden email]>: >>>>> >>>>> Oh, in a build for a DrGeo app based on P7, the working directory is one >>>>> level highter to the image folder. >>>>> >>>>> So in P7, there are two different results for the working directory: the >>>>> user home directory, and one level hight to image dir. >>>>> >>>>> What's the context? Where to look at? >>> >>> For Pharo 7: >>> >>> The working directory is C getcwd(). The differences you are seeing >>> will be the result of how Pharo is launched. If you run it from the >>> command line, it will be the current directory of the shell. I don't >>> use MacOS, but it sounds like dragging a file to an executable always >>> uses the root directory as cwd. >>> >>> The working directory is cached in DiskStore DefaultWorkingDirectory. >>> It's set at session startup to DiskStore >>> class>>defaultWorkingDirectory, which ultimately calls getcwd(). >>> >>> HTH, >>> Alistair >>> >> > |
In reply to this post by alistairgrant
On 18 January 2018 at 14:33, Alistair Grant <[hidden email]> wrote:
> Hi Hernán, > > On 18 January 2018 at 05:41, Hernán Morales Durand > <[hidden email]> wrote: >> >> Note that in R you can set the current working directory with setwd() >> and this is very common in R scripts. >> >> I like the idea around #imageDirectory and #vmStartupDirectory or just >> #vmDirectory. >> And maybe renaming #workingDirectory to #userWorkingDirectory would be >> more clear? Assuming 1 image = 1 user? > > In Pharo 7: > > FileLocator workingDirectory = C getcwd() # same as R and most languages > FileLocator imageDirectory = the directory where the image is located > FileLocator vmDirectory = the directory where the vm is located I like the distinction of having all three. cheers -ben |
On 18/01/18 20:11, Ben Coman wrote: > On 18 January 2018 at 14:33, Alistair Grant <[hidden email]> wrote: >> Hi Hernán, >> >> On 18 January 2018 at 05:41, Hernán Morales Durand >> <[hidden email]> wrote: >>> Note that in R you can set the current working directory with setwd() >>> and this is very common in R scripts. >>> >>> I like the idea around #imageDirectory and #vmStartupDirectory or just >>> #vmDirectory. >>> And maybe renaming #workingDirectory to #userWorkingDirectory would be >>> more clear? Assuming 1 image = 1 user? >> In Pharo 7: >> >> FileLocator workingDirectory = C getcwd() # same as R and most languages >> FileLocator imageDirectory = the directory where the image is located >> FileLocator vmDirectory = the directory where the vm is located > I like the distinction of having all three. > > cheers -ben > > +1 Offray |
In reply to this post by Ben Coman
> On 19 Jan 2018, at 02:11, Ben Coman <[hidden email]> wrote: > > On 18 January 2018 at 14:33, Alistair Grant <[hidden email]> wrote: >> Hi Hernán, >> >> On 18 January 2018 at 05:41, Hernán Morales Durand >> <[hidden email]> wrote: >>> >>> Note that in R you can set the current working directory with setwd() >>> and this is very common in R scripts. >>> >>> I like the idea around #imageDirectory and #vmStartupDirectory or just >>> #vmDirectory. >>> And maybe renaming #workingDirectory to #userWorkingDirectory would be >>> more clear? Assuming 1 image = 1 user? >> >> In Pharo 7: >> >> FileLocator workingDirectory = C getcwd() # same as R and most languages >> FileLocator imageDirectory = the directory where the image is located >> FileLocator vmDirectory = the directory where the vm is located > > I like the distinction of having all three. yes… but I would like an idiom to make declarations easier. for example, you made './something’ asFileReference —> this is a cwd path '{image}/something’ asFileReference —> image path etc. because right now I have to do: FileLocator imageDirectory / ‘something' and it annoys me a bit (not that I cannot live with it, but… ) ;) Esteban > > cheers -ben > |
Free forum by Nabble | Edit this page |