From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id BE7417ED35 for ; Thu, 12 Jul 2012 18:47:11 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of david.mentre@gmail.com) identity=pra; client-ip=209.85.214.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="david.mentre@gmail.com"; x-sender="david.mentre@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of david.mentre@gmail.com designates 209.85.214.54 as permitted sender) identity=mailfrom; client-ip=209.85.214.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="david.mentre@gmail.com"; x-sender="david.mentre@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f54.google.com) identity=helo; client-ip=209.85.214.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="david.mentre@gmail.com"; x-sender="postmaster@mail-bk0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAAL+/k/RVdY2kGdsb2JhbABFuAIIIgEBAQEJCQ0HFAQjgiABAQEDARICLAE4AQMBCwEFBQs7HwMSAQUBHAYTIodcAwYGnxwJA48UhVInDYlIAQUMkTADjQ2ILY4pPoFUgiw X-IronPort-AV: E=Sophos;i="4.77,575,1336341600"; d="scan'208";a="166642256" Received: from mail-bk0-f54.google.com ([209.85.214.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Jul 2012 18:45:22 +0200 Received: by bkcje9 with SMTP id je9so3114550bkc.27 for ; Thu, 12 Jul 2012 09:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=o7iyzfpx59cAeJHvyiwNBe7gPe8wIzjDxuMreT1m+UI=; b=Rrx5892HHkucJTtb/hORthnQ6orQUkfacaevIiGqDYjEyJsMZS2s5hi+ZPtBPk3acx Z6w5EB3EkUX8bpE+v7GM0wvzjfz2vA4B9Ud9SEHTBnUfvTj1oYclJ5Y9OXmwGEVfkCww xZzP+rJ/LWpwMPbrLwtUoKOveGJY16coB9BXaeZ5rt+EOKyEovh4chKmhLxFeKtThc3K t+gCOEGqIyn6ofMWTTmZ9p7kxmsyjmYHw22DYvP8fvMHhVzvN5xIHR9SzGesiNnzwkOk WRMRJk9aZV08BALaDQvyqsdI6GQ6ugKafph6G/awFi4jhNPLiN2mXa26SoIBn9av9p8J WXvw== Received: by 10.204.148.83 with SMTP id o19mr26578402bkv.96.1342111521306; Thu, 12 Jul 2012 09:45:21 -0700 (PDT) MIME-Version: 1.0 Sender: david.mentre@gmail.com Received: by 10.204.129.213 with HTTP; Thu, 12 Jul 2012 09:44:51 -0700 (PDT) In-Reply-To: <4FFEFB0F.5080506@coherentgraphics.co.uk> References: <4FFECB57.9060900@coherentgraphics.co.uk> <4FFEFB0F.5080506@coherentgraphics.co.uk> From: David MENTRE Date: Thu, 12 Jul 2012 18:44:51 +0200 X-Google-Sender-Auth: KqrFWKJ79VhX6Ft9yy6AiqoL0j4 Message-ID: To: John Whitington Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Coherent Graphics Product Updates Hello, 2012/7/12 John Whitington : > 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