Re: Cairo Deimos bindings
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?
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
Am Fri, 27 Apr 2012 13:26:49 +0200 schrieb David Nadlinger s...@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
Re: Cairo Deimos bindings
On 4/27/12, Marco Leise marco.le...@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
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 20:49:54 UTC, Andrej Mitrovic wrote: On 4/27/12, Marco Leise marco.le...@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
Cairo Deimos bindings
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
Re: Cairo Deimos bindings
Am Thu, 26 Apr 2012 10:28:52 +0200 schrieb James Miller ja...@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
Re: Cairo Deimos bindings
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 nos...@example.com wrote: Am Thu, 26 Apr 2012 10:28:52 +0200 schrieb James Miller ja...@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
Re: Cairo Deimos bindings
On 4/26/12, Andrej Mitrovic andrej.mitrov...@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.
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
On 4/26/12, David Nadlinger s...@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%93q=deimostype=Everythingrepo=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
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
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.
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
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.
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
On 4/27/12, Trass3r u...@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.
Re: Cairo Deimos bindings
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
Re: Cairo Deimos bindings
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/
Re: Cairo Deimos bindings
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
