Jump to page: 1 2 3
Thread overview
Cairo Deimos bindings
Apr 26, 2012
James Miller
Apr 26, 2012
Johannes Pfau
Apr 26, 2012
Andrej Mitrovic
Apr 26, 2012
David Nadlinger
Apr 26, 2012
Andrej Mitrovic
Apr 26, 2012
James Miller
Apr 26, 2012
Trass3r
Apr 26, 2012
James Miller
Apr 26, 2012
Trass3r
Apr 26, 2012
James Miller
Apr 26, 2012
Andrej Mitrovic
Apr 26, 2012
Andrej Mitrovic
Apr 27, 2012
Walter Bright
Apr 27, 2012
James Miller
Apr 27, 2012
Walter Bright
Apr 27, 2012
Dejan Lekic
Apr 27, 2012
James Miller
Apr 27, 2012
David Nadlinger
Apr 27, 2012
Marco Leise
Apr 27, 2012
Andrej Mitrovic
Apr 28, 2012
James Miller
April 26, 2012
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
April 26, 2012
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
April 26, 2012
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
>
April 26, 2012
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.
April 26, 2012
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
April 26, 2012
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
April 26, 2012
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
April 26, 2012
> 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.
April 26, 2012
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
April 26, 2012
> 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.
« First   ‹ Prev
1 2 3