On Thursday, 26 April 2012 at 23:28:19 UTC, Trass3r wrote:
>> enums cause issues because the C enum:
>>
>>    enum Status {
>>       STATUS_SUCCESS
>>    }
>>
>> has type enum Status and the members are access like STATUS_SUCCESS. The same enum in D is
>>
>>    enum Status {
>>       STATUS_SUCCESS
>>    }
>>
>> has type Status and the members are accessed using Status.STATUS_SUCCESS
>
> //! bring named enum members into current scope
> string flattenNamedEnum(EnumType)()
> if (is (EnumType == enum))
> {
> 	string s = "";
> 	foreach (i, e; __traits(allMembers, EnumType))
> 	{
> 		s ~= "alias " ~ EnumType.stringof ~ "." ~ __traits(allMembers, EnumType)[i] ~ " " ~ __traits(allMembers, EnumType)[i] ~ ";\n";
> 	}
>
> 	return s;
> }
>
> I proposed 'extern(C) enum' to get rid of all those manual aliases but as always nothing happened.
>
> Exactly.

I like that, its cool, but I figured just doing a minor rewrite
of the enum would suffice. Its not that hard since Vim has a
block select, and cairo has some pretty consistent naming that
makes doing macros easy for them, the last step is just to check
that everything gets renamed properly.

--
James Miller

On 4/27/12, Trass3r <un@known.com> wrote:
> //! bring named enum members into current scope
> string flattenNamedEnum(EnumType)()
> if (is (EnumType == enum))
> {
> 	string s = "";
> 	foreach (i, e; __traits(allMembers, EnumType))
> 	{
> 		s ~= "alias " ~ EnumType.stringof ~ "." ~ __traits(allMembers,
> EnumType)[i] ~ " " ~ __traits(allMembers, EnumType)[i] ~ ";\n";
> 	}
>
> 	return s;
> }

I used something similar for a custom DLL symbol loader. I defined all extern(C) function pointers inside of a struct, then mixed in the loader code for each function by iterating all fields of the struct, and then used a "flattenName" type template to make all the function pointers global.

On 4/26/2012 1:28 AM, James Miller wrote:
> I am currently writing D bindings for Cairo for submission into Deimos, could
> somebody please make the repository so I can fork it?

I need:

library file name
description
home page url for the library

On Friday, 27 April 2012 at 01:45:20 UTC, Walter Bright wrote:
> On 4/26/2012 1:28 AM, James Miller wrote:
>> I am currently writing D bindings for Cairo for submission into Deimos, could
>> somebody please make the repository so I can fork it?
>
> I need:
>
> library file name
cairo (that is it)
> description
Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL, BeOS, OS/2, and DirectFB.

Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).

(From the web page)
> home page url for the library
http://www.cairographics.org/

On 4/26/2012 7:02 PM, James Miller wrote:
> On Friday, 27 April 2012 at 01:45:20 UTC, Walter Bright wrote:
>> On 4/26/2012 1:28 AM, James Miller wrote:
>>> I am currently writing D bindings for Cairo for submission into Deimos, could
>>> somebody please make the repository so I can fork it?
>>
>> I need:
>>
>> library file name
> cairo (that is it)
>> description
> Cairo is a 2D graphics library with support for multiple output devices.
> Currently supported output targets include the X Window System (via both Xlib
> and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output.
> Experimental backends include OpenGL, BeOS, OS/2, and DirectFB.
>
> Cairo is designed to produce consistent output on all output media while taking
> advantage of display hardware acceleration when available (eg. through the X
> Render Extension).
>
> (From the web page)
>> home page url for the library
> http://www.cairographics.org/


https://github.com/D-Programming-Deimos/cairo

James Miller wrote:

> I am currently writing D bindings for Cairo for submission into Deimos, could somebody please make the repository so I can fork it?
> 
> Thanks
> 
> --
> James Miller

Is it a binding, or a wrapper?

On Friday, 27 April 2012 at 09:50:21 UTC, Dejan Lekic wrote:
> James Miller wrote:
>
>> I am currently writing D bindings for Cairo for submission into
>> Deimos, could somebody please make the repository so I can fork
>> it?
>> 
>> Thanks
>> 
>> --
>> James Miller
>
> Is it a binding, or a wrapper?

It is a binding. There are some very minor cosmetic changes that
will be detailed, but otherwise you can just copy-paste a C
example into D, make it D-compatible and it will work as intended.

--
James Miller

On Friday, 27 April 2012 at 11:09:41 UTC, James Miller wrote:
> It is a binding. There are some very minor cosmetic changes that
> will be detailed, but otherwise you can just copy-paste a C
> example into D, make it D-compatible and it will work as intended.

It depends on how minor the changes are, but generally please refrain from making »cosmetic« changes to the C API. Deimos bindings should be the verbatim headers translated to D, and just that (this also means that importing them never requires an additional compilation unit to be linked in) – anything else is better left to wrapper projects.

David

Am Fri, 27 Apr 2012 13:26:49 +0200
schrieb "David Nadlinger" <see@klickverbot.at>:

> On Friday, 27 April 2012 at 11:09:41 UTC, James Miller wrote:
> > It is a binding. There are some very minor cosmetic changes that will be detailed, but otherwise you can just copy-paste a C example into D, make it D-compatible and it will work as intended.
> 
> It depends on how minor the changes are, but generally please refrain from making »cosmetic« changes to the C API. Deimos bindings should be the verbatim headers translated to D, and just that (this also means that importing them never requires an additional compilation unit to be linked in) – anything else is better left to wrapper projects.
> 
> David

I think it is understood and he was referring to renaming the enum members, for which you have to write different code when using them in D anyway:

In C:
STATUS_SUCCESS

In D unmodified:
cairo_status_t.STATUS_SUCCESS

In D with cosmetic changes:
cairo_status_t.SUCCESS

It doesn't change the semantics or add code. It could just as well be a Deimos coding standard.

-- 
Marco

On 4/27/12, Marco Leise <Marco.Leise@gmx.de> wrote:
> In C:
> STATUS_SUCCESS
>
> In D unmodified:
> cairo_status_t.STATUS_SUCCESS
>
> In D with cosmetic changes:
> cairo_status_t.SUCCESS

cairo_status_t.SUCCESS is like going halfway there but stopping. It looks rather ugly imo. I think you either want the existing C names, or names that *fully* fit the D coding style. So maybe the choice should be between this:

cairo_status_t.STATUS_SUCCESS

and this:

CairoStatus.Success