Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 08/08/10 01:44, Don Stewart wrote: Only problem is rewriting the GHC runtime in Java... :-) Perhaps I don't understand the problem domain correctly, but IMHO this project was already once done in LambdaVM: http://wiki.brianweb.net/LambdaVM/LambdaVM. Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 08/08/10 03:08, Mathew de Detrich wrote: Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a generic ASM branch for mobile devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip) This should be S5PC110 if I google correctly which is just yet another ARM Cortex A8: http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=1043 Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
I just did some further talking with Liam, and it appears that the NDK really just produces an ARM binary which ends up getting linked into the Dalvik VM files (it isn't platform independant as I thought) which means that using LLVM to produce an ARM ASM output is a fine choice. By the sounds of it the NDK is designed to be platform dependant (not independent) so it appears that if any Android system does come out in the future that doesn't use ARM, you would have the same issue with NDK There still however leaves the problem with what to do with Java, because a proper Android app (not a linux app compiled for ARM) needs to link with Java to interface with Android On Tue, Aug 10, 2010 at 8:21 PM, Karel Gardas karel.gar...@centrum.czwrote: On 08/08/10 03:08, Mathew de Detrich wrote: Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a generic ASM branch for mobile devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip) This should be S5PC110 if I google correctly which is just yet another ARM Cortex A8: http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=1043 Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On Tue, Aug 10, 2010 at 4:23 PM, Mathew de Detrich dete...@gmail.com wrote: There still however leaves the problem with what to do with Java, because a proper Android app (not a linux app compiled for ARM) needs to link with Java to interface with Android I'm interested in getting jvm-bridge working again, but I've run into problems with understanding how it interfaces with 3rd party source. I would welcome the help if anyone else is also interested :) (are the original authors still around?). The basic capabilities seem to work fine with minor build fixes -- the examples that only use the core java libraries were easy to use. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On Sun, Aug 08, 2010 at 01:08:30AM +, Mathew de Detrich wrote: In my opinion the most reliable approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM. I have heard anecdotal reports that the output from jhc can be compiled with the NDK to android aps with minor changes. If anyone wanted to run with this, I'd add it as a first class target platform for jhc. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Whatever happened to the JVM backend for GHC? That might actually be a relatively straightforward solution to the whole interface to Java problem. On Sun, Apr 18, 2010 at 11:42 PM, Don Stewart d...@galois.com wrote: liamoc: On 19 April 2010 05:29, Don Stewart d...@galois.com wrote: That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. More work also in that you need to port the runtime system to Java... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Only problem is rewriting the GHC runtime in Java... :-) -- Don scooter.phd: Whatever happened to the JVM backend for GHC? That might actually be a relatively straightforward solution to the whole interface to Java problem. On Sun, Apr 18, 2010 at 11:42 PM, Don Stewart d...@galois.com wrote: liamoc: On 19 April 2010 05:29, Don Stewart d...@galois.com wrote: That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. More work also in that you need to port the runtime system to Java... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a generic ASM branch for mobile devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip) In my opinion the most reliable approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM. Using the NDK + Java would mean any app written in Haskell would work on any android device. Of course as mentioned above, there are issues with this. Its a lot of work for one thing, and the GC for Java is probably not the best suited for Haskell structured programs. Also iirc, in order to make official Android apps which can go on the market place, you are basically forced to use the Java API + NDK for any native code, and you have to use the Java API to interface with the android GUI/World (you can't make an proper Android app just using NDK which complicates things further). The GC issue I guess could be solved by generating JVM code (instead of Java code) which would give more freedom for GHC to generate code more suited to Haskell If this ever ended up happening, it does have the advantage that when one would develop an app for Android using Haskell, GHC (or whatever compiler we would use) can use NDK for as much code as possible and only resorting to Java libraries when required which can of course equate to creating very fast Android Apps using a productive language (Haskell) As Don mentioned through, we need a java runtime for GHC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
The Hummingbird is still ARM. ARM doesn't actually build any chips themselves, and just license the architecture design out to people who do make them. Most of the iPhone ARM chips are built by Samsung too. Almost all the mobile devices I know of run ARM, so I think having a native ARM generator would still be very beneficial. And if it isn't ARM on a device, it's almost certainly going to be Intel, these days. Sure, Android doesn't specify that this has to be the case, but realistically, it will be. On Sun, Aug 8, 2010 at 3:08 AM, Mathew de Detrich dete...@gmail.com wrote: Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a generic ASM branch for mobile devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip) In my opinion the most reliable approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM. Using the NDK + Java would mean any app written in Haskell would work on any android device. Of course as mentioned above, there are issues with this. Its a lot of work for one thing, and the GC for Java is probably not the best suited for Haskell structured programs. Also iirc, in order to make official Android apps which can go on the market place, you are basically forced to use the Java API + NDK for any native code, and you have to use the Java API to interface with the android GUI/World (you can't make an proper Android app just using NDK which complicates things further). The GC issue I guess could be solved by generating JVM code (instead of Java code) which would give more freedom for GHC to generate code more suited to Haskell If this ever ended up happening, it does have the advantage that when one would develop an app for Android using Haskell, GHC (or whatever compiler we would use) can use NDK for as much code as possible and only resorting to Java libraries when required which can of course equate to creating very fast Android Apps using a productive language (Haskell) As Don mentioned through, we need a java runtime for GHC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Although I know that ARM basically has monopoly for chipsets on mobile devices, that doesn't mean there couldn't be a chipset used that isn't ARM and runs android (and what if that device happened to be really popular in the future?) The main issue however, as I mentioned before, is the fact that from what I read on the Android site, proper Android apps (as in ones that you can get through the market place), you are forced to use the Java API to interface with android (and the NDK for native code generation if required). I believe what people would want the option of creating proper Android apps So it would just be a difference between using Java + ARM ASM (through LLVM I suppose) or Java + NDK (through FFI??). The latter, actually being supported by Google, is guaranteed to work on any android device, ARM or not The other option is we could just wait for someone to make an Android backend through LLVM :), That of course is the last option, which would also mean that any language that compiles down to LLVM would be able to run on Android as well. On Sun, Aug 8, 2010 at 1:14 AM, Daniel Peebles pumpkin...@gmail.com wrote: The Hummingbird is still ARM. ARM doesn't actually build any chips themselves, and just license the architecture design out to people who do make them. Most of the iPhone ARM chips are built by Samsung too. Almost all the mobile devices I know of run ARM, so I think having a native ARM generator would still be very beneficial. And if it isn't ARM on a device, it's almost certainly going to be Intel, these days. Sure, Android doesn't specify that this has to be the case, but realistically, it will be. On Sun, Aug 8, 2010 at 3:08 AM, Mathew de Detrich dete...@gmail.comwrote: Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a generic ASM branch for mobile devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip) In my opinion the most reliable approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM. Using the NDK + Java would mean any app written in Haskell would work on any android device. Of course as mentioned above, there are issues with this. Its a lot of work for one thing, and the GC for Java is probably not the best suited for Haskell structured programs. Also iirc, in order to make official Android apps which can go on the market place, you are basically forced to use the Java API + NDK for any native code, and you have to use the Java API to interface with the android GUI/World (you can't make an proper Android app just using NDK which complicates things further). The GC issue I guess could be solved by generating JVM code (instead of Java code) which would give more freedom for GHC to generate code more suited to Haskell If this ever ended up happening, it does have the advantage that when one would develop an app for Android using Haskell, GHC (or whatever compiler we would use) can use NDK for as much code as possible and only resorting to Java libraries when required which can of course equate to creating very fast Android Apps using a productive language (Haskell) As Don mentioned through, we need a java runtime for GHC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
liamoc: On 19 April 2010 05:29, Don Stewart d...@galois.com wrote: That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. More work also in that you need to port the runtime system to Java... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Our best bet is to compile to ARM native code and then use the NDK to talk to the Java APIs. Cheers. ~Liam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
liamoc: Our best bet is to compile to ARM native code and then use the NDK to talk to the Java APIs. Cheers. ~Liam That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 18/04/2010, at 1:39 PM, Darrin Chandler wrote: I recently purchased an Android phone and spent a little time looking around to see if Haskellers were doing anything there, but no luck so far. Has anyone here done anything with Android? Not Haskell, but FP on Android: http://www.kablambda.org/blog/2009/07/27/functional-programming-on-android/ I don't have an Android, so all I did was a 'hello world' to see if it could be done. Tom___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On 19 April 2010 05:29, Don Stewart d...@galois.com wrote: That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. Here's the docs about the ABI we need to conform to in order to use the NDK. -- snip -- This is the name of an ABI for ARM-based CPUs that support *at* *least* the ARMv5TE instruction set. Please refer to following documentation for more details: - ARM Architecture Reference manual(a.k.a ARMARM) - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS) - ELF for the ARM Architecture (a.k.a. ARMELF) - ABI for the ARM Architecture (a.k.a. BSABI) - Base Platform ABI for the ARM Architecture (a.k.a. BPABI) - C Library ABI for the ARM Architecture (a.k.a. CLIABI) - C++ ABI for the ARM Architecture (a.k.a. CPPABI) - Runtime ABI for the ARM Architecture (a.k.a. RTABI) - ELF System V Application Binary Interface (DRAFT - 24 April 2001) - Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html) Note that the AAPCS standard defines 'EABI' as a moniker used to specify a _family_ of similar but distinct ABIs. Android follows the little-endian ARM GNU/Linux ABI as documented in the following document: http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf With the exception that wchar_t is only one byte. This should not matter in practice since wchar_t is simply *not* really supported by the Android platform anyway. This ABI does *not* support hardware-assisted floating point computations. Instead, all FP operations are performed through software helper functions that come from the compiler's libgcc.a static library. Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK will generate thumb code by default, unless you define LOCAL_ARM_MODE in your Android.mk (see docs/ANDROID-MK.TXT for all details). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Also worth mentioning that the Android docs explicitly warn against allocating frequently suggesting reuse of objects is by far more preferable than regularly allocating stuff. If we go the Dalvik/Java route, then we'll have alot of work to do to make the GC work for us nicely, whereas compiling to native code gives us full control. The problem (and why I believe compiling to Java would be better) is that it is quite tedious and difficult to interact with Java APIs using native code. You write a shell of your application in java and put calls in to native code everywhere. It ruins alot of the glamor of Haskelling for android. That said, if we can somehow expose some Java functions to haskell (rather than the other way around) then we could eventually write an android API library for native haskell, giving us both the performance benefits and the android api. Cheers. ~Liam On 19 April 2010 14:25, Liam O'Connor lia...@cse.unsw.edu.au wrote: On 19 April 2010 05:29, Don Stewart d...@galois.com wrote: That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. Here's the docs about the ABI we need to conform to in order to use the NDK. -- snip -- This is the name of an ABI for ARM-based CPUs that support *at* *least* the ARMv5TE instruction set. Please refer to following documentation for more details: - ARM Architecture Reference manual (a.k.a ARMARM) - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS) - ELF for the ARM Architecture (a.k.a. ARMELF) - ABI for the ARM Architecture (a.k.a. BSABI) - Base Platform ABI for the ARM Architecture (a.k.a. BPABI) - C Library ABI for the ARM Architecture (a.k.a. CLIABI) - C++ ABI for the ARM Architecture (a.k.a. CPPABI) - Runtime ABI for the ARM Architecture (a.k.a. RTABI) - ELF System V Application Binary Interface (DRAFT - 24 April 2001) - Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html) Note that the AAPCS standard defines 'EABI' as a moniker used to specify a _family_ of similar but distinct ABIs. Android follows the little-endian ARM GNU/Linux ABI as documented in the following document: http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf With the exception that wchar_t is only one byte. This should not matter in practice since wchar_t is simply *not* really supported by the Android platform anyway. This ABI does *not* support hardware-assisted floating point computations. Instead, all FP operations are performed through software helper functions that come from the compiler's libgcc.a static library. Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK will generate thumb code by default, unless you define LOCAL_ARM_MODE in your Android.mk (see docs/ANDROID-MK.TXT for all details). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Ah, looks as though we'll have to write a C layer between Java and Haskell.. doing all of this in the FFI seems like hard: http://www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html Cheers. ~Liam On 19 April 2010 14:33, Liam O'Connor lia...@cse.unsw.edu.au wrote: Also worth mentioning that the Android docs explicitly warn against allocating frequently suggesting reuse of objects is by far more preferable than regularly allocating stuff. If we go the Dalvik/Java route, then we'll have alot of work to do to make the GC work for us nicely, whereas compiling to native code gives us full control. The problem (and why I believe compiling to Java would be better) is that it is quite tedious and difficult to interact with Java APIs using native code. You write a shell of your application in java and put calls in to native code everywhere. It ruins alot of the glamor of Haskelling for android. That said, if we can somehow expose some Java functions to haskell (rather than the other way around) then we could eventually write an android API library for native haskell, giving us both the performance benefits and the android api. Cheers. ~Liam On 19 April 2010 14:25, Liam O'Connor lia...@cse.unsw.edu.au wrote: On 19 April 2010 05:29, Don Stewart d...@galois.com wrote: That's great info -- we do have an unregisterised ARM port of GHC in Debian, iirc. (And the LLVM backend can generate ARM code too) Sounds good. With regards to LLVM, what dependencies does LLVM ARM code have? Android has gnu libraries not llvm, i don't know if that is okay. A superior approach would be to compile haskell to Java or Dalvik bytecode (or even JVM bytecode if it doesn't use any JIT features; then we can compile that to dalvik bytecode), but this is obviously more work if we already have an ARM port. Here's the docs about the ABI we need to conform to in order to use the NDK. -- snip -- This is the name of an ABI for ARM-based CPUs that support *at* *least* the ARMv5TE instruction set. Please refer to following documentation for more details: - ARM Architecture Reference manual (a.k.a ARMARM) - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS) - ELF for the ARM Architecture (a.k.a. ARMELF) - ABI for the ARM Architecture (a.k.a. BSABI) - Base Platform ABI for the ARM Architecture (a.k.a. BPABI) - C Library ABI for the ARM Architecture (a.k.a. CLIABI) - C++ ABI for the ARM Architecture (a.k.a. CPPABI) - Runtime ABI for the ARM Architecture (a.k.a. RTABI) - ELF System V Application Binary Interface (DRAFT - 24 April 2001) - Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html) Note that the AAPCS standard defines 'EABI' as a moniker used to specify a _family_ of similar but distinct ABIs. Android follows the little-endian ARM GNU/Linux ABI as documented in the following document: http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf With the exception that wchar_t is only one byte. This should not matter in practice since wchar_t is simply *not* really supported by the Android platform anyway. This ABI does *not* support hardware-assisted floating point computations. Instead, all FP operations are performed through software helper functions that come from the compiler's libgcc.a static library. Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK will generate thumb code by default, unless you define LOCAL_ARM_MODE in your Android.mk (see docs/ANDROID-MK.TXT for all details). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On Sat, Apr 17, 2010 at 08:21:06PM -0700, Jeffrey Scofield wrote: As a side comment, I haven't noticed any reaction in the Haskell/iPhone community about Apple's recent policy change. I've seen some reaction in other language communities, and I'm sure you can imagine what it's like. Understandable sentiments, but not very productive. I recently purchased an Android phone and spent a little time looking around to see if Haskellers were doing anything there, but no luck so far. Has anyone here done anything with Android? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
Darrin Chandler wrote: On Sat, Apr 17, 2010 at 08:21:06PM -0700, Jeffrey Scofield wrote: As a side comment, I haven't noticed any reaction in the Haskell/iPhone community about Apple's recent policy change. I've seen some reaction in other language communities, and I'm sure you can imagine what it's like. Understandable sentiments, but not very productive. I recently purchased an Android phone and spent a little time looking around to see if Haskellers were doing anything there, but no luck so far. Has anyone here done anything with Android? I've done a simple app in Java, and some experiments with JRuby. I've not done any thing Android with Haskell, but would love to give it a shot. However, I don't know where to begin. James -- Neurogami - Smart application development http://www.neurogami.com ja...@neurogami.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
