Hello World

[Roffi Ulwn via Digitalmars-d]

import std.stdio;

void main(char[][] args)
{
  writefln("Hello World");
}

hello world in D

[khurshid]

I just download dmd 2.063, and compile simple "hello world" 
program:


// hello.d
import std.stdio;
int main()
{
    writeln("hello world");
return 0;
}


with -O -release -inline -noboundscheck  flags.

And size of result output file  'hello'  equal to 1004.1 Kbyte !!!
Why size is big?


I'm using  fedora 14, 32-x.


Regards,
 Khurshid.

hello world executable size

[Joakim via Digitalmars-d]

I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better and 
make them more selective:


https://github.com/D-Programming-Language/phobos/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3A9il+clean

Hello world (void main(){ import std.stdio; writefln("hello 
roboto"); }) size went from 464 KB to 548 KB when going from 
2.066.1 to 2.067.1 on linux/x86, an increase of 18% (dmd -O 
-release main.d).  I used nm to try and find some of the symbols 
using the most space (command taken from SO):


nm -B -r --size-sort --print-size -t d main

I noticed that the symbol taking up the third-most space was 
_d_arraysetlengthT, which wasn't in the older executable 
generated by 2.066.1.  Disassembling the newer executable 
(objdump -rD main), it appears that it's called from exactly one 
function, std.uni.GcPolicy.realloc, which is in turn only called 
from one templated struct's member function, 
std.uni.CowArray.length.  That instantiated function isn't called 
from anywhere else in the binary.


The templated struct std.uni.CowArray is only instantiated by the 
templated struct std.uni.InversionList in the source, but I'm not 
sure why neither is instantiated in the older executable and a 
diff of the two versions of std.stdio doesn't produce anything 
that stands out.  None of this appears to be used when the binary 
is run, as having gdb break on _d_arraysetlengthT does nothing.


But std.uni isn't actually imported directly by std.stdio, where 
does it come from?  Nearest I can tell from adding the -v flag to 
dmd, std.stdio has a couple scoped, selective imports to some 
functions from std.utf.  std.utf has exactly _one_ scoped, 
selective import of std.string.format in its UTFException class, 
and std.string has several selective imports from std.uni, 
including one at module scope.


I tried commenting out that single selective import of 
std.string.format in std.utf and the same binary compiled and ran 
fine without any imports of std.string or std.uni, plus it was 
now 36 KB smaller. :)


I realize executable size may not be a priority, but this 
exploration shows how easy it is to get a bunch of template 
garbage pulled in to executables (I know this is not news for 
some).  Perhaps the binary would have been twice as big if not 
for Ilya's work!  Maybe this isn't considered something that 
should be fixed at the compiler level, but rather by properly 
working with the linker to remove these, as David did with 
--gc-sections for ldc.  Either way, some kind of dashboard that 
charts binary sizes for dmd PRs can't come soon enough, so we can 
keep better tabs on this.

Re: hello world in D

[Adam D. Ruppe]

On Friday, 31 May 2013 at 14:33:48 UTC, khurshid wrote:

And size of result output file  'hello'  equal to 1004.1 Kbyte


Whoa, that's up like several times from the last dmd release 
you can get down to 600 kb or so by not using the flags. Strange, 
combining all those flags increases the size by 50%. This is 
probably some kind of bug in the new release.


But even without bugs, writeln actually pulls in a lot of code. 
If you use printf instead of std.stdio, you'll save about 150 KB 
in the executable


import core.stdc.stdio;

void main() {
printf("hello\n");
}

$ dmd test2.d
$ ls -lh test2
-rwxr-xr-x 1 me users 287K 2013-05-31 10:40 test2
$ strip test2
$ ls -lh test2
-rwxr-xr-x 1 me users 195K 2013-05-31 10:41 test2



D programs don't have any dependencies outside the operating 
system by default, so they carry the parts of the standard 
library they use with them.


That 195K test2 program is mostly druntime's code. If you pull in 
std.stdio it also grabs much of the phobos standard library to 
support printing, conversion of numbers to strings, and much more.



A 1 MB hello world is just strange though, I'm sure that's some 
kind of bug, but the relatively harmless kind, you can still use 
it.

Re: hello world in D

[Regan Heath]

On Fri, 31 May 2013 15:33:46 +0100, khurshid  
 wrote:



I just download dmd 2.063, and compile simple "hello world" program:

// hello.d
import std.stdio;
int main()
{
 writeln("hello world");
 return 0;
}


with -O -release -inline -noboundscheck  flags.

And size of result output file  'hello'  equal to 1004.1 Kbyte !!!
Why size is big?


I'm using  fedora 14, 32-x.


Phobos the std library is statically linked, currently.  You will get a  
similar size (or greater) if you statically link the stdc library.   
Eventually D will support dynamically linking to Phobos.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: hello world in D

[khurshid]

On Friday, 31 May 2013 at 14:48:02 UTC, Adam D. Ruppe wrote:
If you use printf instead of std.stdio, you'll save about 150 
KB in the executable


import core.stdc.stdio;

void main() {
printf("hello\n");
}

$ dmd test2.d
$ ls -lh test2
-rwxr-xr-x 1 me users 287K 2013-05-31 10:40 test2
$ strip test2
$ ls -lh test2
-rwxr-xr-x 1 me users 195K 2013-05-31 10:41 test2


I was try your code, result:

-rwxrwxr-x. 1 khurshid khurshid 299K May 31 19:53 hello

i.e. 299 Kbyte.


Even, when I type  dmd -v  :
DMD32 D Compiler v2.063
Copyright (c) 1999-2012 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
-
Why copyright  2012 not a 2013?

Re: hello world in D

[Adam D. Ruppe]

On Friday, 31 May 2013 at 14:48:12 UTC, Regan Heath wrote:
You  will get a similar size (or greater) if you statically 
link the stdc library.


That's not necessarily true because static linking only pulls 
functions that are actually used by the program


even though I just tried gcc hello.c -static, and got a beefy 600 
KB binary out of it, so maybe it is more intertwined than I 
thought!



Eventually D will support dynamically linking to Phobos.


I think it is worth remembering that this doesn't actually reduce 
the size. In fact, it will increase it since the dynamic linked 
library needs all functions. The phobos.dll will be probably two 
or three megabytes, and if you are distributing a D app, you'll 
still have to offer that file... and now have the hassle of 
dependency management.


Dynamic linking might look less scary when your ls sees 20 KB 
instead of 600 but it doesn't really change anything substantial.

Re: hello world in D

[Regan Heath]

On Fri, 31 May 2013 16:00:00 +0100, Adam D. Ruppe  
 wrote:

On Friday, 31 May 2013 at 14:48:12 UTC, Regan Heath wrote:
You  will get a similar size (or greater) if you statically link the  
stdc library.


That's not necessarily true because static linking only pulls functions  
that are actually used by the program


even though I just tried gcc hello.c -static, and got a beefy 600 KB  
binary out of it, so maybe it is more intertwined than I thought!


It is a bit surprising isn't it.


Eventually D will support dynamically linking to Phobos.


I think it is worth remembering that this doesn't actually reduce the  
size. In fact, it will increase it since the dynamic linked library  
needs all functions. The phobos.dll will be probably two or three  
megabytes, and if you are distributing a D app, you'll still have to  
offer that file... and now have the hassle of dependency management.


Dynamic linking might look less scary when your ls sees 20 KB instead of  
600 but it doesn't really change anything substantial.


Agreed 100%.  But newcomers don't often get that far down the chain of  
thought, they just see a huge exe and wonder WTF! :)  The short answer is  
"it's statically linked" and the longer answer is.. as you say, there are  
pros/cons to each and we have issues in D around the GC and how that would  
work in a dynamically linked situation IIRC.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: hello world in D

[Adam D. Ruppe]

On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote:

i.e. 299 Kbyte.


yeah it varies a bit by computer and 32 bit vs 64 bit etc, but 
same ballpark.



Why copyright  2012 not a 2013?


Walter probably just forgot to update the message.

Re: hello world in D

[Adam D. Ruppe]

On Friday, 31 May 2013 at 15:03:58 UTC, Regan Heath wrote:

It is a bit surprising isn't it.


Aye.

BTW if you want to get into really small, statically linked D 
programs, you can do a custom druntime, no phobos, no C lib, with 
just the code you want. I recently wrote about a toy I've been 
playing with the last couple days in a reddit comment:


http://www.reddit.com/r/programming/comments/1fc9jt/dmd_2063_the_d_programming_language_reference/ca94mek

Under 40 kilobytes! If you do the bare minimum you can get down 
to about 1 KB, but at that point, you're actually writing in 
mostly (inline) assembly rather than D. The code in the link 
though supports a majority (though certainly not all) of D's 
features.


Agreed 100%.  But newcomers don't often get that far down the 
chain of thought, they just see a huge exe and wonder WTF! :)


Indeed.

Re: hello world in D

[Craig Dillabaugh]

Under 40 kilobytes! If you do the bare minimum you can get down 
to about 1 KB, but at that point, you're actually writing in 
mostly (inline) assembly rather than D. The code in the link 
though supports a majority (though certainly not all) of D's 
features.


Agreed 100%.  But newcomers don't often get that far down the 
chain of thought, they just see a huge exe and wonder WTF! :)


Indeed.


Do you really think that is such a big issue?  I can't remember
the last time I looked at the size of an executable I generated.
When I am trying to learn a new language it is really not
something I think of as a major issue.

However, I do scientific computing, and I am not distributing
most of the software I am developing.  If it runs fast and
doesn't fill up my terabyte hard drive - I will never notice.  So
I guess that makes me a little different than many posters on
this mailing list.

I would imagine there is fair segment on the programming
population who like me don't care too much about executable size.
  I suppose if you are developing software for embedded systems or
similar, then you probably watch for these things more.

Craig

Re: hello world in D

[Rob T]

I've seen this happen with 2.062, if you take out -noboundscheck 
it may reduce the size significantly and compile a lot faster. 
Makes no sense.


--rt

Re: hello world in D

[Adam D. Ruppe]

On Friday, 31 May 2013 at 15:58:12 UTC, Craig Dillabaugh wrote:

Do you really think that is such a big issue?  I can't remember
the last time I looked at the size of an executable I generated.


There's three cases where I sometimes care:

1) if I build the program on my computer, then push it to a 
test/live server over a slow internet link. It is edit/run/debug 
but with a sloow wait in the middle for the file to transfer.


2) I make little programs and send people Windows binaries over 
my (kinda slow) home internet sometimes. So upload speed again, 
especially if they play with it, send me comments, and I want to 
send them a new version to try.


3) wanting minimism for its own sake :)

Using dlls can sometimes help, but the initial download is still 
slow and it is a pain to have users manage that stuff, I prefer 
to say "here's a .zip, just unzip it and run the program" so 
smaller total package is a nice benefit.



That said though 95% of the time, a few megabytes isn't a big 
deal.

Re: hello world in D

[Brad Anderson]

On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote:


[snip]

Even, when I type  dmd -v  :
DMD32 D Compiler v2.063
Copyright (c) 1999-2012 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
-
Why copyright  2012 not a 2013?


Fixed in git.

Re: hello world in D

[Regan Heath]

On Fri, 31 May 2013 16:58:11 +0100, Craig Dillabaugh  
 wrote:




Under 40 kilobytes! If you do the bare minimum you can get down to  
about 1 KB, but at that point, you're actually writing in mostly  
(inline) assembly rather than D. The code in the link though supports a  
majority (though certainly not all) of D's features.


Agreed 100%.  But newcomers don't often get that far down the chain of  
thought, they just see a huge exe and wonder WTF! :)


Indeed.


Do you really think that is such a big issue?


Not really an issue, no.  But newcomers keep creating threads like this  
one time and again and who knows how many have been turned away without  
finding out the whys and wherefores.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: hello world in D

[Joseph Rushton Wakeling]

On 05/31/2013 06:34 PM, Brad Anderson wrote:
> On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote:
>> Why copyright  2012 not a 2013?
> 
> Fixed in git.

Is this not something where some clever CTFE could be used to swipe the date of
build and insert the correct year? :-P

Re: hello world in D

[Jonathan M Davis]

On Friday, May 31, 2013 18:05:16 Rob T wrote:
> I've seen this happen with 2.062, if you take out -noboundscheck
> it may reduce the size significantly and compile a lot faster.
> Makes no sense.

My first guess would be that more ends up being inlined with -noboundscheck due 
to the differences in the code that's being generated, but I really don't knw.

- Jonathan M Davis

Re: hello world in D

[Andrei Alexandrescu]

On 5/31/13 12:48 PM, Joseph Rushton Wakeling wrote:

On 05/31/2013 06:34 PM, Brad Anderson wrote:

On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote:

Why copyright  2012 not a 2013?


Fixed in git.


Is this not something where some clever CTFE could be used to swipe the date of
build and insert the correct year? :-P



Yah, rdmd does that.

Andrei

Re: hello world in D

[deadalnix]

On Friday, 31 May 2013 at 16:31:42 UTC, Regan Heath wrote:
On Fri, 31 May 2013 16:58:11 +0100, Craig Dillabaugh 
 wrote:




Under 40 kilobytes! If you do the bare minimum you can get 
down to about 1 KB, but at that point, you're actually 
writing in mostly (inline) assembly rather than D. The code 
in the link though supports a majority (though certainly not 
all) of D's features.


Agreed 100%.  But newcomers don't often get that far down 
the chain of thought, they just see a huge exe and wonder 
WTF! :)


Indeed.


Do you really think that is such a big issue?


Not really an issue, no.  But newcomers keep creating threads 
like this one time and again and who knows how many have been 
turned away without finding out the whys and wherefores.


R


A hello wold in java, statically compiled, was 52Mb last time I
tried.

Re: hello world in D

[Rob T]

On Friday, 31 May 2013 at 16:52:53 UTC, Jonathan M Davis wrote:

On Friday, May 31, 2013 18:05:16 Rob T wrote:
I've seen this happen with 2.062, if you take out 
-noboundscheck

it may reduce the size significantly and compile a lot faster.
Makes no sense.


My first guess would be that more ends up being inlined with 
-noboundscheck due
to the differences in the code that's being generated, but I 
really don't knw.


- Jonathan M Davis


I discovered this last night while playing around with the 
raytrace performance issue a few threads back. I noticed that 
Derelict was being built without -noboundscheck so I put the flag 
in to see what if anything would happen.


The difference is from a few kilobytes per lib to a few megabytes 
per lib, so it's a drastic increase and it takes a lot more time 
to build. This may be something that should be investigated 
further.


--rt

Re: hello world in D

[Marco Leise]

Am Fri, 31 May 2013 17:58:11 +0200
schrieb "Craig Dillabaugh" :

> Do you really think that is such a big issue?  I can't remember
> the last time I looked at the size of an executable I generated.
> When I am trying to learn a new language it is really not
> something I think of as a major issue.
> 
> However, I do scientific computing, and I am not distributing
> most of the software I am developing.  If it runs fast and
> doesn't fill up my terabyte hard drive - I will never notice.  So
> I guess that makes me a little different than many posters on
> this mailing list.
> 
> I would imagine there is fair segment on the programming
> population who like me don't care too much about executable size.
>I suppose if you are developing software for embedded systems or
> similar, then you probably watch for these things more.
> 
> Craig

Fair enough. I've seen Haskell executables for small programs
of about 10 MB. But don't forget that D is used in many areas
and if for a moment you imagine Unix being written in D with
static linking and your standard set of tools like ls,
grep, cat, ... would all be 600-1000 KiB, it would certainly
increase boot times, disk cache thrashing and program loading
times in general despite being just too much for some minimal
devices.
D can do better. There are low hanging fruit like:
http://d.puremagic.com/issues/show_bug.cgi?id=7319

-- 
Marco

Re: hello world in D

[Marco Leise]

Am Fri, 31 May 2013 13:14:48 -0400
schrieb Andrei Alexandrescu :

> On 5/31/13 12:48 PM, Joseph Rushton Wakeling wrote:
> > On 05/31/2013 06:34 PM, Brad Anderson wrote:
> >> On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote:
> >>> Why copyright  2012 not a 2013?
> >>
> >> Fixed in git.
> >
> > Is this not something where some clever CTFE could be used to swipe the 
> > date of
> > build and insert the correct year? :-P
> >
> 
> Yah, rdmd does that.
> 
> Andrei

A copyright year is not the date of compilation, but the date
of last edit. Just saying. :)

-- 
Marco

Re: hello world in D

[Paulo Pinto]

Am 31.05.2013 19:21, schrieb Rob T:

On Friday, 31 May 2013 at 16:52:53 UTC, Jonathan M Davis wrote:

On Friday, May 31, 2013 18:05:16 Rob T wrote:

I've seen this happen with 2.062, if you take out -noboundscheck
it may reduce the size significantly and compile a lot faster.
Makes no sense.


My first guess would be that more ends up being inlined with
-noboundscheck due
to the differences in the code that's being generated, but I really
don't knw.

- Jonathan M Davis


I discovered this last night while playing around with the raytrace
performance issue a few threads back. I noticed that Derelict was being
built without -noboundscheck so I put the flag in to see what if
anything would happen.

The difference is from a few kilobytes per lib to a few megabytes per
lib, so it's a drastic increase and it takes a lot more time to build.
This may be something that should be investigated further.

--rt


dmd is not alone in this regard.

There is a presentation from Chandler Carruth on the last LLVM 
conference, http://llvm.org/devmtg/2013-04/ where he rants about that in 
C++ code.


Basically there are some use cases in C++ where the optimizer currently 
does the wrong thing and the generated code increases exponentially.


--
Paulo

Re: hello world in D

[Paulo Pinto]

Am 31.05.2013 19:19, schrieb deadalnix:

On Friday, 31 May 2013 at 16:31:42 UTC, Regan Heath wrote:

On Fri, 31 May 2013 16:58:11 +0100, Craig Dillabaugh
 wrote:



Under 40 kilobytes! If you do the bare minimum you can get down to
about 1 KB, but at that point, you're actually writing in mostly
(inline) assembly rather than D. The code in the link though
supports a majority (though certainly not all) of D's features.


Agreed 100%.  But newcomers don't often get that far down the chain
of thought, they just see a huge exe and wonder WTF! :)


Indeed.


Do you really think that is such a big issue?


Not really an issue, no.  But newcomers keep creating threads like
this one time and again and who knows how many have been turned away
without finding out the whys and wherefores.

R


A hello wold in java, statically compiled, was 52Mb last time I
tried.


It is the same thing in the Go mailing list, new developers just aren't
used to static binaries. Additionally when they look at the size of 
modern languages, which tend to have JIT based canonical 
implementations, the size of the already installed runtime tends to be 
forgotten.


--
Paulo

Re: hello world in D

[SomeDude]

On Friday, 31 May 2013 at 16:31:42 UTC, Regan Heath wrote:



Do you really think that is such a big issue?


Not really an issue, no.  But newcomers keep creating threads 
like this one time and again and who knows how many have been 
turned away without finding out the whys and wherefores.


R


Maybe it's a question that could be addressed through the wiki 
then ?

Re: hello world in D

[Rob T]

On Friday, 31 May 2013 at 14:33:48 UTC, khurshid wrote:
I just download dmd 2.063, and compile simple "hello world" 
program:


// hello.d
import std.stdio;
int main()
{
    writeln("hello world");
return 0;
}


with -O -release -inline -noboundscheck  flags.

And size of result output file  'hello'  equal to 1004.1 Kbyte 
!!!

Why size is big?


I'm using  fedora 14, 32-x.


Regards,
 Khurshid.


Without -noboundscheck hello executable is only 340.6 kbyte.

Compiled using dmd 2.062 on Debian 6.

--rt

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/

I used nm to try and find some of the symbols using the most 
space (command taken from SO):


http://thecybershadow.net/d/mapview/

Re: hello world executable size

[Joakim via Digitalmars-d]

On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/


Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over the 
years. :) Anyway, I saw that viewer when you announced it before: 
any plans to add it to the github PR checks, along with your 
recent check for documentation info?


I used nm to try and find some of the symbols using the most 
space (command taken from SO):


http://thecybershadow.net/d/mapview/


Does it show sizes somewhere?  Here's the dependency list for my 
binary:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html

It also shows that the relevant setter calling GcPolicy.realloc 
isn't used anywhere:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html#_D3std3uni32__T8CowArrayTS3std3uni8GcPolicyZ8CowArray6lengthMFNaNbNdNekZv

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote:
On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/


Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over the 
years. :) Anyway, I saw that viewer when you announced it 
before: any plans to add it to the github PR checks, along with 
your recent check for documentation info?


Would you believe me if I said that this obvious (in retrospect) 
idea hasn't crossed my mind yet?


Does it show sizes somewhere?  Here's the dependency list for 
my binary:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html


Try the treemap form (above the dependency explorer form).

Re: hello world executable size

[Joakim via Digitalmars-d]

On Thursday, 25 June 2015 at 12:04:26 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote:
Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over the 
years. :) Anyway, I saw that viewer when you announced it 
before: any plans to add it to the github PR checks, along 
with your recent check for documentation info?


Would you believe me if I said that this obvious (in 
retrospect) idea hasn't crossed my mind yet?


I figured that's where you were going when you announced it. :)

Does it show sizes somewhere?  Here's the dependency list for 
my binary:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html


Try the treemap form (above the dependency explorer form).


I didn't know how to generate the .map file, I now see it's 
mentioned on the wiki:


http://wiki.dlang.org/Development_tools#File_size_profiling

Looks nice:

http://thecybershadow.net/d/mapview/view.php?id=558bef76234eb

Surprising that core.* and gc.* are almost as large as std.*, but 
I guess "hello world" isn't going to exercise that much of 
phobos. :)

Re: hello world executable size

[Joakim via Digitalmars-d]

On Thursday, 25 June 2015 at 12:15:26 UTC, Joakim wrote:
On Thursday, 25 June 2015 at 12:04:26 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote:
Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over 
the years. :) Anyway, I saw that viewer when you announced it 
before: any plans to add it to the github PR checks, along 
with your recent check for documentation info?


Would you believe me if I said that this obvious (in 
retrospect) idea hasn't crossed my mind yet?


I figured that's where you were going when you announced it. :)


Another check that would be more worthwhile but harder to measure 
would be speed of compilation of druntime/phobos, especially 
since speed of compilation is considered a key selling point of 
D.  Harder to measure because it depends on what else is going on 
on that machine, but with some care and enough samples, you could 
get something representative.

Re: hello world executable size

[rsw0x via Digitalmars-d]

On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/



looks like this commit more than doubled the size of hello world

https://github.com/D-Programming-Language/phobos/pull/3443

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/



looks like this commit more than doubled the size of hello world

https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote:
Another check that would be more worthwhile but harder to 
measure would be speed of compilation of druntime/phobos, 
especially since speed of compilation is considered a key 
selling point of D.  Harder to measure because it depends on 
what else is going on on that machine, but with some care and 
enough samples, you could get something representative.


Compilation/linking time are measured for the sample programs.

Re: hello world executable size

[Joakim via Digitalmars-d]

On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev wrote:

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
looks like this commit more than doubled the size of hello 
world


https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?


I didn't get that either, maybe he meant the PR that yours fixed 
is the one that doubled it?


On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir Panteleev wrote:

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote:
Another check that would be more worthwhile but harder to 
measure would be speed of compilation of druntime/phobos, 
especially since speed of compilation is considered a key 
selling point of D.  Harder to measure because it depends on 
what else is going on on that machine, but with some care and 
enough samples, you could get something representative.


Compilation/linking time are measured for the sample programs.


Yeah, I saw that, but I was talking about adding a github check 
for D PRs and how they affect compilation speed, especially for 
dmd PRs.  Druntime/Phobos and eventually ddmd may not be the best 
way to check it, but it's the closest lamppost. ;)


Smaller binary size is nice to have, but not that important, 
especially since we've been neglecting it for some time now.


Compilation speed is something we're always trumpeting, we better 
track it.

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 10:06:20 UTC, Joakim wrote:
On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev 
wrote:

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
looks like this commit more than doubled the size of hello 
world


https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?


I didn't get that either, maybe he meant the PR that yours 
fixed is the one that doubled it?


No, he's right. Removing the import doubled the filesize of a 
helloworld binary.


On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir Panteleev 
wrote:

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote:
Another check that would be more worthwhile but harder to 
measure would be speed of compilation of druntime/phobos, 
especially since speed of compilation is considered a key 
selling point of D.  Harder to measure because it depends on 
what else is going on on that machine, but with some care and 
enough samples, you could get something representative.


Compilation/linking time are measured for the sample programs.


Yeah, I saw that, but I was talking about adding a github check 
for D PRs and how they affect compilation speed, especially for 
dmd PRs.  Druntime/Phobos and eventually ddmd may not be the 
best way to check it, but it's the closest lamppost. ;)


Smaller binary size is nice to have, but not that important, 
especially since we've been neglecting it for some time now.


Compilation speed is something we're always trumpeting, we 
better track it.


It's not really possible to meaningfully track such an inaccurate 
statistic on a per-commit basis. See it yourself - select one of 
the time tests in AWSY and zoom in. It works in aggregate - when 
zoomed out, you see the medians and can get the general big 
picture. But when comparing any two commits directly, there is 
just too much error.

Re: hello world executable size

[rsw0x via Digitalmars-d]

On Sunday, 28 June 2015 at 10:06:20 UTC, Joakim wrote:
On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev 
wrote:

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
looks like this commit more than doubled the size of hello 
world


https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?


I didn't get that either, maybe he meant the PR that yours 
fixed is the one that doubled it?


it's the PR that's linked when I zoomed in on executable size in 
'Hello World'. It's not visible at first(I guess because the PR 
is so new?,) you have to zoom in once or twice.


I guess a picture is worth a thousand words. 
http://i.imgur.com/p0r5tFH.png

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 10:37:15 UTC, Joakim wrote:
On Sunday, 28 June 2015 at 10:11:08 UTC, Vladimir Panteleev 
wrote:
No, he's right. Removing the import doubled the filesize of a 
helloworld binary.


Ah, I didn't want to download the full 90 MBs graph data again 
to see it.  Yes, I see it now.


It's only about 5 MB compressed. Some browsers show the 
decompressed size.

Re: hello world executable size

[Joakim via Digitalmars-d]

On Sunday, 28 June 2015 at 10:11:08 UTC, Vladimir Panteleev wrote:
No, he's right. Removing the import doubled the filesize of a 
helloworld binary.


Ah, I didn't want to download the full 90 MBs graph data again to 
see it.  Yes, I see it now.


On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir Panteleev 
wrote:
It's not really possible to meaningfully track such an 
inaccurate statistic on a per-commit basis. See it yourself - 
select one of the time tests in AWSY and zoom in. It works in 
aggregate - when zoomed out, you see the medians and can get 
the general big picture. But when comparing any two commits 
directly, there is just too much error.


Seems pretty stable to me, almost as much as file size even, 
which is surprising.  I did note that you'd have to be careful to 
measure it on a relatively unloaded machine and average multiple 
runs, but I don't see why it couldn't be done.  There is some 
variability on some of those, but as long as you didn't overreact 
on small changes and maybe compared one PR's results to averaged 
past data, ie over multiple PRs, as the baseline, it should work.

Linking fails on Hello World?!

[qwesx]

Hello!

I just installed LDC on Debian from the repository and tried out to compile a 
simple Hello World program:
> import tango.io.Stdout;
> int main(char[][] argv) {
>   Stdout("Hello world!");
>   return 0;
> }

Looks simlpe enough, but when running "ldc main.d" the following error is 
printed:
> main.o: In function `_Dmain':
> main:(.text+0x2a): undefined reference to 
> `_D5tango2io6Stdout6StdoutC5tango2io6stream6Format20__T12FormatOutputTaZ12FormatOutput'
> main:(.text+0x41): undefined reference to 
> `_D5tango2io6stream6Format20__T12FormatOutputTaZ12FormatOutput5printMFYC5tango2io6stream6Format20__T12FormatOutputTaZ12FormatOutput'
> main.o:(.rodata+0x18): undefined reference to `_D5tango2io6Stdout8__ModuleZ'
collect2: ld returned 1 exit status
> Error: linking failed:
> status: 1

The files /usr/include/d/tango/io/Stdout.d, /usr/lib/d/libtango-base-ldc.a and 
/usr/lib/d/libtango-user-ldc.a exist and are readable. I don't know if that's 
important though.

What's wrong here?
Is it my fault?
How can I fix it?

Thanks for your time :)

Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

Encouraged by Timo Sintonen's great posts, I decided to spend 
some time trying to build a Cortex-M toolchain for D-programming.
So this morning, I've successfully built my first toolchain 
supporting C, C++ and D for the first time.
I wanted to take the new language out for a spin, but I ran into 
some trouble...


Referring to the tutorial on this page:


-I'm getting the following error:

start.d:45:11: error: mismatched array lengths, 0 and 3
   uint[3] message =
   ^

... for this part of the code:

void OnReset()
{
while(true)
{
// Create semihosting message
uint[3] message =
[
2,  
// stderr
cast(uint)"hello\r\n".ptr,// ptr to string
7   
// size of string
];
// Send semihosting command
SendCommand(0x05, &message);
}
}

... I've carefully checked the code, but found no difference. Is 
this the expected behaviour ?
When I change the square brackets to parantheses, the error goes 
away, but I'm not sure that is the correct fix ?

Re: Linking fails on Hello World?!

[Robert Clipsham]

On 25/03/10 15:02, qwesx wrote:

Hello!

I just installed LDC on Debian from the repository and tried out to compile a 
simple Hello World program:

import tango.io.Stdout;
int main(char[][] argv) {
   Stdout("Hello world!");
   return 0;
}


Looks simlpe enough, but when running "ldc main.d" the following error is 
printed:

main.o: In function `_Dmain':
main:(.text+0x2a): undefined reference to 
`_D5tango2io6Stdout6StdoutC5tango2io6stream6Format20__T12FormatOutputTaZ12FormatOutput'
main:(.text+0x41): undefined reference to 
`_D5tango2io6stream6Format20__T12FormatOutputTaZ12FormatOutput5printMFYC5tango2io6stream6Format20__T12FormatOutputTaZ12FormatOutput'
main.o:(.rodata+0x18): undefined reference to `_D5tango2io6Stdout8__ModuleZ'

collect2: ld returned 1 exit status

Error: linking failed:
status: 1


The files /usr/include/d/tango/io/Stdout.d, /usr/lib/d/libtango-base-ldc.a and 
/usr/lib/d/libtango-user-ldc.a exist and are readable. I don't know if that's 
important though.

What's wrong here?
Is it my fault?
How can I fix it?

Thanks for your time :)


Try this:
$ ldc -L-L/usr/lib/d -L-ltango-base-ldc -L-ltango-user-ldc main.d

If that works you need to make sure these -L's are included in yout 
ldc.conf (I'm not sure where this is in the debian packages, probably 
/etc/ldc.conf, /etc/ldc/ldc.conf or /usr/bin/ldc.conf).

Re: Linking fails on Hello World?!

[qwesx]

Robert Clipsham Wrote:

> Try this:
> $ ldc -L-L/usr/lib/d -L-ltango-base-ldc -L-ltango-user-ldc main.d
> 
> If that works you need to make sure these -L's are included in yout 
> ldc.conf (I'm not sure where this is in the debian packages, probably 
> /etc/ldc.conf, /etc/ldc/ldc.conf or /usr/bin/ldc.conf).

Thank you very much, it works now.
-L-L/usr/lib/d and -L-ltango-base-ldc were already in the /etc/ldc.conf, but 
-L-ltango-user-ldc was missing.

As I am pretty new to D, is it reasonable that this line was missing or is it 
worth a bug-report?

Thank you very much!

Re: Linking fails on Hello World?!

[Robert Clipsham]

On 25/03/10 15:34, qwesx wrote:

Robert Clipsham Wrote:


Try this:
$ ldc -L-L/usr/lib/d -L-ltango-base-ldc -L-ltango-user-ldc main.d

If that works you need to make sure these -L's are included in yout
ldc.conf (I'm not sure where this is in the debian packages, probably
/etc/ldc.conf, /etc/ldc/ldc.conf or /usr/bin/ldc.conf).


Thank you very much, it works now.
-L-L/usr/lib/d and -L-ltango-base-ldc were already in the /etc/ldc.conf, but 
-L-ltango-user-ldc was missing.

As I am pretty new to D, is it reasonable that this line was missing or is it 
worth a bug-report?

Thank you very much!


The line won't be in there by default, as the tango user library isn't 
required to write your applications, only the runtime is. If you'd like 
to report a bug it should be to the packagers to see if they can 
automatically add in the user library to the configuration file when you 
install it. I'll add a note to
http://dsource.org/projects/ldc/wiki/BuildInstructionsUbuntu for future 
users in case anyone else has the problem.

Re: Linking fails on Hello World?!

[Moritz Warning]

On Thu, 25 Mar 2010 11:34:15 -0400, qwesx wrote:

> Robert Clipsham Wrote:
> 
>> Try this:
>> $ ldc -L-L/usr/lib/d -L-ltango-base-ldc -L-ltango-user-ldc main.d
>> 
>> If that works you need to make sure these -L's are included in yout
>> ldc.conf (I'm not sure where this is in the debian packages, probably
>> /etc/ldc.conf, /etc/ldc/ldc.conf or /usr/bin/ldc.conf).
> 
> Thank you very much, it works now.
> -L-L/usr/lib/d and -L-ltango-base-ldc were already in the /etc/ldc.conf,
> but -L-ltango-user-ldc was missing.
> 
> As I am pretty new to D, is it reasonable that this line was missing or
> is it worth a bug-report?
> 
> Thank you very much!

Hi,

I've found the bug yesterday and wrote to l...@packages.debian.org already.

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

(I just found out that I should probably have posted this in the 
digitalmars.D.learn forum instead, sorry for the inconvenience)

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

I belive the following information is slightly incorrect:
"GDC requires the following minimal object.d file in the same 
folder as start.d. It is imported automatically."


My tests have shown that object.d needs to be in the CWD, not in 
the same directory as "start.d".


This is my command-line:

arm-none-eabi-gdc -DF_CPU=4800 -D__BUILD_WITH_EXAMPLE__=1 
-mcpu=cortex-m4 -mthumb -mthumb-interwork -fno-emit-moduleinfo 
-fdata-sections  -c src/start.d -o output/src/start.o



Here's a summary of the directories when the build works:
./object.d
src/start.d
output/src/start.o

However, the following does not work:
src/object.d
src/start.d
output/src/start.o

-Is this directory behaviour a bug ?

Re: Trouble with Cortex-M "Hello World"

[Mike via Digitalmars-d]

On Tuesday, 31 March 2015 at 10:39:05 UTC, Jens Bauer wrote:


Referring to the tutorial on this page:


-I'm getting the following error:

start.d:45:11: error: mismatched array lengths, 0 and 3
   uint[3] message =
   ^

[snip]


... I've carefully checked the code, but found no difference. 
Is this the expected behaviour ?
When I change the square brackets to parantheses, the error 
goes away, but I'm not sure that is the correct fix ?


I just cut and pasted the code from the wiki myself and compiled 
with my arm-none-eabi-gdc cross-compiler and it works fine.  I'm 
sorry, but I'm not sure what the problem could be.


Mike

Re: Trouble with Cortex-M "Hello World"

[Mike via Digitalmars-d]

On Tuesday, 31 March 2015 at 11:19:29 UTC, Jens Bauer wrote:

I belive the following information is slightly incorrect:
"GDC requires the following minimal object.d file in the same 
folder as start.d. It is imported automatically."


My tests have shown that object.d needs to be in the CWD, not 
in the same directory as "start.d".


I don't believe it is the current working directory, but rather 
the compiler's import path.  See the -I switch.  By default, I 
believe that is the current working directory.




This is my command-line:

arm-none-eabi-gdc -DF_CPU=4800 -D__BUILD_WITH_EXAMPLE__=1 
-mcpu=cortex-m4 -mthumb -mthumb-interwork -fno-emit-moduleinfo 
-fdata-sections  -c src/start.d -o output/src/start.o



Here's a summary of the directories when the build works:
./object.d
src/start.d
output/src/start.o

However, the following does not work:
src/object.d
src/start.d
output/src/start.o

-Is this directory behaviour a bug ?


I believe it is working as designed, but I'm not an authority on 
the compiler.


Mike

Re: Trouble with Cortex-M "Hello World"

[Dan Olson via Digitalmars-d]

"Mike"  writes:

> On Tuesday, 31 March 2015 at 10:39:05 UTC, Jens Bauer wrote:
>
>> Referring to the tutorial on this page:
>> 
>>
>> -I'm getting the following error:
>>
>> start.d:45:11: error: mismatched array lengths, 0 and 3
>>uint[3] message =
>>^
> [snip]
> I just cut and pasted the code from the wiki myself and compiled with
> my arm-none-eabi-gdc cross-compiler and it works fine.  I'm sorry, but
> I'm not sure what the problem could be.
>
> Mike

Yeah, something strange.  The start.d on the webpage compiles fine for
me too.  I am using LDC as cross compiler to ARM, but you should also be
able to compile start.d fine with regular dmd too even though it can't
target ARM.

It is as if your message array declaration line is being read by
compiler as:

uint[0] message =


>> When I change the square brackets to parantheses, the error goes
>> away, but I'm not sure that is the correct fix ?

Changing the square brackets to parens is doing something different.
You do want the square brackets.
--
Dan

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Tuesday, 31 March 2015 at 15:50:17 UTC, Dan Olson wrote:

"Mike"  writes:
I just cut and pasted the code from the wiki myself and 
compiled with
my arm-none-eabi-gdc cross-compiler and it works fine.  I'm 
sorry, but I'm not sure what the problem could be.


Mike


Yeah, something strange.  The start.d on the webpage compiles 
fine for me too.  I am using LDC as cross compiler to ARM, but 
you should also be able to compile start.d fine with regular 
dmd too even though it can't target ARM.


It is as if your message array declaration line is being read by
compiler as:

uint[0] message =


I've also tried putting it all on one line, but that didn't help:

src/start.d:46:12: error: mismatched array lengths, 0 and 3
 uint[3]message=[2,cast(uint)"hello\r\n".ptr,7];
^

-So it's not because there's a problem with spaces, tabs and 
linefeeds.


When I change the square brackets to parantheses, the error 
goes

away, but I'm not sure that is the correct fix ?


Changing the square brackets to parens is doing something 
different.

You do want the square brackets.


I expected that. :)

Thank you both Mike and Dan for the replies.

This could be something related to big endian issues, as my 
compiler is hosted on a big endian machine (PowerMac G5). Note: 
Just in case it's important; I'm using GCC+GDC, not LLVM+LDC.


I hope I'll be able to make a build on my CubieBoard2, so I can 
try the test there.

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

Unfortunately, my attempt to build GDC on my CubieBoard2 failed.

However, I decided to change the line slightly, in order to find 
out exactly what's going wrong...



src/start.d:46:12: error: mismatched array lengths, 0 and 3
 uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
^
make: *** [output/src/start.o] Error 1

This means that the arry on the right hand side is actually 
parsed correctly.

It seems that the number [3] or [4] is parsed/read as zero ??

Re: Trouble with Cortex-M "Hello World"

[Johannes Pfau via Digitalmars-d]

Am Wed, 01 Apr 2015 12:56:22 +
schrieb "Jens Bauer" :

> Unfortunately, my attempt to build GDC on my CubieBoard2 failed.
> 
> However, I decided to change the line slightly, in order to find 
> out exactly what's going wrong...
> 
> 
> src/start.d:46:12: error: mismatched array lengths, 0 and 3
>   uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
>  ^
> make: *** [output/src/start.o] Error 1
> 
> This means that the arry on the right hand side is actually 
> parsed correctly.
> It seems that the number [3] or [4] is parsed/read as zero ??

I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian system.
It could be an endianess issue somewhere in the code. I debugged a
misaligned-access bug in the frontend some time ago, bugs like these can
result in the weirdest effects.

It should compile on the cubieboard though. What exactly failed?

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:

Am Wed, 01 Apr 2015 12:56:22 +
It could be an endianess issue somewhere in the code. I 
debugged a misaligned-access bug in the frontend some time ago,

bugs like these can result in the weirdest effects.


Indeed. I had some strange things happening until OpenOCD had the 
endian bugs squashed.
Endian problems does not necessarily have to mean crashes; it 
could just be some data's high an low bytes being swapped.



It should compile on the cubieboard though. What exactly failed?


building GCC-4.9.2, so this is not an issue with D.
I'll probably be trying to make a build for the next 10 hours.

On my G5, however, I managed to get as complete a build as I 
could, but it involves compiling GCC 4 times total (!) - This 
gives me C/C++ and D - including libstdc++! -but it takes a 
couple of hours. ;)

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

I have successfully built GDC on CubieBoard2 (Cubian) now.
I've rebuilt GDC on the G5 as well, using the same script.

I've used nano for making object.d and start.d, in order to avoid 
too many problems with character encoding.
In addition, I've used hexdump -C .d to verify that the 
text-files are actually the same, thus I think it's fairly safe 
to rule out character encoding problems.


GDC on Cubian works, while GDC on the G5 seems to fail.

I've attempted to see if I could find anything in the sources, by 
first doing a grep -R 'mismatched array lengths' *; however I 
think I got lost in expressions.c as I don't have a good overview.


As the main difference between my Mac and other platforms is that 
it's a Big Endian architecture, I expected to be able to find 
something in the scanner/parser, where it would perhaps be 
reading a 16-bit or 32-bit character 'buffer' and then 
bit-shifting the read characters to the right instead of reading 
byte-by-byte.


But looking at macro.c; I understand that such kind of 
optimizations are probably not used.


So are there any suggestions on enabling debug-code, which might 
give hints on what is going wrong ?

Re: Trouble with Cortex-M "Hello World"

[Mike via Digitalmars-d]

On Thursday, 2 April 2015 at 05:55:52 UTC, Jens Bauer wrote:

So are there any suggestions on enabling debug-code, which 
might give hints on what is going wrong ?


You can find information on debugging GDC here:
http://wiki.dlang.org/GDC/Development/DevelopmentEnvironment

Mike

Re: Trouble with Cortex-M "Hello World"

[Johannes Pfau via Digitalmars-d]

Am Thu, 02 Apr 2015 05:55:48 +
schrieb "Jens Bauer" :

> 
> So are there any suggestions on enabling debug-code, which might 
> give hints on what is going wrong ?

I'm not sure if there's any debug code, but here's what I would do:

/opt/gdc/bin/gdc test.d -c -wrapper gdb,--args

break expression.c:11707
break expression.c:11570
break init.c:1015
run

Breakpoint 2, AssignExp::semantic (this=0x7656fad0,
sc=0x7656f440)
at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:11570

* bt (not that useful in this case)
* maybe print the dim1/2 values in gdb. 
* Look at code: we're interested in TypeSArray
* grep TypeSArray parse.c

break parse.c:3104
break parse.c:2969
break parse.c:7666

run
Breakpoint 2, Parser::parseBasicType2 (this=0x7fffdc70,
t=0x764de350)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:2969
2969t = new TypeSArray(t,e);

print *e
print e->toChars()
print *(IntegerExp*)e

break expression.c:2620
run (y)

print loc
cont (wrong integerexp)
print loc
cont (wrong integerexp)

IntegerExp::IntegerExp (this=0x764e1ff0, loc=..., value=0, 
type=0x764de2c0)
at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:2620
2620IntegerExp::IntegerExp(Loc loc, dinteger_t value, Type
*type)
(gdb) print loc
$3 = {filename = 0x1d6db30 "test.d", linnum = 9, charnum = 10}
(gdb) bt
#0  IntegerExp::IntegerExp (this=0x764e1ff0, loc=..., value=0, 
type=0x764de2c0)
at ../../gcc-5-20150201/gcc/d/dfrontend/expression.c:2620
#1  0x0070bd57 in Parser::parsePrimaryExp (
this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:6893
#2  0x007075b9 in Parser::parseUnaryExp (
this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7247
#3  0x00707d52 in Parser::parseMulExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7270
#4  0x00707ea2 in Parser::parseAddExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7293
#5  0x00707ff2 in Parser::parseShiftExp (
this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7316
#6  0x00708141 in Parser::parseCmpExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7340
#7  0x007083a1 in Parser::parseAndExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7413
#8  0x00708462 in Parser::parseXorExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7430
#9  0x00708532 in Parser::parseOrExp
(this=this@entry=0x7fffdc70)
---Type  to continue, or q  to quit---
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7446
#10 0x00708602 in Parser::parseAndAndExp (
this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7464
#11 0x007086a2 in Parser::parseOrOrExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7480
#12 0x00708742 in Parser::parseCondExp
(this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7497
#13 0x007087e6 in Parser::parseAssignExp (
this=this@entry=0x7fffdc70)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:7515
#14 0x0070b54b in Parser::parseBasicType2 (this=0x7fffdc70, 
t=0x764de350)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:2961
#15 0x00703e84 in Parser::parseDeclarations
(this=0x7fffdc70, 
autodecl=48, pAttrs=0xa0009, comment=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3516
#16 0x007010de in Parser::parseStatement (this=0x7fffdc70, 
flags=9, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4413
#17 0x007013fb in Parser::parseStatement (this=0x7fffdc70, 
flags=2, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4498
#18 0x0070210c in Parser::parseStatement (this=0x7fffdc70, 
flags=-162652272, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4518
---Type  to continue, or q  to quit---
#19 0x007013fb in Parser::parseStatement (this=0x7fffdc70, 
flags=1, endPtr=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:4498
#20 0x00703b2d in Parser::parseContracts (this=0x7fffdc70,
f=
0x764e1d40) at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3874
#21 0x007044da in Parser::parseDeclarations
(this=0x7fffdc70, 
autodecl=48, autodecl@entry=false, pAttrs=0xa0009, 
pAttrs@entry=0x7fffdb80, comment=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:3688
#22 0x00705601 in Parser::parseDeclDefs (
this=this@entry=0x7fffdc70, once=once@entry=0, 
pLastDecl=0x7fffdb18, pLastDecl@entry=0x0,
pAttrs=0x7fffdb80, 
pAttrs@entry=0x0)
at ../../gcc-5-20150201/gcc/d/dfrontend/parse.c:337
#23 0x000

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

So are there any suggestions on enabling debug-code, which 
might give hints on what is going wrong ?


I'm not sure if there's any debug code, but here's what I would 
do [snip]


Mike and Johannes - Thank you both for the suggestions.
I will follow the debug path you've given me when I've finished 
the current build.
(I'm still attempting to find a way to have both coffee and cake; 
eg. multilib support in GCC /and/ GDC).


I expect to get more information about this, and of course, I 
hope to find what causes the bug.
When my next build is finished, I plan to add a zero in front of 
the number 3:

uint[03] message =
... just in case it's a read-pointer "alignment-style" problem.

If the bug is related to Big Endian architectures, then it's a 
bit more important than if it's only related to PowerMacs; 
because there are other Big Endian hosts ...
PowerPC based Amiga, MIPS based hosts, Cortex-A based hosts, 
68xxx based hosts, other PowerPC based systems (IBM, YellowDog, 
etc) - and all those I forgot, plus future architectures.


If you are working with a BE host and come across this post, 
please post a comment, whether or not it works for you.

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

I got a little further, and will continue to look into the issue.
Currently, this is what I've gotten so far...

arm-none-eabi-gdc start.d -c -wrapper gdb,--args

break expression.c:11707
break expression.c:11570
break init.c:1015
break init.c:557
run

...

Breakpoint 1, AssignExp::semantic (this=0x4170b9f0, 
sc=0x4170b860) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:11707
11707	error("mismatched array lengths, %d and 
%d", (int)dim1, (int)dim2);



(gdb) print dim1
$1 = 0

(gdb) print dim2
$2 = 3

... dim1 is the one which is incorrect.
dim1 comes from tsa1; tsa1 comes from se1, se1 comes from e1.


(gdb) print *e1
$3 = {
   = {
_vptr$RootObject = 0xf07570
  },
  members of Expression:
  loc = {
filename = 0x41605be0 "start.d",
linnum = 46,
charnum = 13
  },
  op = TOKvar,
  type = 0x41709040,
  size = 36 '$',
  parens = 0 '\0'
}

(gdb) print e1->toChars()
$4 = 0x41611a74 "message"

(gdb) print e1->isLvalue()
$5 = 1

(gdb) print e1->type->ty
$6 = 1 '\001'


(gdb) bt
#0  AssignExp::semantic (this=0x4170b9f0, sc=0x4170b860) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:11707
#1  0x0003e230 in _ZN10Expression8optimizeEib [inlined] () at 
expression.h:1409
#2  VarDeclaration::semantic (this=0x417093c0, sc=0x4170b860) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/declaration.c:1411
#3  0x00059204 in DeclarationExp::semantic (this=0x417094a0, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/expression.c:5958
#4  0x000fed38 in ExpStatement::semantic (this=0x41709480, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:835
#5  0x00105a64 in CompoundStatement::semantic (this=0x4170b7f0, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1044
#6  0x00104838 in ScopeStatement::semantic (this=0x41709600, 
sc=0x4170b750) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1336
#7  0x0010a890 in ForStatement::semantic (this=0x4170b680, 
sc=0x4170aee0) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1546
#8  0x00105a64 in CompoundStatement::semantic (this=0x41709640, 
sc=0x4170ae40) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/statement.c:1044
#9  0x0007f2ec in FuncDeclaration::semantic3 (this=0x41708e70, 
sc=0x4170aa00) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/func.c:1622
#10 0x000d6f18 in Module::semantic3 (this=0x41707a90) at 
/Users/jens/toolchain/Source/gcc/gcc/d/dfrontend/module.c:787
#11 0x0012c38c in d_parse_file () at 
/Users/jens/toolchain/Source/gcc/gcc/d/d-lang.cc:1064

#12 0x00773ca8 in timevar_pop [inlined] () at timevar.h:548
#13 0x00773ca8 in compile_file () at 
/Users/jens/toolchain/Source/gcc/gcc/toplev.c:550
#14 0x00774c2c in do_compile () at 
/Users/jens/toolchain/Source/gcc/gcc/toplev.c:1926
#15 0x0077519c in toplev_main (argc=11, argv=0xb148) at 
/Users/jens/toolchain/Source/gcc/gcc/toplev.c:2002

#16 0x2404 in start ()

Re: Trouble with Cortex-M "Hello World"

[Daniel Murphy via Digitalmars-d]

"Jens Bauer"  wrote in message news:gufvwhyvuyuhhkgdy...@forum.dlang.org...

I expect to get more information about this, and of course, I hope to find 
what causes the bug.
When my next build is finished, I plan to add a zero in front of the 
number 3:

uint[03] message =
... just in case it's a read-pointer "alignment-style" problem.


You can tell how far through the error is by triggering failures in 
different compilation phases.


eg to generate a parser error, give the compiler something invalid like:
pragma 3
which should generate
testx.d(2): Error: found '3' when expecting '('

This should error during semantic2
static assert(3 == 2); 

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

Well, it seems I found the problem.

lexer.h, line 203 reads:

union
{
d_int32 int32value;
d_uns32 uns32value;
d_int64 int64value;
d_uns64 uns64value;
...
...
...
};

While this optimization is neat, it does not produce correct code 
on Big Endian or Mixed Endian platforms.


If we write a value to int64value and read it from int32value, 
then it will be 0 always.
This is because the int32value is always read if the upper 32 
bits of the int64value is zero.
And since a Big Endian platform reads the most significant 
bits/bytes first, they'll read the upper 32 bits, not the lower 
32 bits.


lexer.c:1874; Lexer::number(Token *t) correctly writes n to 
t->uns64value.
-But let's take parse.c:6384 - here token.uns32value is read, 
thus we'll get a zero, no matter which value was written by 
number(Token *).


In parse.c:6379 we would get a minus one always.

Looking for union-"tricks", I also found ...
stringtable.c:24 hash will not be the same value on Big Endian, 
Mixed Endian and Little Endian machines.
To hash correctly, read one byte at a time, then use bit-shifting 
by 8 if another byte is to be read.

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

I better also mention that the problem is the same for floats in 
Lexer::inreal(Token *).

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 08:06:03 UTC, Jens Bauer wrote:
I better also mention that the problem is the same for floats 
in Lexer::inreal(Token *).


Ignore that - it's always read/written as a long double.
Sorry for then noise.

Re: Trouble with Cortex-M "Hello World"

[Johannes Pfau via Digitalmars-d]

Am Fri, 03 Apr 2015 07:32:21 +
schrieb "Jens Bauer" :

> Well, it seems I found the problem.
> 
> lexer.h, line 203 reads:
> 
>  union
>  {
>  d_int32 int32value;
>  d_uns32 uns32value;
>  d_int64 int64value;
>  d_uns64 uns64value;
>  ...
>  ...
>  ...
>  };
> 
> While this optimization is neat, it does not produce correct code 
> on Big Endian or Mixed Endian platforms.
> 
> If we write a value to int64value and read it from int32value, 
> then it will be 0 always.
> This is because the int32value is always read if the upper 32 
> bits of the int64value is zero.
> And since a Big Endian platform reads the most significant 
> bits/bytes first, they'll read the upper 32 bits, not the lower 
> 32 bits.
> 
> lexer.c:1874; Lexer::number(Token *t) correctly writes n to 
> t->uns64value.
> -But let's take parse.c:6384 - here token.uns32value is read, 
> thus we'll get a zero, no matter which value was written by 
> number(Token *).
> 
> In parse.c:6379 we would get a minus one always.

Nice find. If you open a pull request on
https://github.com/D-Programming-Language/dmd
please notify me (@jpf91). I'll make sure to backport the fix to gdc
once it's been committed to dmd upstream.

> Looking for union-"tricks", I also found ...
> stringtable.c:24 hash will not be the same value on Big Endian, 
> Mixed Endian and Little Endian machines.
> To hash correctly, read one byte at a time, then use bit-shifting 
> by 8 if another byte is to be read.

IIRC it does not really matter if the hash is different here as it's
only used internally in the compiler. So as long as it still hashes
correctly ('no' collisions) it shouldn't matter.

Re: Trouble with Cortex-M "Hello World"

[Daniel Murphy via Digitalmars-d]

"Jens Bauer"  wrote in message news:ckqcspcptqazbawds...@forum.dlang.org... 


Well, it seems I found the problem.

lexer.h, line 203 reads:


Yeah, I thought it might be that.


Looking for union-"tricks", I also found ...
stringtable.c:24 hash will not be the same value on Big Endian, 
Mixed Endian and Little Endian machines.
To hash correctly, read one byte at a time, then use bit-shifting 
by 8 if another byte is to be read.


It doesn't matter for this hash table.

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 10:32:39 UTC, Daniel Murphy wrote:

It doesn't matter for this hash table.


Alright - if there's no major difference in performance, then it 
won't matter (Johannes mentioned that it's only used internally).


I've sent an email to Johannes regarding the patch - because 
GitHub will not support any of my Web-browsers.


A link to the patch is as far as I can get:
https://github.com/D-Programming-Language/dmd/compare/master...jens-gpio:bugfix_endian

Re: Trouble with Cortex-M "Hello World"

[Kai Nacke via Digitalmars-d]

On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian 
system.


LDC is endian-clean. I used LDC on big-endian Linux/PPC64.

Regards,
Kai

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:

On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian 
system.


LDC is endian-clean. I used LDC on big-endian Linux/PPC64.


Unfortunately, I can't b uild LLVM on my PowerMac. :/

... I find it a little strange that LDC is endian-clean; don't 
they all use the same parser ?

Re: Trouble with Cortex-M "Hello World"

[John Colvin via Digitalmars-d]

On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:

On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:
On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau 
wrote:
I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian 
system.


LDC is endian-clean. I used LDC on big-endian Linux/PPC64.


Unfortunately, I can't b uild LLVM on my PowerMac. :/

... I find it a little strange that LDC is endian-clean; don't 
they all use the same parser ?


LDC's frontend is a fork of DMD's frontend - modified to use LLVM 
backend and a few other tweaks - that tracks upstream. Not 
exactly "the same".

Re: Trouble with Cortex-M "Hello World"

[Iain Buclaw via Digitalmars-d]

On 3 April 2015 at 17:05, John Colvin via Digitalmars-d
 wrote:
> On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
>>
>> On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:
>>>
>>> On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:

 I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian system.
>>>
>>>
>>> LDC is endian-clean. I used LDC on big-endian Linux/PPC64.
>>
>>
>> Unfortunately, I can't b uild LLVM on my PowerMac. :/
>>
>> ... I find it a little strange that LDC is endian-clean; don't they all
>> use the same parser ?
>
>
> LDC's frontend is a fork of DMD's frontend - modified to use LLVM backend
> and a few other tweaks - that tracks upstream. Not exactly "the same".

That's a bit greedy of them to not upstream fixes. >:-)

Iain.

Re: Trouble with Cortex-M "Hello World"

[David Nadlinger via Digitalmars-d]

On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:

Unfortunately, I can't b uild LLVM on my PowerMac. :/


Why would that be so?

  — David

Re: Trouble with Cortex-M "Hello World"

[David Nadlinger via Digitalmars-d]

On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:

That's a bit greedy of them to not upstream fixes. >:-)


Some of the fixes use LLVM libraries, so there is not much point 
in upstreaming that. ;)


 – David

Re: Trouble with Cortex-M "Hello World"

[Iain Buclaw via Digitalmars-d]

On 3 April 2015 at 17:40, David Nadlinger via Digitalmars-d
 wrote:
> On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:
>>
>> That's a bit greedy of them to not upstream fixes. >:-)
>
>
> Some of the fixes use LLVM libraries, so there is not much point in
> upstreaming that. ;)
>
>  – David

It might be a suggestion to abstract the changes away into Port/Target
rather than use macros (if you use LLVM macros that is).

Iain

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:

On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:

Unfortunately, I can't b uild LLVM on my PowerMac. :/


Why would that be so?


Basically because it requires GCC > 4.2 - but unfortunately 
there's more.
Once upon a time, LLVM did support being built with GCC 4.2, but 
I can't get those sources anymore, so I can't get a 'bootstrap 
LLVM' that way.

Re: Trouble with Cortex-M "Hello World"

[Iain Buclaw via Digitalmars-d]

On 3 April 2015 at 17:58, Jens Bauer via Digitalmars-d
 wrote:
> On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:
>>
>> On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
>>>
>>> Unfortunately, I can't b uild LLVM on my PowerMac. :/
>>
>>
>> Why would that be so?
>
>
> Basically because it requires GCC > 4.2 - but unfortunately there's more.
> Once upon a time, LLVM did support being built with GCC 4.2, but I can't get
> those sources anymore, so I can't get a 'bootstrap LLVM' that way.

I guess if you're happy to work with D1... (which is far more easier
to port than D2 will ever be).

Iain.

Re: Trouble with Cortex-M "Hello World"

[David Nadlinger via Digitalmars-d]

On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:
Basically because it requires GCC > 4.2 - but unfortunately 
there's more.
Once upon a time, LLVM did support being built with GCC 4.2, 
but I can't get those sources anymore, so I can't get a 
'bootstrap LLVM' that way.


Can't you just bootstrap your way up to a recent GCC first?

 — David

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 16:11:59 UTC, Iain Buclaw wrote:

On 3 April 2015 at 17:58, Jens Bauer via Digitalmars-d
Basically because it requires GCC > 4.2 - but unfortunately 
there's more.
Once upon a time, LLVM did support being built with GCC 4.2, 
but I can't get
those sources anymore, so I can't get a 'bootstrap LLVM' that 
way.


I guess if you're happy to work with D1... (which is far more 
easier

to port than D2 will ever be).


It's actually only clang I have problems with, not LDC.
D2 probably doesn't have any serious errors on my platform.
-The only part that was a bit challenging was the BE issue, but 
I'm confident that it will be solved the right way. ;)


At some point, I might want to try building dmd as well; 
currently it does not seem to support Mac/PPC (I had a short look 
at it, but it seems I need to write some header files in order to 
get it working).

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 16:39:40 UTC, David Nadlinger wrote:

On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:
Basically because it requires GCC > 4.2 - but unfortunately 
there's more.
Once upon a time, LLVM did support being built with GCC 4.2, 
but I can't get those sources anymore, so I can't get a 
'bootstrap LLVM' that way.


Can't you just bootstrap your way up to a recent GCC first?


Unfortunately, GCC > 4.2 is not patched by Apple.
When Apple suddenly decided to stop using GCC, they withdrew all 
patches and made clear to the GCC team that they were not allowed 
to use any of those patches.
This causes some problems with building Mach'o binaries, which is 
native to Mac/PPC.
It also causes incompatibilities regarding ObjC and poor Xcode 
integration (!)
-So it would have been better to get the old clang sources and 
build clang that way.
Or perhaps someone with an Intel Mac could build clang for PPC, 
heh. ;)

Re: Trouble with Cortex-M "Hello World"

[John Colvin via Digitalmars-d]

On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:

On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:

On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:

Unfortunately, I can't b uild LLVM on my PowerMac. :/


Why would that be so?


Basically because it requires GCC > 4.2 - but unfortunately 
there's more.
Once upon a time, LLVM did support being built with GCC 4.2, 
but I can't get those sources anymore, so I can't get a 
'bootstrap LLVM' that way.


There is universal binary of LLVM 2.1 with clang (llvm-gcc back 
then I think) available here: 
http://llvm.org/releases/2.1/llvm-llvm-gcc4.0-2.1-darwin-univ.tar.gz

Re: Trouble with Cortex-M "Hello World"

[Jens Bauer via Digitalmars-d]

On Friday, 3 April 2015 at 17:05:28 UTC, John Colvin wrote:
There is universal binary of LLVM 2.1 with clang (llvm-gcc back 
then I think) available here: 
http://llvm.org/releases/2.1/llvm-llvm-gcc4.0-2.1-darwin-univ.tar.gz


Thank you so much; I'll try it immediately. I don't know why I 
haven't noticed it!

Re: Trouble with Cortex-M "Hello World"

[Kai Nacke via Digitalmars-d]

On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:

That's a bit greedy of them to not upstream fixes. >:-)


I don't know why this change was not upstreamed - it's from 2012!

BTW: There are some places in constfold.c and ctfeexpr.c which 
are also not endian-clean. And also not upstream... Just search 
LDC source for __LITTLE_ENDIAN__.


Regards,
Kai

Re: Trouble with Cortex-M "Hello World"

[Iain Buclaw via Digitalmars-d]

On 4 April 2015 at 01:17, Kai Nacke via Digitalmars-d
 wrote:
> On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote:
>>
>> That's a bit greedy of them to not upstream fixes. >:-)
>
>
> I don't know why this change was not upstreamed - it's from 2012!
>
> BTW: There are some places in constfold.c and ctfeexpr.c which are also not
> endian-clean. And also not upstream... Just search LDC source for
> __LITTLE_ENDIAN__.
>
> Regards,
> Kai

I had a look, you should definitely raise PRs for those.

Iain.

Want to start a graphical Hello world.

[MHE via Digitalmars-d]

Hi there ,  i have this code :


import gtk.MainWindow, gtk.Label, gtk.Main;

class GoodbyeWorld : MainWindow {
this() {
super("GtkD");
add(new Label("Goodbye World"));
showAll();
}
}

void main(string[] args) {
Main.init(args);
new GoodbyeWorld();
Main.run();
}



For this i have made a folder named GIT in the linux directory 
/usr/local/GIT

And Gitcloned in the GIT folder :
git clone https://github.com/nomad-software/x11
git clone https://github.com/nomad-software/tcltk.git
The clones are now in /usr/local/GIT/

When i start the upper code in a cmd the result is as follows :
___
$ dmd hw_graphical.d
hw_graphical.d(1): Error: module MainWindow is in file 
'gtk/MainWindow.d' which cannot be read

import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import


What must be done that the code make a graphical window ?

I want to make the D programming tkd module ready for GUI 
programming.

Need a step by step advice for BEGINNERS in D programming.

Any Internetlink for step by step instructions how to arrange D 
and TK would be helpful !


WBR
MHE

Hello World crashes on OS X 10.6.1

[asd]

import std.stdio;


void main()
{
writef("Hello world\n");
}


dmd -run test.d gives:

Process: test [1703]
Path:/Users/username/Desktop/test
Identifier:  test
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  dmd [1698]

Date/Time:   2009-10-31 10:18:54.604 +
OS Version:  Mac OS X 10.6.1 (10B504)
Report Version:  6

Interval Since Last Report:  1964 sec
Crashes Since Last Report:   4
Per-App Crashes Since Last Report:   3
Anonymous UUID:  1840379D-AECE-4F32-870F-67C913F11C0E

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x9090007c
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   test0x3bf5 
D3std4conv11__T2toTsTiZ2toFiZs + 13
1   test0x2584 _Dmain + 32
2   test0x7ec7 
D2rt6dmain24mainUiPPaZi7runMainMFZv + 23
3   test0x7c4e 
D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42
4   test0x7f0b 
D2rt6dmain24mainUiPPaZi6runAllMFZv + 55
5   test0x7c4e 
D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42
6   test0x7bdc main + 168
7   test0x2559 start + 53

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x9090007c  ebx: 0xb238  ecx: 0x7c35  edx: 0x7eb0
  edi: 0x7b5a  esi: 0xb238  ebp: 0xb118  esp: 0xb0fc
   ss: 0x001f  efl: 0x00010202  eip: 0x3bf5   cs: 0x0017
   ds: 0x001f   es: 0x001f   fs: 0x   gs: 0x0037
  cr2: 0x9090007c

Binary Images:
0x1000 -0x1fff7 +test ??? (???)  
/Users/username/Desktop/test
0x8fe0 - 0x8fe4162b  dyld 132.1 (???) 
<211AF0DD-42D9-79C8-BB6A-1F4BEEF4B4AB> /usr/lib/dyld
0x91b41000 - 0x91b44fe7  libmathCommon.A.dylib ??? (???) 
<1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x94128000 - 0x942ccfeb  libSystem.B.dylib ??? (???) 
 /usr/lib/libSystem.B.dylib
0x - 0x1fff  libSystem.B.dylib ??? (???) 
 /usr/lib/libSystem.B.dylib

Re: Want to start a graphical Hello world.

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 21 January 2018 at 04:16:10 UTC, MHE wrote:

$ dmd hw_graphical.d


You need to link in and tell the compiler where to find the 
library. Tru


dmd -I/usr/local/GIT/whatever hw_graphical.d -L-lgtk

and whatever else the library does. I haven't used gtkd so I 
don't know the exact thing for it, but something like that.

Re: Want to start a graphical Hello world.

[Matthias Klumpp via Digitalmars-d]

On Sunday, 21 January 2018 at 04:16:10 UTC, MHE wrote:

[...]
For this i have made a folder named GIT in the linux directory 
/usr/local/GIT

And Gitcloned in the GIT folder :
git clone https://github.com/nomad-software/x11
git clone https://github.com/nomad-software/tcltk.git
The clones are now in /usr/local/GIT/


Hmm, but you are using GtkD in your example... It looks like you 
compiled the wrong code.
What you actually want is GtkD from 
https://github.com/gtkd-developers/GtkD or installed from the 
Debian repositories (in case you want to use LDC) via `sudo apt 
install libgtkd-3-dev`



When i start the upper code in a cmd the result is as follows :
___
$ dmd hw_graphical.d
hw_graphical.d(1): Error: module MainWindow is in file 
'gtk/MainWindow.d' which cannot be read

import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import


What must be done that the code make a graphical window ?


If you want to use GtkD and achieve a quick result, you might 
want to use the Dub package manager.
GtkD also has a few demo applications that show you how to use it 
with dub, take a look at

https://github.com/gtkd-developers/GtkD/tree/master/demos/gtk

I want to make the D programming tkd module ready for GUI 
programming.

Need a step by step advice for BEGINNERS in D programming.


tkd is a project different from GtkD (which your example above is 
using). For "modern" UI that integrates well with GNOME, you will 
highly likely want to use GtkD. Tcl/Tk is of course an option as 
well, but the D bindings look less complete and well maintained.
In case you want to use Tk, you will need to change your code to 
actually use it, instead of GTK+ though ;-)


Any Internetlink for step by step instructions how to arrange D 
and TK would be helpful !


I can't help with Tk, but for GTK+ a quick Google search found 
https://sites.google.com/site/gtkdtutorial/ - this tutorial is 
rather old, but it might be useful as a reference.


This experience report by Gerald Nunn might also be an 
interesting read for you: 
https://gexperts.com/wp/learning-d-and-gtk/


Cheers,
Matthias

Re: Hello World crashes on OS X 10.6.1

[asd]

forgot to add it's freshly downloaded dmd v2.035.

Re: Hello World crashes on OS X 10.6.1

[Jason House]

It's a known issue. Apple breaks backwards compatibility all the time. Walter 
hinted that 2.034 would fix the issue, but that didn't come to pass. I don't 
know if that's from difficulty or shifting priorities. I'm sure a patch would 
be appreciated ;)

asd Wrote:

> import std.stdio;
> 
> 
> void main()
> {
>   writef("Hello world\n");
> }
> 
> 
> dmd -run test.d gives:
> 
> Process: test [1703]
> Path:/Users/username/Desktop/test
> Identifier:  test
> Version: ??? (???)
> Code Type:   X86 (Native)
> Parent Process:  dmd [1698]
> 
> Date/Time:   2009-10-31 10:18:54.604 +
> OS Version:  Mac OS X 10.6.1 (10B504)
> Report Version:  6
> 
> Interval Since Last Report:  1964 sec
> Crashes Since Last Report:   4
> Per-App Crashes Since Last Report:   3
> Anonymous UUID:  1840379D-AECE-4F32-870F-67C913F11C0E
> 
> Exception Type:  EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x9090007c
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> 
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   test  0x3bf5 
> D3std4conv11__T2toTsTiZ2toFiZs + 13
> 1   test  0x2584 _Dmain + 32
> 2   test  0x7ec7 
> D2rt6dmain24mainUiPPaZi7runMainMFZv + 23
> 3   test  0x7c4e 
> D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42
> 4   test  0x7f0b 
> D2rt6dmain24mainUiPPaZi6runAllMFZv + 55
> 5   test  0x7c4e 
> D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42
> 6   test  0x7bdc main + 168
> 7   test  0x2559 start + 53
> 
> Thread 0 crashed with X86 Thread State (32-bit):
>   eax: 0x9090007c  ebx: 0xb238  ecx: 0x7c35  edx: 0x7eb0
>   edi: 0x7b5a  esi: 0xb238  ebp: 0xb118  esp: 0xb0fc
>ss: 0x001f  efl: 0x00010202  eip: 0x3bf5   cs: 0x0017
>ds: 0x001f   es: 0x001f   fs: 0x   gs: 0x0037
>   cr2: 0x9090007c
> 
> Binary Images:
> 0x1000 -0x1fff7 +test ??? (???) 
>  /Users/username/Desktop/test
> 0x8fe0 - 0x8fe4162b  dyld 132.1 (???) 
> <211AF0DD-42D9-79C8-BB6A-1F4BEEF4B4AB> /usr/lib/dyld
> 0x91b41000 - 0x91b44fe7  libmathCommon.A.dylib ??? (???) 
> <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
> 0x94128000 - 0x942ccfeb  libSystem.B.dylib ??? (???) 
>  /usr/lib/libSystem.B.dylib
> 0x - 0x1fff  libSystem.B.dylib ??? (???) 
>  /usr/lib/libSystem.B.dylib
> 
> 

why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Abe via Digitalmars-d]

Dear all,

Me: a very experienced computer programmer, a newbie to D.

The test program:



   import std.stdio;

   void main() {
   writeln("hello world!");
   }



The result:

   > ls -l foo
   -rwxr-xr-x  1 Abe  wheel  502064 Aug 31 18:47 foo

   > file foo
   foo: Mach-O 64-bit executable x86_64

   > ./foo
   hello world!


Please note: 502064 bytes!!!  [for the curious: 490.296875
kilobytes]


The compiler:

   DMD64 D Compiler v2.066.0
   Copyright (c) 1999-2014 by Digital Mars written by Walter 
Bright

   Documentation: http://dlang.org/


The OS: Mac OS X 10.6.8


The question: why is Hello World so frickin` huge?!?

[FYI: using "dmd -O" instead of plan "dmd" makes no difference in
the size of the executable]


— Abe

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 31 August 2014 at 23:51:41 UTC, Abe wrote:

   writeln("hello world!");


The std.stdio package imports most the standard library, so using 
it means a lot of library code is linked into your executable too.


About 200kb is the D runtime code and the rest is standard 
library code.

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Jacob Carlborg via Digitalmars-d]

On 01/09/14 01:51, Abe wrote:


The question: why is Hello World so frickin` huge?!?


The runtime and standard library is statically linked, compared to C 
where it's dynamically linked. Also unnecessary symbols are not 
stripped. DMD on OS X doesn't currently support dynamic libraries. LDC 
has the --gc-sections flag, enabled by default. This will significantly 
reduce the since of the binary.


--
/Jacob Carlborg

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Dan Olson via Digitalmars-d]

Jacob Carlborg  writes:

> On 01/09/14 01:51, Abe wrote:
>
>> The question: why is Hello World so frickin` huge?!?
>
> The runtime and standard library is statically linked, compared to C
> where it's dynamically linked. Also unnecessary symbols are not
> stripped. DMD on OS X doesn't currently support dynamic libraries. LDC
> has the --gc-sections flag, enabled by default. This will
> significantly reduce the since of the binary.

Another option you can use today with OS X is pass in -dead_strip linker
option to get rid of unreachable symbols. It works good with LDC.

using LDC - the LLVM D compiler (0.14.0):
  based on DMD v2.065 and LLVM 3.4.2

$ ldc2 -L-dead_strip hello.d
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   305K Sep  1 10:01 hello
$ strip hello
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   228K Sep  1 10:01 hello

A version using puts instead of writeln shrinks more.

ldc2 helloputs -L-dead_strip
$ ldc2 -L-dead_strip helloputs.d
$ ls -lh helloputs
-rwxr-xr-x  1 dan  staff   243K Sep  1 10:01 helloputs
$ strip helloputs
$ ls -lh helloputs
-rwxr-xr-x  1 dan  staff   181K Sep  1 10:01 helloputs

Otherwise LDC makes really big binaries:

$ ldc2 hello.d
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   2.2M Sep  1 10:01 hello
$ strip hello
$ ls -lh hello
-rwxr-xr-x  1 dan  staff   1.9M Sep  1 10:01 hello

When I try -dead_strip with DMD, I get runtime SEGV with simple writeln
hello world :-(

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Dicebot via Digitalmars-d]

On Monday, 1 September 2014 at 17:23:03 UTC, Dan Olson wrote:

Jacob Carlborg  writes:


On 01/09/14 01:51, Abe wrote:


The question: why is Hello World so frickin` huge?!?


The runtime and standard library is statically linked, 
compared to C

where it's dynamically linked. Also unnecessary symbols are not
stripped. DMD on OS X doesn't currently support dynamic 
libraries. LDC

has the --gc-sections flag, enabled by default. This will
significantly reduce the since of the binary.


Another option you can use today with OS X is pass in 
-dead_strip linker
option to get rid of unreachable symbols. It works good with 
LDC.


using LDC - the LLVM D compiler (0.14.0):
  based on DMD v2.065 and LLVM 3.4.2


This was supposed to be enabled by default in 0.14.0 (it is 
exactly what ld --gc-sections does). Probably some issue with ld 
argument wrapper for whatever lines OSX uses?

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-01 19:28, Dicebot wrote:


This was supposed to be enabled by default in 0.14.0 (it is exactly what
ld --gc-sections does). Probably some issue with ld argument wrapper for
whatever lines OSX uses?


It only works for Linux.

--
/Jacob Carlborg

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-01 19:23, Dan Olson wrote:


When I try -dead_strip with DMD, I get runtime SEGV with simple writeln
hello world :-(


It will probably clean out TLS, module info and similar data which is 
not reachable from the main function.


--
/Jacob Carlborg

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Dicebot via Digitalmars-d]

On Monday, 1 September 2014 at 17:46:11 UTC, Jacob Carlborg wrote:

On 2014-09-01 19:28, Dicebot wrote:

This was supposed to be enabled by default in 0.14.0 (it is 
exactly what
ld --gc-sections does). Probably some issue with ld argument 
wrapper for

whatever lines OSX uses?


It only works for Linux.


Any reason why it can't work for OSX in a same way? Assuming LDC 
does emit ModuleInfo & Co sections the same way it does on Linux, 
using OSX specific alternative to --gc-sections should "just 
work".

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[David Nadlinger via Digitalmars-d]

On Monday, 1 September 2014 at 18:33:44 UTC, Dicebot wrote:
Any reason why it can't work for OSX in a same way? Assuming 
LDC does emit ModuleInfo & Co sections the same way it does on 
Linux, using OSX specific alternative to --gc-sections should 
"just work".


The reason we don't enable the -dead_strip option of ld64 is 
simply because nobody had time to make sure it works as intended. 
For Linux, I made the necessary adjustments to get --gc-sections 
to function correctly while I was working on the related code for 
runtime loading anyway.


David

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Jacob Carlborg via Digitalmars-d]

On 01/09/14 20:33, Dicebot wrote:


Any reason why it can't work for OSX in a same way? Assuming LDC does
emit ModuleInfo & Co sections the same way it does on Linux, using OSX
specific alternative to --gc-sections should "just work".


It does not emit these sections the same way, at least not on DMD.

--
/Jacob Carlborg

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Dicebot via Digitalmars-d]

On Tuesday, 2 September 2014 at 06:18:27 UTC, Jacob Carlborg
wrote:

On 01/09/14 20:33, Dicebot wrote:

Any reason why it can't work for OSX in a same way? Assuming 
LDC does
emit ModuleInfo & Co sections the same way it does on Linux, 
using OSX

specific alternative to --gc-sections should "just work".


It does not emit these sections the same way, at least not on 
DMD.


Well I am speaking about LDC ;) --gc-sections don't work with
Linux DMD either.

Re: why does DMD compile "hello world" to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

[Marco Leise via Digitalmars-d]

Am Tue, 02 Sep 2014 07:03:52 +
schrieb "Dicebot" :

> On Tuesday, 2 September 2014 at 06:18:27 UTC, Jacob Carlborg
> wrote:
> > On 01/09/14 20:33, Dicebot wrote:
> >
> >> Any reason why it can't work for OSX in a same way? Assuming 
> >> LDC does
> >> emit ModuleInfo & Co sections the same way it does on Linux, 
> >> using OSX
> >> specific alternative to --gc-sections should "just work".
> >
> > It does not emit these sections the same way, at least not on 
> > DMD.
> 
> Well I am speaking about LDC ;) --gc-sections don't work with
> Linux DMD either.

Hey, every new release I go and try it, but found that dub
will still crash when linked with --gc-sections, so some
symbols need to be "added as GC roots".

That said with -defaultlib=phobos2 (picking up the .so
version) the file size is:

   48 KiB  !!!

after `strip main` it comes down to:

   34 KiB  !!!

Only when you think about how people put 5 minutes of a
stunning 3D gfx demo into 64 KiB you start to worry about 34
KiB for "Hello World!" again.

-- 
Marco