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 [email protected] http://felix-lang.org _______________________________________________ Ctypes mailing list [email protected] http://lists.ocaml.org/listinfo/ctypes
