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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 93E357F7AF for ; Sat, 26 Sep 2015 17:59:52 +0200 (CEST) IronPort-PHdr: 9a23:yD1bMBFdDWVRhwfytJsq0J1GYnF86YWxBRYc798ds5kLTJ75oM+wAkXT6L1XgUPTWs2DsrQf27aQ7vqrBzxIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/ni6bvodaNM01hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv+YJa6jxfrw5QLpEF3xmdjltvIy4/SXEGDGG4WYYGkkLkRcAVxLM6wz+Ur/+tyL7sqx23yzMbuPsSrVhRjSj86pyVRbyi29TKD447GzOl8Vqj4pEoBO9qgViypTXJoaPO6wtLevmYdoGSD8ZDY5qXCtbD9b5NtNXAg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=whitequark@whitequark.org; spf=Pass smtp.mailfrom=whitequark@whitequark.org; spf=None smtp.helo=postmaster@mail.whitequark.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBACUwAZW/31nOrBdg3jALoV5AoFbEAEBAQEBAQEBgQmCHYIHAQEBAwEjDwEFOgcQBAcJDwICJgICLCsGG4geDAm3QZQnAQEBBwIBGwSBIokpgSWCboIfB4JpgUMBBI1wiACBUINFh3aBU5YDg204K4IRHIFXO4lUAQEB X-IPAS-Result: A0CeBACUwAZW/31nOrBdg3jALoV5AoFbEAEBAQEBAQEBgQmCHYIHAQEBAwEjDwEFOgcQBAcJDwICJgICLCsGG4geDAm3QZQnAQEBBwIBGwSBIokpgSWCboIfB4JpgUMBBI1wiACBUINFh3aBU5YDg204K4IRHIFXO4lUAQEB X-IronPort-AV: E=Sophos;i="5.17,593,1437429600"; d="scan'208";a="179563313" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 26 Sep 2015 17:59:52 +0200 Received: by mail.whitequark.org (Postfix, from userid 33) id D4E4A112421; Sat, 26 Sep 2015 15:59:50 +0000 (UTC) To: Raoul Duke X-PHP-Originating-Script: 1000:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 26 Sep 2015 18:59:50 +0300 From: whitequark Cc: Gerd Stolpmann , OCaml In-Reply-To: References: <1443259698.4442.12.camel@e130.lan.sumadev.de> Message-ID: X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.1.0 Subject: Re: [Caml-list] whither portability? I will offer a few comments as the author of opam-android[1]. On 2015-09-26 15:48, Raoul Duke wrote: > Exciting to hear! Thank you and your contributors for this work. I > know there are ways people can be parochial, but I have never been > able to fathom how the core OCaml team can ignore mobile so actively, > it seems. It is to sigh, oy veh. No one is being parochial or "actively" ignoring mobile. The OCaml core team consists of unpaid volunteers. I suggest that next time, in place of a snide remark, you contribute some code and/or money. That being said... > > Throwing out random ideas as a potential some-day user of such a thing: > > * Getting anything working as simply as possible would be a nice first > step, even if it isn't the most performant. I.e. bytecode. It seems > Apple has loosened up on that a bit over the years? And I wonder if > LLVM bytecode would be no problem with them now. Both ocamlc and ocamlopt work for iOS and Android; there is not really a good reason to use the bytecode compiler for deployment to mobile. There is no such thing as "LLVM bytecode" and LLVM bitcode (sic) is merely an intermediate format for native executable code. Shipping LLVM bitcode offers no conceptual improvement over shipping machine code and in any case, there is neither an LLVM backend for ocamlopt nor much need for such a backend. > > * FFI will be essential. It is one thing to have 2+2 working on > mobile, it is another to be able to get any real app work done. (In > the past I have had some negative experiences with OCaml and FFI for > OpenGL so I am always a little worried about trying to reignite my > relationship with OCaml.) Definitely. ocaml-ctypes[2] in cstubs mode allows bidirectional integration of OCaml code with C code, i.e. OCaml can call into C and C can call into OCaml. Daniel Bünzli's tgls OpenGL bindings can be made to compile in cstubs mode, but this is not quite upstream yet[2]. > > * Ideally it has to integrate well with the platform toolchains, > including the preferred IDEs. E.g. if there's no good installer, if I > have to do a lot of work to build things, etc., then I'm way less > likely to even try to use it. I know that is work most people do not > like to do. I say that empirically. With opam-android, the workflow is exactly identical to building any regular OCaml project, with the difference that the final binary produced is a .o or .so file that you can use as any other C library in your Android project; the Android cross-toolchain is just another switch in opam. I don't know how it works for iOS but it is almost certainly possible to achieve the same level of convenience. [1]: https://github.com/whitequark/opam-android [2]: https://github.com/dbuenzli/tgls/pull/14 -- whitequark