On 2011-10-17 04:02, Walter Bright wrote:
> Brad and I were talking about some D code that needed openssl support,
> when we ran into the same old problem:
>
> No D files corresponding to the openssl C .h files.
>
> It's not that these are a big problem to create, it's just that they are
> not done, and it tends to turn off people from using D. D is binary API
> compatible with C, but only with a corresponding D import file. This,
> out of the box, makes D *harder* to use than C.

I'm working on a Clang based tool for automatically converting C header files to D modules.

-- 
/Jacob Carlborg

That sounds good.
Now D projects will have a mother and a father.
Phobos is the mother, which is always there for you and is the first
one you'll go to if you need help :-)
Diemos is the father, which is the backbone of your software family,
who you rely on to do all the hard work for you. :-)

It's generally a good idea to separate our own code from an external
one, which we provide support for.
And if the "remote modules" proposal gets implemented, there would be
no problems with using Diemos if it won't get included in DMD package.

On Mon, Oct 17, 2011 at 7:55 AM, Walter Bright <newshound2@digitalmars.com> wrote:
> On 10/16/2011 8:17 PM, Vladimir Panteleev wrote:
>>
>> I think the name's fine. I don't see "<4-letter word> is already taken" as
>> a
>> valid argument, considering the huge number of users. There's a GitHub
>> user
>> called "phobos" and one called "tools", etc.
>>
>> Also, I'm pretty sure the D standard library is named after Mars's moon,
>> considering that D was originally named "Mars Programming Language" (after
>> the
>> company name, "Digital Mars").
>
> I thought maybe Diemos.
>
>

> Unless CAPI is trademarked, I think we're in good shape.

when i hear of CAPI i instantly think of this:

http://www.capi.org/pages/home.php

Yeah. Diemos is much better, IMO.

On Mon, Oct 17, 2011 at 12:30 PM, Mirko Pilger <pilger@cymotec.de> wrote:
>> Unless CAPI is trademarked, I think we're in good shape.
>
> when i hear of CAPI i instantly think of this:
>
> http://www.capi.org/pages/home.php
>
>

On Oct 16, 2011, at 7:02 PM, Walter Bright wrote:
> 
> The CAPI Manifesto
> ------------------
> 
> CAPI is a collection of C header files to publicly available C libraries
> and their translations to D. The idea is that if, in C, to interface to a library
> one would write:
> 
>   #include "foo.h"
> 
> then the corresponding D code would look like:
> 
>   import foo;

If the C header file has a name that is a D keyword, an underscore will be appended to the D module name.  If a C type name matches a C function name (stat), the type name will have a "_t" appended.

There's also the occasional issue of something that doesn't translate into D.  As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like "$2003" that are the versions which should be called on newer versions of the OS.  I'm still not sure of the best way to handle this, since D doesn't have macros.

Am 17.10.2011, 10:20 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>:

> That sounds good.
> Now D projects will have a mother and a father.
> Phobos is the mother, which is always there for you and is the first
> one you'll go to if you need help :-)
> Diemos is the father, which is the backbone of your software family,
> who you rely on to do all the hard work for you. :-)
>
> It's generally a good idea to separate our own code from an external
> one, which we provide support for.
> And if the "remote modules" proposal gets implemented, there would be
> no problems with using Diemos if it won't get included in DMD package.
>
> On Mon, Oct 17, 2011 at 7:55 AM, Walter Bright
> <newshound2@digitalmars.com> wrote:
>> On 10/16/2011 8:17 PM, Vladimir Panteleev wrote:
>>>
>>> I think the name's fine. I don't see "<4-letter word> is already taken" as
>>> a
>>> valid argument, considering the huge number of users. There's a GitHub
>>> user
>>> called "phobos" and one called "tools", etc.
>>>
>>> Also, I'm pretty sure the D standard library is named after Mars's moon,
>>> considering that D was originally named "Mars Programming Language" (after
>>> the
>>> company name, "Digital Mars").
>>
>> I thought maybe Diemos.

Deimos, people, its Deimos >.<

> I'm working on a Clang based tool for automatically converting C header files to D modules.

Great! Does it work yet?

On 2011-10-17 13:27, Steve Teale wrote:
>> I'm working on a Clang based tool for automatically converting C header
>> files to D modules.
>
> Great! Does it work yet?

Well, yes. Some parts of it. I have mostly focused on converting Objective-C headers. I have also started to rewrite the tool to use libclang instead of embed it straight into clang.

https://github.com/jacob-carlborg/clang
https://github.com/jacob-carlborg/dstep
-- 
/Jacob Carlborg

On 2011-10-17 10:21:45 +0000, Sean Kelly <sean@invisibleduck.org> said:

> On Oct 16, 2011, at 7:02 PM, Walter Bright wrote:
>> 
>> The CAPI Manifesto
>> ------------------
>> 
>> CAPI is a collection of C header files to publicly available C
> libraries
>> and their translations to D. The idea is that if, in C, to interface
> to a library
>> one would write:
>> 
>> #include "foo.h"
>> 
>> then the corresponding D code would look like:
>> 
>> import foo;
> 
> If the C header file has a name that is a D keyword, an underscore will
> be appended to the D module name.  If a C type name matches a C function
> name (stat), the type name will have a "_t" appended.

Hum, but _t in C stands for typedef. Wouldn't it be better to just append an underscore like for module names, that'd make only one rule to remember.


> There's also the occasional issue of something that doesn't translate
> into D.  As one slightly weird example, some of the the Posix routines
> in OSX have alternates with odd suffixes like "$2003" that are the
> versions which should be called on newer versions of the OS.  I'm still
> not sure of the best way to handle this, since D doesn't have macros.

I think what D needs to handle that is some pragma to manually specify the mangled name of a given function. Why would you need macros?


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-10-17 14:01, Michel Fortin wrote:
> On 2011-10-17 10:21:45 +0000, Sean Kelly <sean@invisibleduck.org> said:
>
>> On Oct 16, 2011, at 7:02 PM, Walter Bright wrote:
>>>
>>> The CAPI Manifesto
>>> ------------------
>>>
>>> CAPI is a collection of C header files to publicly available C
>> libraries
>>> and their translations to D. The idea is that if, in C, to interface
>> to a library
>>> one would write:
>>>
>>> #include "foo.h"
>>>
>>> then the corresponding D code would look like:
>>>
>>> import foo;
>>
>> If the C header file has a name that is a D keyword, an underscore will
>> be appended to the D module name. If a C type name matches a C function
>> name (stat), the type name will have a "_t" appended.
>
> Hum, but _t in C stands for typedef. Wouldn't it be better to just
> append an underscore like for module names, that'd make only one rule to
> remember.
>
>
>> There's also the occasional issue of something that doesn't translate
>> into D. As one slightly weird example, some of the the Posix routines
>> in OSX have alternates with odd suffixes like "$2003" that are the
>> versions which should be called on newer versions of the OS. I'm still
>> not sure of the best way to handle this, since D doesn't have macros.
>
> I think what D needs to handle that is some pragma to manually specify
> the mangled name of a given function. Why would you need macros?

Perhaps the macro is used to determine if "foo" or "foo$2003" is supposed to be called, based on some condition.

-- 
/Jacob Carlborg