[Caml-list] Coherent Graphics Product Updates

[Caml-list] Coherent Graphics Product Updates

[John Whitington]

Hi,

1. A new version of our PDF editor for OS X (PDF manipulation in OCaml, 
interface in Objective C):

http://www.coherentpdf.com/proview.html

Should be on the Apple App Store within the next couple of weeks.


2. The latest versions of our PDF command line tools from last year 
(/almost/ pure OCaml):

http://www.coherentpdf.com/


3. Not really OCaml-related, but I wrote a book about PDF:

http://shop.oreilly.com/product/0636920021483.do

Also available in Portuguese!

http://novatec.com.br/livros/pdf/


There should be new releases of the command line tools and CamlPDF later 
in the year. Our OCaml codebase just exceeded 100,000 lines - not that 
that's necessarily a good sign :-)

Thanks,

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

Re: [Caml-list] Coherent Graphics Product Updates

[David MENTRE]

Hello,

2012/7/12 John Whitington <john@coherentgraphics.co.uk>:
> 1. A new version of our PDF editor for OS X (PDF manipulation in OCaml,
> interface in Objective C):

An architectural question: how your backend OCaml part and your
Objective C GUI are communicating between each other?

Sincerely yours,
david

Re: [Caml-list] Coherent Graphics Product Updates

[John Whitington]

Hi,

David MENTRE wrote:
> Hello,
>
> 2012/7/12 John Whitington<john@coherentgraphics.co.uk>:
>> 1. A new version of our PDF editor for OS X (PDF manipulation in OCaml,
>> interface in Objective C):
>
> An architectural question: how your backend OCaml part and your
> Objective C GUI are communicating between each other?

It's entirely one-way. Objective C calls OCaml. OCaml never calls 
Objective C.

Here's the makefile for the library - this method is straight out of the 
OCaml manual.

mklib:
	ocamlc.opt cpdfstrftime.mli;
	ocamlopt.opt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa 
camlpdf.cmxa cpdfstrftime.ml;
	ocamlc.opt cpdf.mli;
	ocamlopt.opt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa 
camlpdf.cmxa cpdf.ml;
	ocamlc.opt cpdflib.mli;
	ocamlopt.opt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa 
camlpdf.cmxa cpdf.cmx cpdflib.ml;
	ocamlc.opt cpdflibwrapper.c;
	ocamlopt.opt -output-obj -o cpdflib.o unix.cmxa bigarray.cmxa 
cgutil.cmxa camlpdf.cmxa cpdfstrftime.cmx cpdf.cmx cpdflib.cmx;
	cp /usr/local/lib/ocaml/libasmrun.a cpdflib.a;
	ar r cpdflib.a cpdflib.o cpdflibwrapper.o

test:   zlibstubs.o cpdflib.a cpdflibc-test.c
  	cc -c cpdflibc-test.c -o cpdflibc-test.o; \
         cc -L'/usr/local/lib/ocaml' -lunix -lbigarray -lz -o test 
cpdflibc-test.o zlibstubs.o cpdflib.a


For example, for a single function 'fromFile' to load a PDF from disc:

cpdflib.ml (Wraps up functionality from our command line tools imperatively)
==============================================================

(* Read a file, no attempt at decryption, unless it's the blank user 
password. *)
let fromFile filename =
   try
     new_pdf (Pdfread.pdf_of_file (Some "") None filename)
   with
     e -> handle_error "fromFile" e; err_int

let _ = Callback.register "fromFile" fromFile



cpdflibwrapper.c (the foreign function interface)
=================================================

int fromFile(char* filename)
{
   CAMLparam0 ();
   CAMLlocal3(fromfile_v, filename_v, result_v);
   fromfile_v = *caml_named_value("fromFile");
   filename_v = caml_copy_string(filename);
   result_v = caml_callback(fromfile_v, filename_v);
   updateLastError ();
   CAMLreturnT(int, Int_val(result_v));
}



PDFDocument.m (Objective C)
===========================

...
clearError ();
const char* in_c = [[[self fileURL] path] UTF8String];
int pdf = fromFile((char*) in_c);
if (lastError != 0) return NO;
...



Functions like handle_error, updateLastError(), clearError() etc. 
provide a simple flat system for dealing with errors without exceptions 
crossing the C/OCaml boundary. This is very old fashioned, but seems to 
work. C code checks the error code after each callback to Ocaml, and can 
extract extra information about the error.

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 :-)

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.

PDFKit (The cocoa PDF component) is only used for rendering - almost 
every other piece of functionality is dealt with by CamlPDF via the FFI.

Thanks,

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

Re: [Caml-list] Coherent Graphics Product Updates

[David MENTRE]

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

Re: [Caml-list] Coherent Graphics Product Updates

[Francois Berenger]

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
>