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 740DC7EE49 for ; Thu, 19 Sep 2013 22:57:45 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of krismicinski@gmail.com) identity=pra; client-ip=209.85.214.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="krismicinski@gmail.com"; x-sender="krismicinski@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of krismicinski@gmail.com designates 209.85.214.172 as permitted sender) identity=mailfrom; client-ip=209.85.214.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="krismicinski@gmail.com"; x-sender="krismicinski@gmail.com"; 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-ob0-f172.google.com) identity=helo; client-ip=209.85.214.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="krismicinski@gmail.com"; x-sender="postmaster@mail-ob0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDAHlkO1LRVdaslGdsb2JhbABbgz9ShGqqHoldiEaBGggWDgEBAQEHCwsJEiqCJQEBBAFAARsdAQMBCwYFCw0uIQEBEQEFARwGE4dwAQMJBgybe4xRgweEFwoZJw1kiH0BBQyMb4JsB4QeA5YTgWmBL4sTg0oYKYRoIA X-IPAS-Result: AlwDAHlkO1LRVdaslGdsb2JhbABbgz9ShGqqHoldiEaBGggWDgEBAQEHCwsJEiqCJQEBBAFAARsdAQMBCwYFCw0uIQEBEQEFARwGE4dwAQMJBgybe4xRgweEFwoZJw1kiH0BBQyMb4JsB4QeA5YTgWmBL4sTg0oYKYRoIA X-IronPort-AV: E=Sophos;i="4.90,939,1371074400"; d="scan'208";a="33593007" Received: from mail-ob0-f172.google.com ([209.85.214.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Sep 2013 22:57:43 +0200 Received: by mail-ob0-f172.google.com with SMTP id gq1so10824687obb.31 for ; Thu, 19 Sep 2013 13:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6PaezHvMGtJ/pEcOgxvPBA6QHQmcEc02zs52rFKF5Qc=; b=XZGds2cK7EY+fcVkRr9W1dXSS2Jm0DZTsN2tXiq++qTpFw/I0d9fxtuSagzvmHGtqt PLEgGhNfDoY5OWdQmaywLhSoAI8tJO2BkqxmHADvDM8CjZAKpqxr2mxT8iVT6wiFOyQx DEkhaljg4Rl6CeurUM4Lpc8BM1W5Lp5XLcZIuMgb/d0CLE3eW7yuWlySbZ13Vg8Hs7U5 6Ggsk9XtudAyUII4Owf8K8+/Arqc3Van31FOvv+Q3CRZCPgNGr22YHLC6lgN6JRTXS/X MjCPJrQSY65cxJPrhOLyBsEZCv6O+MmnB4H0bmDe05DlrJ/nsKgXuQjL3rWF1md60qU0 Aqqw== MIME-Version: 1.0 X-Received: by 10.182.227.136 with SMTP id sa8mr2680787obc.39.1379624263176; Thu, 19 Sep 2013 13:57:43 -0700 (PDT) Received: by 10.182.96.34 with HTTP; Thu, 19 Sep 2013 13:57:43 -0700 (PDT) In-Reply-To: References: <036501ceb3e5$bcd7b920$36872b60$@ffconsultancy.com> <87bo3pqy9o.fsf@golf.niidar.ru> Date: Thu, 19 Sep 2013 16:57:43 -0400 Message-ID: From: Kristopher Micinski To: Alexandre Pilkiewicz Cc: "forum@x9c.fr" , Ivan Gotovchits , Jon Harrop , Caml List Content-Type: multipart/alternative; boundary=001a11c3035021a5bc04e6c2cea7 Subject: Re: [Caml-list] OCaml on Android --001a11c3035021a5bc04e6c2cea7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, so this is what happens if you want to just run an ocaml binary on your Android device. If you actually want to do anything android related at all (other than running a binary in the shell, treating your device like it's a linux computer) then you have to run inside a VM, so you can actually talk to the GUI, SDK, etc... Kris On Thu, Sep 19, 2013 at 12:53 PM, Alexandre Pilkiewicz < alexandre.pilkiewicz@polytechnique.org> wrote: > http://gallium.inria.fr/blog/ocaml-on-a-nexus-7/ > > > On Thu, Sep 19, 2013 at 11:18 AM, Kristopher Micinski < > krismicinski@gmail.com> wrote: > >> >> >> >> On Thu, Sep 19, 2013 at 2:19 AM, forum@x9c.fr wrote: >> >>> >>> Le 19 sept. 2013 =E0 06:35, Kristopher Micinski a =E9crit : >>> >>> > With a little bit of hacking it'd probably work, but I'm not sure of >>> the status of ocaml-java and haven't looked into the implementation >>> details. Since ocaml-java outputs class files (afaik) you'd have to so= rt >>> of hack the android build pipeline yourself, but that wouldn't be the h= ard >>> part: all the tools are there. The harder part is that the Android SDK= is >>> very Java oriented, and it just feels awkward as hell to use in OCaml e= ven >>> if you were to write a thin wrapper around the SDK. >>> >>> In theory, you are right that it wouldn't be hard. >>> In practice, the problem is that OCaml-Java emits classes >>> for Java 1.7 while (to the best of my knowledge) Android >>> only accepts Java 1.6 classes. As far as I know, there is no >>> other pending problem. >>> >>> From this point, the question would be: is it better to wait >>> for Android to update to Java 1.7 (or even 1.8...), or to >>> modify OCaml-Java? Honestly, I would need quite a bit >>> of encouragement to modify OCaml-Java in this direction... >>> >>> >> Yes, that would be a deal breaker. That fell under the technical points >> of ocaml-java with which I wasn't familiar. >> >> Regarding interaction with the classes of the Android SDK, >>> one may be interested in the typer extension allowing to >>> manipulate Java instances from pure OCaml code: >>> http://ocamljava.x9c.fr/preview/javaext.html >>> The main potential problem with this approach is that the >>> extension currently allows only to implement interfaces, but >>> not to extend classes. It may be a problem if for example the >>> event system of Android is based on abstract classes. >>> Another problem may be the "linking", i. e. the way Android >>> expects to execute an application: is it a bare main method, >>> or is there a need to implement/extend a given interface/class? >>> >> >> Yes, it does rely on extending an abstract class. This does, in fact, >> permeate the framework. >> >> kris >> >> > > --001a11c3035021a5bc04e6c2cea7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, so this is what happens if you want to just run an oc= aml binary on your Android device. =A0If you actually want to do anything a= ndroid related at all (other than running a binary in the shell, treating y= our device like it's a linux computer) then you have to run inside a VM= , so you can actually talk to the GUI, SDK, etc...

Kris


On Thu, Sep 19, 2013 at 12:53 PM, Alexandr= e Pilkiewicz <alexandre.pilkiewicz@polytechnique.org<= /a>> wrote:

On Thu, Sep 19, 2013 at 11:18 AM, Kristoph= er Micinski <krismicinski@gmail.com> wrote:



On Thu, Sep 19, 2013 at 2:19 AM= , forum@x9c.fr <forum@x9c= .fr> wrote:

Le 19 sept. 2013 =E0 06:35, Kristopher Micinski a =E9crit :

> With a little bit of hacking it'd probably work, but I'm not s= ure of the status of ocaml-java and haven't looked into the implementat= ion details. =A0Since ocaml-java outputs class files (afaik) you'd have= to sort of hack the android build pipeline yourself, but that wouldn't= be the hard part: all the tools are there. =A0The harder part is that the = Android SDK is very Java oriented, and it just feels awkward as hell to use= in OCaml even if you were to write a thin wrapper around the SDK.

In theory, you are right that it wouldn't be hard.
In practice, the problem is that OCaml-Java emits classes
for Java 1.7 while (to the best of my knowledge) Android
only accepts Java 1.6 classes. As far as I know, there is no
other pending problem.

=46rom this point, the question would be: is it better to wait
for Android to update to Java 1.7 (or even 1.8...), or to
modify OCaml-Java? Honestly, I would need quite a bit
of encouragement to modify OCaml-Java in this direction...


Yes, that would be a deal breake= r. =A0That fell under the technical points of ocaml-java with which I wasn&= #39;t familiar.

Regarding interaction with the classes of the Android SDK,
one may be interested in the typer extension allowing to
manipulate Java instances from pure OCaml code:
=A0 =A0 http://ocamljava.x9c.fr/preview/javaext.html
The main potential problem with this approach is that the
extension currently allows only to implement interfaces, but
not to extend classes. It may be a problem if for example the
event system of Android is based on abstract classes.
Another problem may be the "linking", i. e. the way Android
expects to execute an application: is it a bare main method,
or is there a need to implement/extend a given interface/class?

Yes, it does rely on extending an abstract c= lass. =A0This does, in fact, permeate the framework.

kris
=A0


--001a11c3035021a5bc04e6c2cea7--