Re: [Caml-list] Coherent Graphics Product Updates

[David MENTRE <dmentre@linux-france.org>]

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.

> 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