[Pharo-project] Working directory
When OSProcess is integrated, we will have two different concepts of the working directory: fsPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/' asFileReference. [ FileSystem disk changeDirectory: fsPwd ] on: Exception do: []. FileSystem disk workingDirectory = fsPwd. "true" ospPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/workspace'. OSProcess thisOSProcess chDir: ospPwd. FileSystem disk workingDirectory = ospPwd. "false" (PipeableOSProcess command: 'pwd') output trimRight = ospPwd "true" -- View this message in context: http://forum.world.st/Working-directory-tp4631865.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
we should integrate the chdir fix to osprocess into jenkins vms On 25 May 2012 22:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
When OSProcess is integrated, we will have two different concepts of the working directory: Â fsPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/' asFileReference. Â [ FileSystem disk changeDirectory: fsPwd ] on: Exception do: []. Â FileSystem disk workingDirectory = fsPwd. "true"
 ospPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/workspace'.  OSProcess thisOSProcess chDir: ospPwd.  FileSystem disk workingDirectory = ospPwd. "false"  (PipeableOSProcess command: 'pwd') output trimRight = ospPwd "true"
-- View this message in context: http://forum.world.st/Working-directory-tp4631865.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
+1 Thanks Igor. Dave On Sat, May 26, 2012 at 02:13:34AM +0200, Igor Stasenko wrote:
we should integrate the chdir fix to osprocess into jenkins vms
On 25 May 2012 22:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
When OSProcess is integrated, we will have two different concepts of the working directory: ??fsPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/' asFileReference. ??[ FileSystem disk changeDirectory: fsPwd ] on: Exception do: []. ??FileSystem disk workingDirectory = fsPwd. "true"
??ospPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/workspace'. ??OSProcess thisOSProcess chDir: ospPwd. ??FileSystem disk workingDirectory = ospPwd. "false" ??(PipeableOSProcess command: 'pwd') output trimRight = ospPwd "true"
-- View this message in context: http://forum.world.st/Working-directory-tp4631865.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 26 May 2012 02:33, David T. Lewis <lewis@mail.msen.com> wrote:
+1
Thanks Igor.
yeah.. one of the problems, that we're running Pharo image tests on successfull build. But these tests are not including the tests for "optional" components, like OSProcess.. Because if we ship VM with PluginA, PluginB, apparently we should run tests which testing those plugins, to check that they are functional, even if they are not used by default into Pharo image(s).
Dave
On Sat, May 26, 2012 at 02:13:34AM +0200, Igor Stasenko wrote:
we should integrate the chdir fix to osprocess into jenkins vms
On 25 May 2012 22:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
When OSProcess is integrated, we will have two different concepts of the working directory: ??fsPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/' asFileReference. ??[ FileSystem disk changeDirectory: fsPwd ] on: Exception do: []. ??FileSystem disk workingDirectory = fsPwd. "true"
??ospPwd := '/Volumes/Sean''s Universe/sean/.jenkins/jobs/Dynabook/workspace'. ??OSProcess thisOSProcess chDir: ospPwd. ??FileSystem disk workingDirectory = ospPwd. "false" ??(PipeableOSProcess command: 'pwd') output trimRight = ospPwd "true"
-- View this message in context: http://forum.world.st/Working-directory-tp4631865.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
we should integrate the chdir fix to osprocess into jenkins vms
Oops, I took the error handler off the wrong call...
 OSProcess thisOSProcess chDir: ospPwd. should have been  [ OSProcess thisOSProcess chDir: ospPwd ] on: Exception do: [].
And, the question still stands as to whether OSP and FS should have two separate concepts of the working directory... -- View this message in context: http://forum.world.st/Working-directory-tp4631865p4631888.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Fri, May 25, 2012 at 05:59:17PM -0700, Sean P. DeNigris wrote:
Igor Stasenko wrote
we should integrate the chdir fix to osprocess into jenkins vms
Oops, I took the error handler off the wrong call...
??OSProcess thisOSProcess chDir: ospPwd. should have been ??[ OSProcess thisOSProcess chDir: ospPwd ] on: Exception do: [].
And, the question still stands as to whether OSP and FS should have two separate concepts of the working directory...
Yes. They probably represent different concepts, so it is OK if they are implemented differently. What is a "working directory"? And for that matter, what is a "directory"? These are concepts and metaphors that have been used in various ways by some (but not all) operating systems, and that do not automatically have a well defined meaning independent of those metaphors and operating systems. There is really no such thing as "current working directory" in Squeak/Pharo, so if you want to create such a concept you are free to do so in any way you please. With respect to OSProcess, it is intentionally maintained separately from Squeak/Pharo and IMO should remain that way. It provides access to the external platform, which is useful. But the metaphorical desktop objects (files, desktops, file folders, etc) are artifacts of various operating systems and computing traditions, and there is no "right way" to represent the concept of a current working directory. OSProcess attempts to report CWD from the point of view of the external platform, but that does not make it right. It is perfectly legitimate for FS to define a concept of current working directory, and hopefully this would have a clear definition in terms of how it is to be used in the image. But there is no reason to expect that this definition of "current working directory" will be the same as the "current working directory" as understood by Unix, Windows, Android, or other computing platforms, some of which may not have any concept of "directory" at all. CommandShell also has a concept of current working directory, and this is also different from the CWD of OSProcess. CommandShell attempts to behave more like a shell, and when running on Windows it keeps track of the current volume (C: drive, D: drive, etc) in addition to the current working directory path associated with each volume. Again, then is platform dependent, and there is no particular reason to expect this concept of "current working directory" to make sense outside of the operating system that it is emulating. Dave
On 2012-05-26, at 06:41, David T. Lewis wrote:
On Fri, May 25, 2012 at 05:59:17PM -0700, Sean P. DeNigris wrote:
Igor Stasenko wrote
we should integrate the chdir fix to osprocess into jenkins vms
Oops, I took the error handler off the wrong call...
??OSProcess thisOSProcess chDir: ospPwd. should have been ??[ OSProcess thisOSProcess chDir: ospPwd ] on: Exception do: [].
And, the question still stands as to whether OSP and FS should have two separate concepts of the working directory...
Yes. They probably represent different concepts, so it is OK if they are implemented differently.
I don't think so... if we can unify them we should! And in this case I would say its simply a matter of calling the right c-function? And I would even say by solely relying on the OS' working directory implementation you can avoid some nasty issues we have with the working directory right now. For instance on OSX the whole thing doesn't behave that nicely.
What is a "working directory"? And for that matter, what is a "directory"? These are concepts and metaphors that have been used in various ways by some (but not all) operating systems, and that do not automatically have a well defined meaning independent of those metaphors and operating systems. There is really no such thing as "current working directory" in Squeak/Pharo, so if you want to create such a concept you are free to do so in any way you please.
well on all unix there is a very clear precise definition of it "getcwd()"! and on all decent platforms there's a more or less clear notion of what is a file and what is a directory? Talking about Pharo, which platforms do we target? - Linux - OS X - Win maybe I am wrong, but I think we could assume a common denominator here? (Using python and ruby yields to the same results AFAIK)
With respect to OSProcess, it is intentionally maintained separately from Squeak/Pharo and IMO should remain that way. It provides access to the external platform, which is useful. But the metaphorical desktop objects (files, desktops, file folders, etc) are artifacts of various operating systems and computing traditions, and there is no "right way" to represent the concept of a current working directory. OSProcess attempts to report CWD from the point of view of the external platform, but that does not make it right.
Indeed specific locations are to be modeled differently, see FileLocator for that reason.
It is perfectly legitimate for FS to define a concept of current working directory, and hopefully this would have a clear definition in terms of how it is to be used in the image. But there is no reason to expect that this definition of "current working directory" will be the same as the "current working directory" as understood by Unix, Windows, Android, or other computing platforms, some of which may not have any concept of "directory" at all.
CommandShell also has a concept of current working directory, and this is also different from the CWD of OSProcess. CommandShell attempts to behave more like a shell, and when running on Windows it keeps track of the current volume (C: drive, D: drive, etc) in addition to the current working directory path associated with each volume. Again, then is platform dependent, and there is no particular reason to expect this concept of "current working directory" to make sense outside of the operating system that it is emulating.
Dave
On Sat, May 26, 2012 at 10:44:15AM +0200, Camillo Bruni wrote:
On 2012-05-26, at 06:41, David T. Lewis wrote:
What is a "working directory"? And for that matter, what is a "directory"? These are concepts and metaphors that have been used in various ways by some (but not all) operating systems, and that do not automatically have a well defined meaning independent of those metaphors and operating systems. There is really no such thing as "current working directory" in Squeak/Pharo, so if you want to create such a concept you are free to do so in any way you please.
well on all unix there is a very clear precise definition of it "getcwd()"! and on all decent platforms there's a more or less clear notion of what is a file and what is a directory?
Talking about Pharo, which platforms do we target? - Linux - OS X - Win
You're right about that of course. I guess I just like to remind people that unix is not the only good operating system that has ever been invented, and that ideas like "files" are just part of a metaphor that was invented decades ago to help people relate their computer to something they already understood (a physical desk with a desktop and with file cabinets filled with folders that contained paper documents). With cell phones, tablets, and solid state storage it is quite possible that the ancient "desk with file cabinet" metaphors will become obsolete, so it is good to keep an open mind.
maybe I am wrong, but I think we could assume a common denominator here? (Using python and ruby yields to the same results AFAIK)
I don't know. But OS X may well be an example of an environment that presents a file system view to the user that is different from the file system view at the unix file system or unix shell level. And Windows 7 appears to be trying to imitate OS X in that regard. If you implement a concept of "current working directory" in the image, you are free to define it in whatever way makes good sense. But there is no fundamental reason why you need to use a definition that matches the unix file system view (as reported by OSProcess). You might instead prefer to use a definition that matches what the OS X user expects to see in the finder, and maybe that is a different thing (I am not an OS X user, so apologies if I am getting this wrong). Dave
On 26 May 2012 16:55, David T. Lewis <lewis@mail.msen.com> wrote:
On Sat, May 26, 2012 at 10:44:15AM +0200, Camillo Bruni wrote:
On 2012-05-26, at 06:41, David T. Lewis wrote:
What is a "working directory"? And for that matter, what is a "directory"? These are concepts and metaphors that have been used in various ways by some (but not all) operating systems, and that do not automatically have a well defined meaning independent of those metaphors and operating systems. There is really no such thing as "current working directory" in Squeak/Pharo, so if you want to create such a concept you are free to do so in any way you please.
well on all unix there is a very clear precise definition of it "getcwd()"! and on all decent platforms there's a more or less clear notion of what is a file and what is a directory?
Talking about Pharo, which platforms do we target? - Linux - OS X - Win
You're right about that of course.
I guess I just like to remind people that unix is not the only good operating system that has ever been invented, and that ideas like "files" are just part of a metaphor that was invented decades ago to help people relate their computer to something they already understood (a physical desk with a desktop and with file cabinets filled with folders that contained paper documents).
With cell phones, tablets, and solid state storage it is quite possible that the ancient "desk with file cabinet" metaphors will become obsolete, so it is good to keep an open mind.
I can hardly see what else can replace a tree/graph-like data organization.
maybe I am wrong, but I think we could assume a common denominator here? (Using python and ruby yields to the same results AFAIK)
I don't know. But OS X may well be an example of an environment that presents a file system view to the user that is different from the file system view at the unix file system or unix shell level. And Windows 7 appears to be trying to imitate OS X in that regard. If you implement a concept of "current working directory" in the image, you are free to define it in whatever way makes good sense. But there is no fundamental reason why you need to use a definition that matches the unix file system view (as reported by OSProcess). You might instead prefer to use a definition that matches what the OS X user expects to see in the finder, and maybe that is a different thing (I am not an OS X user, so apologies if I am getting this wrong).
the 'working directory' concept matters for consoles & console-based shells. So, of course it is beneficial to have same behavior/definition of working directory as in shell. For those who using different graphical-rich file system "shells" like 'finder' on os-x or 'explorer' on windows, this concept means nothing, as well as things like stdin/stdout/pipes and many other. So why we need to worry about it?
Dave
-- Best regards, Igor Stasenko.
On 26/05/2012 23:08, Igor Stasenko wrote:
I can hardly see what else can replace a tree/graph-like data organization.
Something entirely unexpected that no one saw coming, no doubt :) e.g. what does the "current working directory" mean in a system with orthogonal persistence?
On 27 May 2012 15:04, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 26/05/2012 23:08, Igor Stasenko wrote:
I can hardly see what else can replace a tree/graph-like data organization.
Something entirely unexpected that no one saw coming, no doubt :)
e.g. what does the "current working directory" mean in a system with orthogonal persistence?
probably nothing. and i don't care. but if we're working in ecosystem like today, we should make it work right. -- Best regards, Igor Stasenko.
I can hardly see what else can replace a tree/graph-like data organization.
Something entirely unexpected that no one saw coming, no doubt :)
e.g. what does the "current working directory" mean in a system with orthogonal persistence?
probably nothing. and i don't care. but if we're working in ecosystem like today, we should make it work right.
+ 100 make it right and adapt if needed :)
-- Best regards, Igor Stasenko.
participants (6)
-
Camillo Bruni -
David T. Lewis -
Douglas Brebner -
Igor Stasenko -
Sean P. DeNigris -
Stéphane Ducasse