Re: [Caml-list] Coherent Graphics Product Updates

[Francois Berenger <berenger@riken.jp>]

On 07/13/2012 01:44 AM, David MENTRE wrote:
> Hello,
>
> 2012/7/12 John Whitington <john@coherentgraphics.co.uk>:
>> It's entirely one-way. Objective C calls OCaml. OCaml never calls Objective
>> C.
> [...]
>> Similarly, no complicated OCaml data structures cross the boundary - it's
>> all direct ints, floats, strings, and the occasional void*. The possibility
>> for programmer error in building big OCaml data structures directly in C
>> seems to outweigh the annoyance of a slightly flat interface, at least for
>> this particular application. FFI Masters may disagree :-)
>
> OK, thanks. I immediately thought at more complicated things (e.g. two
> processes with a protocol between them) and I did not thought at
> OCaml's C interface.

Can't you generate the bindings to C code automatically?

Aren't there tools for this?

>> The multiple PDF files representing different undo/redo states of a document
>> are held in memory in OCaml (with most of the data shared between them
>> automatically, of course). When the PDF is updated or undone/redone, it's
>> flattened to disk, and the PDFKit component in Cocoa picks it up and renders
>> it - surprisingly, this is quick enough - it's all in the memory cache
>> rather than the actual disk usually, of course.
>
> That's an interesting way to bypass simple FFI approach.
>
>> PDFKit (The cocoa PDF component) is only used for rendering - almost every
>> other piece of functionality is dealt with by CamlPDF via the FFI.
>
> Thank you for your detailed and quick answer,
> Best regards,
> david
>