Re: Starting D with a project in mind.
Does anybody know if this is now fixed ? :- https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm I might be wrong but I could be facing this bug when trying to run any of the vibe.d samples, here's an example :- (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x001ad15c in gc_addRange () at ../../../../gcc-4.8-20131010/libphobos/libdruntime/gc/gc.d:293 #2 0x00174fb4 in vibe.utils.memory.T19FreeListObjectAllocTS4vibe4core7drivers13libevent2_tcp10TCPContextVb0Vb1Z.T5allocTC4vibe4core6driver10DriverCoreTPS6deimos6event212eventstruct10eventbaseTiTPS6deimos6event211bufferevent11buffereventTS4vibe4core3net14NetworkAddressTS4vibe4core3net14NetworkAddressZ.alloc() () #3 0x00034008 in vibe.core.drivers.libevent2_tcp.onConnect() () #4 0x00043430 in vibe.core.core.CoreTask.run() () #5 0x001a37fc in fiber_entryPoint () at ../../../../gcc-4.8-20131010/libphobos/libdruntime/core/thread.d:3800 #6 0xb6cbe0b0 in setcontext () from /lib/arm-linux-gnueabihf/libc.so.6 #7 0xb6cbe0b0 in setcontext () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Re: Starting D with a project in mind.
andrew@islay:~/dub$ ./build.sh Generating version file... Running gdmd... /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L) line 224 is trying to instantiate a Duration object. Any ideas ? Giving up on dub, I tried niaively to build one of the vibe.d samples directly :- andrew@islay:~/vibe.d/examples/http_server/source$ gdmd -I~/vibe.d/source app.d /data/home/andrew/vibe.d/source/vibe/stream/ssl.d:43: error: module bio is in file 'deimos/openssl/bio.d' which cannot be read Looks like I'm missing some openssl dependencies, where do these come from as they don't appear to be part of phobos ? Thanks
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote: andrew@islay:~/dub$ ./build.sh Generating version file... Running gdmd... /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L) line 224 is trying to instantiate a Duration object. Any ideas ? Giving up on dub, I tried niaively to build one of the vibe.d samples directly :- andrew@islay:~/vibe.d/examples/http_server/source$ gdmd -I~/vibe.d/source app.d /data/home/andrew/vibe.d/source/vibe/stream/ssl.d:43: error: module bio is in file 'deimos/openssl/bio.d' which cannot be read Looks like I'm missing some openssl dependencies, where do these come from as they don't appear to be part of phobos ? Thanks As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems...
Re: Starting D with a project in mind.
As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems... I've been using a Cubieboard A20, it's much better than a RPi as it has 1GB RAM, dual core armv7 and much better IO including on-board SATA for $50. The gcc /gdc build takes around 2 - 3 hours on that. You'll probably run into the same libphobos issues that I had, since there are many places where there are no ARM headers.
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote: Giving up on dub, I tried niaively to build one of the vibe.d samples directly This is something I have used with vibe.d in absence of dub (untested, from my memory): git clone https://github.com/D-Programming-Deimos/openssl git clone https://github.com/D-Programming-Deimos/libevent git clone https://github.com/rejectedsoftware/vibe.d cd myvibeapp rdmd --compiler=gdmd2 -I../openssl/ -I../libevent -I../vibe.d/source -J./views/ -version=VibeLibeventDriver --build-only source/app.d Usage of `rdmd` is crucial here as you need something to take care of compiling all imported modules. dmd/gdc/ldc don't do it on their own and you really don't want to track that module list manually ;) rdmd sources are here (it is a small trivial D app): https://github.com/D-Programming-Language/tools
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 22:52:42 UTC, Andrew wrote: andrew@islay:~/dub$ ./build.sh Generating version file... Running gdmd... /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L) line 224 is trying to instantiate a Duration object. Any ideas ? Here the problem is that your install script has provided only *.di files as bindings to druntime and `dub` tries to use some of those function for compile-time constfolding (CTFE) which requires having full function source. *.di are supposed to be bindings to library blobs for cases when you want to hide implementation from end user, no idea why those are used here. Normal DMD install puts those as plain *.d modules.
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 23:16:07 UTC, Brad Roberts wrote: I think you mean catch-22 rather than dead-end. There's not more people helping support ARM due to ARM not yet working well, so there's no developers. ARM's not exotic, it's just not on as many people's desktops. Thats been changing rapidly over the last several years. In my opinion catch-22 is partial case of a dead-end - something that blocks your effective forward movement :) ARM support is rather exotic among projects of current D users.
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 23:03:15 UTC, Andrew wrote: Thanks for your patience supporting me BTW. You are welcome. D development is pure open-source movement with all its pros and cons - almost anyone here will gladly help you not only because we care about a good public image but because it gives a chance that you may investigate and improve situation in currently under-explored domain, to the greater community benefit. It is very important to have someone with personal interest in such development areas, helping with few cheap advises is the very least we can do :)
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 09:11:16 UTC, Andrew wrote: As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems... I've been using a Cubieboard A20, it's much better than a RPi as it has 1GB RAM, dual core armv7 and much better IO including on-board SATA for $50. The gcc /gdc build takes around 2 - 3 hours on that. You'll probably run into the same libphobos issues that I had, since there are many places where there are no ARM headers. Ok, I logged onto my Pi during lunch break, and actually the compilation process went fine, and pragma(msg, __VERSION__); now correctly has 2063L as output. So in my recent experience: - GDC master branch doesn't compile properly, because it's missing the ARM-specific code. - GDC-jp91 master branch compiles, but is based on 2.060 and is too old to be useful. - GDC-jp91 arm branch seems to work, although Johannes has warned that there is some codegen bug when compiling with -O2. This is all now a bit confusing, but I expect GDC master branch to compile again for ARM when either frontend version 2.064 is released and merged into GDC (in a few weeks hopefully?), or Johannes' arm fork is merged into GDC (whenever he has time to find and fix his codegen bug). Then everything would be (relatively) easy again... Looking into dub / vibe.d is out of my lunch scope :-P
Re: Starting D with a project in mind.
I'm a very happy man ! Everything is built and working including dub and the http_server example from vibe.d. It's slow to build, but it executes quickly and strips down to about 3MB which is heavy but tolerable. Thanks to everybody for the help, now I can start learning D, exploring vibe.d and Pegged and hopefully make some good progress on my MUD. So to recap, to help anybody else building on ARM these are the steps I took :- mkdir gdc cd gdc wget http://gcc.igor.onlinedirect.bg/snapshots/LATEST-4.8/gcc-4.8-20131010.tar.bz2 tar xvf gcc-4.8-20131010.tar.bz2 git clone https://github.com/jpf91/GDC.git arm_gdc cd arm_gdc git checkout arm ./setup-gcc.sh ../gcc-4.8-20131010 cd ../ mkdir build cd build export C_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch) export EXTRA_CONF=-mfloat-abi=hard --with-float=hard ../gcc-4.8-20131010/configure --enable-languages=d --disable-bootstrap --prefix=/usr/local/gdc --disable-multilib --disable-softfloat --with-float=hard make -j2 sudo make install sudo cp ../arm_gdc/libphobos/libdruntime/core/time.d /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core sudo mv /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di.old I don't know why that last step was necessary but dub and a few other things didn't build without it. After that dub built fine once I'd hacked the build file to use gdc.
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote: I'm a very happy man ! Everything is built and working including dub and the http_server example from vibe.d. It's slow to build, but it executes quickly and strips down to about 3MB which is heavy but tolerable. Thanks to everybody for the help, now I can start learning D, exploring vibe.d and Pegged and hopefully make some good progress on my MUD. So to recap, to help anybody else building on ARM these are the steps I took :- mkdir gdc cd gdc wget http://gcc.igor.onlinedirect.bg/snapshots/LATEST-4.8/gcc-4.8-20131010.tar.bz2 tar xvf gcc-4.8-20131010.tar.bz2 git clone https://github.com/jpf91/GDC.git arm_gdc cd arm_gdc git checkout arm ./setup-gcc.sh ../gcc-4.8-20131010 cd ../ mkdir build cd build export C_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch) export EXTRA_CONF=-mfloat-abi=hard --with-float=hard ../gcc-4.8-20131010/configure --enable-languages=d --disable-bootstrap --prefix=/usr/local/gdc --disable-multilib --disable-softfloat --with-float=hard make -j2 sudo make install sudo cp ../arm_gdc/libphobos/libdruntime/core/time.d /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core sudo mv /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di.old I don't know why that last step was necessary but dub and a few other things didn't build without it. After that dub built fine once I'd hacked the build file to use gdc. Cool. I was posting in the D.GNU newsgroup about this when I noticed your update, so I included a link to this work around in my post [1]. Maybe Iain or any of the other gurus know of a better way, because the last part looks awfully dirty :-D [1] http://forum.dlang.org/post/wshaxsawkvkwfaefp...@forum.dlang.org
Re: Starting D with a project in mind.
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote: I'm a very happy man ! Everything is built and working including dub and the http_server example from vibe.d. It's slow to build, but it executes quickly and strips down to about 3MB which is heavy but tolerable. Thanks to everybody for the help, now I can start learning D, exploring vibe.d and Pegged and hopefully make some good progress on my MUD. So to recap, to help anybody else building on ARM these are the steps I took :- mkdir gdc cd gdc wget http://gcc.igor.onlinedirect.bg/snapshots/LATEST-4.8/gcc-4.8-20131010.tar.bz2 tar xvf gcc-4.8-20131010.tar.bz2 git clone https://github.com/jpf91/GDC.git arm_gdc cd arm_gdc git checkout arm ./setup-gcc.sh ../gcc-4.8-20131010 cd ../ mkdir build cd build export C_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch) export EXTRA_CONF=-mfloat-abi=hard --with-float=hard ../gcc-4.8-20131010/configure --enable-languages=d --disable-bootstrap --prefix=/usr/local/gdc --disable-multilib --disable-softfloat --with-float=hard make -j2 sudo make install sudo cp ../arm_gdc/libphobos/libdruntime/core/time.d /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core sudo mv /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di.old I don't know why that last step was necessary but dub and a few other things didn't build without it. After that dub built fine once I'd hacked the build file to use gdc. This is very cool. You should add it to the wiki so it doesn't get lost: http://wiki.dlang.org
Re: Starting D with a project in mind.
I've successfully built Pegged and I'm now trying to build vibe.d which requires dub so ... andrew@islay:~$ cd dub-0.9.18/ andrew@islay:~/dub-0.9.18$ ls binbuild-files.txt CHANGELOG.md examples LICENSE_DE.txt package.json source build.cmd build.sh curl.lib installer LICENSE.txt README.md andrew@islay:~/dub-0.9.18$ ./build.sh Generating version file... fatal: Not a git repository (or any parent up to mount point /data) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Running gdmd... source/dub/internal/std/processcompat.d:301: Error: no identifier for declarator args2 source/dub/internal/std/processcompat.d:301: Error: alias cannot have initializer source/dub/internal/std/processcompat.d:315: Error: no identifier for declarator args2 source/dub/internal/std/processcompat.d:315: Error: alias cannot have initializer andrew@islay:~/dub-0.9.18$ Any ideas what I'm doing wrong ? Thanks for all of the hand-holding BTW.
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 12:31:49 UTC, Andrew wrote: Any ideas what I'm doing wrong ? Thanks for all of the hand-holding BTW. What is your GDC version? Looks like one with pre-2.063 front-end as it does not support `alias X = ...` syntax. vibe.d developers do try to support latest two released front-end versions but it is not as easy as it sounds (I hope situation will improve a lot once CI is finally up and running for vibe,d)
Re: Starting D with a project in mind.
What is your GDC version? Looks like one with pre-2.063 front-end as it does not support `alias X = ...` syntax. vibe.d developers do try to support latest two released front-end versions but it is not as easy as it sounds (I hope situation will improve a lot once CI is finally up and running for vibe,d) I think it's the latest version of GDC :- https://github.com/jpf91/GDC/tree/arm which apparently supports 2.062. In the D community, is there not the concept of stable releases that all tools and libraries support or is it a free for all i.e. nothing works together ? Can I get an earlier version of vibe.d that is compatible with GDC ? I notice that dub must be using a different version of phobos also :- andrew@islay:~/dub/source$ gdmd app.d dub/packagemanager.d:21: Error: module sha is in file 'std/digest/sha.d' which cannot be read Is this something I can update easily ?
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 14:38:32 UTC, Andrew wrote: I think it's the latest version of GDC :- https://github.com/jpf91/GDC/tree/arm which apparently supports 2.062. Ugh, don't know about ARM build but GDC itself currently supports 2.063.2 version for both 4.8 and 4.9 branch. In the D community, is there not the concept of stable releases that all tools and libraries support or is it a free for all i.e. nothing works together ? Can I get an earlier version of vibe.d that is compatible with GDC ? Generally, only latest DMD release + latest library release are guaranteed to work. It is a big and complicated problem to get this right. First, all 3 major compilers have incompatible ABI so they need whole own library stack built starting with druntime / phobos. Second, bigger cross-platform programs like vibe.d have lot of version definitions that change behavior considerably (for example, various event drivers for vibe.d), on top of usual OS / processor versioning. Combined together that creates an exponential configuration count that is almost impossible to test manually. Sonke (vibe.d author) has recently recognized what a disaster this creates and right now adding Continuous Integration testing is high priority target - but this is still work-in-progress. As a result, with every small step from configuration common among library/program developers (usually it is latest DMD + x64_86 + Linux/Windows) probability of something breaking bad is damn high. Actually, I don't know if vibe.d has ever been tested with GDC at all. Is this something I can update easily ? If rebuilding GDC from sources so that it will catch 2.063.2 frontend version is an option - it may help.
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 14:56:06 UTC, Dicebot wrote: On Tuesday, 15 October 2013 at 14:38:32 UTC, Andrew wrote: Is this something I can update easily ? If rebuilding GDC from sources so that it will catch 2.063.2 frontend version is an option - it may help. Looking at https://github.com/jpf91/GDC/commits/arm , 2.063.2 support is also included in the ARM branch, cf. commit 1aa5755 from June 30, so you should have it already I think. Where did you get the 2.062 info from?
Re: Starting D with a project in mind.
Looking at https://github.com/jpf91/GDC/commits/arm , 2.063.2 support is also included in the ARM branch, cf. commit 1aa5755 from June 30, so you should have it already I think. Where did you get the 2.062 info from? 2.062 was mentioned on the GDC website as the latest supported D2. So I'm thoroughly confused then, why won't dub build as it looks as though it didn't support aliases and the phobos library looks as though it has sha1 missing ?
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 18:41:50 UTC, Andrew wrote: Looking at https://github.com/jpf91/GDC/commits/arm , 2.063.2 support is also included in the ARM branch, cf. commit 1aa5755 from June 30, so you should have it already I think. Where did you get the 2.062 info from? 2.062 was mentioned on the GDC website as the latest supported D2. So I'm thoroughly confused then, why won't dub build as it looks as though it didn't support aliases and the phobos library looks as though it has sha1 missing ? Can you check the output for this micro-program on your GDC? ``` pragma(msg, __VERSION__); ```
Re: Starting D with a project in mind.
On Tue, Oct 15, 2013 at 09:19:56PM +0200, Andrew wrote: pragma(msg, __VERSION__); ``` 2060L - seems I'm further advanced than everybody else :-) Wow that's pretty old. The current language version supported by GDC is 2063L. You should probably consider upgrading GDC to at least 2.0.62 (but preferably 2.0.63). Lots of bugs and issues have been fixed since 2.0.60. :) T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
Re: Starting D with a project in mind.
2060L - seems I'm further advanced than everybody else :-) Sorry, I thought it was 2.052, but now I see it's well behind since it should be 2.063. I'm rebuilding again from the master.
Re: Starting D with a project in mind.
pragma(msg, __VERSION__); ``` 2060L - seems I'm further advanced than everybody else :-)
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 19:23:13 UTC, Andrew wrote: 2060L - seems I'm further advanced than everybody else :-) Sorry, I thought it was 2.052, but now I see it's well behind since it should be 2.063. I'm rebuilding again from the master. Aha, oops, I have the same 2060L, but that is presumably because I forgot to 'git checkout arm', and the master branch on Johannes' fork is not up-to-date. The reason why this works while normal GDC doesn't is that this is so old it doesn't include some explicit architecture static ifs that were added later (and for which ARM was not available for some time). I'm going to let this stuff rebuild overnight...
Re: Starting D with a project in mind.
Aha, oops, I have the same 2060L, but that is presumably because I forgot to 'git checkout arm', and the master branch on Johannes' fork is not up-to-date. The reason why this works while normal GDC doesn't is that this is so old it doesn't include some explicit architecture static ifs that were added later (and for which ARM was not available for some time). I'm going to let this stuff rebuild overnight... My build, from GDC master, went really well until it got to libphobos and then there were many architecture specific bits of code that just didn't include any ARM directives so it's probably currently impossible to build the latest libphobos on ARM. I tried comparing the ARM fork but it was massively different and it looks like libphobos has been mostly rewritten since then. I don't really understand why there are so many .d files that just seem to wrap standard os stuff - why not just use the standard installed C headers and avoid all of this overhead that needs maintaining ? Interestingly the gcc Go compiler that is also included with gcc 4.8 built and installed first time so I'm rather tempted to just to give up with D as this point after a valiant battle for the last few days.
Re: Starting D with a project in mind.
On Tuesday, 15 October 2013 at 22:28:59 UTC, Andrew wrote: I don't really understand why there are so many .d files that just seem to wrap standard os stuff - why not just use the standard installed C headers and avoid all of this overhead that needs maintaining ? Those .d files are essentially just that - ported C headers so that you don't need to declared these functions manually. You can easily re-generated those from actual system C headers using tool like https://github.com/jacob-carlborg/dstep Interestingly the gcc Go compiler that is also included with gcc 4.8 built and installed first time so I'm rather tempted to just to give up with D as this point after a valiant battle for the last few days. Unfortunately, this is an area where difference in developer count is really notable. It is a dead end - support for more exotic platforms like ARM is lacking because there too few people who need it and new bypassers are scared from further investigation because of lacking support. There is hardly anything we can do until some volunteer will appear who is willing to champion this.
Re: Starting D with a project in mind.
P.S. I'd recommend to try to contact Johannes Pfau and ask if he has any plans for updating his ARM Phobos fork to recent version. Such changes should be probably integrated Phobos upstream eventually.
Re: Starting D with a project in mind.
After roughly hacking all of the 'static assert unimplemented' lines in libphobos to just do whatever X86 does, I got it to build and install. Now I'm on 2063L and now hello world builds to 8MB instead of 2MB (although it strips to 760k - twice the previous version). So now I resume my quest to build vibe.d by first trying to build dub and I get :- andrew@islay:~/dub$ ./build.sh Generating version file... Running gdmd... /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L) line 224 is trying to instantiate a Duration object. Any ideas ?
Re: Starting D with a project in mind.
Unfortunately, this is an area where difference in developer count is really notable. It is a dead end - support for more exotic platforms like ARM is lacking because there too few people who need it and new bypassers are scared from further investigation because of lacking support. There is hardly anything we can do until some volunteer will appear who is willing to champion this. I was hoping to actually learn D before I had to maintain it :-) ARM is hardly exotic, it's the best selling CPU by a large margin. I bet even Microsoft ships more ARM Windows licences than it does Intel now. I'll have a look at that dstep util and see if I can contribute some patches back in order to save some other hapless fool like myself from suffering the same pain. Thanks for your patience supporting me BTW.
Re: Starting D with a project in mind.
On 10/15/13 3:38 PM, Dicebot wrote: Unfortunately, this is an area where difference in developer count is really notable. It is a dead end - support for more exotic platforms like ARM is lacking because there too few people who need it and new bypassers are scared from further investigation because of lacking support. There is hardly anything we can do until some volunteer will appear who is willing to champion this. I think you mean catch-22 rather than dead-end. There's not more people helping support ARM due to ARM not yet working well, so there's no developers. ARM's not exotic, it's just not on as many people's desktops. Thats been changing rapidly over the last several years.
Re: Starting D with a project in mind.
Thanks Stefan, those were the instructions that I tried. With GDC, is it possible to generate portable intermediate C code so that I can compile D sources on the Mac and then just copy the resultant C code to an ARM debian machine and build that there ? That would allow me to work around the problem of not being able to build D directly on the target system. Thanks
Re: Starting D with a project in mind.
On Monday, 14 October 2013 at 07:36:03 UTC, Andrew wrote: Thanks Stefan, those were the instructions that I tried. With GDC, is it possible to generate portable intermediate C code so that I can compile D sources on the Mac and then just copy the resultant C code to an ARM debian machine and build that there ? That would allow me to work around the problem of not being able to build D directly on the target system. Thanks Hi, I actually managed to build GDC over the weekend, directly on the RPi. It required some small changes to the process as compared to [1]: - Fresh raspbian install (same). - Installed the packages (same). - Set up swap USB HD (same). - I got gcc-4.8.1 release sources, didn't apply the patches (seems they are already in place now), nor did I rerun the autoconf. I then proceeded to clone GDC, run the scripts and build, however I ran into a set of bugs[2]. I tried to get around those with my limited knowledge but got stuck. Luckily Johannes Pfau has been doing some great work as usual and already fixed these problems (mostly) in his fork / ARM branch [3]. So I redid this part of the process, with a fresh GCC source directory, using a clone of his fork, and the compilation ran to completion. A small test program also worked, but Johannes warned that there is some codegen issue in his fork, which is why he hasn't opened a pull request to merge into GDC proper yet[2]. I don't know the details of that but this might be good enough for now for your purposes. I assume that by the time 2.064 comes around and GDC's frontend is update one can go back to the main GDC master branch, as most fixes are already in druntime as well. Cheers, Stefan [1] http://gdcproject.org/wiki/Raspberry%20Pi/build/Raspbian%28Hardfloat%29/GCC-Devel [2] http://bugzilla.gdcproject.org/show_bug.cgi?id=80 [3] https://github.com/jpf91/GDC/tree/arm
Re: Starting D with a project in mind.
Hallelujah - it's built ! Thanks Stefan for the link to the ARM fork, that and a pile of messing about with float ABI types and I managed to get it built and installed on my Cubieboard A20 (ARM7 debian distro). So now I compile Hello World and I get a 2MB executable ! This compares with 8kb for the same in C. Have I done something wrong ? I can understand that it has GC and UTF8 with bounds checking so I was expecting maybe 100kb. Does it need to be stripped or optimised in some way ? Surely only the used functions get linked in. My current C code has an embedded web server, json libraries and mongodb client and it's 80kb - what can I expect for the same thing in D ? Thanks Andrew
Re: Starting D with a project in mind.
On Monday, 14 October 2013 at 20:59:25 UTC, Andrew wrote: So now I compile Hello World and I get a 2MB executable ! gdc makes kinda large executables... but with my gdc cross compiler for arm, the hello world is 360 KB after stripping, but I used printf instead of writefln. phobos is pretty bad about its dependencies - use writef() and it pulls 20 modules. But even so 2MB is 5x bigger than it should be... My current C code has an embedded web server, json libraries and mongodb client and it's 80kb - what can I expect for the same thing in D ? D's size cost is mostly up-front - hello world bears the brunt of the size and increases after that are small (since the hello world already includes most that functionality due to the web of dependencies!). I'd estimate your size to be between 500 KB and 2.5 MB once you get all your functionality in. You *can* go much smaller if you don't touch phobos at all, writing your D with just C libraries. Then it'll be probably around 400 KB like my hello world test - still the size of grabbing druntime, but you don't get the phobos functions.
Re: Starting D with a project in mind.
As Adam already said D on Pi is adventurous. For MongoDB and web stuff, you should look into Vibe.d [0]. For parsing I would suggest Pegged [1]. Welcome to D and Happy Hacking! :) [0] http://vibed.org/ [1] https://github.com/PhilippeSigaud/Pegged Thanks both. Well after several hours of hacking I have spectacularly failed to build GDC on any arm based debian environment - tried both my RPi and Cubieboard. In both cases it fails with a pile of compilation errors. I'm guessing that D just isn't mainstream enough at the moment to be properly supported on Debian and yet it's too big and complicated to build easily yourself and so it's probably a non-starter for me at the moment. There is a pre-built package on debian gdc-4.4 but it's too old to build vibe or dub from my experimentation. I guess I'll go back to plain old C. Thanks anyway - I'll check back in a few years.
Re: Starting D with a project in mind.
On Friday, 11 October 2013 at 07:09:17 UTC, Andrew wrote: As Adam already said D on Pi is adventurous. For MongoDB and web stuff, you should look into Vibe.d [0]. For parsing I would suggest Pegged [1]. Welcome to D and Happy Hacking! :) [0] http://vibed.org/ [1] https://github.com/PhilippeSigaud/Pegged Thanks both. Well after several hours of hacking I have spectacularly failed to build GDC on any arm based debian environment - tried both my RPi and Cubieboard. In both cases it fails with a pile of compilation errors. I'm guessing that D just isn't mainstream enough at the moment to be properly supported on Debian and yet it's too big and complicated to build easily yourself and so it's probably a non-starter for me at the moment. There is a pre-built package on debian gdc-4.4 but it's too old to build vibe or dub from my experimentation. I guess I'll go back to plain old C. Thanks anyway - I'll check back in a few years. Hi, I don't know which instructions you followed, but building GDC for the Pi was slow (overnight job) but in the end relatively pain free for me using these instructions: http://gdcproject.org/wiki/Raspberry%20Pi/build/Raspbian%28Hardfloat%29/GCC-Devel. This was some time ago however (more than a year by now, wow), so I don't know if some change has broken the process since. I don't think I have the SD card with GDC installed anymore so I don't know for sure which version I built at the time. I think it was based on 2.0.59 still. See also http://forum.dlang.org/thread/kpdcgoynlofeosxaj...@forum.dlang.org. When I have some free time I will fire up one of my Pis and give it a try again and report back. Cheers, Stefan
Re: Starting D with a project in mind.
On Thursday, 10 October 2013 at 19:49:15 UTC, Andrew wrote: Hence my interest in D. I've spent a few hours trying to get GDC working on my Pi which is proving to be a bitch but I'm hoping that it will be worth it. I haven't done a serious program on the Pi, but I was able to get gdc and some test programs to compile and run successfully for it. Took me a couple hours too, the way I did it was with a crosstool-ng thingy: http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG so I can compile it on my Linux desktop for the pi. I did hit one druntime bug in the process, but I believe it has already been fixed so you hopefully won't have to deal with that. The biggest problem I had was at first I didn't use the gnu-eabi option. I think that was in compiling druntime, not sure though, my memory is failing as this was several months ago when I played with it. Bottom line though is I know it is possible, but I don't know how seamless it will be with a larger program.
Re: Starting D with a project in mind.
On Thursday, 10 October 2013 at 19:49:15 UTC, Andrew wrote: Hi All, I've been writing a MUD for a little while, initially using Haskell but now using C. I develop on MacOS X but deploy to a Raspberry Pi. I loved using Haskell especially using the Parsec parser but unfortunately I couldn't build on the Pi because the resource requirements were just too heavy. Now I develop in C and the same Makefile builds on Mac and Debian equally well and of course I can use the lovely Xcode environment. However, as I start to add more advanced features it's getting rather tedious. The MUD has an embedded web server which supports web sockets for real time play and the back end is a Mongo DB. The C code to access DB is very repetitive and is slowing me down because of the lack of higher level constructs. Similarly the parser is very basic and ropey which needs attention. Hence my interest in D. I've spent a few hours trying to get GDC working on my Pi which is proving to be a bitch but I'm hoping that it will be worth it. Before I get too far down this path, would you recommend D for this task and will porting from Mac to Pi be seamless ? As Adam already said D on Pi is adventurous. For MongoDB and web stuff, you should look into Vibe.d [0]. For parsing I would suggest Pegged [1]. Welcome to D and Happy Hacking! :) [0] http://vibed.org/ [1] https://github.com/PhilippeSigaud/Pegged
