Yesterday, I wrote a small test program and linked it against Apple's "Carbon framework". To my surprise, it worked. So, against all expectations, the current compiler is able to link to Apple "dylibs" and Apple "frameworks". The compiler produces ".o" code and the Apple-"ld" linker takes care of the rest.
This implies, that I am loosing interest in the Apple-patched GCC compiler. Apple writes "we're not even sure what all of them [the compiler changes] are, because the existing compiler has many undocumented changes inherited from 10 years of NeXT and Apple hacking, and nobody knows what some of them are for." This doesn't inspire confidence.
Besides, important changes (like precompiled header support) are now getting integrated into mainline FSF. So, I am slowly considering it an advantage (rather than a disadvantage) that the current port is based on mainline FSF-GCC 3.2.1. And isn't it fun to read in officlal Apple docs for some compiler option "Not supported on Mac OS X" where the GPC compiler actually does ....
As a further experiment, I compiled hello.pas into hello.o and tried to link it with "mwld", the command-line version of the MetroWerks CodeWarrior linker. Again, to my surprise, it worked. I added "hello.o" to a CodeWarrior Project and disassembled it there. It worked. So, maybe some day there will be a GNU Pascal compiler plug-in CodeWarrior (not a promise, just an idea) ....
Regards,
Adriaan van Os
Dear Adrian,
does this mean that your version for MacOS of GPC is already working all right? Are you able to compile units, and to link external libraries, too? I'm not an expert of Mac OS, so I don't know what Carbon is, but, does it perhaps mean you can call also graphics libraries?
Silvio a Beccara
| Yesterday, I wrote a small test program and linked it against Apple's | "Carbon framework". To my surprise, it worked. So, against all | expectations, the current compiler is able to link to Apple "dylibs" | and Apple "frameworks". The compiler produces ".o" code and the | Apple-"ld" linker takes care of the rest. | | This implies, that I am loosing interest in the Apple-patched GCC | compiler. Apple writes "we're not even sure what all of them [the | compiler changes] are, because the existing compiler has many | undocumented changes inherited from 10 years of NeXT and Apple hacking, | and nobody knows what some of them are for." This doesn't inspire | confidence. | | Besides, important changes (like precompiled header support) are now | getting integrated into mainline FSF. So, I am slowly considering it an | advantage (rather than a disadvantage) that the current port is based | on mainline FSF-GCC 3.2.1. And isn't it fun to read in officlal Apple | docs for some compiler option "Not supported on Mac OS X" where the GPC | compiler actually does .... | | As a further experiment, I compiled hello.pas into hello.o and tried to | link it with "mwld", the command-line version of the MetroWerks | CodeWarrior linker. Again, to my surprise, it worked. I added "hello.o" | to a CodeWarrior Project and disassembled it there. It worked. So, | maybe some day there will be a GNU Pascal compiler plug-in CodeWarrior | (not a promise, just an idea) .... | | Regards, | | Adriaan van Os
Silvio a Beccara wrote:
does this mean that your version for MacOS of GPC is already working all right? Are you able to compile units, and to link external libraries, too? I'm not an expert of Mac OS, so I don't know what Carbon is, but, does it perhaps mean you can call also graphics libraries?
There hasn't been much experience with GPC on Mac OS X up to now, but to answer your question, to the best of my knowledge, yes. Provided, of course, that Pascal "headers" have been written for these libraries (or that you write them yourself). What graphics libraries do you mean ? gtk? I know there is a public bèta of X11 for Mac OS X, but that is all I know about it.
Regards,
Adriaan van Os
If GPC is basically compatable with the C objects used by OS X (and since OS X is built with GCC, it should be, correct?), you should be able to access the native Quartz library, I would suspect.
--- Adriaan van Os gpc@microbizz.nl wrote:
Silvio a Beccara wrote:
does this mean that your version for MacOS of GPC is already
working
all right? Are you able to compile units, and to link external
libraries,
too? I'm not an expert of Mac OS, so I don't know what Carbon is, but,
does
it perhaps mean you can call also graphics libraries?
There hasn't been much experience with GPC on Mac OS X up to now, but
to answer your question, to the best of my knowledge, yes. Provided, of course, that Pascal "headers" have been written for these libraries (or that you write them yourself). What graphics libraries do you mean ? gtk? I know there is a public bèta of X11 for Mac OS X, but that is all I know about it.
Regards,
Adriaan van Os
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Frank D. Engel, Jr. wrote:
If GPC is basically compatable with the C objects used by OS X (and since OS X is built with GCC, it should be, correct?), you should be able to access the native Quartz library, I would suspect.
Unfortunately, Quartz is NeXT Step technology, based on Objective-C, not C. To use it, you would have to write "flattened C" interfaces in C and then link them with the Pascal code. See the recent mailing list item "can I use C++ units in GPC projects?". In the long run, I think, it will be inevitable that (somehow) GPC interfaces directly with C++ and Objective-C objects (and not only on Mac OS X).
OpenGL on the other hand is C and should present no problem. I don't know if there are GPC "headers" for OpenGL (and if anybody is interested).
Is there, by the way a general tool to translate C headers to GPC ? Jonas Maebe, of the Free Pascal project, pointed me to h2pas.
My priorities for the moment are: Apple Project Builder integration, Carbon Pascal Interfaces, some compiler and compatibility issues and maybe CodeWarrior integration. I will be quite happy if that has been done.
Regards,
Adriaan van Os
Unfortunately, Quartz is NeXT Step technology, based on Objective-C, not C. To use it, you would have to write "flattened C" interfaces in C
Actually, Apple provides a "flattened" C interface to Quartz as part of OS X, for use with Carbon (which is in C, not Objective C):
http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Quartz2...
The NeXTStep interfaces (in the Objective C language) are referred to as Cocoa now (formerly called OpenStep, etc.; see the GNUStep project at www.gnustep.org for more details).
Quartz can be accessed natively from either one.
it will be inevitable that (somehow) GPC interfaces directly with C++
and Objective-C objects (and not only on Mac OS X).
Linking with C++ is a possibility, but the semantics of Objective-C objects are VASTLY different from those of C++ objects, and it would be very difficult to try to support them in a Pascal compiler without extending the language for that purpose (Objective-Pascal?)
Even Apple's "Objective C++", which allows C++ and Objective C code to be used together in the same source file, does not integrate C++ and Objective C objects: they are treated as independent entities in the same language (Apple provides this in order to allow use of legacy C++ libraries, such the KHTML component of KDE, from Objective C programs).
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Frank D. Engel, Jr. wrote:
Unfortunately, Quartz is NeXT Step technology, based on Objective-C, not C. To use it, you would have to write "flattened C" interfaces in C
Actually, Apple provides a "flattened" C interface to Quartz as part of OS X, for use with Carbon (which is in C, not Objective C):
Anybody on the list with serious plans to use Quartz with GPC ?
Regards,
Adriaan van Os
On Wed, Feb 05, 2003 at 09:39:46PM +0100, Adriaan van Os wrote:
Anybody on the list with serious plans to use Quartz with GPC ?
No, but it would be interesting to use GRX (http://www.gnu.de/software/grx/) and SDL (http://www.libsdl.org/, http://www.gnu-pascal.de/contrib/eike/) with MacOS and GPC.
Actually, I do not own a Mac, so I cannot help.
Eike
I am interested in the graph unit and therefore gave grx a short try.
After some problems I started with: ./configure --target=X11 --enable-gpc
Then a problem showed up related to bigendian-littleendian. The file byteorder.h was missing in my sys directory. I found one deep down in the sources of gcc and used it by symlinking it. The next error came with grx20.h (which to my understanding is the first file to be processed): "Your system is not supported" I found the position and added according defines so that it assumes unix and X11. But this still didn't do the job and I got completely lost in all the files and defines and I don't know what. So, I finally gave up on it.
If you can get this going again, I would appreciate it. BTW, I own a Mac, as you might guess, but that wouldn't help you much, wouldn't it.?
On Thursday, Feb 6, 2003, at 10:24 pm (Europe/Berlin), Eike Lange wrote:
On Wed, Feb 05, 2003 at 09:39:46PM +0100, Adriaan van Os wrote:
Anybody on the list with serious plans to use Quartz with GPC ?
No, but it would be interesting to use GRX (http://www.gnu.de/software/grx/) and SDL (http://www.libsdl.org/, http://www.gnu-pascal.de/contrib/eike/) with MacOS and GPC.
Actually, I do not own a Mac, so I cannot help.
Eike
Dr. Karl-Michael Schindler Fachbereich Physik Martin-Luther-Univerisität Halle-Wittenberg D-06099 Halle/Saale
Tel.: ++49 (9) 345-55 25563
On Thu, Feb 06, 2003 at 01:50:02PM +0100, Karl-Michael Schindler wrote: [Lots of probs with MacOSX and GRX]
That was why I asked.
If you can get this going again, I would appreciate it. BTW, I own a Mac, as you might guess, but that wouldn't help you much, wouldn't it.?
Is your Mac OS-X capable? I'd be happy, if you could donate me your Mac (its just for GPC, GRX and playing Galactica ;-)
Eike
Karl-Michael Schindler wrote:
I am interested in the graph unit and therefore gave grx a short try.
After some problems I started with: ./configure --target=X11 --enable-gpc
Then a problem showed up related to bigendian-littleendian. The file byteorder.h was missing in my sys directory. I found one deep down in the sources of gcc and used it by symlinking it. The next error came with grx20.h (which to my understanding is the first file to be processed): "Your system is not supported" I found the position and added according defines so that it assumes unix and X11. But this still didn't do the job and I got completely lost in all the files and defines and I don't know what. So, I finally gave up on it.
Since these issues are more related to GRX than to GPC, you might rather want to ask on the GRX mailing list grx@gnu.de.
Frank
Not owning a Mac is one of the two realistic reasons for not using Quartz.
The other is mine: my Macs are too old to run OS X (all are pre-G3, with not enough RAM).
If I *did* have access to OS X, I would love to get native bindings to do Mac GUI programming with Pascal. Particularly with Aqua on the scene...
Right now, most of my GUI programming is limited to Java, which is much better than C. After looking at Apple's docs, though, Carbon doesn't look too bad, and the native speeds, with a Pascal environment...
It should not be difficult to write headers for Quartz, and for other Carbon features. It should just be a matter of writing unit interfaces, and figuring out which libraries to {$L} in them.
--- Eike Lange eike.lange@uni-essen.de wrote:
On Wed, Feb 05, 2003 at 09:39:46PM +0100, Adriaan van Os wrote:
Anybody on the list with serious plans to use Quartz with GPC ?
No, but it would be interesting to use GRX (http://www.gnu.de/software/grx/) and SDL (http://www.libsdl.org/, http://www.gnu-pascal.de/contrib/eike/) with MacOS and GPC.
Actually, I do not own a Mac, so I cannot help.
Eike
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
All of Apple's PInterfaces have been ported to GNU Pascal ! They can be downloaded from <www.microbizz.nl/gpc.html>.
Special thanks to Peter N. Lewis, who did the bulk of the work, and to Frank Heckenbach for providing the needed compiler options.
---
Frank D. Engel, Jr. wrote:
Unfortunately, Quartz is NeXT Step technology, based on Objective-C, not C. To use it, you would have to write "flattened C" interfaces in C
Actually, Apple provides a "flattened" C interface to Quartz as part of OS X, for use with Carbon (which is in C, not Objective C):
Quartz is part of the ported PInterfaces.
---
Frank Heckenbach wrote:
Peter N Lewis wrote:
One alternative is to change from unit "uses" to include files (which the Mac interfaces support anyway for reasons I've never understood), and just make a single really really big unit including all the interfaces. However that would be quite large and I don't know how happy GPC will be with a single unit with 300,000 lines in it, or how slow it will be for users to use it once the .gpi has been created.
300000 lines sounds very much. It's more than on my Linux system the total of all headers of the system, X11 various libraries etc.
This doesn't mean that GPC will necessarily fail on such a large unit (I haven't tried this, except for pathetic cases). If there are no O(n^2) cases anymore, it might work, but it might take a lot of memory ...
Included in the ported PInterfaces is GPCMacOS.pas, a unit that combines all other units into one big file. By leaving out unsupported technologies, we got it down from 300000 lines to 160000 lines. It compiles in just a few seconds. Amazing !
Regards,
Adriaan van Os
Adriaan van Os wrote:
Special thanks to Peter N. Lewis, who did the bulk of the work, and to Frank Heckenbach for providing the needed compiler options.
BTW, `local maximum-field-alignment' will work in the next release. I've just implemented it.
Included in the ported PInterfaces is GPCMacOS.pas, a unit that combines all other units into one big file. By leaving out unsupported technologies, we got it down from 300000 lines to 160000 lines. It compiles in just a few seconds. Amazing !
Good to hear so. Generally, compiling interfaces should not take too long (unless there's another "O(n^2)" or similar case we've missed). What takes most of the time usually is the code generation, especially with optimizations.
Frank
-
Adriaan van Os -
Eike Lange -
Frank D. Engel, Jr. -
Frank Heckenbach -
Karl-Michael Schindler -
Silvio a Beccara