Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-09

Re: command-line+Carbon template

2 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

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 command-line app (thanks for answering that one, Jonas!).

But Felipe asked, so here goes --

I am porting a program from CodeWarrior Pascal under Mac OS 9 to FPC/Xcode under Mac OSX 10.4, and I've encountered an anomaly that seems to bear on FPC's (Turbo-Pascal-based) file i/o, as follows:

The program I'm porting needs to intercommunicate with a large piece of legacy LISP code (running under Windows 98) via a primitive file-exchange protocol. The way it works is: my Pascal code writes a file containing a query to a shared folder, then waits in a tight loop for the LISP to read and delete it and write a response-file to the same folder, which my code then reads and deletes, and so on. Embarrassingly dumb, I know, but I'm not in a position to upgrade the LISP code to a more modern IPC protocol. :(

Be all that as it may, this whole Rube Goldberg runs great when compiled under CodeWarrior using MPW file i/o routines. With FPC's Turbo routines, I'm seeing some strange "race conditions" that lead me to believe the FPC version of the program perhaps is not completely relinquishing its hold on a file even after it's been flushed and closed. Whatever the cause, the end result is that the file persists in the shared folder after the LISP code thinks it's deleted it, confusing matters in a big way.

I've been thinking that I might evade the problem if I dropped back to native Mac file i/o (StandardFile or equivalent). I can't go Carbon whole hog, because my app is supposed to be faceless and, in fact, cross-platform.

Under the circumstances, I despaired of constructing a simple code snippet that would illustrate the problem, so I just asked the key question regarding how to give a command-line (Terminal) app access to the Mac FileManager routines. Sorry for any confusion.

Bill

PS: In this context, "flaky" = erratic and incomprehensible. :)

Show quoted text 23 lines
------------------------------ I do not know what the word flaky means, but it would probably be better if you describe your problem with the standard pascal I/O in FPC so someone can help you. I have never had problems with it. And what is the turbo-based I/O? TStream? -- Felipe Monteiro de Carvalho ------------------------------ That works exactly the same as with using a C, Objective-C or C++ project in Xcode: just add Carbon.framework to your project (Project- >Add to Project... -> navigate to /System/Library/Frameworks -> select Carbon.framework -> click "Add". (note: *never* select frameworks from SDK's, but always in the regular system hierarchy; if you then tell Xcode to use a particular SDK, it will prepend all the regular system paths with the SDK paths). Jonas
Jonas Maebe
to Unknown author
Show quoted text 9 lines
Be all that as it may, this whole Rube Goldberg runs great when compiled under CodeWarrior using MPW file i/o routines. With FPC's Turbo routines, I'm seeing some strange "race conditions" that lead me to believe the FPC version of the program perhaps is not completely relinquishing its hold on a file even after it's been flushed and closed.

When you call close() on a file, it will be flushed and closed immediately. From what you described, it seems more likely to me that the FPC code is probably opening and reading the file before the LISP code has finished writing it (and/or vice versa), because FPC's standard I/O routines do not try to acquire exclusive access files (regardless of whether you open them for reading and/or writing).

The Carbon routines probably do check for exclusive access by default, so the LISP code will only open the file once the MW/FPC code is finished, and vice versa.

Jonas