Hi, Dave,
At Fri, 30 Sep 2011 23:47:16 -0400, David T. Lewis wrote:
On Fri, Sep 30, 2011 at 03:27:44PM -0700, Yoshiki Ohshima wrote:
At Wed, 28 Sep 2011 13:47:22 -0700, Eliot Miranda wrote:
...at?http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
CogVM binaries as per VMMaker.oscog-eem.128/r2496 Fix regression in object-as-method/cannot-interpret for single and polymorphic inline cache misses (lookup:for:methodAndErrorSelectorInto:). Fix formatting bugette in context printing.
This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
This probably is not an issue with the latest VM, and I now remember the discussion related to my question here:
http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-t...
but I'm not sure the current consensus is and let me ask it in the context of my problem.
So, the switch apparently happened sometime after 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I have been using for a project. When I try to switch to the latest version of VM, there are (at least) two things that has changed.
One is that
OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory
now returns '/'. I used to launch an external command by:
PipeableOSProcess command: './demo'.
it stopped working. Is this just a known issue, and I should just use longer interface to OSProcess with cwd explicitly specified?
I do not have a mac to test, but in case it may help:
The primGetCurrentWorkingDirectory method calls the C library function getcwd(), which answers the current working directory of the calling process (i.e. the process in which the VM is running). If the result is '/' then I suspect there is something about the way the VM is being launched that causes it to think it is running from the root directory, or perhaps a chroot() is being done.
Yes, as quoted in http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html, running the VM at '/' was a conscious decision. Sorry for not clearly asking a question. My question was that how people deal with this change, when the change has apparent drawback in a case such as this. (Say, you want to distribute your application as a single directory, the natural place to put an external executable is somewhere under the directory. But now cwd is '/', you need to supply the current directory.)
In my code, I already made a change so that instead of using #command:, I now call #command:environment:workingDir:input:output:error:errorPipelineStream:. from a convenience method. Perhaps just having a variation of #command: that invokes command in the image directory would be handy.
Unix systems also usually have a shell variable $PWD that points to the current working directory. You can read its value with 'OSProcess thisOSProcess environmentAt: #PWD'. On my system (Linux) this gives the same result as primGetCurrentWorkingDirectory, but possibly it will give the result you need on OS X.
$PWD is certainly the same as the VMs cwd (checked with lsof command). I get nil for environmentAt: #PWD.
By the way, you can also call primGetCurrentWorkingDirectory with 'OSProcess thisOSProcess getCwd'.
Ah, thanks!
-- Yoshiki