On Tue, Jan 22, 2013 at 8:37 PM, Kristopher Micinski krismicin...@gmail.com
wrote:
By the way, the Android APIs aren't really meant to be used by native
code: the only real use for native code in Android is GPU code and
math code (think games and DSP-type programs).
They may not be meant to
In what way are they exposed for use? I certainly haven't seen any
API which lets you touch any of the standard GUI utilities without
writing JNI wrappers that communicate to the Java based UI elements.
As far as I know there is no way to use the actual Android API: you
have to write a wrapper
For reference, the only components provided by the Android platform
(listed on the Android website, and what I found digging through the
provided NDK) are:
libc (C library) headers
libm (math library) headers
JNI interface headers
libz (Zlib compression) headers
liblog (Android logging) header
On Jan 19, 2013, at 10:29 PM, Nathan Hüsken wrote:
Recently I managed to get ghc to target android working (this still
needs some work): [4].
this is great news, thanks!
Of couse, ffi bindings for all these platforms would be needed to get
serious.
i think that you can get quite serious
Can we un-deprecate GHC's ability to compile to C code? C may be the best
option to bridge to mobile, as Android, iOS, and Windows RT do support
C/C++ apps.
On Jan 22, 2013 2:14 PM, Dan Choi dhc...@gmail.com wrote:
What about the option of using Haskell's Parsec or AttoParsec to implement
a
On Tue, Jan 22, 2013 at 2:40 PM, Andrew Pennebaker
andrew.penneba...@gmail.com wrote:
Can we un-deprecate GHC's ability to compile to C code? C may be the best
option to bridge to mobile, as Android, iOS, and Windows RT do support
C/C++ apps.
The C code generated by GHC, except in
I don't believe that was really the point of the C compiler, and I'd
suspect you'd have a hard time with the runtime.
By the way, the Android APIs aren't really meant to be used by native
code: the only real use for native code in Android is GPU code and
math code (think games and DSP-type
There are currently very few options, especially free and open source
options, when it comes to developing cross-platform mobile applications.
It's basically web apps with JavaScript, or C++. If Haskell supported app
development on Android, iOS, and Windows RT, that alone would bring in more
You would need native compilers for all the platforms and/or virtual
machine technology.
Might be easier to have the browser connect to a Haskell app.
On Sat, Jan 19, 2013 at 10:42 AM, Andrew Pennebaker
andrew.penneba...@gmail.com wrote:
There are currently very few options, especially free
Then it looks as if the easier implementation would be small Haskell
VM's for the various platforms with a byte code compiler.
I do not believe the JVM supports all the optimizations GHC can do.
Oh wait!
Can the LLVM be easily ported to do this?
On Sat, Jan 19, 2013 at 11:40 AM, Andrew
LLVM probably already supports producing native code for all of the
architectures for the mobile platforms. The non-trivial parts are probably
getting GHC to cross-compile and wrapping all of the libraries you need for
the platforms you want to support.
On Sat, Jan 19, 2013 at 12:41 PM, KC
Well, to target javascript there is haste [1] and ghcjs [2].
Ghc can target iOS [3].
Recently I managed to get ghc to target android working (this still
needs some work): [4].
And there is also an active effort by Stephen Paul Weber to get
blackberry working in the devs-ghc mailinglist.
So my
12 matches
Mail list logo
