digitalmars.D - killer App for D? (was: State of D on iOS/Android)
- J Arrizza (15/19) Jan 28 2012 Isn't this the killer "app" for D (like ROR for Ruby, etc.) ? There was...
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (12/33) Jan 28 2012 Yes, D on Android would be great.
- Nick Sabalausky (4/8) Jan 28 2012 CAN I HAZ DETAILS PLZ?
- Andrew Wiley (9/20) Jan 28 2012 a
- Chad J (8/28) Jan 28 2012 http://interaxiom.blogspot.com/2011/08/android-d-stuff.html
- Johannes Pfau (19/51) Jan 29 2012 GDC on Android is not the same as a GDC/ARM cross compiler. The android ...
- Manu (9/31) Jan 29 2012 Am I the only one that finds it annoying that any dev that wants to use ...
- Johannes Pfau (16/52) Jan 29 2012 Some linux distributions ship gdc already, also following the gdc build
- Manu (6/21) Jan 29 2012 he
- J Arrizza (25/34) Jan 29 2012 Interesting response.
- J Arrizza (37/43) Feb 02 2012 No response to this?
- Iain Buclaw (8/10) Feb 02 2012 Not replace, but it is my goal to certainly have it a viable
- H. S. Teoh (15/17) Feb 02 2012 [...]
- Manu (5/14) Feb 02 2012 Have you experimented with the android toolchain? Successfully built a G...
- Johannes Pfau (10/30) Feb 04 2012 Here's a toolchain, can't guarantee that it works though ;-)
- Iain Buclaw (8/24) Feb 02 2012 C
- Iain Buclaw (9/30) Feb 02 2012 DC
- Manu (3/31) Feb 02 2012 Is the NDK's ARM7 toolchain modified in any way from stock GCC? why do t...
- Johannes Pfau (20/60) Feb 02 2012 Well, they have their own build systems/scripts (and those are not
- J Arrizza (24/34) Feb 03 2012 A viable alternative will, in my opinion, pave the road (interstate?)
- Steve Teale (8/8) Feb 05 2012 On Sat, 28 Jan 2012 17:58:40 -0800, J Arrizza wrote:
- Ludovic Silvestre (3/14) Feb 06 2012 Don't you mean Raspberry Pi?
- Steve Teale (6/8) Feb 07 2012 Ah, yes - I keep doing that.
- Marco Leise (58/58) Feb 07 2012 Hi, this is me again with some "size matters" topic. This time, it's not...
- Marco Leise (2/2) Feb 07 2012 Aw Opera fooled me again into answering a post, instead of creating a ne...
> As far as I know, gdc can already produce ARM code since it uses theIsn'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> 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.
Jan 28 2012
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 orI 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
"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
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...d.Yes, D on Android would be great. In fact, D already runs on Android if you do some tweaks to the GDC buil=aI've managed to get D apps running on both a Galaxy Tab 10.1 and an Efik=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).MX.CAN I HAZ DETAILS PLZ? KTHNXBYE
Jan 28 2012
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: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."Alex Rønne Petersen"<xtzgzorex gmail.com> wrote in message news:jg29bs$2dm8$1 digitalmars.com...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).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
Chad J wrote:On 01/29/2012 12:42 AM, Andrew Wiley wrote: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)On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky<a a.a> wrote: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."Alex Rønne Petersen"<xtzgzorex gmail.com> wrote in message news:jg29bs$2dm8$1 digitalmars.com...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).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? KTHNXBYEBuilding 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
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: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."Alex R=C3=B8nne Petersen" <xtzgzorex gmail.com> wrote in message news:jg29bs$2dm8$1 digitalmars.com...build.Yes, D on Android would be great. In fact, D already runs on Android if you do some tweaks to the GDCEfikaI've managed to get D apps running on both a Galaxy Tab 10.1 and anI 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).MX.CAN I HAZ DETAILS PLZ? KTHNXBYE
Jan 29 2012
Manu wrote:On 29 January 2012 07:42, Andrew Wiley <wiley.andrew.j gmail.com> wrote: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.On Sat, Jan 28, 2012 at 9:11 PM, Nick Sabalausky <a a.a> wrote: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?"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message news:jg29bs$2dm8$1 digitalmars.com...build.Yes, D on Android would be great. In fact, D already runs on Android if you do some tweaks to the GDCEfikaI've managed to get D apps running on both a Galaxy Tab 10.1 and anI 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).MX.CAN I HAZ DETAILS PLZ? KTHNXBYEBuild 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
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:he> 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?
Jan 29 2012
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 libraryInteresting 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. Johnand develop native UIs for each platform you wish to support. It is the only way to give users the experience they expect and want.
Jan 29 2012
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
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=exttwo 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
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
On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote: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.So... Will D and Android GUI libraries be able to replace Java in thenexttwo 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.
Feb 02 2012
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: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.On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote: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.So... Will D and Android GUI libraries be able to replace Java in thenexttwo 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.
Feb 04 2012
On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:On 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:eOn 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=CHave you experimented with the android toolchain? Successfully built a GD=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.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
On 2 February 2012 18:54, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:heOn 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=DCHave you experimented with the android toolchain? Successfully built a G=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.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';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. :)
Feb 02 2012
On 2 February 2012 20:57, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 2 February 2012 18:54, Iain Buclaw <ibuclaw ubuntu.com> wrote: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?On 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:GDCOn 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:Have you experimented with the android toolchain? Successfully built aSo... 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.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.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. :)
Feb 02 2012
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: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.On 2 February 2012 18:54, Iain Buclaw <ibuclaw ubuntu.com> wrote:Is the NDK's ARM7 toolchain modified in any way from stock GCC? whyOn 2 February 2012 18:10, Manu <turkeyman gmail.com> wrote:GDCOn 2 February 2012 17:18, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 2 February 2012 14:50, J Arrizza <cppgent0 gmail.com> wrote:Have you experimented with the android toolchain? Successfully built aSo... 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.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.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. :)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
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: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. JohnSo... Will D and Android GUI libraries be able to replace Java in thenexttwo 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,
Feb 03 2012
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
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
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
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
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