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?

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.

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

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?

Right now, C++ and C# are your only options for that, in what concerns compiled languages.

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 ...

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.

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.

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.

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

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)