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 3229D7EE49 for ; Fri, 20 Sep 2013 01:14:28 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=pra; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=mailfrom; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@avasout03.plus.net) identity=helo; client-ip=84.93.230.244; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout03.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnECACGEO1JUXeb0nGdsb2JhbABbgkN8r12JXYhGgR4WDgEBAQEBBg0JCRQogiUBAQQBCAIjTAUIAwIJDgMEAQEoBxkIGwoJCAIEEwsFh2EDCQoIsEQNiWqMe4JsBgGEHgOJAIYShwGDGIsTiFg X-IPAS-Result: AnECACGEO1JUXeb0nGdsb2JhbABbgkN8r12JXYhGgR4WDgEBAQEBBg0JCRQogiUBAQQBCAIjTAUIAwIJDgMEAQEoBxkIGwoJCAIEEwsFh2EDCQoIsEQNiWqMe4JsBgGEHgOJAIYShwGDGIsTiFg X-IronPort-AV: E=Sophos;i="4.90,940,1371074400"; d="scan'208,217";a="33599897" Received: from avasout03.plus.net ([84.93.230.244]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 Sep 2013 01:14:26 +0200 Received: from XPS ([87.113.102.230]) by avasout03 with smtp id TBEQ1m0014yFic701BERl2; Fri, 20 Sep 2013 00:14:26 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=OYOhUHjY c=1 sm=1 tr=0 a=S0N8oXB6HfTRxD1Ve5EJrw==:117 a=S0N8oXB6HfTRxD1Ve5EJrw==:17 a=0Bzu9jTXAAAA:8 a=L1PzsWp0xOIA:10 a=Xub9RBUEA-sA:10 a=Kvk-SOs2Z7YA:10 a=r2vSxAw-AAAA:8 a=221dAGmKDAYA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=pGLkceISAAAA:8 a=wYqWQwwNAAAA:8 a=ZOzjf2MOAAAA:8 a=QNFTUrvXAAAA:8 a=LzTIamQIO2OeqLuGo8oA:9 a=wPNLvfGTeEIA:10 a=tPdp2tgl6LcA:10 a=MSl-tDqOz04A:10 a=4AN35qoD-4YA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=M-4cwxJVl5hOiQ3cYwgA:9 a=dcp5qSyzeTTerPnj:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Kristopher Micinski'" Cc: "'Caml List'" References: <036501ceb3e5$bcd7b920$36872b60$@ffconsultancy.com> <87bo3pqy9o.fsf@golf.niidar.ru> In-Reply-To: Date: Fri, 20 Sep 2013 00:14:32 +0100 Organization: Flying Frog Consultancy Ltd. Message-ID: <063b01ceb58e$005929f0$010b7dd0$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063C_01CEB596.621E5540" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK4ErqTtJ8VGV7M8l9ymgj2PKwLGwHbzoNmAi/iQPUCL4CSCQIongTSAV/58DYCXAOjEgFAM35Il4/2W4A= Content-Language: en-gb Subject: RE: [Caml-list] OCaml on Android This is a multipart message in MIME format. ------=_NextPart_000_063C_01CEB596.621E5540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 You cannot even call OpenGL ES directly? =20 That would explain some weirdness in the Xamarin libs=85 =20 Cheers, Jon. =20 From: Kristopher Micinski [mailto:krismicinski@gmail.com]=20 Sent: 19 September 2013 21:58 To: Alexandre Pilkiewicz Cc: forum@x9c.fr; Ivan Gotovchits; Jon Harrop; Caml List Subject: Re: [Caml-list] OCaml on Android =20 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... =20 Kris =20 =20 On Thu, Sep 19, 2013 at 12:53 PM, Alexandre Pilkiewicz wrote: http://gallium.inria.fr/blog/ocaml-on-a-nexus-7/ =20 On Thu, Sep 19, 2013 at 11:18 AM, Kristopher Micinski wrote: =20 =20 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 sort of hack the android build pipeline yourself, but that wouldn't be the hard 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 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... =20 Yes, that would be a deal breaker. That fell under the technical points of ocaml-java with which I wasn't familiar. =20 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? =20 Yes, it does rely on extending an abstract class. This does, in fact, permeate the framework. =20 kris =20 =20 =20 ------=_NextPart_000_063C_01CEB596.621E5540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

&nbs= p;

You cannot even call OpenGL = ES directly?

 

That would explain some weirdnes= s in the Xamarin libs…

 

Cheers,

Jon.

 

From: Kristopher Micinski [mailto:krismicinski@gmail.com]=
Sent: 19 September 2013 21:58
To: Alexandre Pilkiewic= z
Cc: forum@x9c.fr; Ivan Gotovchits; Jon Harrop; Caml List
= Subject: Re: [Caml-list] OCaml on Android

 

Yes, so this is= what happens if you want to just run an ocaml binary on your Android devic= e.  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.pilki= ewicz@polytechnique.org> wrote:

 

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

 

 

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


Le 19 se= pt. 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 sort of hack the android build p= ipeline yourself, but that wouldn't be the hard part: all the tools are the= re.  The harder part is that the Android SDK is very Java oriented, an= d 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 har= d.
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 c= lasses. 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 d= irection...

 

Yes, that would be a deal breaker. &nbs= p;That fell under the technical points of ocaml-java with which I wasn't fa= miliar.

 

Regarding interaction with the classes of the Android SDK,
one = may be interested in the typer extension allowing to
manipulate Java ins= tances from pure OCaml code:
    http://ocamljava.x9c.fr/previ= ew/javaext.html
The main potential problem with this approach is tha= t the
extension currently allows only to implement interfaces, but
no= t 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 &qu= ot;linking", i. e. the way Android
expects to execute an applicatio= n: is it a bare main method,
or is there a need to implement/extend a gi= ven interface/class?

<= o:p> 

Yes, it does rely= on extending an abstract class.  This does, in fact, permeate the fra= mework.

 

=

kris

 

 

 

= ------=_NextPart_000_063C_01CEB596.621E5540--