caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Camlidl questions
@ 2007-10-26 20:36 Christopher L Conway
  2007-10-27  8:43 ` [Caml-list] " Daniel Bünzli
  0 siblings, 1 reply; 5+ messages in thread
From: Christopher L Conway @ 2007-10-26 20:36 UTC (permalink / raw)
  To: caml-list

I'm trying to write an interface to an existing C library using
Camlidl and I'm having trouble in just a few cases... The
documentation and examples only go so far...

The library has a function which returns a boolean and, if the result
is true, populates an array with a set of "witnesses." The original
function looks like:

int foo(T x, U** y, int* n)

where x is the input, *y will be the array of witnesses, and *n will
be the length of *y. The desired type of the OCaml binding is

foo : t -> bool * u array

for which I've tried the Camlidl declaration

boolean foo([in] T x, [out, size_is(*n), ref*] U** y, [ignore] int* n)

This does indeed generate the desired type, but the stub is wrong. It
tries to use *n to allocate the array _before_ calling foo in the C
library. Camlidl seemingly can't distinguish between size_is as a
pre-condition vs. a post-condition in this case.

In contrast, if a C function returns a pointer to an array and has the
size as an output parameter, Camlidl does the right thing. I.e.,

[size_is(*n)] U *bar([in] T x, [ignore] int* n)

generates a binding

bar : t -> u array

and the stub code allocates the array after calling bar in the C
library using *n, as expected.

Is it possible to accomplish this without writing my own C stub?

Note 1: It would be even better if the OCaml return type where something like:

type foo_ret = No | Yes of u array

Can Camlidl do this (again, without resorting to a hand-written stub)?

Note 2: It's always nice to have lists at the OCaml level... It would
be even better still (and this would apply to the inputs and outputs
of many functions in the library, even without the behavior of foo) if
the array could be transformed into a list... It wouldn't even be
inefficient, since the stub is already allocating and copying over the
entire array as it is. Can Camlidl do this?

Any insight is appreciated.

Thanks,
Chris


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Camlidl questions
  2007-10-26 20:36 Camlidl questions Christopher L Conway
@ 2007-10-27  8:43 ` Daniel Bünzli
  2007-10-27 16:45   ` Richard Jones
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Bünzli @ 2007-10-27  8:43 UTC (permalink / raw)
  To: Christopher L Conway; +Cc: caml-list


Le 26 oct. 07 à 22:36, Christopher L Conway a écrit :

> I'm trying to write an interface to an existing C library using  
> Camlidl and I'm having trouble in just a few cases...

I'd say don't use camlidl. It seems to be unsupported software. There  
is for example a bug the handling of records of floats only that I  
reported a long time ago but was lost in the bugtracker update. I  
guess it wasn't fixed.

Try to understand the caml-c interface (chap. 18 of the manual) and  
then use C pre-processor hacks to streamline the development of your  
bindings, have a look at lablgl to see what I mean by that.

Best,

Daniel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Camlidl questions
  2007-10-27  8:43 ` [Caml-list] " Daniel Bünzli
@ 2007-10-27 16:45   ` Richard Jones
  2007-10-27 23:27     ` Chris Conway
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Jones @ 2007-10-27 16:45 UTC (permalink / raw)
  To: Daniel Bünzli; +Cc: Christopher L Conway, caml-list

On Sat, Oct 27, 2007 at 10:43:46AM +0200, Daniel Bünzli wrote:
> Le 26 oct. 07 à 22:36, Christopher L Conway a écrit :
> >I'm trying to write an interface to an existing C library using  
> >Camlidl and I'm having trouble in just a few cases...
> 
> I'd say don't use camlidl. It seems to be unsupported software. There  
> is for example a bug the handling of records of floats only that I  
> reported a long time ago but was lost in the bugtracker update. I  
> guess it wasn't fixed.
> 
> Try to understand the caml-c interface (chap. 18 of the manual) and  
> then use C pre-processor hacks to streamline the development of your  
> bindings, have a look at lablgl to see what I mean by that.

Absolutely agreed.

While I think there is room for someone to _really_ tackle the issue
of building interfaces to C automatically (using something like CIL
and a bucket-load of meta-information about how the C library deals
with memory), until that day comes it's just much better to write the
bindings by hand.

I've used the native interface APIs for several languages including
Java, Perl and Python, but OCaml's is by far the easiest.  Well, maybe
apart from C++ :-)

Rich.

-- 
Richard Jones
Red Hat


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Camlidl questions
  2007-10-27 16:45   ` Richard Jones
@ 2007-10-27 23:27     ` Chris Conway
  2007-10-28 21:48       ` Richard Jones
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Conway @ 2007-10-27 23:27 UTC (permalink / raw)
  To: Richard Jones; +Cc: Daniel Bünzli, Christopher L Conway, caml-list

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1679 bytes --]

On Sat, 27 Oct 2007, Richard Jones wrote:
> On Sat, Oct 27, 2007 at 10:43:46AM +0200, Daniel Bünzli wrote:
>> Le 26 oct. 07 à 22:36, Christopher L Conway a écrit :
>>> I'm trying to write an interface to an existing C library using
>>> Camlidl and I'm having trouble in just a few cases...
>>
>> I'd say don't use camlidl. It seems to be unsupported software. There
>> is for example a bug the handling of records of floats only that I
>> reported a long time ago but was lost in the bugtracker update. I
>> guess it wasn't fixed.
>>
>> Try to understand the caml-c interface (chap. 18 of the manual) and
>> then use C pre-processor hacks to streamline the development of your
>> bindings, have a look at lablgl to see what I mean by that.
>
> Absolutely agreed.
>
> While I think there is room for someone to _really_ tackle the issue
> of building interfaces to C automatically (using something like CIL
> and a bucket-load of meta-information about how the C library deals
> with memory), until that day comes it's just much better to write the
> bindings by hand.
>
> I've used the native interface APIs for several languages including
> Java, Perl and Python, but OCaml's is by far the easiest.  Well, maybe
> apart from C++ :-)
>
> Rich.

I'm afraid I don't understand this position at all. With a few dozen, 
mostly obvious, annotations to the header files, I have covered 99% of the 
library's functionality, automatically generating several thousand lines 
of low-level boilerplate code. Leaving aside the possibility of known bugs 
in Camlidl that might never get fixed... why would I want to code this all 
by hand?

Regards,
Chris

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Camlidl questions
  2007-10-27 23:27     ` Chris Conway
@ 2007-10-28 21:48       ` Richard Jones
  0 siblings, 0 replies; 5+ messages in thread
From: Richard Jones @ 2007-10-28 21:48 UTC (permalink / raw)
  To: Chris Conway; +Cc: Daniel Bünzli, caml-list

On Sat, Oct 27, 2007 at 07:27:15PM -0400, Chris Conway wrote:
> I'm afraid I don't understand this position at all. With a few dozen, 
> mostly obvious, annotations to the header files, I have covered 99% of the 
> library's functionality, automatically generating several thousand lines 
> of low-level boilerplate code. Leaving aside the possibility of known bugs 
> in Camlidl that might never get fixed... why would I want to code this all 
> by hand?

Sorry, I was somehow confusing camlidl & SWIG.

Rich.

-- 
Richard Jones
Red Hat


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-10-28 21:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-26 20:36 Camlidl questions Christopher L Conway
2007-10-27  8:43 ` [Caml-list] " Daniel Bünzli
2007-10-27 16:45   ` Richard Jones
2007-10-27 23:27     ` Chris Conway
2007-10-28 21:48       ` Richard Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).