www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.062 and 2.047 release

reply Walter Bright <newshound1 digitalmars.com> writes:
There are a lot of improvements in this release, done by quite a lot of people 
working on it. Thanks to everyone who pitched in!


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.062.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.047.zip
Jun 12 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Great, thank you!

I noticed both std.concurrency and std.json are not (yet?) included in the
documentation. Does that have any bearing on their status, are they usable and
/ or stable? 

There are some other modules without documentation like std.openrj and
std.perf. Is there a page somewhere that documents their fate? I could only
find this one:

http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel
Jun 13 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:

 Great, thank you!
 
 I noticed both std.concurrency and std.json are not (yet?) included in the
documentation. Does that have any bearing on their status, are they usable and
/ or stable? 


std.container too.


 There are some other modules without documentation like std.openrj and
std.perf.


I removed std.openrj a while ago.


Andrei
Jun 13 2010
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:


 Lutger wrote:

 Great, thank you!
 
 I noticed both std.concurrency and std.json are not (yet?) included in
 the documentation. Does that have any bearing on their status, are they
 usable and / or stable?


 
 std.container too.
 

 There are some other modules without documentation like std.openrj and
 std.perf.


 
 I removed std.openrj a while ago.
 
 
 Andrei


std.openrj is still included is the src folder and in the repository. There is
a commit on it 4 weeks ago, perhaps it should be deleted from svn?

http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/openrj.d?rev=1519
Jun 13 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Lutger wrote:

 I noticed both std.concurrency and std.json are not (yet?) included in 
 the documentation. Does that have any bearing on their status, are 
 they usable and / or stable? 


 
 std.container too.


Fixed.
Jun 13 2010
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 13 Jun 2010 09:30:43 -0400, Lutger <lutger.blijdestijn gmail.com>  
wrote:


 Great, thank you!

 I noticed both std.concurrency and std.json are not (yet?) included in  
 the documentation. Does that have any bearing on their status, are they  
 usable and / or stable?

 There are some other modules without documentation like std.openrj and  
 std.perf. Is there a page somewhere that documents their fate? I could  
 only find this one:

 http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel


I know std.json is buggy and not ready for prime-time yet.
Jun 13 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 13 Jun 2010 12:13:54 -0400, Robert Jacques <sandford jhu.edu>  
wrote:


 On Sun, 13 Jun 2010 09:30:43 -0400, Lutger  
 <lutger.blijdestijn gmail.com> wrote:


 Great, thank you!

 I noticed both std.concurrency and std.json are not (yet?) included in  
 the documentation. Does that have any bearing on their status, are they  
 usable and / or stable?

 There are some other modules without documentation like std.openrj and  
 std.perf. Is there a page somewhere that documents their fate? I could  
 only find this one:

 http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel


 I know std.json is buggy and not ready for prime-time yet.


Sorry, spoke a bit too soon. I know there was a bug in an old version of  
the code-base to do with unicode escape character parsing. I don't know if  
it got fixed. And I thought I saw a new bug in the code base as I was  
skimming it, but it turned out not to be an issue.
Jun 13 2010
prev sibling parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
On 6/13/2010 9:30 AM, Lutger wrote:

 Great, thank you!

 I noticed both std.concurrency and std.json are not (yet?) included in the
documentation. Does that have any bearing on their status, are they usable and
/ or stable?

 There are some other modules without documentation like std.openrj and
std.perf. Is there a page somewhere that documents their fate? I could only
find this one:

 http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel


Speaking of std.json, has anyone looked at the Orange library on 
dsource?  http://www.dsource.org/projects/orange/

I haven't used it (yet), but it looks to support a back-end 
serialization engine that supports different front-ends, with xml 
currently being implemented.  It's also Boost licensed.
Jun 13 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-06-14 04:10, Eric Poggel wrote:

 On 6/13/2010 9:30 AM, Lutger wrote:

 Great, thank you!

 I noticed both std.concurrency and std.json are not (yet?) included in
 the documentation. Does that have any bearing on their status, are
 they usable and / or stable?

 There are some other modules without documentation like std.openrj and
 std.perf. Is there a page somewhere that documents their fate? I could
 only find this one:

 http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel


 Speaking of std.json, has anyone looked at the Orange library on
 dsource? http://www.dsource.org/projects/orange/

 I haven't used it (yet), but it looks to support a back-end
 serialization engine that supports different front-ends, with xml
 currently being implemented. It's also Boost licensed.


I would but it the other way around, a serialization front end with 
support for different back ends (archive types). I hope to add support 
for Phobos soon.

-- 
/Jacob Carlborg
Jun 15 2010
parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
On 6/15/2010 5:58 AM, Jacob Carlborg wrote:

 On 2010-06-14 04:10, Eric Poggel wrote:

 On 6/13/2010 9:30 AM, Lutger wrote:

 Great, thank you!

 I noticed both std.concurrency and std.json are not (yet?) included in
 the documentation. Does that have any bearing on their status, are
 they usable and / or stable?

 There are some other modules without documentation like std.openrj and
 std.perf. Is there a page somewhere that documents their fate? I could
 only find this one:

 http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel


 Speaking of std.json, has anyone looked at the Orange library on
 dsource? http://www.dsource.org/projects/orange/

 I haven't used it (yet), but it looks to support a back-end
 serialization engine that supports different front-ends, with xml
 currently being implemented. It's also Boost licensed.


 I would but it the other way around, a serialization front end with
 support for different back ends (archive types). I hope to add support
 for Phobos soon.


Maybe I'm calling the front-end the back-end.  Orange provides a 
reflection/serialization engine and allows for plugable serialization 
types--xml being the only one implemented so far.
Jun 16 2010
parent Jacob Carlborg <doob me.com> writes:
== Quote from Eric Poggel (dnewsgroup yage3d.net)'s article

 On 6/15/2010 5:58 AM, Jacob Carlborg wrote:

 On 2010-06-14 04:10, Eric Poggel wrote:

 On 6/13/2010 9:30 AM, Lutger wrote:

 Great, thank you!

 I noticed both std.concurrency and std.json are not (yet?) included in
 the documentation. Does that have any bearing on their status, are
 they usable and / or stable?

 There are some other modules without documentation like std.openrj and
 std.perf. Is there a page somewhere that documents their fate? I could
 only find this one:

 http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel


 Speaking of std.json, has anyone looked at the Orange library on
 dsource? http://www.dsource.org/projects/orange/

 I haven't used it (yet), but it looks to support a back-end
 serialization engine that supports different front-ends, with xml
 currently being implemented. It's also Boost licensed.


 I would but it the other way around, a serialization front end with
 support for different back ends (archive types). I hope to add support
 for Phobos soon.


 Maybe I'm calling the front-end the back-end.  Orange provides a
 reflection/serialization engine and allows for plugable serialization
 types--xml being the only one implemented so far.


Yes, regardless of what the parts are called you description is correct. I'm
working now on creating an XML document abstraction layer so I can support both
Tango and Phobos.

(replying using the Web interface, this particular post didn't have any content
in
my news reader)

/Jacob Carlborg
Jun 16 2010
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
I tried the example on page 406-407 of the book (copying stdin to stdout 
using message passing).  I don't mean to be a killjoy, but it doesn't 
compile. :(

I'm using the latest pdf version of the book, and dmd 2.047.


I get this:

---
d:\prog\dmd\bin\..\src\phobos\std\stdio.d(1902): Error: cannot 
implicitly conver
t expression (buffer) of type ubyte[] to immutable(ubyte)[]
d:\prog\dmd\bin\..\src\phobos\std\stdio.d(7): Error: template instance 
std.stdio
.chunks.opApply!(int delegate(ref immutable(ubyte)[] __applyArg0)) error 
instant
iating
---
Jun 13 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
torhu Wrote:


 I tried the example on page 406-407 of the book (copying stdin to stdout 
 using message passing).  I don't mean to be a killjoy, but it doesn't 
 compile. :(
 
 I'm using the latest pdf version of the book, and dmd 2.047.
 
 
 I get this:
 
 ---
 d:\prog\dmd\bin\..\src\phobos\std\stdio.d(1902): Error: cannot 
 implicitly conver
 t expression (buffer) of type ubyte[] to immutable(ubyte)[]
 d:\prog\dmd\bin\..\src\phobos\std\stdio.d(7): Error: template instance 
 std.stdio
 .chunks.opApply!(int delegate(ref immutable(ubyte)[] __applyArg0)) error 
 instant
 iating
 ---


stdin.byChunk uses a mutable buffer that's overwritten for each chunk so you
can't ask for an immutable ubyte[] in the foreach line.  Here's the version of
that sample I used to test (13.7):

import std.algorithm, std.concurrency, std.stdio;

void main()
{
    enum bufferSize = 10;
    auto tid = spawn( &fileWriter );
    // Read loop
    foreach( ubyte[] buffer; stdin.byChunk( bufferSize ) )
        send( tid, buffer.idup );
}

void fileWriter()
{
    // Write loop
    for( ; ; )
    {
        auto buffer = receiveOnly!(immutable(ubyte)[])();
        writeln( "rx: ", buffer );
    }
}
Jun 14 2010
parent torhu <no spam.invalid> writes:
On 15.06.2010 00:45, Sean Kelly wrote:

 stdin.byChunk uses a mutable buffer that's overwritten for each chunk so you
can't ask for an immutable ubyte[] in the foreach line.  Here's the version of
that sample I used to test (13.7):

 import std.algorithm, std.concurrency, std.stdio;

 void main()
 {
      enum bufferSize = 10;
      auto tid = spawn(&fileWriter );
      // Read loop
      foreach( ubyte[] buffer; stdin.byChunk( bufferSize ) )
          send( tid, buffer.idup );
 }

 void fileWriter()
 {
      // Write loop
      for( ; ; )
      {
          auto buffer = receiveOnly!(immutable(ubyte)[])();
          writeln( "rx: ", buffer );
      }
 }


Right, now where's the bugzilla for TDPL? :)
Jun 14 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
I am back.

From the v2.047 changelog:

std.conv: Added file and line information to conversion errors; added brackets
'[' and ']' around arrays and associative arrays as defaults; added emplace()
for non-class types.<


This program:

import std.stdio: writeln;
import std.conv: to;
void main() {
    int[] a = [1, 2, 3];
    writeln(to!string(a));
    writeln(a);
}


Prints:
[1 2 3]
1 2 3


But I think if they produce the same default output.

Like:
[1, 2, 3]
[1, 2, 3]

--------------------------

I have reopened bug 4109 and in the meantime Shin Fujishiro has closed it
again. He looks efficient :-)

Bye,
bearophile
Jun 14 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 I am back.
 
 From the v2.047 changelog:

 std.conv: Added file and line information to conversion errors; added brackets
'[' and ']' around arrays and associative arrays as defaults; added emplace()
for non-class types.<


 
 This program:
 
 import std.stdio: writeln;
 import std.conv: to;
 void main() {
     int[] a = [1, 2, 3];
     writeln(to!string(a));
     writeln(a);
 }
 
 
 Prints:
 [1 2 3]
 1 2 3
 
 
 But I think if they produce the same default output.
 
 Like:
 [1, 2, 3]
 [1, 2, 3]
 
 --------------------------
 
 I have reopened bug 4109 and in the meantime Shin Fujishiro has closed it
again. He looks efficient :-)
 
 Bye,
 bearophile


Thank you guys. Indeed that was my intent.

Andrei
Jun 14 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Thank you guys. Indeed that was my intent.


What do you mean?

Bye,
bearophile
Jun 14 2010
parent bearophile <bearophileHUGS lycos.com> writes:
 What do you mean?


I have now understood :-)
Jun 14 2010
prev sibling parent reply strtr <strtr spam.com> writes:
My project takes 4 times longer to compile with 1.062 (iso 1.061).
It now takes 1min 20sec on my p4 and memory doesn't seem to be the problem
(<80MB).
I'd rather have it below 30sec :)

bud prj\main.d -w -inline -O -full -cleanup -IC:\D\Libs\
Jun 15 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
strtr wrote:

 My project takes 4 times longer to compile with 1.062 (iso 1.061).
 It now takes 1min 20sec on my p4 and memory doesn't seem to be the problem
(<80MB).
 I'd rather have it below 30sec :)



I have no idea why that might be. Anyone else have this problem?
Jun 15 2010
parent reply strtr <strtr spam.com> writes:
It's the optimization :)
Without -O compilation took only a few seconds!
Jun 15 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
strtr wrote:

 It's the optimization :)
 Without -O compilation took only a few seconds!


Well, that explains it! Little attempt is made in the optimizer to make it 
compile faster if that would interfere with generating faster code.
Jun 15 2010
next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Tue, 15 Jun 2010, Walter Bright wrote:


 strtr wrote:

 It's the optimization :)
 Without -O compilation took only a few seconds!


 
 Well, that explains it! Little attempt is made in the optimizer to make it
 compile faster if that would interfere with generating faster code.


Chances are that the changes to allow more inlining contribute to handing 
the optimizer more work to chew on too.
Jun 15 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:

 On Tue, 15 Jun 2010, Walter Bright wrote:
 

 strtr wrote:

 It's the optimization :)
 Without -O compilation took only a few seconds!


 Well, that explains it! Little attempt is made in the optimizer to make it
 compile faster if that would interfere with generating faster code.


 
 Chances are that the changes to allow more inlining contribute to handing 
 the optimizer more work to chew on too.


You're very likely right.
Jun 15 2010
prev sibling parent reply BCS <none anon.com> writes:
Hello Walter,


 strtr wrote:
 

 It's the optimization :)
 Without -O compilation took only a few seconds!


 Well, that explains it! Little attempt is made in the optimizer to
 make it compile faster if that would interfere with generating faster
 code.
 


How does 1.061 w/ -O compare to 1.062 w/ -O? If 62 is much slower that might 
be of interest.

-- 
... <IXOYE><
Jun 15 2010
parent reply strtr <strtr sp.am> writes:
== Quote from BCS (none anon.com)'s article

 Hello Walter,

 strtr wrote:


 It's the optimization :)
 Without -O compilation took only a few seconds!


 Well, that explains it! Little attempt is made in the optimizer to
 make it compile faster if that would interfere with generating faster
 code.


 How does 1.061 w/ -O compare to 1.062 w/ -O? If 62 is much slower that might
 be of interest.


That is exactly what I mentioned :?
Or did you mean w/o ?
In that case I don't much care it takes 5 or 10 seconds for thousands of lines
of
code :)
(or, I don't know how to time dmd more precise than with my stopwatch when
called
through bud :D)

Anyway, I kind of like that it takes longer now with optimization.
I haven't checked whether things actually got any faster, but it feels a bit
like
in older games when it said:
"Optimizing X for your computer" or "Generating A.I."
:)
Jun 15 2010
parent Eric Poggel <dnewsgroup yage3d.net> writes:
On 6/15/2010 7:58 PM, strtr wrote:

 == Quote from BCS (none anon.com)'s article

 Hello Walter,

 strtr wrote:


 It's the optimization :)
 Without -O compilation took only a few seconds!


 Well, that explains it! Little attempt is made in the optimizer to
 make it compile faster if that would interfere with generating faster
 code.


 How does 1.061 w/ -O compare to 1.062 w/ -O? If 62 is much slower that might
 be of interest.


 That is exactly what I mentioned :?
 Or did you mean w/o ?
 In that case I don't much care it takes 5 or 10 seconds for thousands of lines
of
 code :)
 (or, I don't know how to time dmd more precise than with my stopwatch when
called
 through bud :D)

 Anyway, I kind of like that it takes longer now with optimization.
 I haven't checked whether things actually got any faster, but it feels a bit
like
 in older games when it said:
 "Optimizing X for your computer" or "Generating A.I."
 :)


"Reticulating Splines" was always my favorite.
Jun 16 2010