www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mobile app support?

reply "Andrew Pennebaker" <andrew.pennebaker gmail.com> writes:
What's the state of Android, iOS, and Windows RT support for D? 
Wouldn't it be great if we could write cross-platform mobile apps 
in a single language?
Jan 24 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 00:24:31 +0100
"Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote:

 What's the state of Android, iOS, and Windows RT support for D? 
 Wouldn't it be great if we could write cross-platform mobile apps 
 in a single language?
Someone else will have to answer about the state of D on Android/iOS/Win8Arm, as I don't know. My understanding it that it's getting there, but not quite there yet. Someone's been working on connecting D with ObjC. I don't know anymore details. But if you just want "cross-platform mobile apps in a single language" there is Marmalade <http://madewithmarmalade.com>. The downsides are that it's neither free nor free, and you have to use C++, not D. And last I looked it didn't yet support C++11 or Win8Arm, though I'm sure it'll eventually get those. Of course, I look forward do being able to do it all in D, and without a non-free and non-free toolkit.
Jan 24 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 20:31:58 -0500
schrieb Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>:

 On Fri, 25 Jan 2013 00:24:31 +0100
 "Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote:
 
 What's the state of Android, iOS, and Windows RT support for D? 
 Wouldn't it be great if we could write cross-platform mobile apps 
 in a single language?
Someone else will have to answer about the state of D on Android/iOS/Win8Arm, as I don't know. My understanding it that it's getting there, but not quite there yet. Someone's been working on connecting D with ObjC. I don't know anymore details.
I don't remember anyone working on Windows RT or iOS. Michel Fortin has code to interface to ObjC which would benefit iOS development: * A template based solution, but IIRC that created to much bloat and development was stopped. * A dmd patch which added extern(ObjC). http://michelf.ca/projects/d-objc/ I'm not sure what's the status here. IIRC I thought it was a quite intrusive language change (it added additional syntax except from extern(ObjC)), but with UDAs + compiler support it could probably be adapted to make it less controversial. Either way it would be a huge patch and huge patches tend to get not reviewed merged into dmd so it's difficult. I can tell more about Android: About a year ago I tried porting D(GDC) to Android. I didn't care about JNI/GUI, I just wanted to get druntime and phobos working first. There are 2 fundamental issues, both making D on Android impossible right now: * Google castrated it's libc: it doesn't support TLS. D can't work without TLS. (Things might get better with C++/11 which also has TLS support). AFAIK google was just to lazy to implement TLS (Java doesn't need it), ARM/Linux even provides hardware support for fast TLS (TLS register). * GCC has emulated TLS. It would be slow but it could work. Except that it can't work with the D garbage collector right now. It could be integrated with some effort, but it would veeeery be slow. (Basically emuTLS allocates small distinct memory ranges, real TLS has one big range per thread. Now the GC needs to get all ranges and scan them. Our current approach can't get the small ranges. Even if we could make it work scanning many small ranges is slow) * And, not related to the other issues, but also a show-stopper: the android runtime linker is pretty stupid. Applications which where not started by the javaVM or use static linking have strange problems (such as global variables not working. Even fprintf(stdout) doesn't work, known android problem). It actually seems this has been fixed now ( http://code.google.com/p/android/issues/detail?id=28598 ), but only in recent Android versions. There could be more issues like these though, as google officially does not support native applications. Even if those did work, you can't write gui applications if you app wasn't started by the Java VM. The Android solution is this: Write a small JAVA app, load the native shared library, call function in the shared library done. Well, D shared libraries don't work yet and we need a shared druntime & phobos as well. That's it for Android. For ARM in general, gdc support is quite OK. There are <10 failures in the compiler test suite which are really arm specific bugs. Not much work has been done on druntime & phobos ARM supprt though. I know that at least the GC & TLS is working on ARM/Glibc.
Jan 25 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 20:37, Johannes Pfau wrote:

 I don't remember anyone working on Windows RT or iOS. Michel Fortin has
 code to interface to ObjC which would benefit iOS development:
 * A template based solution, but IIRC that created to much bloat and
    development was stopped.
You can do it manually to avoid bloat but that is very tedious.
 * A dmd patch which added extern(ObjC).
    http://michelf.ca/projects/d-objc/
    I'm not sure what's the status here. IIRC I thought it was a quite
    intrusive language change (it added additional syntax except from
    extern(ObjC)), but with UDAs + compiler support it could probably be
    adapted to make it less controversial. Either way it would be a huge
    patch and huge patches tend to get not reviewed merged into dmd so
    it's difficult.
It hasn't had an update for two or three years.
 * Google castrated it's libc: it doesn't support TLS. D can't work
    without TLS. (Things might get better with C++/11 which also has TLS
    support). AFAIK google was just to lazy to implement TLS (Java
    doesn't need it), ARM/Linux even provides hardware support for fast
    TLS (TLS register).
 * GCC has emulated TLS. It would be slow but it could work. Except that
    it can't work with the D garbage collector right now. It could be
    integrated with some effort, but it would veeeery be slow. (Basically
    emuTLS allocates small distinct memory ranges, real TLS has one big
    range per thread. Now the GC needs to get all ranges and scan them.
    Our current approach can't get the small ranges. Even if we could
    make it work scanning many small ranges is slow)
DMD on Mac OS X currently uses an emulated TLS. -- /Jacob Carlborg
Jan 25 2013
parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 21:43:29 +0100
schrieb Jacob Carlborg <doob me.com>:

 
 DMD on Mac OS X currently uses an emulated TLS.
 
yep, but a custom implementation. I'd like to use the GCC implementation for increased compatibility between C/C++ __thread and D (foe example declaring a __thread variable in C, using it in D or the other way round)
Jan 25 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.01.2013 20:37, schrieb Johannes Pfau:
 Am Thu, 24 Jan 2013 20:31:58 -0500
 schrieb Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>:

 On Fri, 25 Jan 2013 00:24:31 +0100
 "Andrew Pennebaker" <andrew.pennebaker gmail.com> wrote:

 What's the state of Android, iOS, and Windows RT support for D?
 Wouldn't it be great if we could write cross-platform mobile apps
 in a single language?
Someone else will have to answer about the state of D on Android/iOS/Win8Arm, as I don't know. My understanding it that it's getting there, but not quite there yet. Someone's been working on connecting D with ObjC. I don't know anymore details.
I don't remember anyone working on Windows RT or iOS. Michel Fortin has code to interface to ObjC which would benefit iOS development: * A template based solution, but IIRC that created to much bloat and development was stopped. * A dmd patch which added extern(ObjC). http://michelf.ca/projects/d-objc/ I'm not sure what's the status here. IIRC I thought it was a quite intrusive language change (it added additional syntax except from extern(ObjC)), but with UDAs + compiler support it could probably be adapted to make it less controversial. Either way it would be a huge patch and huge patches tend to get not reviewed merged into dmd so it's difficult. I can tell more about Android: About a year ago I tried porting D(GDC) to Android. I didn't care about JNI/GUI, I just wanted to get druntime and phobos working first. There are 2 fundamental issues, both making D on Android impossible right now: * Google castrated it's libc: it doesn't support TLS. D can't work without TLS. (Things might get better with C++/11 which also has TLS support). AFAIK google was just to lazy to implement TLS (Java doesn't need it), ARM/Linux even provides hardware support for fast TLS (TLS register). * GCC has emulated TLS. It would be slow but it could work. Except that it can't work with the D garbage collector right now. It could be integrated with some effort, but it would veeeery be slow. (Basically emuTLS allocates small distinct memory ranges, real TLS has one big range per thread. Now the GC needs to get all ranges and scan them. Our current approach can't get the small ranges. Even if we could make it work scanning many small ranges is slow) * And, not related to the other issues, but also a show-stopper: the android runtime linker is pretty stupid. Applications which where not started by the javaVM or use static linking have strange problems (such as global variables not working. Even fprintf(stdout) doesn't work, known android problem). It actually seems this has been fixed now ( http://code.google.com/p/android/issues/detail?id=28598 ), but only in recent Android versions. There could be more issues like these though, as google officially does not support native applications. Even if those did work, you can't write gui applications if you app wasn't started by the Java VM. The Android solution is this: Write a small JAVA app, load the native shared library, call function in the shared library done. Well, D shared libraries don't work yet and we need a shared druntime & phobos as well. That's it for Android. For ARM in general, gdc support is quite OK. There are <10 failures in the compiler test suite which are really arm specific bugs. Not much work has been done on druntime & phobos ARM supprt though. I know that at least the GC & TLS is working on ARM/Glibc.
And I can provide some information regarding Windows Phone 8, at least from I know from reading MSDN and Channel 9 videocasts. The main operating system runtime is WinRT, so D would probably need to make use of it. D already supports COM and there was a Microsoft employee that played a bit with it, if I remember correctly. Nonetheless, D code would need to interoperate with WinRT, which is actually improved COM objects, and their projections (metadata). In a similar way like C++/CX and .NET do. Plus certain care needs to be taken with the small set of available Win32 calls, otherwise it won't be possible to sign the applications: https://forums.embarcadero.com/message.jspa?messageID=484319#484319 -- Paulo
Jan 25 2013
prev sibling parent reply "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Friday, 25 January 2013 at 19:37:43 UTC, Johannes Pfau wrote:
 That's it for Android. For ARM in general, gdc support is quite 
 OK.
 There are <10 failures in the compiler test suite which are 
 really arm
 specific bugs. Not much work has been done on druntime & phobos 
 ARM
 supprt though. I know that at least the GC & TLS is working on
 ARM/Glibc.
Good overview and job Johannes, thanks! Just a note, may be somebody are not aware. Even DMD can be used to play with Android! There are already Intel based smartphones in Europe and Asia, like Motorola RAZR I and some telcos-branded. Atom and Core tablets will be there soon starting with Windows 8 and then I hope Android too. It may simplify RT porting efforts a lot. Oleg.
Jan 25 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 26 January 2013 at 05:33:17 UTC, Oleg Kuporosov 
wrote:
 On Friday, 25 January 2013 at 19:37:43 UTC, Johannes Pfau wrote:
 That's it for Android. For ARM in general, gdc support is 
 quite OK.
 There are <10 failures in the compiler test suite which are 
 really arm
 specific bugs. Not much work has been done on druntime & 
 phobos ARM
 supprt though. I know that at least the GC & TLS is working on
 ARM/Glibc.
Good overview and job Johannes, thanks! Just a note, may be somebody are not aware. Even DMD can be used to play with Android! There are already Intel based smartphones in Europe and Asia, like Motorola RAZR I and some telcos-branded. Atom and Core tablets will be there soon starting with Windows 8 and then I hope Android too. It may simplify RT porting efforts a lot. Oleg.
I'm typing this on an Intel AZ210 right now, branded as an Orange San Diego. It would be really cool to be able to write apps in D for it!
Jan 26 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 00:24, Andrew Pennebaker wrote:
 What's the state of Android, iOS, and Windows RT support for D? Wouldn't
 it be great if we could write cross-platform mobile apps in a single
 language?
In general, not good. DMD cannot compile for ARM. You do have other options like GDC and LDC which are supposed to be able to compile for ARM. Don't know the state of the runtime on ARM for these compilers. Except for the above, for iOS you would want to interact with Objective-C, which is kind of a pain in the ass. The correct solution is to make D ABI compatible with Objective-C. Michel Fortin has been working on this, he released an alpha version of his DMD fork that is usable. But unfortunately he has not worked on it for a couple of years. That was also only for Mac OS X, not for iOS. http://michelf.ca/projects/d-objc/ Another option is to use the Objective-C runtime functions (which are in plain C) and use them manually or with the help of a bridge. That has its own problems, like a Hello World application (desktop) taking around 60MB due to code bloat. Objective-C bridge: http://www.dsource.org/projects/dstep -- /Jacob Carlborg
Jan 24 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 January 2013 at 23:24:32 UTC, Andrew Pennebaker 
wrote:
 What's the state of Android, iOS, and Windows RT support for D? 
 Wouldn't it be great if we could write cross-platform mobile 
 apps in a single language?
concerns compiled languages.
Jan 25 2013
prev sibling parent reply "angel" <andrey.gelman gmail.com> writes:
Take into account that generating ARM binary is not all the story.
For example, Android applications run in a virtual machine 
targetted by (a dialect of) Java. These Java applications can be 
bound to native code via JNI interface, that also does not target 
D, and even a plain C application would have to be ported, as 
they use some kind of Android-specific version of C standard 
library.
To summarize, possibly you could port a D application to Android 
with reasonable investment of sweat and blood, but ... you know, 
everyone can fall out of a window, but this cannot be considered 
the most convenient way to get to the street.
Possibly the upcoming Ubuntu phone will be able to provide a 
friendlier platform ...
Jan 25 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 25 January 2013 at 11:59:38 UTC, angel wrote:
 Take into account that generating ARM binary is not all the 
 story.
 For example, Android applications run in a virtual machine 
 targetted by (a dialect of) Java. These Java applications can 
 be bound to native code via JNI interface, that also does not 
 target D, and even a plain C application would have to be 
 ported, as they use some kind of Android-specific version of C 
 standard library.
 To summarize, possibly you could port a D application to 
 Android with reasonable investment of sweat and blood, but ... 
 you know, everyone can fall out of a window, but this cannot be 
 considered the most convenient way to get to the street.
 Possibly the upcoming Ubuntu phone will be able to provide a 
 friendlier platform ...
Additionally both Google and Microsoft see the plain C and C++ environment as meant for games only, a way to make use of "legacy" code or for common code across platforms.
Jan 25 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 15:07:06 +0100
"Paulo Pinto" <pjmlp progtools.org> wrote:
 
 Additionally both Google and Microsoft see the plain C and C++ 
 environment as meant for games only, a way to make use of 
 "legacy" code or for common code across platforms.
 
And also for a lot of their *own* code. But just not for code *other* people write to run on MS/Google's C/C++-written platforms.
Jan 25 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.01.2013 20:16, schrieb Nick Sabalausky:
 On Fri, 25 Jan 2013 15:07:06 +0100
 "Paulo Pinto" <pjmlp progtools.org> wrote:
 Additionally both Google and Microsoft see the plain C and C++
 environment as meant for games only, a way to make use of
 "legacy" code or for common code across platforms.
And also for a lot of their *own* code. But just not for code *other* people write to run on MS/Google's C/C++-written platforms.
Well, if you look at the Android source code, the majority of the code is really Java. The C and C++ source code are mostly what is coming from Linux kernel and drivers. -- Paulo
Jan 25 2013