www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Up to date documentation on D implementation.

reply "ReneSac" <reneduani yahoo.com.br> writes:
Hi.

I'm totally new to D, and would like to use it to prototype some 
compression software ideas. But everywhere in old posts I see 
that some XYZ feature of the language is buggy, subject to 
change, etc. But I don't know how it is today, and I would rather 
not learn what is wrong with the feature in the hard way, by 
stumbling in the compiler bugs. My hand will be full with my own 
bugs, and I would like to suppose an correctly working language...

So, is there any up to date documentation on D implementation, 
saying what is stable, what is beta quality (and I should use 
with caution), what is alpha (and I should really avoid), and 
what is unimplemented?

Also, witch compiler I should use? In the 
[url=http://dlang.org/dmd-windows.html]DMD requirements[/url], it 
says "32 bit Windows (Win32) operating system, such as Windows 
XP", so I guess I'm out of luck with Windows 7 64 bits... Do I 
really have to use a VM to develop in D for running in Windows? 
And on linux, which is the most stable? Which is the faster one 
for my use case?

Thanks.
Apr 05 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ReneSac:


 My hand will be full with my own bugs, and I would like to 
 suppose an correctly working language...


If you use more than the basic C features, you will find DMD
compiler bugs (and probably the same is true for any D compiler,
because most bugs are in the front-end, that is shared). Lately I
hit new bugs less often, but they happen still.

Bye,
bearophile
Apr 05 2012
parent David <d dav1d.de> writes:
Am 05.04.2012 17:56, schrieb bearophile:

 ReneSac:


 My hand will be full with my own bugs, and I would like to suppose an
 correctly working language...


 If you use more than the basic C features, you will find DMD
 compiler bugs (and probably the same is true for any D compiler,
 because most bugs are in the front-end, that is shared). Lately I
 hit new bugs less often, but they happen still.

 Bye,
 bearophile


Well, that's true, sometimes you hit a compiler or phobos-bug, but it's 
not like:

uhm, today I wanna code something, let's begin … 5 minutes later … uh 
tha fuq another compiler bug !!!!

It has gotten pretty rare that you hit them and when you do, you 
normally realize it very soon that this is a bug from the compiler (e.g. 
cod2.c shows up in the error message).
And if you hit one, ppl in the IRC or here will help you out, with a 
bugfix or a workaround!
Apr 05 2012
prev sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 5 April 2012 at 15:01:53 UTC, ReneSac wrote:

 Hi.

 I'm totally new to D, and would like to use it to prototype 
 some compression software ideas.


You'll be pretty safe using features you know for C, but you can 
venture out pretty far from it.

While, the page isn't specific to the questions you have at hand, 
this does cover much of the current state. Remember, recently 
implemented features are more likely to have bugs.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel
Apr 05 2012
parent reply "ReneSac" <reneduani yahoo.com.br> writes:
On Thursday, 5 April 2012 at 18:34:05 UTC, Jesse Phillips wrote:

 You'll be pretty safe using features you know for C, but you 
 can venture out pretty far from it.

 While, the page isn't specific to the questions you have at 
 hand, this does cover much of the current state. Remember, 
 recently implemented features are more likely to have bugs.


I will probably program close to C/Lua style (the languages I'm 
most proficient with), but "pretty far" is vague. And I haven't 
been following the time line of the feature additions, like old 
users do, and I'm not sure if I should read the entire changelog 
for some vague indication of the stability of a feature...


 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel


Ok, that page gives some pointers. Seems like I shouldn't use 
std.stream. So, std.cstream or std.stdio are safe?

Dynamic Arrays, Slicing, Unittest, conditional compilation and 
compile time function execution should be working well, right? 
What about std.paralelism and message passing, non-shared 
multithreading?

And I still don't know how to generate windows executables.. If 
it is really impossible to compile D in Windows 64 bits, then 
what is the best compiler for Linux?
Apr 05 2012
next sibling parent reply David <d dav1d.de> writes:
Am 05.04.2012 23:10, schrieb ReneSac:

 Ok, that page gives some pointers. Seems like I shouldn't use
 std.stream. So, std.cstream or std.stdio are safe?


I also heared that, but actually std.stream works pretty well, 
especially the EndianStream. So I can recommend you to use it.
Apr 05 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, April 05, 2012 23:47:52 David wrote:

 Am 05.04.2012 23:10, schrieb ReneSac:

 Ok, that page gives some pointers. Seems like I shouldn't use
 std.stream. So, std.cstream or std.stdio are safe?


 
 I also heared that, but actually std.stream works pretty well,
 especially the EndianStream. So I can recommend you to use it.


Regardless of how well it works, it's going to be replaced with a range-based 
API. So, it's not going to be around in the long run. You can use it. You just 
have to be aware that it's going to go away. Unfortunately, its replacement is 
far from ready, so we really don't know when it's actually going to be 
replaced.

- Jonathan M Davis
Apr 05 2012
prev sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 5 April 2012 at 21:10:41 UTC, ReneSac wrote:


 I will probably program close to C/Lua style (the languages I'm 
 most proficient with), but "pretty far" is vague. And I haven't 
 been following the time line of the feature additions, like old 
 users do, and I'm not sure if I should read the entire 
 changelog for some vague indication of the stability of a 
 feature...


The page I liked does have compiler versions for some of the 
implemented features, as you appear to have noticed.


 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel


 Ok, that page gives some pointers. Seems like I shouldn't use 
 std.stream. So, std.cstream or std.stdio are safe?


Hmm, bring up a good point, I think someone is working on 
revamping stdio, though I would think it would mostly remain 
compatible. Who's doing that? Could you write the details here:

http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue


 Dynamic Arrays, Slicing, Unittest, conditional compilation and 
 compile time function execution should be working well, right?


Yep, there are some requested improvements but, things are stable.


 What about std.paralelism and message passing, non-shared 
 multithreading?


I'm not sure how much use they have been getting, so it is hard 
to say. I know there have been questions about how to use them, 
but they seem solid.

If you get into using shared though, you'll probably walk into 
areas that will require casting to get things done. I don't know 
what if any changes are planned, but likely it needs a closer 
look.


 And I still don't know how to generate windows executables.. If 
 it is really impossible to compile D in Windows 64 bits, then 
 what is the best compiler for Linux?


Sorry, forgot to cover that. I believe GDC will compile 64bit 
Windows applications, but otherwise you can still compile and run 
32bit applications.

Most people use DMD, but GDC, I hear, should be on par.
Apr 05 2012
next sibling parent reply "ReneSac" <reneduani yahoo.com.br> writes:
On Thursday, 5 April 2012 at 22:07:05 UTC, Jesse Phillips wrote:

 On Thursday, 5 April 2012 at 21:10:41 UTC, ReneSac wrote:


 I will probably program close to C/Lua style (the languages 
 I'm most proficient with), but "pretty far" is vague. And I 
 haven't been following the time line of the feature additions, 
 like old users do, and I'm not sure if I should read the 
 entire changelog for some vague indication of the stability of 
 a feature...


 The page I liked does have compiler versions for some of the 
 implemented features, as you appear to have noticed.


Ah, I saw "The following list of major issues dates from July 
2009." So I supposed it was old, but now I see that I understood 
wrong.


 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel


 Ok, that page gives some pointers. Seems like I shouldn't use 
 std.stream. So, std.cstream or std.stdio are safe?


 Hmm, bring up a good point, I think someone is working on 
 revamping stdio, though I would think it would mostly remain 
 compatible. Who's doing that? Could you write the details here:


So, what I should use?


 http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue


 Dynamic Arrays, Slicing, Unittest, conditional compilation and 
 compile time function execution should be working well, right?


 Yep, there are some requested improvements but, things are 
 stable.


Good! Thanks.


 What about std.paralelism and message passing, non-shared 
 multithreading?


 I'm not sure how much use they have been getting, so it is hard 
 to say. I know there have been questions about how to use them, 
 but they seem solid.

 If you get into using shared though, you'll probably walk into 
 areas that will require casting to get things done. I don't 
 know what if any changes are planned, but likely it needs a 
 closer look.


I would try to avoid anything shared anyway. It is hard to 
program if "a++" isn't deterministic...


 Sorry, forgot to cover that. I believe GDC will compile 64bit 
 Windows applications, but otherwise you can still compile and 
 run 32bit applications.

 Most people use DMD, but GDC, I hear, should be on par.


I don't need a 64bit binary right now. Actually, I would even 
prefer a 32bit one for development because then I can't run too 
wild in memory usage. The problem is that DMD seems to require 32 
bit windows, according to the page I linked... Is it not true?

Anyway, GDC seems to have quite better performance/optimization, 
so I may end up using it... But I also heard bad things about it 
in old posts... so...
Apr 05 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Apr 06, 2012 at 12:42:57AM +0200, ReneSac wrote:

 On Thursday, 5 April 2012 at 22:07:05 UTC, Jesse Phillips wrote:


[...]

 Anyway, GDC seems to have quite better performance/optimization, so
 I may end up using it... But I also heard bad things about it in old
 posts... so...


I use GDC for some of my D projects. I didn't find anything wrong with
it. Plus, GCC's backend optimizer is a LOT better than dmd. Something to
consider if you're writing performance-critical code.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've
forgotten this before.
Apr 05 2012
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 4/6/2012 7:42 AM, ReneSac wrote:


 Most people use DMD, but GDC, I hear, should be on par.


 I don't need a 64bit binary right now. Actually, I would even prefer a
 32bit one for development because then I can't run too wild in memory
 usage. The problem is that DMD seems to require 32 bit windows,
 according to the page I linked... Is it not true?


DMD runs just fine on 64-bit Windows.
Apr 05 2012
parent reply "ReneSac" <reneduani yahoo.com.br> writes:
On Friday, 6 April 2012 at 01:33:10 UTC, Mike Parker wrote:

 DMD runs just fine on 64-bit Windows.


Then why "32 bit Windows (Win32) operating system, such as 
Windows XP" is put as a requirement? This should be corrected: 
http://dlang.org/dmd-windows.html

Anyway, in the mean time I have setup GDC using the latest 
binaries, and it is working well.

The only thing I noticed is that a simple "Hello World" took 
several seconds to compile, and ended up with 1.25MB (release, 
non-debug build)! And I thought that D was fast to compile... But 
then I discovered that switching to std.c.stdio made the 
compilation almost instantaneous, and the executable size a 
slightly more reasonable 408KB. It works, but that isn't really 
an option, as D strings aren't readily compatible with C 
strings...

I know that the lower limiter in binary size is higher, due to 
the statically compiled runtime, but this "bloat" in the std lib 
for a single function worries me a bit. Is DMD better in this 
measurement, or is it a limitation of the current D libraries?

This may be kinda important latter, as in compression benchmarks, 
the decompressor size is added in the compressed size to prevent 
cheating. I don't want a multi-megabyte executable size.
Apr 06 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 07.04.2012 8:51, ReneSac wrote:

 On Friday, 6 April 2012 at 01:33:10 UTC, Mike Parker wrote:

 DMD runs just fine on 64-bit Windows.


 Then why "32 bit Windows (Win32) operating system, such as Windows XP"
 is put as a requirement? This should be corrected:
 http://dlang.org/dmd-windows.html

 Anyway, in the mean time I have setup GDC using the latest binaries, and
 it is working well.

 The only thing I noticed is that a simple "Hello World" took several
 seconds to compile, and ended up with 1.25MB (release, non-debug build)!


how about strip it?
+ MinGW debug info is notoriously bloated (if it was debug build).


 And I thought that D was fast to compile... But then I discovered that
 switching to std.c.stdio made the compilation almost instantaneous, and
 the executable size a slightly more reasonable 408KB. It works, but that
 isn't really an option, as D strings aren't readily compatible with C
 strings...

 I know that the lower limiter in binary size is higher, due to the
 statically compiled runtime, but this "bloat" in the std lib for a
 single function worries me a bit. Is DMD better in this measurement, or
 is it a limitation of the current D libraries?

 This may be kinda important latter, as in compression benchmarks, the
 decompressor size is added in the compressed size to prevent cheating. I
 don't want a multi-megabyte executable size.



-- 
Dmitry Olshansky
Apr 06 2012
parent "ReneSac" <reneduani yahoo.com.br> writes:
On Saturday, 7 April 2012 at 06:21:16 UTC, Dmitry Olshansky wrote:

 On 07.04.2012 8:51, ReneSac wrote:

 The only thing I noticed is that a simple "Hello World" took 
 several
 seconds to compile, and ended up with 1.25MB (release, 
 non-debug build)!


 how about strip it?
 + MinGW debug info is notoriously bloated (if it was debug 
 build).


I said it was a non-debug build. The debug build for the "Hello 
World" is 7.6MB.
Apr 07 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, April 06, 2012 00:07:03 Jesse Phillips wrote:

 Hmm, bring up a good point, I think someone is working on
 revamping stdio, though I would think it would mostly remain
 compatible. Who's doing that? Could you write the details here:


It's Steven Schveighoffer, but it's far from ready, since he hasn't had a lot 
of time to work on it of late. He put up an initial version for feedback a few 
weeks back, and one of the main points of feedback (which Walter felt very 
strongly about) was that it needed to be compatible with the current std.stdio 
rather than having a whole new API, so while it may do new stuff and have a 
better implementation, most (all?) of the stuff using the current std.stdio 
will continue to work with the new one whenever it's finished.

- Jonathan M Davis
Apr 05 2012