Converting the carbon headers has proven to be quite a task for me.  It seems
like it's easier to manually
create the extern declarations when I need them.  However, I think it would be
nice if all us MacOS
developers could correlate our efforts.  Could we start a dsource.org project?
We could check in
modifications as we add more function declarations.


P.S. Props to Anders for making the gdcmac packages.

-Sha

Shammah Chancellor wrote:

> Converting the carbon headers has proven to be quite a task for me. It seems like it's easier to manually create the extern declarations when I need them.

That's about the same conclusion that I came to, as well. :-P

Especially since any such import modules for D would still
have the Apple copyright from the headers, and thus not be
distributable to other developers - without legal troubles...

So I'm probably going to use an open source GUI framework
instead, myself. Upside of that is that it'll be portable ?
The problem with those, are that they are all written in C++.

> However, I think it would be nice if all us MacOS developers could correlate our efforts.  Could we start
> a dsource.org project? We could check in modifications as we add more function declarations.

Feel free to start such a project, if you have made any
larger efforts or other achievements you want to share... :-)
(let me know if you need hosting space at the gdcmac project)

I just did a simple Carbon Hello World, which I posted earlier.
(which was more done as a proof-of-concept, than a real project)
And I should put my import modules for SDL/GL/AL up somewhere too...

> P.S. Props to Anders for making the gdcmac packages.

Glad you like them, just wished it was easier to integrate
it with Xcode - but currently it is still stuck at writing
custom shell scripts for compiling and linking D programs...

And it still needs some better documentation, but I think I'll
just leave that to a book (if anyone ever cares to write one ?)
Unfortunately it seems like I will have no time for D this year.

--anders

In article <dcipi1$5no$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

>Especially since any such import modules for D would still have the Apple copyright from the headers, and thus not be distributable to other developers - without legal troubles...

The best solution would be something like what the MinGW team created for
Windows developers. Only some years of work, I guess... ;-)
Oh, and I already have a name for it: MinGM - Minimal GNU for Macintosh!
Now, who's gonna take up the work? ;-)

LOPI

In article <dcipi1$5no$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Shammah Chancellor wrote:
>
>> Converting the carbon headers has proven to be quite a task for me. It seems like it's easier to manually create the extern declarations when I need them.
>
>That's about the same conclusion that I came to, as well. :-P
>
>Especially since any such import modules for D would still have the Apple copyright from the headers, and thus not be distributable to other developers - without legal troubles...

I don't know why this would be the case?  There are carbon language bindings for
Perl, and python and
a few other languages.  They're able to distribute them fine.  There are even
carbon bindings for Ada
floating around.

>
>So I'm probably going to use an open source GUI framework instead, myself. Upside of that is that it'll be portable ? The problem with those, are that they are all written in C++.

Personally, I would like to see std.macosx.... in phobos eventually.  I want to
port MinWin over to
carbon.  I have an old C++ gui API i wrote (Very unfinished) called HotChocolate
(Har har.. ) which
might be helpful to people trying to get into D from Obj-C, to see how Carbon
stuff works.

>
>> However, I think it would be nice if all us MacOS
>> developers could correlate our efforts.  Could we start
>> a dsource.org project? We could check in
>> modifications as we add more function declarations.
>
>Feel free to start such a project, if you have made any larger efforts or other achievements you want to share... :-) (let me know if you need hosting space at the gdcmac project)
>
>I just did a simple Carbon Hello World, which I posted earlier. (which was more done as a proof-of-concept, than a real project) And I should put my import modules for SDL/GL/AL up somewhere too...

I wrote one that ran SysBeep() about a year ago :)  Had to manually link it with
Carbon framework on the
command line.  Your efforts have got me more interested in D.  Manually
compiling my own gdc and
then using emacs and makefiles kinda bored me.

>
>> P.S. Props to Anders for making the gdcmac packages.
>
>Glad you like them, just wished it was easier to integrate it with Xcode - but currently it is still stuck at writing custom shell scripts for compiling and linking D programs...
>
>And it still needs some better documentation, but I think I'll just leave that to a book (if anyone ever cares to write one ?) Unfortunately it seems like I will have no time for D this year.

One thing that would make it easier is if you put your HelloDWorld on
gdcmac.sourceforge.net.  When
you search gdcmac in google you get the sourceforge page first.  Which is almost
identical to another
page i found about it.  Save the fact that the non sourceforge one included the
template project.  I
couldn't get the custom build rules working properly for me.  (It was generating
the .o's, but they
weren't being linked together.)  Once I found your project I was able to use the
script you wrote, and
figure out where I went wrong.

>
>--anders

Shammah Chancellor wrote:

> I don't know why this would be the case? There are carbon language bindings for Perl, and python and a few other languages. They're able
> to distribute them fine. There are even carbon bindings for Ada
> floating around.

Maybe not. In fact, when you remind me I did see some Pascal versions
of the headers a while back (natural since it used to be all in Pascal)

Just leaves the lots-of-work factor then, for the Carbon framework :-)

>>And it still needs some better documentation, but I think I'll
>>just leave that to a book (if anyone ever cares to write one ?)
>>Unfortunately it seems like I will have no time for D this year.
> 
> One thing that would make it easier is if you put your HelloDWorld on
> gdcmac.sourceforge.net.  When you search gdcmac in google you get
> the sourceforge page first.  Which is almost identical to another page i found about it.  Save the fact that the non sourceforge one
> included the template project.  I couldn't get the custom build rules
> working properly for me.  (It was generating the .o's, but they weren't being linked together.)  Once I found your project I was able
> to use the script you wrote, and figure out where I went wrong.

Hmm, I think I did put the Xcode stuff back up on SourceForge ?

But you are right, I did take the Carbon things and sample project
out since I was rewriting them but never got around to finishing it...

Time to get the old ones off my home page and onto "gdcmac" then.

--anders

In article <dcipi1$5no$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Glad you like them, just wished it was easier to integrate it with Xcode - but currently it is still stuck at writing custom shell scripts for compiling and linking D programs...

I have Xcode integration sorted with a specification file in Xcode 2.1.

Though it can't calculate D import dependancies. I have added all relevant
options for release/debug/unit-
test etc... I've been using it for the past couple of hours seems fine.

I suspect Xcode will handle Cats and Dogs sleeping together... err I mean C and D files compiled together.

In article <dcl0e5$2eb0$1@digitaldaemon.com>, Alan West says...
>
>In article <dcipi1$5no$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>
>>Glad you like them, just wished it was easier to integrate it with Xcode - but currently it is still stuck at writing custom shell scripts for compiling and linking D programs...
>
>I have Xcode integration sorted with a specification file in Xcode 2.1.
>
>Though it can't calculate D import dependancies. I have added all relevant
>options for release/debug/unit-
>test etc... I've been using it for the past couple of hours seems fine.
>
>I suspect Xcode will handle Cats and Dogs sleeping together... err I mean C and D files compiled together.

You seem to have forgotten attach the file, sir.

:) Sha

Brad is going to add a project to dsource.org for us.  It'll be a learning
experience for me, I've never used
SVN.  Anybody know of a good MacOS X client?

-Sha

Shammah Chancellor wrote:

> Brad is going to add a project to dsource.org for us.  It'll be a learning
> experience for me, I've never used SVN. Anybody know of a good MacOS X client?

A command line client is available from: "fink install svn"
I also think later versions of Xcode adds support for SVN ?

Since I'm more "traditional" (read: old), I'm using CVS...
And Make, for that matter, which is also hopelessly "out". ;-)

--anders

Shammah Chancellor wrote:
> You seem to have forgotten attach the file, sir.

I was trying to sort out an xcbuildrules file to include as well, but it doesn't seem to pick that up in the Specifications directory. Therefore you still need to create a build rule for D source files for each target.