www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - killer App for D? (was: State of D on iOS/Android)

reply J Arrizza <cppgent0 gmail.com> writes:
  > As far as I know, gdc can already produce ARM code since it uses the

  > gcc backend. All we need now is a nice native D interface to the
  > Android libraries, and I'll be a very very happy man.




Isn't this the killer "app" for D (like ROR for Ruby, etc.) ?  There was a
thread a while ago where someone said the popularity of a language depends
on an app that drives the use of that language.

So why not D-based Android applications? Consider:

- D-based Android apps running on millions of phones, tablets, iPad
killers, etc.
- Android developers choose Java for quick and dirty, or choose D when
speed is of the essence. "Quick and dirty" becomes less of an issue as more
of the common JDK functionality is added to Phobos or is at least available
for D. As some critical point is reached, why choose Java at all?
- As more devices use Android, it's GUI library will become more popular.
 With a bit of work, PC apps will start using D-based Android GUIs for
cross-platform development. Forget QT, GTK, etc. etc., use Android for the
app that runs on the PC, on the tablet and on your phone.


John
Jan 28 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-01-2012 02:58, J Arrizza wrote:

          > As far as I know, gdc can already produce ARM code since it
         uses the
          > gcc backend. All we need now is a nice native D interface to the
          > Android libraries, and I'll be a very very happy man.


 Isn't this the killer "app" for D (like ROR for Ruby, etc.) ?  There was
 a thread a while ago where someone said the popularity of a language
 depends on an app that drives the use of that language.


Yes, D on Android would be great.

In fact, D already runs on Android if you do some tweaks to the GDC 
build. I've managed to get D apps running on both a Galaxy Tab 10.1 and 
an Efika MX.


 So why not D-based Android applications? Consider:

     - D-based Android apps running on millions of phones, tablets, iPad
     killers, etc.
     - Android developers choose Java for quick and dirty, or choose D
     when speed is of the essence. "Quick and dirty" becomes less of an
     issue as more of the common JDK functionality is added to Phobos or


I think that's pushing it. I see no reason to include something that 
domain and target specific in the standard library.


     is at least available for D. As some critical point is reached, why
     choose Java at all?
     - As more devices use Android, it's GUI library will become more
     popular.  With a bit of work, PC apps will start using D-based
     Android GUIs for cross-platform development. Forget QT, GTK, etc.
     etc., use Android for the app that runs on the PC, on the tablet and
     on your phone.


The concept of a cross-platform UI is broken. Put your logic in a 
library and develop native UIs for each platform you wish to support. It 
is the only way to give users the experience they expect and want.


 John


-- 
- Alex
Jan 28 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jg29bs$2dm8$1 digitalmars.com...

 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC build. 
 I've managed to get D apps running on both a Galaxy Tab 10.1 and an Efika 
 MX.


CAN I HAZ DETAILS PLZ?
KTHNXBYE
Jan 28 2012
next sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky <a a.a> wrote:

 "Alex R=F8nne Petersen" <xtzgzorex gmail.com> wrote in message
 news:jg29bs$2dm8$1 digitalmars.com...

 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC buil=




d.

 I've managed to get D apps running on both a Galaxy Tab 10.1 and an Efik=




a

 MX.


 CAN I HAZ DETAILS PLZ?
 KTHNXBYE


I can't speak to Android, but I know that building GDC on ARM is
fairly routine these days. Make sure to build with
DFLAGS=3D"-fno-section-anchors" in the environment, but otherwise,
follow the normal build instructions.
I would assume the same would apply when building a cross compiler for
ARM (although the normal build instructions are just a bit harder).
Jan 28 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/29/2012 12:42 AM, Andrew Wiley wrote:

 On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky<a a.a>  wrote:

 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jg29bs$2dm8$1 digitalmars.com...

 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC build.
 I've managed to get D apps running on both a Galaxy Tab 10.1 and an Efika
 MX.


 CAN I HAZ DETAILS PLZ?
 KTHNXBYE


 I can't speak to Android, but I know that building GDC on ARM is
 fairly routine these days. Make sure to build with
 DFLAGS="-fno-section-anchors" in the environment, but otherwise,
 follow the normal build instructions.
 I would assume the same would apply when building a cross compiler for
 ARM (although the normal build instructions are just a bit harder).


http://interaxiom.blogspot.com/2011/08/android-d-stuff.html
See my post there for an example of a "routine" GDC on ARM cross 
compiler build not working.  It's the second comment.

Building GCC cross-compilers at all is a huge pain in the ass.  I gave 
up on trying for my Android GDC build for the time being because I don't 
have infinite hours to mess with that stuff.

Binaries please.
Jan 28 2012
parent Johannes Pfau <spam example.com> writes:
Chad J wrote:


 On 01/29/2012 12:42 AM, Andrew Wiley wrote:

 On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky<a a.a>  wrote:

 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jg29bs$2dm8$1 digitalmars.com...

 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC
 build. I've managed to get D apps running on both a Galaxy Tab 10.1 and
 an Efika MX.


 CAN I HAZ DETAILS PLZ?
 KTHNXBYE


 I can't speak to Android, but I know that building GDC on ARM is
 fairly routine these days. Make sure to build with
 DFLAGS="-fno-section-anchors" in the environment, but otherwise,
 follow the normal build instructions.
 I would assume the same would apply when building a cross compiler for
 ARM (although the normal build instructions are just a bit harder).


 
 http://interaxiom.blogspot.com/2011/08/android-d-stuff.html
 See my post there for an example of a "routine" GDC on ARM cross
 compiler build not working.  It's the second comment.


GDC on Android is not the same as a GDC/ARM cross compiler. The android NDK 
has complicated build scripts to build the compiler and there is no 
documentation how to add another language like D to the ndk. Someone has to 
look into that first.

So:
* GDC on ARM, native compiler:
  easy (use -fno-section-anchors),
  fixing -f-section-anchors: not as easy
  ( https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-
arm )
* GDC on ARM, cross compiler
  use -fno-section-anchors, shouldn't be more difficult than building a gcc 
  cross compiler (which already sucks)
* GDC on Android:
  Need to integrate with the android build system
  Android uses a different C library, you'll probably have to adjust 
  druntime and phobos. Also some libraries might not be available on Android 
  (libdl)

 
 Building GCC cross-compilers at all is a huge pain in the ass.  I gave
 up on trying for my Android GDC build for the time being because I don't
 have infinite hours to mess with that stuff.
 
 Binaries please.
Jan 29 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 29 January 2012 07:42, Andrew Wiley <wiley.andrew.j gmail.com> wrote:


 On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky <a a.a> wrote:

 "Alex R=C3=B8nne Petersen" <xtzgzorex gmail.com> wrote in message
 news:jg29bs$2dm8$1 digitalmars.com...

 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC




 build.

 I've managed to get D apps running on both a Galaxy Tab 10.1 and an




 Efika

 MX.


 CAN I HAZ DETAILS PLZ?
 KTHNXBYE


 I can't speak to Android, but I know that building GDC on ARM is
 fairly routine these days. Make sure to build with
 DFLAGS=3D"-fno-section-anchors" in the environment, but otherwise,
 follow the normal build instructions.
 I would assume the same would apply when building a cross compiler for
 ARM (although the normal build instructions are just a bit harder).


Am I the only one that finds it annoying that any dev that wants to use D
seems to have to A) use linux, and B) know how to build GCC on their own?
How many people does this turn away?

Build scripts and mingw binaries plz! Then devs can actually get to work
and start writing software. 90% of my time spent with D involves trying to
fuck around with msys/cygwin environments, trying to build toolchains, and
having an endless stream of related problems. Complete waste of my time,
and loss of community contribution.
Jan 29 2012
parent Johannes Pfau <spam example.com> writes:
Manu wrote:


 On 29 January 2012 07:42, Andrew Wiley <wiley.andrew.j gmail.com> wrote:
 

 On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky <a a.a> wrote:

 "Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message
 news:jg29bs$2dm8$1 digitalmars.com...

 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC




 build.

 I've managed to get D apps running on both a Galaxy Tab 10.1 and an




 Efika

 MX.


 CAN I HAZ DETAILS PLZ?
 KTHNXBYE


 I can't speak to Android, but I know that building GDC on ARM is
 fairly routine these days. Make sure to build with
 DFLAGS="-fno-section-anchors" in the environment, but otherwise,
 follow the normal build instructions.
 I would assume the same would apply when building a cross compiler for
 ARM (although the normal build instructions are just a bit harder).


 
 Am I the only one that finds it annoying that any dev that wants to use D
 seems to have to A) use linux, and B) know how to build GCC on their own?
 How many people does this turn away?


Some linux distributions ship gdc already, also following the gdc build 
instructions isn't hard. Once GDC is part of GCC that problem is solved 
anyway.
This is of course different for cross compilers, but Iains time is limited 
and few people are aware of the gcc/gdc/dmd internals, so other 
architectures are not really supported in gdc. For example, 
https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm 
needs to be fixed before we could call GDC on ARM alpha state. I might have 
another look at that issue in ~2 months, but without knowledge of gdc/gcc 
internals, fixing it isn't easy.
  

 
 Build scripts and mingw binaries plz! Then devs can actually get to work
 and start writing software. 90% of my time spent with D involves trying to
 fuck around with msys/cygwin environments, trying to build toolchains, and
 having an endless stream of related problems. Complete waste of my time,
 and loss of community contribution.


Using "-fno-section-anchors" is only a workaround to get gdc working on ARM. 

built like that is in no way supported. Doing stuff like that isn't really 
supposed to be easy.
Jan 29 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 29 January 2012 04:02, Alex R=C3=B8nne Petersen <xtzgzorex gmail.com> wr=
ote:


 On 29-01-2012 02:58, J Arrizza wrote:


         > As far as I know, gdc can already produce ARM code since it
        uses the
         > gcc backend. All we need now is a nice native D interface to t=




he

         > Android libraries, and I'll be a very very happy man.


 Isn't this the killer "app" for D (like ROR for Ruby, etc.) ?  There was
 a thread a while ago where someone said the popularity of a language
 depends on an app that drives the use of that language.


 Yes, D on Android would be great.

 In fact, D already runs on Android if you do some tweaks to the GDC build=


.

 I've managed to get D apps running on both a Galaxy Tab 10.1 and an Efika
 MX.



Really? Where is the toolchain, and why isn't it available/mentioned on
d-p-l?
Jan 29 2012
prev sibling next sibling parent J Arrizza <cppgent0 gmail.com> writes:
On Sat, Jan 28, 2012 at 6:02 PM, Alex R=F8nne Petersen <xtzgzorex gmail.com=

wrote:



 In fact, D already runs on Android if you do some tweaks to the GDC build=


.

 I've managed to get D apps running on both a Galaxy Tab 10.1 and an Efika
 MX.


 I think that's pushing it. I see no reason to include something that
 domain and target specific in the standard library.





 The concept of a cross-platform UI is broken. Put your logic in a library

 and develop native UIs for each platform you wish to support. It is the
 only way to give users the experience they expect and want.




Interesting response.

Look at the IQ bell curve. Now follow this:

- to be popular is to widen the appeal of D to 2 sigmas of that curve.
- to widen the appeal is to make D easy enough for 95% of the
developer population to use it without any hassle
- "no hassle" is equivalent to make it simple enough for the farthest left
hand side of the curve.
- and that means dead simple to install, dead simple to code in, dead
simple to determine and fix when it goes wrong, dead simple to get it
working on any OS they are used to working on.
- that means there is no "that's pushing it" or "concept is broken" or "all
you have to do is some tweaks" or any other rationalization. If they need
it, they get it. Period.


In short, to make D popular is a hell of a lot more work.  Samuel Johnson
said "I did not have time to write you a short letter, so I wrote you a
long one instead." Paraphrase that for D.

So another, better, question: Do you -- we -- want to make D a popular
language or not?

If not, that implies one set of development and architectural strategies.
 If yes, it implies another set. The two sets have some but little
intersection. And that means you have to choose the end goal you want now
and, once chosen, you have to stick to it.

John
Jan 29 2012
prev sibling next sibling parent J Arrizza <cppgent0 gmail.com> writes:
On Sun, Jan 29, 2012 at 4:26 PM, J Arrizza <cppgent0 gmail.com> wrote:


 So another, better, question: Do you -- we -- want to make D a popular
 language or not?

 If not, that implies one set of development and architectural strategies.
  If yes, it implies another set. The two sets have some but little
 intersection. And that means you have to choose the end goal you want now
 and, once chosen, you have to stick to it.


No response to this?

I currently have an embedded Java application running on an ARM. I am
looking for a replacement language and  associated libraries, specifically
a GUI. I need the user responsiveness to be fast and I need to have a few
extra cycles free to eventually do some graphing, all on
an under-powered processor.

I chose Java for this device because I didn't want to divert my developers
re-inventing the wheel or playing the "match the library versions" game.
The JDK is big and it's clean. It is self-consistent. Java is a
simple language, there is no struggling with odd obscure error messages or
compiler errors. There is a huge breadth and depth of community support.

For the current device, using Java has paid off hugely. It's easy to
develop in, it was easy to set up and the developers have been able to
concentrate on the application (the thing we get paid to write and
deliver). If we need some utility or functionality, chances are it's
already been written and debugged over many years and by millions of people.

The down side is Java is slow. That's why I'm looking at D. I need a fast,
efficient language that is strongly OO and has a gc. There must be GUI
support that does not use X (and 3 or 4 other layers) on an ARM processor
running embedded linux. It has to cross-compile because we simulate the
device and debug on our workstations. D looks like a custom fit for this
situation!

On the other hand D is facing a catch-22. It can't get a full suite of
support code, IDEs, etc until its popular and it won't get popular until it
gets all of that ready to go up-front. The only solution is to leap-frog
using existing technology on an already popular platform.

The Android GUI libraries provide two things towards that end: a platform
for D to take off from and the beginnings of debugged GUI code. The
popularity of Android will pull D along with it, especially if D can find a
niche in the needs of those Android application developers who want speed.
As D's relevant libraries fill out, there will be less and less a need to
use Java and it will gradually take over as the predominant language for
serious apps on Android.

So... Will D and Android GUI libraries be able to replace Java in the next
two years? Is there a commitment or direction towards that end?

John
Feb 02 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So...=A0Will D and Android GUI libraries be able to replace Java in the n=


ext

 two years? Is there a commitment or direction towards that end?


Not replace, but it is my goal to certainly have it a viable
alternative, just as you could alternatively use C/C++ on Android
instead of Java.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 02 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 02, 2012 at 06:50:42AM -0800, J Arrizza wrote:
[...]

 So... Will D and Android GUI libraries be able to replace Java in the
 next two years? Is there a commitment or direction towards that end?


[...]

Somebody just has to do it. IMNSHO, talking about it isn't going to
accomplish much. It's up to the community to produce the library/set of
libraries that will allow easy development in D for Android. If nobody
is currently committed to do it, then somebody should take the
initiative to do it. Waiting around for "official" recognition will only
waste time.

Just my $0.02.


T

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but
haven't gotten around to it yet. " -- swr
Feb 02 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So... Will D and Android GUI libraries be able to replace Java in the


 next

 two years? Is there a commitment or direction towards that end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on Android
 instead of Java.



Have you experimented with the android toolchain? Successfully built a GDC
for it?
I'm keen to get on with it the moment a working toolchain appears,
regardless if druntime/phobos builds/works.
Feb 02 2012
parent Johannes Pfau <nospam example.com> writes:
Am Thu, 2 Feb 2012 20:10:55 +0200
schrieb Manu <turkeyman gmail.com>:


 On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 

 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So... Will D and Android GUI libraries be able to replace Java in
 the


 next

 two years? Is there a commitment or direction towards that end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on Android
 instead of Java.


 
 
 Have you experimented with the android toolchain? Successfully built
 a GDC for it?
 I'm keen to get on with it the moment a working toolchain appears,
 regardless if druntime/phobos builds/works.
 


Here's a toolchain, can't guarantee that it works though ;-)
http://www.mediafire.com/?i5at6mlzo60y4
(linux only, 32bit)

Couldn't test the toolchain in any way yet. I think to compile you'll
need to uses the --sysroot switch:
http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
and you'll have to use -fno-section-anchors of course.

A druntime build is included, but it maybe won't work at all.
Feb 04 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:

 On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So...=A0Will D and Android GUI libraries be able to replace Java in th=






e

 next
 two years? Is there a commitment or direction towards that end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on Android
 instead of Java.



 Have you experimented with the android toolchain? Successfully built a GD=


C

 for it?
 I'm keen to get on with it the moment a working toolchain appears,
 regardless if druntime/phobos builds/works.


As soon as I've got some things off my plate with getting GDC out the
door. I intend to get it going on my Android and my ARM7 plug. :)

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 02 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 2 February 2012 18:54, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:

 On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So...=A0Will D and Android GUI libraries be able to replace Java in t=








he

 next
 two years? Is there a commitment or direction towards that end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on Android
 instead of Java.



 Have you experimented with the android toolchain? Successfully built a G=




DC

 for it?
 I'm keen to get on with it the moment a working toolchain appears,
 regardless if druntime/phobos builds/works.


 As soon as I've got some things off my plate with getting GDC out the
 door. I intend to get it going on my Android and my ARM7 plug. :)


To answer your question though, I have an old copy that worked on my
ARM plug device back a few months ago when I started experimenting.  I
intend to pick it back up soon though.



--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 02 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 2 February 2012 20:57, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 2 February 2012 18:54, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:

 On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So... Will D and Android GUI libraries be able to replace Java in the
 next
 two years? Is there a commitment or direction towards that end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on Android
 instead of Java.



 Have you experimented with the android toolchain? Successfully built a




 GDC

 for it?
 I'm keen to get on with it the moment a working toolchain appears,
 regardless if druntime/phobos builds/works.


 As soon as I've got some things off my plate with getting GDC out the
 door. I intend to get it going on my Android and my ARM7 plug. :)


 To answer your question though, I have an old copy that worked on my
 ARM plug device back a few months ago when I started experimenting.  I
 intend to pick it back up soon though.



Is the NDK's ARM7 toolchain modified in any way from stock GCC? why do they
provide their own toolchain? shouldn't they just build it from GCC main?
Feb 02 2012
parent Johannes Pfau <nospam example.com> writes:
Am Thu, 2 Feb 2012 22:28:19 +0200
schrieb Manu <turkeyman gmail.com>:


 On 2 February 2012 20:57, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 

 On 2 February 2012 18:54, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:

 On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So... Will D and Android GUI libraries be able to replace
 Java in the next
 two years? Is there a commitment or direction towards that
 end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on
 Android instead of Java.



 Have you experimented with the android toolchain? Successfully
 built a




 GDC

 for it?
 I'm keen to get on with it the moment a working toolchain
 appears, regardless if druntime/phobos builds/works.


 As soon as I've got some things off my plate with getting GDC out
 the door. I intend to get it going on my Android and my ARM7
 plug. :)


 To answer your question though, I have an old copy that worked on my
 ARM plug device back a few months ago when I started
 experimenting.  I intend to pick it back up soon though.


 
 
 Is the NDK's ARM7 toolchain modified in any way from stock GCC? why


Well, they have their own build systems/scripts (and those are not
that easy to understand and they're huge). Cross compilers are usually
built with such scripts (crosstool is a famous one, openembedded has
some stuff too) as building them manually can be a pita.

 do they provide their own toolchain? shouldn't they just build it
 from GCC main?
 


I guess you mean why they use different sources? They add some patches
to GCC, but afaik they try to upstream most of those now.
See /android-ndk-r7/build/tools/toolchain-patches/gcc/

Regarding toolchain binaries, you'll need special compiler/optimization
flags depending on the processor you actually target. IIRC gcc also
needs information about the C library your targeting and some kernel
headers, so you'll need different binaries for different systems(eglibc
glibc uclibc bionic), abis (arm-eabi-gcc, gnueabi). Android uses
arm-eabi-gcc and their own bionic C library, while other linux based
ARM systems usually use glibc and gnueabi.

BTW: when googling for the android ndk i found this:
http://michael.f1337.us/2011/11/19/rebuilding-the-android-ndk-for-objective-c-support/
this could actually be useful when trying to add D
support to the ndk.
Feb 02 2012
prev sibling parent J Arrizza <cppgent0 gmail.com> writes:
On Thu, Feb 2, 2012 at 7:18 AM, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:

 So... Will D and Android GUI libraries be able to replace Java in the


 next

 two years? Is there a commitment or direction towards that end?


 Not replace, but it is my goal to certainly have it a viable
 alternative, just as you could alternatively use C/C++ on Android
 instead of Java.

 Iain,


A viable alternative will, in my opinion, pave the road (interstate?)
towards eventually replacing Java. I currently use embedded Java (Jamvm &
GNU classpath) and I am planning to move to Android when my project has
some time. Others in my organization are already on board, it's just a
matter of appropriate timing in the project.

I like to believe I made a  rational choice with Java and I also like to
believe that moving to Android and the dalvik JVM is an even better
rational choice and so, again,  it is very likely that others are  making
the same choices.

And there is strong evidence Android has been chosen in the current wave of
devices. I've been looking at Android for the last couple of years, and
this was front page news recently:
http://www.medicalelectronicsdesign.com/article/android-best-operating-system-choice-many-medical-applications

I also know I am very dissatisfied with Java's speed and so it is very
likely others are dissatisfied too. They will be or already looking for a
replacement.

If D is ready, it will be snapped up. I think most embedded device people
who went to Java are ex-C/C++ (as I am) and even though the benefits are
huge, Java's slow speed grates on their nerves (like it does mine). D is
the next logical step.

I have only a few hours a week to dedicate to this but if you can give me
some instructions & downloads, I'd like to try whatever you have.

John
Feb 03 2012
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Sat, 28 Jan 2012 17:58:40 -0800, J Arrizza wrote:

Isn't this the killer "app" for D (like ROR for Ruby, etc.) ?  There was a
thread a while ago where someone said the popularity of a language depends
on an app that drives the use of that language.

There's also the up-coming ARM based Blackberry Pi. That could achieve a 
lot of penetration in the education sector internationally.

Catch em while they're young!

Steve
Feb 05 2012
parent reply "Ludovic Silvestre" <ludovic.silvestre gmail.com> writes:
Don't you mean Raspberry Pi?

http://www.raspberrypi.org/

On Sunday, 5 February 2012 at 15:45:11 UTC, Steve Teale wrote:

 On Sat, 28 Jan 2012 17:58:40 -0800, J Arrizza wrote:

 Isn't this the killer "app" for D (like ROR for Ruby, etc.) ?  
 There was a
 thread a while ago where someone said the popularity of a 
 language depends
 on an app that drives the use of that language.

 There's also the up-coming ARM based Blackberry Pi. That could 
 achieve a lot of penetration in the education sector 
 internationally.

 Catch em while they're young!

 Steve
Feb 06 2012
parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Mon, 06 Feb 2012 12:22:45 +0100, Ludovic Silvestre wrote:


 Don't you mean Raspberry Pi?
 


Ah, yes - I keep doing that.

I have an virtualbox emulator for it up and running, and will try to 
build GDC within that as soon as I get myself into town and buy more 
memory.

Steve
Feb 07 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Hi, this is me again with some "size matters" topic. This time, it's not  
the executable size, no! Instead I want to discuss a runtime memory  
footprint and speed issue that affects everyone, and how to improve the  
situation dramatically.

In D we allocate memory through the GC, that is initialized according to  
the type's .init, which gives us a save default. In most cases this will  
result in the memory block being zeroed out, like in the case of  
allocating ubyte[] buffers. Let's assume, we have a program that allocates  
some buffers in advance, that it may not use fully. This often happens  
when the input data is much smaller than the anticipated case. So our  
memory manager should handle this situation well:
   o  zero out a memory block
   o  we probably don't need all of it

So here is a small benchmark that allocates 512 * 1 MB, first using the  
typical method: new ubyte[1024 * 1024]. The oputput is:

	** new ubyte[1024 * 1024]
	   ressource usage: +526840 KB
	   user time: +0.098s | sys. time: +0.368s

As expected we have a physical memory usage increase of ~512 MB and spent  
a considerable amount of time in the system to find free memory blocks and  
in our program to initialize the data to zero. Can we use the GC more  
directly? Let's try GC.calloc:

	** GC.calloc(1024 * 1024)
	   ressource usage: +525104 KB
	   user time: +0.089s | sys. time: +0.370s

Again, 512 MB and about the same time. Nothing gained, but my RAM is  
starting to fill up. By the way, how does a good old system call to  
'malloc' compare? That gives us a block of garbage 'initialized' data - a  
situation we left behind for good in D! So here we go with another test:

	** malloc(1024 * 1024)
	   ressource usage: +2048 KB
	   user time: +0.000s | sys. time: +0.002s

Oh nice! May I say... these 512 calls were for free? 2 MB and 0.002  
seconds ain't worth talking about. The operating system didn't actually  
allocate the memory, it merely gave us a virtual memory range to use. Only  
when we write to the memory will physical memory be bound. That's perfect  
for a generously sized buffer, right? Well... we still want it zeroed out,  
so let's initialize this data to zero with ptr[0 .. 1024 * 1024] = 0:

	** malloc(1024 * 1024) + zero out
	   ressource usage: +526336 KB
	   user time: +0.053s | sys. time: +0.366s

... and we are back at square one. With the exception, that the user time  
is notably lower. What we need is a facility that gives us lazily  
allocated zeroed out memory. And guess what, it's not too much to ask for.  
Here is 'calloc' to the rescue:

	** calloc(1, 1024 * 1024)
	   ressource usage: +2048 KB
	   user time: +0.001s | sys. time: +0.001s

How does it work? The operating system fakes the memory allocation and  
just gives us 131072 references to a special read-only memory page of  
zeroes. The semantic is copy-on-write. So we start with a view on zeroed  
out memory and get the real thing once we write into it. (Sorry, if I tell  
some of you nothing new, but I just found this out today ;) )
The question I have is, should we go and improve druntime with that  
knowledge? I'm not aware of any caveats, are there any?
Thanks for reading and the test program for Linux is in the attachment (I  
used GDC to compile).

-- Marco
Feb 07 2012
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Aw Opera fooled me again into answering a post, instead of creating a new  
one - ignore this, I'll repost a proper thread.
Feb 07 2012