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.
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.
By the way, you can also call primGetCurrentWorkingDirectory with 'OSProcess thisOSProcess getCwd'.
Dave
Another is our custom VM plugin (.bundle) file in the same directory cannot be found anymore. It works if I copy it into Resources directory; but it is inconvenient.
What are the suggested solutions for these problems? Thanks!
-- Yoshiki