www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cairo Deimos bindings

reply "James Miller" <james aatch.net> writes:
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
Apr 26 2012
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 26 Apr 2012 10:28:52 +0200
schrieb "James Miller" <james aatch.net>:

 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

Sounds like you already finished most of the bindings, but this could still be useful: https://github.com/jpf91/cairoD/tree/master/src/cairo/c
Apr 26 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Is there really a need to write it manually? All I had to do to use
the C library directly is call HTOD on the headers. Otherwise I use
CairoD.

On 4/26/12, Johannes Pfau <nospam example.com> wrote:
 Am Thu, 26 Apr 2012 10:28:52 +0200
 schrieb "James Miller" <james aatch.net>:

 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

Sounds like you already finished most of the bindings, but this could still be useful: https://github.com/jpf91/cairoD/tree/master/src/cairo/c

Apr 26 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/26/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Is there really a need to write it manually? All I had to do to use
 the C library directly is call HTOD on the headers. Otherwise I use
 CairoD.

Sorry for the wrong quote and text above quote, it was meant for OP.
Apr 26 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 26 April 2012 at 18:15:49 UTC, Andrej Mitrovic wrote:
 Is there really a need to write it manually? All I had to do to 
 use
 the C library directly is call HTOD on the headers. Otherwise I 
 use
 CairoD.

I'd say that usable htod generated headers still are a welcome addition to Deimos. David
Apr 26 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/26/12, David Nadlinger <see klickverbot.at> wrote:
 On Thursday, 26 April 2012 at 18:15:49 UTC, Andrej Mitrovic wrote:
 Is there really a need to write it manually? All I had to do to
 use
 the C library directly is call HTOD on the headers. Otherwise I
 use
 CairoD.

I'd say that usable htod generated headers still are a welcome addition to Deimos.

Somewhat related: Deimos doesn't seem to show up on github search: https://github.com/search?utf8=%E2%9C%93&q=deimos&type=Everything&repo=&langOverride=&start_value=1 I think the link to it should be put in the Community section, right below the Github link. The link is also here but very hard to spot imo: http://dlang.org/interfaceToC.html
Apr 26 2012
prev sibling next sibling parent "James Miller" <james aatch.net> writes:
On Thursday, 26 April 2012 at 18:20:01 UTC, David Nadlinger wrote:
 On Thursday, 26 April 2012 at 18:15:49 UTC, Andrej Mitrovic 
 wrote:
 Is there really a need to write it manually? All I had to do 
 to use
 the C library directly is call HTOD on the headers. Otherwise 
 I use
 CairoD.

I'd say that usable htod generated headers still are a welcome addition to Deimos. David

On top of that htod doesn't work on linux AFAIK. Also there are alot of header files missing from that, probably due to people not realising that not all installations install all the headers. I have the headers for the following surfaces: beos, cogl, directfb, drm, gl, os2, pdf, ps, qt, quartz, quartz-image, script, skia, svg, tee, vg, wind32, xcb, xlib and xml. There are also the extra headers like the core cairo, gobject support, hardware-specific definitions and so on. I am also slightly altering some of the code (in a well-documented manner) to reflect the difference between the usage of similar constructs in C. So, un-namespacing enums because you access the values as TypeName.Member, rather than just Member, as in C. Also replacing ifdef blocks with conditional compilation so I can replicate, in D, similar error messages to the C headers. There is alot that is difficult to do with automated tools, and it would be nice if this was properly complete, I plan on actually writing a proper install for this so your installed D bindings reflect the available C functions. -- James Miller
Apr 26 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 I'd say that usable htod generated headers still are a welcome addition  
 to Deimos.

 David

Even using some regex's is better than htod. It drops const, removes or messes up the comments etc.
Apr 26 2012
prev sibling next sibling parent "James Miller" <james aatch.net> writes:
On Thursday, 26 April 2012 at 22:45:01 UTC, Trass3r wrote:
 I'd say that usable htod generated headers still are a welcome 
 addition to Deimos.

 David

Even using some regex's is better than htod. It drops const, removes or messes up the comments etc.

There are also many things that should be changed in a binding to make it more D compatible, without affecting the C binding. Many C libraries define their own bool type, but D has a bool type that can be used just as easily, also making it easier to write D using native types. Lots of C code has extraneous typedefs that are only there to strip out struct and union keywords, so they can be rewritten. 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, which can be very bloated when converting heavily-namespaced code into D, because accessing the member CAIRO_STATUS_NO_MEMORY from the enum cario_status_t is fine in C, and neccessary because of the lack of modules, but the same in D is cario_status_t.CAIRO_STATUS_NO_MEMORY, which is very verbose. Consider that this is one of the shorter enums in cairo, then it becomes a problem. Sometimes code will rely on specific, extra, headers to determine what to do, further complicating bindings, especially when you need to check for certain functionality. htod is not a useful tool, especially if you want to do any sort of cross-platform, robust binding, manual binding is really the only way to do it properly and properly reflect the original binding and api of the library. It doesn't take that long, I did the binding for the 3000 line cairo.h file in about 3 hours, through judicious use of regex replaces and macros (I love Vim). -- James Miller
Apr 26 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 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.
 htod is not a useful tool, especially if you want to do any sort of  
 cross-platform, robust binding, manual binding is really the only way to  
 do it properly and properly reflect the original binding and api of the  
 library.

 It doesn't take that long, I did the binding for the 3000 line cairo.h  
 file in about 3 hours, through judicious use of regex replaces and  
 macros (I love Vim).

Exactly.
Apr 26 2012
prev sibling next sibling parent "James Miller" <james aatch.net> writes:
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
Apr 26 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Apr 26 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Apr 26 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
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

 description

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


https://github.com/D-Programming-Deimos/cairo
Apr 26 2012
prev sibling next sibling parent "James Miller" <james aatch.net> writes:
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

 description

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

Apr 26 2012
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
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?
Apr 27 2012
prev sibling next sibling parent "James Miller" <james aatch.net> writes:
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
Apr 27 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Apr 27 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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=20
 intended.

It depends on how minor the changes are, but generally please=20 refrain from making =C2=BBcosmetic=C2=AB changes to the C API. Deimos=20 bindings should be the verbatim headers translated to D, and just=20 that (this also means that importing them never requires an=20 additional compilation unit to be linked in) =E2=80=93 anything else is=20 better left to wrapper projects. =20 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 Dei= mos coding standard. --=20 Marco
Apr 27 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Apr 27 2012
prev sibling parent "James Miller" <james aatch.net> writes:
On Friday, 27 April 2012 at 20:49:54 UTC, Andrej Mitrovic wrote:
 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

I'm going for the second one, due mostly to the fact that if I'm going to change the enum to fit in with D, I might make it fit in with D style-wise. The difference in style should help to make it obvious to spot. Also, most functions would get covered by a wrapper, but there is little use to wrapping enums, so it is worthwhile making it nice to work with in "normal" D code. -- James Miller
Apr 27 2012