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:
--f46d040f9ca2a2a68b04b7a11152
Content-Type: text/plain; charset=ISO-8859-1

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


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 --f46d040f9ca2a2a68b04b7a11152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gma= il_quote"><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>=A0&gt; As far as I know, gdc can already produce ARM code since it us= es the<br>=A0&gt; gcc backend. All we need now is a nice native D interface= to the<br>=A0&gt; Android libraries, and I&#39;ll be a very very happy man= .<br> </div></blockquote></div></div></blockquote><div><br></div><div>Isn&#39;t t= his the killer &quot;app&quot; for D (like ROR for Ruby, etc.) ? =A0There w= as a thread a while ago where someone said the popularity of a language dep= ends on an app that drives the use of that language.</div> <div><br></div><div>So why not D-based Android applications?=A0Consider:</d= iv></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><d= iv class=3D"gmail_quote"><div>- D-based Android apps running on millions of= phones, tablets, iPad killers, etc.</div> </div><div class=3D"gmail_quote"><div>- Android developers choose Java for = quick and dirty, or choose D when speed is of the essence.=A0&quot;Quick an= d dirty&quot; becomes less of an issue as more of the common JDK functional= ity is added to Phobos or is at least available for D. As some critical poi= nt is reached, why choose Java at all?</div> </div><div class=3D"gmail_quote"><div>- As more devices use Android, it&#39= ;s GUI library will become more popular. =A0With a bit of work, PC apps wil= l start using D-based Android GUIs for cross-platform development. Forget Q= T, GTK, etc. etc., use Android for the app that runs on the PC, on the tabl= et and on your phone.=A0</div> </div></blockquote><div><br></div><div>John</div> --f46d040f9ca2a2a68b04b7a11152--
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
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 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 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


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


 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?

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. It's never been documented, it's only mentioned in bug #120 and using a gdc 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 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=


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


 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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363f351fdec604b7a877eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=


         > 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? --20cf30363f351fdec604b7a877eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 January 2012 04:02, Alex R=C3=B8nne Peters= en <span dir=3D"ltr">&lt;<a href=3D"mailto:xtzgzorex gmail.com">xtzgzorex g= mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 29-01-2012 02:58, J Arrizza wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 &gt; As far as I know, gdc can already produce= ARM code since it<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0uses the<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 &gt; gcc backend. All we need now is a nice na= tive D interface to the<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 &gt; Android libraries, and I&#39;ll be a very= very happy man.<br> <br> <br> Isn&#39;t this the killer &quot;app&quot; for D (like ROR for Ruby, etc.) ?= =C2=A0There was<br> a thread a while ago where someone said the popularity of a language<br> depends on an app that drives the use of that language.<br> </blockquote> <br></div> Yes, D on Android would be great.<br> <br> In fact, D already runs on Android if you do some tweaks to the GDC build. = I&#39;ve managed to get D apps running on both a Galaxy Tab 10.1 and an Efi= ka MX.</blockquote><div><br></div><div>Really? Where is the toolchain, and = why isn&#39;t it available/mentioned on d-p-l?</div> </div> --20cf30363f351fdec604b7a877eb--
Jan 29 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235433297ea104ff04b7a88927
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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


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


 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. --00235433297ea104ff04b7a88927 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 January 2012 07:42, Andrew Wiley <span dir= =3D"ltr">&lt;<a href=3D"mailto:wiley.andrew.j gmail.com">wiley.andrew.j gma= il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Sat, Jan 28, 2012 at 9:11 PM, Ni= ck Sabalausky &lt;a a.a&gt; wrote:<br> &gt; &quot;Alex R=C3=B8nne Petersen&quot; &lt;<a href=3D"mailto:xtzgzorex g= mail.com">xtzgzorex gmail.com</a>&gt; wrote in message<br> &gt; news:jg29bs$2dm8$1 digitalmars.com...<br> &gt;&gt;<br> &gt;&gt; Yes, D on Android would be great.<br> &gt;&gt;<br> &gt;&gt; In fact, D already runs on Android if you do some tweaks to the GD= C build.<br> &gt;&gt; I&#39;ve managed to get D apps running on both a Galaxy Tab 10.1 a= nd an Efika<br> &gt;&gt; MX.<br> &gt;&gt;<br> &gt;<br> &gt; CAN I HAZ DETAILS PLZ?<br> &gt; KTHNXBYE<br> &gt;<br> <br> </div></div>I can&#39;t speak to Android, but I know that building GDC on A= RM is<br> fairly routine these days. Make sure to build with<br> DFLAGS=3D&quot;-fno-section-anchors&quot; in the environment, but otherwise= ,<br> follow the normal build instructions.<br> I would assume the same would apply when building a cross compiler for<br> ARM (although the normal build instructions are just a bit harder).<br> </blockquote></div><br><div>Am I the only one that finds it annoying that a= ny dev that wants to use D seems to have to A) use linux, and B) know how t= o build GCC on their own?</div><div>How many people does this turn away?</d= iv> <div><br></div><div>Build scripts and mingw binaries plz! Then devs can act= ually get to work and start writing software. 90% of my time spent with D i= nvolves trying to fuck around with msys/cygwin environments, trying to buil= d toolchains, and having an endless stream of related problems. Complete wa= ste of my time, and loss of community contribution.</div> --00235433297ea104ff04b7a88927--
Jan 29 2012
prev sibling next sibling parent J Arrizza <cppgent0 gmail.com> writes:
--f46d041a439e961d9b04b7b3e4da
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.


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 --f46d041a439e961d9b04b7b3e4da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jan 28, 2012 at 6:02 PM, Alex R=F8nne Pe= tersen <span dir=3D"ltr">&lt;<a href=3D"mailto:xtzgzorex gmail.com">xtzgzor= ex gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">In fact, D already runs on Android if you do some tweaks = to the GDC build. I&#39;ve managed to get D apps running on both a Galaxy T= ab 10.1 and an Efika MX.</div><div class=3D"im"><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"> I think that&#39;s pushing it. I see no reason to include something that do= main and target specific in the standard library.=A0</blockquote></div></bl= ockquote><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">The concept of a cross-pla= tform 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 exp= erience they expect and want.</blockquote> </div></blockquote><div><br></div><div>Interesting response.</div><div><br>= </div><div>Look at the IQ bell curve. Now follow this:</div></div><blockquo= te style=3D"margin:0 0 0 40px;border:none;padding:0px"><div class=3D"gmail_= quote"> <div>- to be popular is to widen the appeal of D to 2 sigmas of that curve.= </div></div><div class=3D"gmail_quote"><div>- to widen the appeal is to mak= e D easy enough for 95% of the developer=A0population=A0to use it without a= ny hassle</div> </div><div class=3D"gmail_quote"><div>- &quot;no hassle&quot; is equivalent= to make it simple enough for the farthest left hand side of the curve.</di= v><div>- and that means dead simple to install, dead simple to code in, dea= d simple to determine and fix when it goes wrong, dead simple to get it wor= king on any OS they are used to working on.</div> </div><div class=3D"gmail_quote"><div>- that means there is no &quot;that&#= 39;s pushing it&quot; or &quot;concept is broken&quot; or &quot;all you hav= e to do is some tweaks&quot; or any other rationalization. If they need it,= they get it. Period.</div> </div></blockquote><div class=3D"gmail_quote"><div><br></div><div>In short,= to make D popular is a hell of a lot more work.=A0<span style=3D"backgroun= d-color:rgb(255,255,255);font-family:verdana,helvetica,arial">=A0</span><sp= an style=3D"background-color:rgb(255,255,255);font-family:verdana,helvetica= ,arial">Samuel Johnson said &quot;I did not have time to write you a short = letter, so I wrote you a long one instead.&quot; Paraphrase that for D.</sp= an></div> <div><br></div><div>So another, better, question: Do you -- we -- want to m= ake D a popular language or not?</div><div><br></div><div>If not, that impl= ies one set of development and architectural strategies. =A0If yes, it impl= ies another set. The two sets have some but little intersection. And that m= eans you have to choose the end goal you want now and, once chosen, you hav= e to stick to it.</div> <div><br></div><div>John</div></div> --f46d041a439e961d9b04b7b3e4da--
Jan 29 2012
prev sibling next sibling parent J Arrizza <cppgent0 gmail.com> writes:
--f46d040f9ca207499404b7fc524e
Content-Type: text/plain; charset=ISO-8859-1

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.

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 --f46d040f9ca207499404b7fc524e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sun, Jan 29, 2012 at 4:26 PM, J Arrizza <span= dir=3D"ltr">&lt;<a href=3D"mailto:cppgent0 gmail.com">cppgent0 gmail.com</= a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"gmail_quote"><div class=3D"im"><br></div></div><div class=3D"= gmail_quote"><div>So another, better, question: Do you -- we -- want to mak= e D a popular language or not?</div><div><br></div><div>If not, that implie= s one set of development and architectural strategies. =A0If yes, it implie= s another set. The two sets have some but little intersection. And that mea= ns you have to choose the end goal you want now and, once chosen, you have = to stick to it.</div> <div><br></div></div></blockquote><div><br></div><div>No response to this?<= /div><div><br></div><div>I currently have an embedded Java application runn= ing on an ARM. I am looking for a replacement language and =A0associated li= braries, 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=A0under-powered=A0processor.</div> <div><br></div><div>I chose Java for this device because I didn&#39;t want = to divert my developers re-inventing the wheel or playing the &quot;match t= he library versions&quot; game. The JDK is big and it&#39;s clean. It is se= lf-consistent. Java is a simple=A0language, there is no struggling with odd= obscure error messages or compiler errors. There is a huge breadth and dep= th of community support.</div> <div><br></div><div>For the current device, using Java has paid off hugely.= It&#39;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 writ= e and deliver). If we need some utility or functionality, chances are it&#3= 9;s already been written and debugged over many years and by millions of pe= ople.</div> <div><br></div><div>The down side is Java is slow. That&#39;s why I&#39;m l= ooking 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 layer= s) on an ARM processor running embedded linux. It has to cross-compile beca= use we simulate the device and debug on our workstations. D looks like a cu= stom fit for this situation!</div> <div><br></div><div>On the other hand D is facing a catch-22. It can&#39;t = get a full suite of support code, IDEs, etc until its popular and it won&#3= 9;t get popular until it gets all of that ready to go up-front. The only so= lution is to leap-frog using existing technology on an already popular plat= form.=A0</div> <div><br></div><div>The Android GUI libraries provide two things towards th= at end: a platform for D to take off from and the beginnings of=A0debugged = GUI code. The popularity of Android will pull D along with it, especially i= f D can find a niche in the needs of those Android application developers w= ho want speed. As D&#39;s relevant libraries fill out, there will be less a= nd less a need to use Java and it will gradually take over as the predomina= nt language for serious apps on Android.</div> <div><br></div><div>So...=A0Will D and Android GUI libraries be able to rep= lace Java in the next two years? Is there a commitment or direction towards= that end?</div><div><br></div><div>John</div><div><br></div></div> --f46d040f9ca207499404b7fc524e--
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=

 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 Manu <turkeyman gmail.com> writes:
--e89a8f2354d513d91f04b7ff1e0e
Content-Type: text/plain; charset=UTF-8

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

 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. --e89a8f2354d513d91f04b7ff1e0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 2 February 2012 17:18, Iain Buclaw <span dir= =3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.com" target=3D"_blank">ibucla= w ubuntu.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On 2 February 2012 14:50, J Arrizza &lt;<a href=3D"mailto:cppgent0 gma= il.com" target=3D"_blank">cppgent0 gmail.com</a>&gt; wrote:<br> &gt;<br> &gt; So...=C2=A0Will D and Android GUI libraries be able to replace Java in= the next<br> &gt; two years? Is there a commitment or direction towards that end?<br> &gt;<br> <br> </div>Not replace, but it is my goal to certainly have it a viable<br> alternative, just as you could alternatively use C/C++ on Android<br> instead of Java.</blockquote><div><br></div><div>Have you experimented with= the android toolchain? Successfully built a GDC for it?</div><div>I&#39;m = keen to get on with it the moment a working toolchain appears, regardless i= f druntime/phobos builds/works.</div> </div> --e89a8f2354d513d91f04b7ff1e0e--
Feb 02 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=



 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=

 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=




 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=


 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 Manu <turkeyman gmail.com> writes:
--0023544717e471603204b80109fa
Content-Type: text/plain; charset=UTF-8

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


 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? --0023544717e471603204b80109fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 2 February 2012 20:57, Iain Buclaw <span dir= =3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw ubuntu.com</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 2 February 2012 18:54, Iain Bucl= aw &lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw ubuntu.com</a>&gt; wro= te:<br> &gt; On 2 February 2012 18:10, Manu &lt;<a href=3D"mailto:turkeyman gmail.c= om">turkeyman gmail.com</a>&gt; wrote:<br> &gt;&gt; On 2 February 2012 17:18, Iain Buclaw &lt;<a href=3D"mailto:ibucla= w ubuntu.com">ibuclaw ubuntu.com</a>&gt; wrote:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; On 2 February 2012 14:50, J Arrizza &lt;<a href=3D"mailto:cppg= ent0 gmail.com">cppgent0 gmail.com</a>&gt; wrote:<br> &gt;&gt;&gt; &gt;<br> &gt;&gt;&gt; &gt; So...=C2=A0Will D and Android GUI libraries be able to re= place Java in the<br> &gt;&gt;&gt; &gt; next<br> &gt;&gt;&gt; &gt; two years? Is there a commitment or direction towards tha= t end?<br> &gt;&gt;&gt; &gt;<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; Not replace, but it is my goal to certainly have it a viable<b= r> &gt;&gt;&gt; alternative, just as you could alternatively use C/C++ on Andr= oid<br> &gt;&gt;&gt; instead of Java.<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; Have you experimented with the android toolchain? Successfully bui= lt a GDC<br> &gt;&gt; for it?<br> &gt;&gt; I&#39;m keen to get on with it the moment a working toolchain appe= ars,<br> &gt;&gt; regardless if druntime/phobos builds/works.<br> &gt;<br> &gt; As soon as I&#39;ve got some things off my plate with getting GDC out = the<br> &gt; door. I intend to get it going on my Android and my ARM7 plug. :)<br> &gt;<br> <br> </div></div>To answer your question though, I have an old copy that worked = on my<br> ARM plug device back a few months ago when I started experimenting. =C2=A0I= <br> intend to pick it back up soon though.</blockquote><div><br></div><div>Is t= he NDK&#39;s ARM7 toolchain modified in any way from stock GCC? why do they= provide their own toolchain? shouldn&#39;t they just build it from GCC mai= n?=C2=A0</div> </div> --0023544717e471603204b80109fa--
Feb 02 2012
prev sibling next sibling 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


 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?
 

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 next sibling parent J Arrizza <cppgent0 gmail.com> writes:
--14dae9c09e06ecca9604b80ee4e6
Content-Type: text/plain; charset=ISO-8859-1

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

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

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 --14dae9c09e06ecca9604b80ee4e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Feb 2, 2012 at 7:18 AM, Iain Buclaw <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw ubuntu.com<= /a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2 February 2012 14:50, J Arrizza &lt;<a href=3D"mailto= :cppgent0 gmail.com">cppgent0 gmail.com</a>&gt; wrote:<br> &gt;<br> &gt; So...=A0Will D and Android GUI libraries be able to replace Java in th= e next<br> &gt; two years? Is there a commitment or direction towards that end?<br> &gt;<br>Not replace, but it is my goal to certainly have it a viable</div> alternative, just as you could alternatively use C/C++ on Android<br> instead of Java.<br><font color=3D"#888888"><br></font></blockquote></div><= div>Iain,</div><div><br></div><div>A viable alternative will, in my opinion= , pave the road (interstate?) towards eventually replacing Java. I currentl= y use embedded Java (Jamvm &amp; GNU classpath) and I am planning to move t= o Android when my project has some time. Others in my organization are alre= ady on board, it&#39;s just a matter of appropriate timing in the project.<= /div> <div><br></div><div>I like to believe I made a =A0rational 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, =A0it is very likely that other= s are =A0making the same choices.</div> <div><br></div><div>And there is strong evidence Android has been chosen in= the current wave of devices. I&#39;ve been looking at Android for the last= couple of years, and this was front page news recently:</div><div><a href= =3D"http://www.medicalelectronicsdesign.com/article/android-best-operating-= system-choice-many-medical-applications">http://www.medicalelectronicsdesig= n.com/article/android-best-operating-system-choice-many-medical-application= s</a></div> <div><br></div><div>I also know I am very dissatisfied with Java&#39;s spee= d and so it is very likely others are dissatisfied too.=A0They will be or a= lready looking for a replacement.=A0</div><div><br></div><div>If D is ready= , it will be snapped up. I think most embedded device people who went to Ja= va are ex-C/C++ (as I am) and even though the benefits are huge, Java&#39;s= slow speed grates on their nerves (like it does mine). D is the next logic= al step.</div> <div><br></div><div>I have only a few hours a week to dedicate to this but = if you can give me some instructions &amp; downloads, I&#39;d like to try w= hatever you have.</div><div><br></div><div>John</div><div><br></div> --14dae9c09e06ecca9604b80ee4e6--
Feb 03 2012
prev sibling next sibling 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

 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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?
 

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
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
------------LRoRWsaLEWTqilnSsrKqMm
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

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
------------LRoRWsaLEWTqilnSsrKqMm
Content-Disposition: attachment; filename=memory_benchmark.d
Content-Type: application/octet-stream; name=memory_benchmark.d
Content-Transfer-Encoding: Base64

aW1wb3J0IGNvcmUubWVtb3J5LCBzdGQuc3RkaW8sIGNvcmUuc3lzLnBvc2l4LnN5
cy50aW1lLCBjb3JlLnN5cy5wb3NpeC5zdGRsaWI7CgplbnVtIEFMTE9DUyA9IDUx
MjsKCnZvaWQgbWFpbigpCnsKCXVieXRlW11bQUxMT0NTXSB4OwoJdm9pZCpbQUxM
T0NTXSB5LCB3LCB6OwoJdWJ5dGUqW0FMTE9DU10gcTsKCUdDLmRpc2FibGUoKTsK
CWF1dG8gcHJldiA9IHByaW50X3Jlc3NvdXJjZXMoKTsKCgl3cml0ZWxuKCIqKiBu
ZXcgdWJ5dGVbMTAyNCAqIDEwMjRdIik7Cglmb3JlYWNoIChpOyAwIC4uIEFMTE9D
UykgeFtpXSA9IG5ldyB1Ynl0ZVsxMDI0ICogMTAyNF07CglwcmV2ID0gcHJpbnRf
cmVzc291cmNlcygmcHJldik7CgoJd3JpdGVsbigiKiogR0MuY2FsbG9jKDEwMjQg
KiAxMDI0KSIpOwoJZm9yZWFjaCAoaTsgMCAuLiBBTExPQ1MpIHlbaV0gPSBHQy5j
YWxsb2MoMTAyNCAqIDEwMjQpOwoJcHJldiA9IHByaW50X3Jlc3NvdXJjZXMoJnBy
ZXYpOwoKCXdyaXRlbG4oIioqIG1hbGxvYygxMDI0ICogMTAyNCkiKTsKCWZvcmVh
Y2ggKGk7IDAgLi4gQUxMT0NTKSB6W2ldID0gbWFsbG9jKDEwMjQgKiAxMDI0KTsK
CXByZXYgPSBwcmludF9yZXNzb3VyY2VzKCZwcmV2KTsKCgl3cml0ZWxuKCIqKiBt
YWxsb2MoMTAyNCAqIDEwMjQpICsgemVybyBvdXQiKTsKCWZvcmVhY2ggKGk7IDAg
Li4gQUxMT0NTKQoJewoJCXFbaV0gPSBjYXN0KHVieXRlKikgbWFsbG9jKDEwMjQg
KiAxMDI0KTsKCQlxW2ldWzAgLi4gMTAyNCAqIDEwMjRdID0gMDsKCX0KCXByZXYg
PSBwcmludF9yZXNzb3VyY2VzKCZwcmV2KTsKCXdyaXRlbG4oIioqIGNhbGxvYygx
LCAxMDI0ICogMTAyNCkiKTsKCWZvcmVhY2ggKGk7IDAgLi4gQUxMT0NTKSB3W2ld
ID0gY2FsbG9jKDEsIDEwMjQgKiAxMDI0KTsKCXByZXYgPSBwcmludF9yZXNzb3Vy
Y2VzKCZwcmV2KTsKfQoKcnVzYWdlIHByaW50X3Jlc3NvdXJjZXMocnVzYWdlKiBw
cmV2ID0gbnVsbCkKewoJcnVzYWdlIHJlczsKCWdldHJ1c2FnZShydXNhZ2Vfd2hv
LlNFTEYsICZyZXMpOwoJaWYgKHByZXYgIWlzIG51bGwpCgl7CgkJd3JpdGVmbG4o
IiAgIHJlc3NvdXJjZSB1c2FnZTogKyVzIEtCIiwgcmVzLnJ1X21heHJzcyAtIHBy
ZXYucnVfbWF4cnNzKTsKCQl3cml0ZWZsbigiICAgdXNlciB0aW1lOiArJS4zZnMg
fCBzeXMuIHRpbWU6ICslLjNmcyIsCgkJICAgICAgICAgdGltZV9kaWZmKHByZXYu
cnVfdXRpbWUsIHJlcy5ydV91dGltZSksCgkJICAgICAgICAgdGltZV9kaWZmKHBy
ZXYucnVfc3RpbWUsIHJlcy5ydV9zdGltZSkpOwoJfQoJcmV0dXJuIHJlczsKfQoK
ZG91YmxlIHRpbWVfZGlmZihyZWYgdGltZXZhbCBhLCByZWYgdGltZXZhbCBiKQp7
CglyZXR1cm4gYi50dl9zZWMgLSBhLnR2X3NlYyArIDAuMDAwMDAxICogKGIudHZf
dXNlYyAtIGEudHZfdXNlYyk7Cn0KCmV4dGVybihDKSBpbnQgZ2V0cnVzYWdlIChy
dXNhZ2Vfd2hvIHdobywgcnVzYWdlKiB1c2FnZSk7CQoKZW51bSBydXNhZ2Vfd2hv
IDogaW50IHsgU0VMRiA9IDAsIENISUxEUkVOID0gLTEsIEJPVEggPSAtMiwgVEhS
RUFEID0gMSB9CgpzdHJ1Y3QgcnVzYWdlCnsKCXRpbWV2YWwgcnVfdXRpbWU7ICAg
ICAgICAvKiogdXNlciB0aW1lIHVzZWQgKi8KCXRpbWV2YWwgcnVfc3RpbWU7ICAg
ICAgICAvKiogc3lzdGVtIHRpbWUgdXNlZCAqLwoJbG9uZyAgICBydV9tYXhyc3M7
ICAgICAgIC8qKiBtYXhpbXVtIHJlc2lkZW50IHNldCBzaXplICovCglsb25nICAg
IHJ1X2l4cnNzOyAgICAgICAgLyoqIGludGVncmFsIHNoYXJlZCBtZW1vcnkgc2l6
ZSAqLwoJbG9uZyAgICBydV9pZHJzczsgICAgICAgIC8qKiBpbnRlZ3JhbCB1bnNo
YXJlZCBkYXRhIHNpemUgKi8KCWxvbmcgICAgcnVfaXNyc3M7ICAgICAgICAvKiog
aW50ZWdyYWwgdW5zaGFyZWQgc3RhY2sgc2l6ZSAqLwoJbG9uZyAgICBydV9taW5m
bHQ7ICAgICAgIC8qKiBwYWdlIHJlY2xhaW1zICovCglsb25nICAgIHJ1X21hamZs
dDsgICAgICAgLyoqIHBhZ2UgZmF1bHRzICovCglsb25nICAgIHJ1X25zd2FwOyAg
ICAgICAgLyoqIHN3YXBzICovCglsb25nICAgIHJ1X2luYmxvY2s7ICAgICAgLyoq
IGJsb2NrIGlucHV0IG9wZXJhdGlvbnMgKi8KCWxvbmcgICAgcnVfb3VibG9jazsg
ICAgICAvKiogYmxvY2sgb3V0cHV0IG9wZXJhdGlvbnMgKi8KCWxvbmcgICAgcnVf
bXNnc25kOyAgICAgICAvKiogbWVzc2FnZXMgc2VudCAqLwoJbG9uZyAgICBydV9t
c2dyY3Y7ICAgICAgIC8qKiBtZXNzYWdlcyByZWNlaXZlZCAqLwoJbG9uZyAgICBy
dV9uc2lnbmFsczsgICAgIC8qKiBzaWduYWxzIHJlY2VpdmVkICovCglsb25nICAg
IHJ1X252Y3N3OyAgICAgICAgLyoqIHZvbHVudGFyeSBjb250ZXh0IHN3aXRjaGVz
ICovCglsb25nICAgIHJ1X25pdmNzdzsgICAgICAgLyoqIGludm9sdW50YXJ5ICIg
Ki8KfQo=

------------LRoRWsaLEWTqilnSsrKqMm--
Feb 07 2012
prev sibling 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