www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.054 and 2.038 release

reply Walter Bright <newshound1 digitalmars.com> writes:
Happy New Year!

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


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.038.zip

Many thanks to the numerous people who contributed to this update.
Dec 31 2009
next sibling parent BCS <none anon.com> writes:
Hello Walter,

 Happy New Year!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.054.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip
 Many thanks to the numerous people who contributed to this update.
 

New updates, Always nice to see! Damn, I like to see those long list of bugs!
Dec 31 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Walter,

 Happy New Year!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.054.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip
 Many thanks to the numerous people who contributed to this update.
 

Oh cool, I think I'm going to like this one: 2816: "Sudden-death static assert is not very useful" 12 Grammar fixes? Sweeeeet!
Dec 31 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Happy New Year!

Happy end of the year to you too! Is this the last release for the 2009? ;-) This is funny: min(x, y) = 10; // sets x to 10 This looks by far like the most useful improvement/change of this DMD release, I've already tried it and I like it a lot, thanks to Don and to you!
Bugzilla 2816: Sudden-death static assert is not very useful<

Bye, bearophile
Dec 31 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 This is funny: min(x, y) = 10;    // sets x to 10
 
 This looks by far like the most useful improvement/change of this DMD
 release, I've already tried it and I like it a lot, thanks to Don and
 to you!

A lot of credit also goes to Andrei for design issues, and some others who also submitted bugzilla reports and patches, such as Rainer Schuetze. I don't think the min() example is that useful, I can't think of when I ever needed it. But min() is important as one of those metaprogramming "litmus tests" that are the canary that indicates whether one has a complete system or not.
Dec 31 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 I don't think the min() example is that useful,

No, I meant it's the Bugzilla 2816 that's very useful! :-) Bye, bearophile
Dec 31 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Walter Bright:
 Happy New Year!

Happy end of the year to you too! Is this the last release for the 2009? ;-) This is funny: min(x, y) = 10; // sets x to 10 This looks by far like the most useful improvement/change of this DMD release, I've already tried it and I like it a lot, thanks to Don and to you!
 Bugzilla 2816: Sudden-death static assert is not very useful<


I can't take credit for that. It comes from the LDC guys, I just enhanced it slightly. There are 26 Bugzilla votes fixed in this release, which is probably a record. (I'm assuming bug 1961('scoped const') is considered to be fixed).
Dec 31 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
(I'm assuming bug 1961('scoped const') is considered to be 
 fixed).

Sadly, it's not fixed yet :( struct S { int x; inout(int)* getX() inout { return &x;} } void main() { S s; int *x = s.getX(); } testinout.d(10): Error: function testinout.S.getX () inout is not callable using argument types () testinout.d(10): Error: cannot implicitly convert expression (s.getX()) of type inout(int)* to int* It appears the auto-conversion is not happening on the return, and also the call isn't working.

The inout on the return has to be at the top level, as in inout(int *). This probably needs improvement.
Dec 31 2009
next sibling parent Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer wrote:

 The only thing I could get to work is this:
 
 
 struct S
 {
      int x;
 }
 
 inout(int *) getSX(inout S* s) { return &s.x;}
 
 void main()
 {
      S s;
      const(S)* sp = &s;
      int *x = getSX(&s);
      //int *y = getSX(sp);  // uncomment this line for an error
      const(int) *y = getSX(sp);
 }
 
 If you uncomment the designated line, the error reads:
 
 testinout.d(13): Error: cannot implicitly convert expression (getSX(sp))
 of type const(int*) to int*
 
 which looks good.

The error looks misleading to me. The error is with the input argument to the function, not the return type.
Jan 01 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Thu, 31 Dec 2009 16:20:08 -0500, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Steven Schveighoffer wrote:
 (I'm assuming bug 1961('scoped const') is considered to be fixed).

struct S { int x; inout(int)* getX() inout { return &x;} } void main() { S s; int *x = s.getX(); } testinout.d(10): Error: function testinout.S.getX () inout is not callable using argument types () testinout.d(10): Error: cannot implicitly convert expression (s.getX()) of type inout(int)* to int* It appears the auto-conversion is not happening on the return, and also the call isn't working.

The inout on the return has to be at the top level, as in inout(int *). This probably needs improvement.

Yes, this is an important distinction. With your recommended change, the error is now: testinout.d(4): Error: inout on return means inout must be on a parameter as well for inout inout(int*)() inout doesn't seem to work with ref either. The only thing I could get to work is this: struct S { int x; } inout(int *) getSX(inout S* s) { return &s.x;} void main() { S s; const(S)* sp = &s; int *x = getSX(&s); //int *y = getSX(sp); // uncomment this line for an error const(int) *y = getSX(sp); } If you uncomment the designated line, the error reads: testinout.d(13): Error: cannot implicitly convert expression (getSX(sp)) of type const(int*) to int* which looks good. -Steve

Well I'm sorry to tell that inout is useless as currently implemented. One important motivating use case was: inout(char)[] blah(inout(char)[] input) { return input; } void main() { blah("xyz"); blah("xyz".dup); } That doesn't work at all. The second motivating case also doesn't work: class A { A _next; inout A next() inout { return _next; } } void main() { auto a = new A; const b = a; auto c = a.next(); auto d = b.next(); } There are few, if any, cases where the current inout does help. The good news is that most of the implementation effort has been done so probably making things work will not be very difficult. Andrei
Jan 01 2010
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:

 struct S
 {
      int x;
      inout(int)* getX() inout { return &x;}
 }
 
 void main()
 {
      S s;
      int *x = s.getX();
 }
 
 
 testinout.d(10): Error: function testinout.S.getX () inout is not callable  
 using argument types ()

That's the same error message as http://d.puremagic.com/issues/show_bug.cgi?id=3642 Does that error message ever pop up in a meaningful context???
 testinout.d(10): Error: cannot implicitly convert expression (s.getX()) of  
 type inout(int)* to int*

At least in this case, there are other error messages that give a strong hint to what the real cause is. I'm still crossing my fingers that 3642 can be improved in some way.
Dec 31 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 31 Dec 2009 15:05:56 -0500, Don <nospam nospam.com> wrote:

 bearophile wrote:
 Walter Bright:
 Happy New Year!

Is this the last release for the 2009? ;-) This is funny: min(x, y) = 10; // sets x to 10 This looks by far like the most useful improvement/change of this DMD release, I've already tried it and I like it a lot, thanks to Don and to you!
 Bugzilla 2816: Sudden-death static assert is not very useful<


I can't take credit for that. It comes from the LDC guys, I just enhanced it slightly. There are 26 Bugzilla votes fixed in this release, which is probably a record. (I'm assuming bug 1961('scoped const') is considered to be fixed).

Sadly, it's not fixed yet :( struct S { int x; inout(int)* getX() inout { return &x;} } void main() { S s; int *x = s.getX(); } testinout.d(10): Error: function testinout.S.getX () inout is not callable using argument types () testinout.d(10): Error: cannot implicitly convert expression (s.getX()) of type inout(int)* to int* It appears the auto-conversion is not happening on the return, and also the call isn't working. I'm surprised this was listed as an implemented feature... Is there some test code that you were using to confirm this Walter? -Steve
Dec 31 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 31 Dec 2009 16:20:08 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 (I'm assuming bug 1961('scoped const') is considered to be fixed).

struct S { int x; inout(int)* getX() inout { return &x;} } void main() { S s; int *x = s.getX(); } testinout.d(10): Error: function testinout.S.getX () inout is not callable using argument types () testinout.d(10): Error: cannot implicitly convert expression (s.getX()) of type inout(int)* to int* It appears the auto-conversion is not happening on the return, and also the call isn't working.

The inout on the return has to be at the top level, as in inout(int *). This probably needs improvement.

Yes, this is an important distinction. With your recommended change, the error is now: testinout.d(4): Error: inout on return means inout must be on a parameter as well for inout inout(int*)() inout doesn't seem to work with ref either. The only thing I could get to work is this: struct S { int x; } inout(int *) getSX(inout S* s) { return &s.x;} void main() { S s; const(S)* sp = &s; int *x = getSX(&s); //int *y = getSX(sp); // uncomment this line for an error const(int) *y = getSX(sp); } If you uncomment the designated line, the error reads: testinout.d(13): Error: cannot implicitly convert expression (getSX(sp)) of type const(int*) to int* which looks good. -Steve
Jan 01 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Jan 2010 11:16:00 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 Well I'm sorry to tell that inout is useless as currently implemented.  
 One important motivating use case was:

 inout(char)[] blah(inout(char)[] input) {
      return input;
 }

 void main()
 {
      blah("xyz");
      blah("xyz".dup);
 }

 That doesn't work at all.

Yeah, I think walter said the inout currently must apply to the entire parameter/return value. That is a severe limitation I think, but the fact that it parses makes me think it's a simple fix. It's almost like the type system is working right, but the trigger to convert inout back and forth isn't firing.
 The second motivating case also doesn't work:

 class A {
      A _next;
      inout A next() inout { return _next; }
 }

 void main()
 {
      auto a = new A;
      const b = a;
      auto c = a.next();
      auto d = b.next();
 }

I found that inout member functions don't work at all. It's almost as if the compiler ignores the inout designation when doing the inout const match.
 There are few, if any, cases where the current inout does help. The good  
 news is that most of the implementation effort has been done so probably  
 making things work will not be very difficult.

Yeah, I just was disappointed that it was listed as implemented. Half implemented is ok, as long as it will be fixed. -Steve
Jan 01 2010
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:
 Happy New Year!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.054.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip
 
 Many thanks to the numerous people who contributed to this update.

Very nice! In http://www.digitalmars.com/d/2.0/function.html#auto-ref-functions the links for auto function and ref function are broken. Happy New Year! Ary
Dec 31 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 Happy New Year!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.054.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip
 
 Many thanks to the numerous people who contributed to this update.

Tons of bug fixes == great! But I have a problem: the compiler is either extremely slow for me, or is stuck in an endless loop. All it does is to slowly allocate memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile. Can anyone confirm this?
Dec 31 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
grauzone:
 But I have a problem: the compiler is either extremely slow for me, or 
 is stuck in an endless loop. All it does is to slowly allocate memory. I 
 aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This 
 wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile.
 Can anyone confirm this?

Show the code! Bye, bearophile
Dec 31 2009
parent reply grauzone <none example.net> writes:
bearophile wrote:
 grauzone:
 But I have a problem: the compiler is either extremely slow for me, or 
 is stuck in an endless loop. All it does is to slowly allocate memory. I 
 aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This 
 wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile.
 Can anyone confirm this?

Show the code!

I was going to say "but it's hundreds of modules", but then I tried to compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/Demangler.d?rev=5248 The exact command line for this was: dmd -c -I../tango/core -I.. -I../tango/core/vendor -release -oftango-core-tools-Demangler-release.o ../tango/core/tools/Demangler.d Again, could anyone confirm this? Anyway, no time for this anymore, it's going to be 2010 soon here.
 Bye,
 bearophile

Dec 31 2009
parent reply Don <nospam nospam.com> writes:
Moritz Warning wrote:
 On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
 
 bearophile wrote:
 grauzone:
 But I have a problem: the compiler is either extremely slow for me, or
 is stuck in an endless loop. All it does is to slowly allocate memory.
 I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation.
 This wasn't the case with dmd 1.053, where it only took 5-10 seconds
 to compile. Can anyone confirm this?


compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/

 The exact command line for this was:
 dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
 -oftango-core-tools-Demangler-release.o ../tango/core/tools/Demangler.d

 Again, could anyone confirm this?

 Anyway, no time for this anymore, it's going to be 2010 soon here.

 Bye,
 bearophile


http://d.puremagic.com/issues/show_bug.cgi?id=3663

It's caused by the patch for bug 400.
Jan 01 2010
parent reply Don <nospam nospam.com> writes:
Moritz Warning wrote:
 On Fri, 01 Jan 2010 22:35:12 +0000, Moritz Warning wrote:
 
 On Fri, 01 Jan 2010 19:31:49 +0100, Don wrote:

 Moritz Warning wrote:
 On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:

 bearophile wrote:
 grauzone:
 But I have a problem: the compiler is either extremely slow for me,
 or is stuck in an endless loop. All it does is to slowly allocate
 memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM
 allocation. This wasn't the case with dmd 1.053, where it only took
 5-10 seconds to compile. Can anyone confirm this?


to compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/

 The exact command line for this was:
 dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
 -oftango-core-tools-Demangler-release.o
 ../tango/core/tools/Demangler.d

 Again, could anyone confirm this?

 Anyway, no time for this anymore, it's going to be 2010 soon here.

 Bye,
 bearophile


http://d.puremagic.com/issues/show_bug.cgi?id=3663


But now there is another problem/regression: tango/net/device/Berkeley.d(1065): Error: enum member tango.net.device.Berkeley.IPv4Address.ADDR_ANY conflicts with enum member tango.net.device.Berkeley.IPv4Address.ADDR_ANY at tango/net/device/ Berkeley.d(1065) tango/net/device/Berkeley.d(1066): Error: enum member tango.net.device.Berkeley.IPv4Address.ADDR_NONE conflicts with enum member tango.net.device.Berkeley.IPv4Address.ADDR_NONE at tango/net/ device/Berkeley.d(1066) tango/net/device/Berkeley.d(1067): Error: enum member tango.net.device.Berkeley.IPv4Address.PORT_ANY conflicts with enum member tango.net.device.Berkeley.IPv4Address.PORT_ANY at tango/net/device/ Berkeley.d(1067)

I've made a ticket: http://d.puremagic.com/issues/show_bug.cgi?id=3664 (tested with original dmd 1.054)

Jan 01 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 That's also caused by the other half of the patch for 400, in class.c.

There's a patch up now for it.
Jan 02 2010
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Thu, 31 Dec 2009 21:03:25 +0100, grauzone wrote:

 Walter Bright wrote:
 Happy New Year!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.054.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip
 
 Many thanks to the numerous people who contributed to this update.

Tons of bug fixes == great! But I have a problem: the compiler is either extremely slow for me, or is stuck in an endless loop. All it does is to slowly allocate memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation. This wasn't the case with dmd 1.053, where it only took 5-10 seconds to compile. Can anyone confirm this?

I just stumbled over the problem compiling Tango trunk with dmd 1.054. It works on Windows.
Jan 01 2010
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:

 bearophile wrote:
 grauzone:
 But I have a problem: the compiler is either extremely slow for me, or
 is stuck in an endless loop. All it does is to slowly allocate memory.
 I aborted the compilation after ~ 20 minutes and 2 GB RAM allocation.
 This wasn't the case with dmd 1.053, where it only took 5-10 seconds
 to compile. Can anyone confirm this?

Show the code!

I was going to say "but it's hundreds of modules", but then I tried to compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/

 
 The exact command line for this was:
 dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
 -oftango-core-tools-Demangler-release.o ../tango/core/tools/Demangler.d
 
 Again, could anyone confirm this?
 
 Anyway, no time for this anymore, it's going to be 2010 soon here.
 
 Bye,
 bearophile


http://d.puremagic.com/issues/show_bug.cgi?id=3663
Jan 01 2010
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Fri, 01 Jan 2010 19:31:49 +0100, Don wrote:

 Moritz Warning wrote:
 On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
 
 bearophile wrote:
 grauzone:
 But I have a problem: the compiler is either extremely slow for me,
 or is stuck in an endless loop. All it does is to slowly allocate
 memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM
 allocation. This wasn't the case with dmd 1.053, where it only took
 5-10 seconds to compile. Can anyone confirm this?


compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/

 The exact command line for this was:
 dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
 -oftango-core-tools-Demangler-release.o
 ../tango/core/tools/Demangler.d

 Again, could anyone confirm this?

 Anyway, no time for this anymore, it's going to be 2010 soon here.

 Bye,
 bearophile


http://d.puremagic.com/issues/show_bug.cgi?id=3663

It's caused by the patch for bug 400.

Thanks, that fixed it. But now there is another problem/regression: tango/net/device/Berkeley.d(1065): Error: enum member tango.net.device.Berkeley.IPv4Address.ADDR_ANY conflicts with enum member tango.net.device.Berkeley.IPv4Address.ADDR_ANY at tango/net/device/ Berkeley.d(1065) tango/net/device/Berkeley.d(1066): Error: enum member tango.net.device.Berkeley.IPv4Address.ADDR_NONE conflicts with enum member tango.net.device.Berkeley.IPv4Address.ADDR_NONE at tango/net/ device/Berkeley.d(1066) tango/net/device/Berkeley.d(1067): Error: enum member tango.net.device.Berkeley.IPv4Address.PORT_ANY conflicts with enum member tango.net.device.Berkeley.IPv4Address.PORT_ANY at tango/net/device/ Berkeley.d(1067)
Jan 01 2010
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Fri, 01 Jan 2010 22:35:12 +0000, Moritz Warning wrote:

 On Fri, 01 Jan 2010 19:31:49 +0100, Don wrote:
 
 Moritz Warning wrote:
 On Thu, 31 Dec 2009 21:22:58 +0100, grauzone wrote:
 
 bearophile wrote:
 grauzone:
 But I have a problem: the compiler is either extremely slow for me,
 or is stuck in an endless loop. All it does is to slowly allocate
 memory. I aborted the compilation after ~ 20 minutes and 2 GB RAM
 allocation. This wasn't the case with dmd 1.053, where it only took
 5-10 seconds to compile. Can anyone confirm this?


to compile some other big hog of code: Tango. And I found compiling this file hangs: http://dsource.org/projects/tango/browser/trunk/tango/core/tools/

 The exact command line for this was:
 dmd -c -I../tango/core -I.. -I../tango/core/vendor -release
 -oftango-core-tools-Demangler-release.o
 ../tango/core/tools/Demangler.d

 Again, could anyone confirm this?

 Anyway, no time for this anymore, it's going to be 2010 soon here.

 Bye,
 bearophile


http://d.puremagic.com/issues/show_bug.cgi?id=3663

It's caused by the patch for bug 400.

Thanks, that fixed it. But now there is another problem/regression: tango/net/device/Berkeley.d(1065): Error: enum member tango.net.device.Berkeley.IPv4Address.ADDR_ANY conflicts with enum member tango.net.device.Berkeley.IPv4Address.ADDR_ANY at tango/net/device/ Berkeley.d(1065) tango/net/device/Berkeley.d(1066): Error: enum member tango.net.device.Berkeley.IPv4Address.ADDR_NONE conflicts with enum member tango.net.device.Berkeley.IPv4Address.ADDR_NONE at tango/net/ device/Berkeley.d(1066) tango/net/device/Berkeley.d(1067): Error: enum member tango.net.device.Berkeley.IPv4Address.PORT_ANY conflicts with enum member tango.net.device.Berkeley.IPv4Address.PORT_ANY at tango/net/device/ Berkeley.d(1067)

I've made a ticket: http://d.puremagic.com/issues/show_bug.cgi?id=3664 (tested with original dmd 1.054)
Jan 01 2010
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
On Sat, 02 Jan 2010 12:24:18 -0800, Walter Bright wrote:

 Don wrote:
 That's also caused by the other half of the patch for 400, in class.c.

There's a patch up now for it.

Thanks, I've build dmd from trunk and I've got Tango and QTD (D1) compiled.
Jan 02 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hhirlb$fj0$1 digitalmars.com...
 Happy New Year!

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


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip

 Many thanks to the numerous people who contributed to this update.

Improved static assert messages and a few forward reference fixes == Awesome!
Dec 31 2009
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-31 13:48:09 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Happy New Year!
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.054.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip
 
 Many thanks to the numerous people who contributed to this update.

Thanks. There's a quite annoying bug on Mac OS X that I've been able to reduce to a very simple test case. Depending on link order, static initializers might not work, resulting in, among other things, a non-functional writeln. Also when that happens even 'throw' often does not work (execution continues after throw!). It seems linked. This makes 'enforce' non-functional and you get a null dereference when calling writeln instead of an exception. The workaround seems to be to always link first the module containing 'main'. But it's quite annoying that you can get a segfault with a program as simple as hello world split in two modules. Would it be possible to look at it? <http://d.puremagic.com/issues/show_bug.cgi?id=3453> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 01 2010
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Am 31.12.2009 19:48, schrieb Walter Bright:
 Happy New Year!

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


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip

 Many thanks to the numerous people who contributed to this update.

Great to see so many fixes that make the language much more hassle-free to use - especially for newcomers that hit such things for the first time. However, I have at least one blocker problem in this release: Because of the now disallowed struct initializers for structs with constructors (bug 3476), there is no way to use those structs as static immutable values as the constructors are not CTFE processable. (-> Error: cannot evaluate ((X __ctmp2; ) , __ctmp2).this() at compile time) This problem has been there since struct constructors have been introduced. A quick search on bugzilla did not return a matching bug report, only some other issues related to struct constructors. I'll file a bug report if noone else knows of any existing one (technically this would be an 'improvement', but I think it is a really important issue). This exact place in my code (something like struct Vector(S){ static invariant Vector zero = Vector(0, 0); }) had to be modified after almost every compiler release and also rendered a lot of versions useless for me because there was somtimes no real workaround. BTW: I was not really watching the newsgroups lately and just noticed the DIP2/inout implementation. IMO 'inout' is really not a good choice for the keyword, introducing a backwards imcompatibility, changing the meaning of a de-facto standard keyword (IDL etc) and not really hitting the point (placeholder for const/immutable/nothing). Also if I did not know about the concept of DIP2 such code would have been a mystery for me. Sönke
Jan 02 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sönke Ludwig:
 BTW: I was not really watching the newsgroups lately and just noticed 
 the DIP2/inout implementation. IMO 'inout' is really not a good choice 
 for the keyword, introducing a backwards imcompatibility, changing the 
 meaning of a de-facto standard keyword (IDL etc) and not really hitting 
 the point (placeholder for const/immutable/nothing). Also if I did not 
 know about the concept of DIP2 such code would have been a mystery for me.

It seems that Walter has yet to learn that names are important. Using nearly random words (and syntax) to express ideas and features, as currently done in D2, is bad. It's the silly "invariant" / "immutable" story again. Python devs ask all people how to name things before, and then Guido V. R. picks the most popular name. They do this because a single person may have some bias: what is intuitive for a person (like Guido, or Walter, or Andrei) may be not intuitive for most other people. Choosing one of the most popular choices can't solve all problems, but it helps finding a name/syntax that will result intuitive for most future programmers. Bye, bearophile
Jan 02 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Sönke Ludwig:
 BTW: I was not really watching the newsgroups lately and just
 noticed the DIP2/inout implementation. IMO 'inout' is really not a
 good choice for the keyword, introducing a backwards
 imcompatibility, changing the meaning of a de-facto standard
 keyword (IDL etc) and not really hitting the point (placeholder for
 const/immutable/nothing). Also if I did not know about the concept
 of DIP2 such code would have been a mystery for me.

It seems that Walter has yet to learn that names are important. Using nearly random words (and syntax) to express ideas and features, as currently done in D2, is bad. It's the silly "invariant" / "immutable" story again. Python devs ask all people how to name things before, and then Guido V. R. picks the most popular name. They do this because a single person may have some bias: what is intuitive for a person (like Guido, or Walter, or Andrei) may be not intuitive for most other people. Choosing one of the most popular choices can't solve all problems, but it helps finding a name/syntax that will result intuitive for most future programmers. Bye, bearophile

The discussion on the name is here: http://www.digitalmars.com/d/archives/digitalmars/D/transporting_qualifier_from_parameter_to_the_return_value_103609.html And no, it was not random.
Jan 02 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 And no, it was not random.

Sorry for showing disrespect for your work, it has slipped me. I have used a wrong wording. Do you see a correlation between the "inout" word and the semantics of this feature? I think this connection is not intuitive. What are the alternative words that can be used here? Are those a worse choice? What are the most intuitive words for most people? Is this feature worth introducing a keyword? Bye, bearophile
Jan 02 2010
prev sibling parent Don <nospam nospam.com> writes:
Sönke Ludwig wrote:
 Am 31.12.2009 19:48, schrieb Walter Bright:
 Happy New Year!

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


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.038.zip

 Many thanks to the numerous people who contributed to this update.

Great to see so many fixes that make the language much more hassle-free to use - especially for newcomers that hit such things for the first time. However, I have at least one blocker problem in this release: Because of the now disallowed struct initializers for structs with constructors (bug 3476), there is no way to use those structs as static immutable values as the constructors are not CTFE processable. (-> Error: cannot evaluate ((X __ctmp2; ) , __ctmp2).this() at compile time) This problem has been there since struct constructors have been introduced. A quick search on bugzilla did not return a matching bug report, only some other issues related to struct constructors. I'll file a bug report if noone else knows of any existing one (technically this would be an 'improvement', but I think it is a really important issue).

Bug 3535. There are still several bugs related to struct constructors. Workaround is to use static opCall instead of a constructor.
Jan 02 2010
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Thanks a lot everybody. Also special thanks to Don for his increased 
involvement and stepping up to help with some serious bugfixing!

It feels like D2 is becoming more solid and usable every release in 
spite of major features still being added.

Happy new year! It will be an exciting one for D.
Jan 03 2010