Thanks, Jonas --
I'll give that a try and report back.
Bill
> On 04 Oct 2008, at 22:48, Jonas Maebe <[EMAIL PROTECTED]> wrote:
>
> You could try running
>
> sudo fs_usage -w yourapp
>
> to see what exactly is going on at the file system level. Or you can
> start your application and run "sudo fs
Marco --
If by "the two tests" you mean testing the FPC version vs. testing the
CodeWarrior version, then: yes, I'm pretty sure, since I'm running them
both on the same machine (a Powerbook G4 laptop running Mac OSX 10.4.11).
The tests are self-contained within that machine (the LISP code running
Hi, Danie --
I'm not sure if you saw my most recent post, where I described what I was
actually doing, in response to Jonas's concern that the LISP code might be
trying to read the FPC-created file before it had been closed.
I'm actually writing to a dummy file name (suffixed ".TMP"), then closin
Thanks, Jonas --
Actually, I dealt with that potential source of anomalies way back in the
original CodeWarrior version: the Pascal code opens and writes out to the
file under a different name than the one the LISP code is looking for.
Only after the file's been written and closed is it renamed so
I didn't describe the problem I was experiencing becasue it seemed
unlikely that anyone else would ever find themselves in this particular
bind. That, and it didn't seem germane to the question I was asking --
namely, what to include in the project so as to access Carbon file
routines from a comman
Hi,
I'm porting a rather larger CW app to FPC under MacOSX 10.4.11, and am
trying to work around some rather flaky behavior I'm seeing with FPC's
Turbo-based file i/o -- by dropping back to the old MacOS
FileManager routines.
Trouble is, the app I'm porting is a command-line utility, which I've
