[ocaml-ctypes] Help with strings

[john skaller]

BTW: Just though I’d say, Ctypes is a pretty nice library.
Well done! There’s no such thing as a perfect foreign interface
to C, but Ctypes handles much of it reasonably well.
Indeed, even the “domestic” interface to C (using C from C
code) is pretty messy.

>> I have another question: what’s the best way to bind an “enum”?
>> If the codes are sequential is there a builtin way to map the enum
>> into an Ocaml variant?
> 
> Ctypes provides two functions for this:
> 
>   'constant' retrieves the value of a compile-time constant
> (enumeration constant, #define value, etc.)
>   http://ocamllabs.io/ocaml-ctypes/Cstubs.Types.TYPE.html#VALconstant
> 
>   'enum' builds a 'typ' value from a mapping between constants and OCaml values
>   http://ocamllabs.io/ocaml-ctypes/Cstubs.Types.TYPE.html#VALenum

Ah, thanks, I missed that.

Hmm. What does it mean when it says “the size and alignment are retrieved”??
The only way to do that would be to generate C code and measure it.

So this is Cstubs which IS used that way. But its a multi-step process I do not
wish to use.  At least for me at this stage .. too much magic:

https://www.youtube.com/watch?v=cV5mmi7BBMY

Looking at the yaml example, jbuilder is used with a ppx to do this at
during Ocaml compilation, is that correct?


> 
> Ctypes_type.TYPE is an abstract interface to type descriptions.  The
> Ctypes module gives a default implementation of the interface.  The
> interface is also used elsewhere, though; in particular, it's used for
> describing C types whose layout is retrieved from C:
> 
>    https://github.com/ocamllabs/ocaml-ctypes/blob/0.13.1/src/cstubs/cstubs.mli

Ah, ok, that makes sense.

> 
> For example, you can bind a struct using the 'structure' and 'field'
> values in the TYPE interface:
> 
>   let s = structure "s"
>   let x  = field s "x" int
>   ....
> 
> If you use the implementations of 'structure' and 'field in the Ctypes
> module then the struct layout is computed using an implementation that
> computes offsets using the alignment information for each type.  But
> if you use the implementations of 'structure' and 'field' from the
> Cstubs module then the layout information is retrieved by generating C
> code that's run through a C compiler.  The interface (i.e. TYPE) is
> the same in both cases, but it's useful to have different
> implementations of that interface.

Again, worth adding this description somewhere in the docs.
Not sure where though, it doesn’t fit into the “ocamldoc” generated
pages, more into an “overall design” doc.

Hmm. How can I contribute easily. Its too early for me to actually
write docs. However I could create an issue with copies of your
email comments for someone to integrate.

Also the Q&A style here might suit Stackoverflow?


> 
>> Current rules say Ocaml strings are immutable, use bytes instead.
>> However, if several threads are running, normally Ocaml is using
>> a global lock to serialise them. However the lock is normally
>> released when calling C code. That would not be safe in this
>> case, using ocaml_string, so presumably in this case the lock
>> is not released. Is that correct?
> 
> Yes, that's correct.  Ctypes supports releasing the lock (via the
> ~release_runtime_lock argument in Foreign.foreign, or via the
> concurrency policy in Cstubs), but the lock isn’t released by default.

Ah. That’s important info. Hmm. It is possible the client will be
using the binding which is of a high performance specialised
file transfer/analysis code with Jane St Async and might expect
operations to run “in the background” using a future. The C library
uses a thread pool, for example. I suspect this means the lock
would have to be released. Also  .. when .. or should that be “if?”
multi-core arrives it will create a big mess. (Especially for 
JS/Async :)

—
john skaller
skaller at users.sourceforge.net
http://felix-lang.org