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