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
Ope
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 th
On Tue, Jan 22, 2013 at 8:37 PM, Kristopher Micinski 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 be in some sense,
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 program
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 unreg
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" wrote:
>
> What about the option of using Haskell's Parsec or AttoParsec to implement
> a Haskell-ish la
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 seriou
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 imp
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 wrote
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 Pennebake
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
wrote:
> There are currently very few options, especially free and open source
> options, wh
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
develo
12 matches
Mail list logo