www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Starting D with a project in mind.

reply "Andrew " <andrew nowhere.com> writes:
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 ?

Thanks

Andrew
Oct 10 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Oct 10 2013
prev sibling parent reply "qznc" <qznc web.de> writes:
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
Oct 10 2013
parent reply "Andrew" <andrew nowhere.com> writes:
 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.
Oct 11 2013
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
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%28Har
float%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/kpdcgoynlofeosxajwgc 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
Oct 11 2013
parent reply "Andrew" <andrew nowhere.com> writes:
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
Oct 14 2013
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
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
Oct 14 2013
parent reply "Andrew" <andrew nowhere.com> writes:
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
Oct 14 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Oct 14 2013
parent reply "Andrew" <andrew nowhere.com> writes:
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
bin        build-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.
Oct 15 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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)
Oct 15 2013
parent reply "Andrew" <andrew nowhere.com> writes:
 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 ?
Oct 15 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Oct 15 2013
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
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?
Oct 15 2013
parent reply "Andrew" <andrew nowhere.com> writes:
 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 ?
Oct 15 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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__);
```
Oct 15 2013
parent reply "Andrew" <andrew nowhere.com> writes:
 pragma(msg, __VERSION__);
 ```



2060L  - seems I'm further advanced than everybody else :-)
Oct 15 2013
next sibling parent reply "Andrew" <andrew nowhere.com> writes:
 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.
Oct 15 2013
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
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...
Oct 15 2013
parent reply "Andrew" <andrew nowhere.com> writes:
 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.
Oct 15 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Oct 15 2013
next sibling parent reply "Andrew" <andrew nowhere.com> writes:
 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.
Oct 15 2013
parent "Dicebot" <public dicebot.lv> writes:
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 :)
Oct 16 2013
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
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.
Oct 15 2013
parent "Dicebot" <public dicebot.lv> writes:
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.
Oct 16 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Oct 15 2013
prev sibling parent reply "Andrew" <andrew nowhere.com> writes:
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 ?
Oct 15 2013
next sibling parent reply "Andrew" <andrew nowhere.com> writes:
 andrew islay:~/dub$ ./build.sh
 Generating version file...
 Running gdmd...
 /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabi
f/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
Oct 16 2013
next sibling parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
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-gnueabi
f/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...
Oct 16 2013
parent reply "Andrew" <andrew nowhere.com> writes:
 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.
Oct 16 2013
parent reply "Stefan Frijters" <sfrijters gmail.com> writes:
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
Oct 16 2013
parent reply "Andrew" <andrew nowhere.com> writes:
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.
Oct 16 2013
next sibling parent "Stefan Frijters" <sfrijters gmail.com> writes:
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/wshaxsawkvkwfaefpirj forum.dlang.org
Oct 16 2013
prev sibling parent reply "simendsjo" <simendsjo gmail.com> writes:
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
Oct 16 2013
parent "Andrew" <andrew nowhere.com> writes:
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.
0x00000000 in ?? ()
(gdb) bt


../../../../gcc-4.8-20131010/libphobos/libdruntime/gc/gc.d:293

vibe.utils.memory.T19FreeListObjectAllocTS4vibe4core7drivers13libevent2_tcp10TCPContextVb0Vb1Z.T5allocTC4vibe4core6driver10DriverCoreTPS6deimos6event212eventstruct10eventbaseTiTPS6deimos6event211bufferevent11buffereventTS4vibe4core3net14NetworkAddressTS4vibe4core3net14Net
orkAddressZ.alloc() 
()



../../../../gcc-4.8-20131010/libphobos/libdruntime/core/thread.d:3800

/lib/arm-linux-gnueabihf/libc.so.6

/lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame 
(corrupt stack?)
Oct 17 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
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
Oct 16 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
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-gnueabi
f/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.
Oct 16 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Oct 15 2013