www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.032 and 2.016 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
Mostly bug fixing.

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

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.016.zip
Jul 09 2008
next sibling parent reply "Koroskin Denis" <2korden gmail.com> writes:
On Wed, 09 Jul 2008 12:34:02 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Mostly bug fixing.

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

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

Wow, great! P.S. Left menu is missing in a D2.0 changelog page.
Jul 09 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Koroskin Denis wrote:
 P.S. Left menu is missing in a D2.0 changelog page.

Fixed.
Jul 09 2008
prev sibling next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Wed, 09 Jul 2008 01:34:02 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Mostly bug fixing.

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

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

Thank you very much for recursive mixins! Change log page for D 1.0 is also broken
Jul 09 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:
 Change log page for D 1.0 is also broken

Not no more!
Jul 09 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright Wrote:
 Mostly bug fixing.

It seems my libs work again with this version (1.032), I've had to change just two things in a 10-minutes debugging, than you. I have had to change this line (inside a function template, T is a type, often it's an array, but it can be a void array too): static if(!is( typeof(T) == void[0] )) { To: static if(!is( T == void[0] )) { At a first test, it seems the compiled executables are 2-3+ times bigger than the ones produced by 1.029. Bye, bearophile
Jul 09 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 It seems my libs work again with this version (1.032), I've had to
 change just two things in a 10-minutes debugging, than you. I have
 had to change this line (inside a function template, T is a type,
 often it's an array, but it can be a void array too):
 
 static if(!is( typeof(T) == void[0] )) { To: static if(!is( T ==
 void[0] )) {

Yes, that bug fix caught several such instances in my code, too.
 At a first test, it seems the compiled executables are 2-3+ times
 bigger than the ones produced by 1.029.

Hmm, haven't noticed that.
Jul 09 2008
parent reply bearophile <bearophileHUGS mailas.com> writes:
Walter Bright:
 bearophile wrote:
 At a first test, it seems the compiled executables are 2-3+ times
 bigger than the ones produced by 1.029.

Hmm, haven't noticed that.

Here are some exact results: V. 1.029: libs: 951_324 bytes (with unittests) test.d: 118_300 bytes V. 1.032: libs: 1_386_012 bytes (with unittests) test.d: 277_020 bytes Where the libs are my ones, and the test.d is just: import std.stdio: put = writef, putr = writefln; import std.string: join; void main() { putr(["ab", "cde"].join("")); } I'd like to know if someone else can confirm this inflation. Bye, bearophile
Jul 09 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Here are some exact results:

Why not compile a file with the two different compilers, and compare the obj sizes? Then run obj2asm on each.
Jul 09 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
I know that the libraries get bigger because of the multiobj option, but 
the exe files shouldn't. Try generating a .map file for each (compile 
with -L/map) and see.
Jul 09 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
Why not compile a file with the two different compilers, and compare the obj
sizes?<

V. 1.029: 3.223 test.asm 118.300 test.exe 2.390 test.map 162.794 test.map2 1.044 test.obj V. 1.032: 3.223 test.asm 277.020 test.exe 2.390 test.map 163.326 test.map2 1.044 test.obj 447.132 byte The contents of obj files are identical.
Then run obj2asm on each.<

asm files are identical.
Try generating a .map file for each (compile with -L/map) and see.<

V.1.029 map file (162_794 bytes): http://rafb.net/p/A5PA0n33.html V.1.032 map file (163_326 bytes): http://rafb.net/p/VhEC2d66.html Their difference: http://rafb.net/p/OeEttz65.html // test.d code: import std.stdio: put = writef, putr = writefln; import std.string: join; void main() { putr(["ab", "cde"].join("")); } Bye, bearophile
Jul 09 2008
prev sibling parent reply torhu <no spam.invalid> writes:
bearophile wrote:
 Walter Bright:
 bearophile wrote:
 At a first test, it seems the compiled executables are 2-3+ times
 bigger than the ones produced by 1.029.

Hmm, haven't noticed that.

Here are some exact results: V. 1.029: libs: 951_324 bytes (with unittests) test.d: 118_300 bytes V. 1.032: libs: 1_386_012 bytes (with unittests) test.d: 277_020 bytes Where the libs are my ones, and the test.d is just: import std.stdio: put = writef, putr = writefln; import std.string: join; void main() { putr(["ab", "cde"].join("")); } I'd like to know if someone else can confirm this inflation.

I recently tried linking my app with DWT built with 1.031 using -lib, and the exe was larger than when using 1.027 and dsss with oneatatime=yes to build DWT. I didn't look into it, just went back to my 1.027 setup for the time being. So I think you might be onto something.
Jul 09 2008
parent torhu <no spam.invalid> writes:
torhu wrote:
 bearophile wrote:
 Walter Bright:
 bearophile wrote:
 At a first test, it seems the compiled executables are 2-3+ times
 bigger than the ones produced by 1.029.

Hmm, haven't noticed that.

Here are some exact results: V. 1.029: libs: 951_324 bytes (with unittests) test.d: 118_300 bytes V. 1.032: libs: 1_386_012 bytes (with unittests) test.d: 277_020 bytes Where the libs are my ones, and the test.d is just: import std.stdio: put = writef, putr = writefln; import std.string: join; void main() { putr(["ab", "cde"].join("")); } I'd like to know if someone else can confirm this inflation.

I recently tried linking my app with DWT built with 1.031 using -lib, and the exe was larger than when using 1.027 and dsss with oneatatime=yes to build DWT. I didn't look into it, just went back to my 1.027 setup for the time being. So I think you might be onto something.

I've tested this properly now, with dmd 1.033. My app grows from 1.9 to 3.0 MB when linking with a dwt library that's built with dsss and oneatatime=yes, versus built with just dmd using the -lib switch. The new discovery here would be that it doesn't matter which compiler version is used, it's the -lib switch that's broken somehow. I haven't looked into this further, but if someone wants to submit a minimal test case to bugzilla, be my guest.
Aug 02 2008
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 09 Jul 2008 19:56:18 -0400, bearophile wrote:

 Walter Bright:
Why not compile a file with the two different compilers, and compare the
obj sizes?<

V. 1.029: 3.223 test.asm 118.300 test.exe 2.390 test.map 162.794 test.map2 1.044 test.obj V. 1.032: 3.223 test.asm 277.020 test.exe 2.390 test.map 163.326 test.map2 1.044 test.obj 447.132 byte The contents of obj files are identical.
Then run obj2asm on each.<

asm files are identical.
Try generating a .map file for each (compile with -L/map) and see.<

V.1.029 map file (162_794 bytes): http://rafb.net/p/A5PA0n33.html V.1.032 map file (163_326 bytes): http://rafb.net/p/VhEC2d66.html Their difference: http://rafb.net/p/OeEttz65.html // test.d code: import std.stdio: put = writef, putr = writefln; import std.string: join; void main() { putr(["ab", "cde"].join("")); } Bye, bearophile

Any progress? Is there a bug report?
Jul 23 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Mostly bug fixing.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.032.zip

Again a stable release that breaks Tango : http://d.puremagic.com/issues/show_bug.cgi?id=2207 It would be nice if the release process could stop this from happening. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 09 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lars Ivar Igesund wrote:

 Walter Bright wrote:
 
 Mostly bug fixing.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.032.zip

Again a stable release that breaks Tango : http://d.puremagic.com/issues/show_bug.cgi?id=2207 It would be nice if the release process could stop this from happening.

There is another one triggered by the Tango unittests: tango/core/Variant.d(361): Error: functions cannot return static array char[3u] I'm not able to minimize it out of the box though. Maybe this is a result of the compiler becoming stricter, but it is any case a breaking change. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 09 2008
parent reply Don <nospam nospam.com.au> writes:
Lars Ivar Igesund wrote:
 Lars Ivar Igesund wrote:
 
 Walter Bright wrote:

 Mostly bug fixing.

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

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


The probably related bug #2208 also breaks Tango.
 It would be nice if the release process could stop this from happening.


email problem.
 
 There is another one triggered by the Tango unittests:
 
 tango/core/Variant.d(361): Error: functions cannot return static array
 char[3u]
 
 I'm not able to minimize it out of the box though. Maybe this is a result of
 the compiler becoming stricter, but it is any case a breaking change.

Not necessarily. It might have uncovered a pre-existing bug. (Any accepts-invalid bug is very likely to break broken code).
Jul 09 2008
next sibling parent reply Don <nospam nospam.com.au> writes:
Don wrote:
 Lars Ivar Igesund wrote:
 Lars Ivar Igesund wrote:

 Walter Bright wrote:

 Mostly bug fixing.

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

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


The probably related bug #2208 also breaks Tango.
 It would be nice if the release process could stop this from happening.


email problem.
 There is another one triggered by the Tango unittests:

 tango/core/Variant.d(361): Error: functions cannot return static array
 char[3u]

 I'm not able to minimize it out of the box though. Maybe this is a 
 result of
 the compiler becoming stricter, but it is any case a breaking change.

Not necessarily. It might have uncovered a pre-existing bug. (Any accepts-invalid bug is very likely to break broken code).

Jul 09 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Bug 870 is not completely fixed. It still gives missing line numbers.

I forgot to fold the fix from 2.0 into 1.0 on that one. It'll get done next update.
Jul 09 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Don (nospam nospam.com.au)'s article
 Lars Ivar Igesund wrote:
 There is another one triggered by the Tango unittests:

 tango/core/Variant.d(361): Error: functions cannot return static array
 char[3u]

 I'm not able to minimize it out of the box though. Maybe this is a result of
 the compiler becoming stricter, but it is any case a breaking change.

accepts-invalid bug is very likely to break broken code).

While it's invalid to return a static array from a function, it does seem like this could have undesired consequences: T fn(T)( T val ) { return val; } Shouldn't the above be valid for all types? Sean
Jul 09 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 While it's invalid to return a static array from a function, it does seem like
 this could have undesired consequences:
 
     T fn(T)( T val ) { return val; }
 
 Shouldn't the above be valid for all types?

Yes, but returning static arrays is not allowed.
Jul 09 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 While it's invalid to return a static array from a function, it does 
 seem like
 this could have undesired consequences:

     T fn(T)( T val ) { return val; }

 Shouldn't the above be valid for all types?

Yes, but returning static arrays is not allowed.

So if I do this: int[3] x; fn( x ); I should expect to get a compile error?
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 So if I do this:
 
     int[3] x;
     fn( x );
 
 I should expect to get a compile error?

If fn returns a static array, yes.
Jul 09 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 So if I do this:

     int[3] x;
     fn( x );

 I should expect to get a compile error?

If fn returns a static array, yes.

And given my sample implementation of fn: T fn(T)( T val ) { return val; } Then I assume the answer is yes? If so, then I'm not sure how to interpret your "yes, but..." response to my prior post. Clearly this function isn't valid for all types if T can't be a static array type. Sean
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Clearly this 
 function isn't valid for all types if T can't be a static array type.

Right. Andrei has also pointed out that this lack of consistency is a problem and should be fixed, but at the moment, that's the way it is.
Jul 09 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Clearly this function isn't valid for all types if T can't be a static 
 array type.

Right. Andrei has also pointed out that this lack of consistency is a problem and should be fixed, but at the moment, that's the way it is.

No problem. It's good to hear that this may be looked at eventually though. Sean
Jul 09 2008
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Koroskin Denis" <2korden gmail.com> wrote in message 
news:op.ud24ipehenyajd proton.creatstudio.intranet...
 On Thu, 10 Jul 2008 02:56:29 +0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:
 Clearly this function isn't valid for all types if T can't be a static 
 array type.

Right. Andrei has also pointed out that this lack of consistency is a problem and should be fixed, but at the moment, that's the way it is.

The same goes for Tuple. Honestly, I don't see a reason why tuples can't be returned. And since Tuple!(char,char,char,char) is no different from char[4], I think that static arrays should also be allowed as a return type.

The problem with returning static arrays is that they live on the stack. Function goes out of scope, bye bye array. Or are you suggesting that the static array be automatically .dup()ed?
Jul 10 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Koroskin Denis wrote:
 On Thu, 10 Jul 2008 22:58:19 +0400, Nick Sabalausky <a a.a> wrote:
 
 "Koroskin Denis" <2korden gmail.com> wrote in message
 news:op.ud24ipehenyajd proton.creatstudio.intranet...
 On Thu, 10 Jul 2008 02:56:29 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:
 Clearly this function isn't valid for all types if T can't be a static
 array type.

Right. Andrei has also pointed out that this lack of consistency is a problem and should be fixed, but at the moment, that's the way it is.

The same goes for Tuple. Honestly, I don't see a reason why tuples can't be returned. And since Tuple!(char,char,char,char) is no different from char[4], I think that static arrays should also be allowed as a return type.

The problem with returning static arrays is that they live on the stack. Function goes out of scope, bye bye array. Or are you suggesting that the static array be automatically .dup()ed?

I expect that a bitwise copy returned. Just like with structs. What's the difference between char[2] and struct { char[2]; }?

The former is passed (to a function) by reference, the latter by value. Having a type that's passed by ref, but return by val, seems inconsistent. Wasn't there plans to make static arrays value types? is this already so? Tomas
Jul 10 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tomas Lindquist Olsen" <tomas famolsen.dk> wrote in message 
news:g55q99$1r6u$1 digitalmars.com...

 I expect that a bitwise copy returned. Just like with structs.
 What's the difference between char[2] and struct { char[2]; }?

The former is passed (to a function) by reference, the latter by value. Having a type that's passed by ref, but return by val, seems inconsistent.

Having a type that's initialized by value and passed by ref also seems inconsistent, as does a type whose .init is not the same type ;)
 Wasn't there plans to make static arrays value types? is this already so?

W mentioned it in passing but I don't know if it'll make it into D2. Yeah, I mean all the const-correctness doesn't really leave much room for anything else, does it! No macros either. sigh.
Jul 10 2008
prev sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Sean Kelly wrote:
     T fn(T)( T val ) { return val; }
 
 Shouldn't the above be valid for all types?

Except for static arrays, it seems. void fn(T)( ref T val ) {} also excludes static arrays. Christian
Jul 09 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lars Ivar Igesund wrote:
 
 It would be nice if the release process could stop this from happening.

I wrote a short piece on this topic : http://larsivi.net/node/114 As it is, I will recommend against using this release for Tango users. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 09 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Lars Ivar Igesund wrote:
 Lars Ivar Igesund wrote:
  
 It would be nice if the release process could stop this from happening.

I wrote a short piece on this topic : http://larsivi.net/node/114 As it is, I will recommend against using this release for Tango users.

After reading larsivi's blog post, I can only say I couldn't agree more! I would personally not mind getting a release candidate and running it through some dstress/tango testing. Obviously this is not done already... I would probably even try merging the changes into LLVMDC and see if anything shows up there. Consider it an offer!
Jul 09 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Koroskin Denis wrote:

 On Wed, 09 Jul 2008 21:03:38 +0400, Tomas Lindquist Olsen
 <tomas famolsen.dk> wrote:
 
 Lars Ivar Igesund wrote:
 Lars Ivar Igesund wrote:

 It would be nice if the release process could stop this from happening.

As it is, I will recommend against using this release for Tango users.

After reading larsivi's blog post, I can only say I couldn't agree more! I would personally not mind getting a release candidate and running it through some dstress/tango testing. Obviously this is not done already... I would probably even try merging the changes into LLVMDC and see if anything shows up there. Consider it an offer!

I don't agree, it's useless to have a group of reviewers for DMD releases *unless* you are targeting a simultaneous DMD/Tango or DMD/GDC or DMD/<something-else> release. Now you know that stuff doesn't compile, and what? The breaking changes won't be reverter anyway, the bugs weren't fixed just to know that this bugfix breaks existing code, although I understand that it's frustrating to see that your code doesn't compile anymore. Just continue using DMD1.031, this release doesn't introduce any great features anyway.

I agree that there is no particular need to upgrade, although new DMD releases tend to have bugfixes that are important to Tango users. Furthermore, D users expect any D 1.0 library to work with the next DMD 1.0xx compiler release, it is a stable branch after all. When this does not happen, i.e the compiler has a breaking change, there is some furious work at our end to figure out what the heck is wrong, with potentially quite a few requests and pings from the users (I speak from experience). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 I agree that there is no particular need to upgrade, although new DMD
 releases tend to have bugfixes that are important to Tango users.
 Furthermore, D users expect any D 1.0 library to work with the next DMD
 1.0xx compiler release, it is a stable branch after all. When this does not
 happen, i.e the compiler has a breaking change, there is some furious work
 at our end to figure out what the heck is wrong, with potentially quite a
 few requests and pings from the users (I speak from experience).

I apologize for that.
Jul 09 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Lars Ivar Igesund wrote:
 
 I agree that there is no particular need to upgrade, although new DMD
 releases tend to have bugfixes that are important to Tango users.
 Furthermore, D users expect any D 1.0 library to work with the next
 DMD 1.0xx compiler release, it is a stable branch after all. When
 this does not happen, i.e the compiler has a breaking change, there
 is some furious work at our end to figure out what the heck is wrong,
 with potentially quite a few requests and pings from the users (I
 speak from experience).
 


If you could test dmd with tango from a single shell script (runs SVN up; some tests; etc) would you add that to the pre release tests?
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 If you could test dmd with tango from a single shell script (runs SVN 
 up; some tests; etc) would you add that to the pre release tests?

The problem with that is if it fails, then I will be debugging Tango (and every other project). It's not practical.
Jul 09 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 BCS wrote:
 If you could test dmd with tango from a single shell script (runs SVN up; 
 some tests; etc) would you add that to the pre release tests?

The problem with that is if it fails, then I will be debugging Tango (and every other project). It's not practical.

No, Tango devs will be debugging it. Hell, let them do the work with a pre-release compiler. I'll volunteer to do it. If they determine it is a DMD bug, they give you a minimal case, and then you go back and fix it, or you determine that it can't be fixed for this release (with appropriate bugzilla entry logged). But without access to the compiler pre-release, there is not much the Tango guys can do except say "another stable release that is broken" And all this is moot if we can build dmd from source :) It would be nice to be able to help... -Steve
Jul 09 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 BCS wrote:
 If you could test dmd with tango from a single shell script (runs SVN up; 
 some tests; etc) would you add that to the pre release tests?

every other project). It's not practical.

No, Tango devs will be debugging it.

Not if I'm running it as part of the release cycle. Having 100K of source code that is unknown to me that dies somewhere in it will be a huge and impractical burden. What would take me many hours would take the person who wrote the code a few minutes. The people who know that code need to be the ones to check it out, because they can efficiently isolate it. Then, I can add the small test case to my test suite and it will stay fixed. Over time, this aggregate of small test cases is much more effective at keeping the quality stable than sheer masses of opaque code.
 Hell, let them do the work with a 
 pre-release compiler.  I'll volunteer to do it.  If they determine it is a 
 DMD bug, they give you a minimal case, and then you go back and fix it, or 
 you determine that it can't be fixed for this release (with appropriate 
 bugzilla entry logged).

That is a practical way.
 But without access to the compiler pre-release, there is not much the Tango 
 guys can do except say "another stable release that is broken"

I agree.
 And all this is moot if we can build dmd from source :)  It would be nice to 
 be able to help...

I know.
Jul 09 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,

 Steven Schveighoffer wrote:
 
 "Walter Bright" wrote
 
 BCS wrote:
 
 If you could test dmd with tango from a single shell script (runs
 SVN up; some tests; etc) would you add that to the pre release
 tests?
 

(and every other project). It's not practical.


source code that is unknown to me that dies somewhere in it will be a huge and impractical burden. What would take me many hours would take the person who wrote the code a few minutes.

One option, take 3 minutes (and use an egg timer) to look at it. If nothing jumps out, e-mail the whole log off to the tango team and forget about it until they get back to you. Another is to just e-mail it off at the start.
 The people who know that code need to be the ones to check it out,
 because they can efficiently isolate it. Then, I can add the small
 test case to my test suite and it will stay fixed. Over time, this
 aggregate of small test cases is much more effective at keeping the
 quality stable than sheer masses of opaque code.

The point isn't to (directly) add to your test cases, it it to known of you are going to break Tango and give someone an opportunity to do something about it before things get released
 Hell, let them do the work with a pre-release compiler.  I'll
 volunteer to do it.  If they determine it is a DMD bug, they give you
 a minimal case, and then you go back and fix it, or you determine
 that it can't be fixed for this release (with appropriate bugzilla
 entry logged).
 


I guess if e-mail the pre-release version with it you get that as well.
Jul 09 2008
prev sibling parent reply JAnderson <ask me.com> writes:
Walter Bright wrote:
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 BCS wrote:
 If you could test dmd with tango from a single shell script (runs 
 SVN up; some tests; etc) would you add that to the pre release tests?

(and every other project). It's not practical.

No, Tango devs will be debugging it.

Not if I'm running it as part of the release cycle. Having 100K of source code that is unknown to me that dies somewhere in it will be a huge and impractical burden. What would take me many hours would take the person who wrote the code a few minutes. The people who know that code need to be the ones to check it out, because they can efficiently isolate it. Then, I can add the small test case to my test suite and it will stay fixed. Over time, this aggregate of small test cases is much more effective at keeping the quality stable than sheer masses of opaque code.
 Hell, let them do the work with a pre-release compiler.  I'll 
 volunteer to do it.  If they determine it is a DMD bug, they give you 
 a minimal case, and then you go back and fix it, or you determine that 
 it can't be fixed for this release (with appropriate bugzilla entry 
 logged).

That is a practical way.
 But without access to the compiler pre-release, there is not much the 
 Tango guys can do except say "another stable release that is broken"

I agree.
 And all this is moot if we can build dmd from source :)  It would be 
 nice to be able to help...

I know.

I'm not sure I understand. How long do the test take to run. Couldn't you use the standard unit test coding cycle with the tango stuff as well? ie 1) Make a change. 2) Run the tango unit tests (perhaps on a separate machine in a different unit tests) 3) Now you know your small code change broke something. The bug is most likely to be around that area because its the first change to crash tango's unit tests. 4) If it's a compile crash its probably easy to solve, run it though the debugger and look at your stack. I'll bet most of these would be a piece of cake to figure out. Otherwise make a note of it. Let the tango team know like discussed and send them a pre-version of the compiler so they can generate a unit test. Seriously the Tango team is probably the most important library that everyone uses outside of D itself. When we write unit tests at work. Were not writing them for just ourselves, were writing them so that other users don't un-intentionally break our code. When we break something, we can normally figure it out by doing a dif on our own changes. -Joel
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
I have a LOT of experience doing this. It is not quick and easy with 
large masses of code that one is unfamiliar with.
Jul 10 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 I have a LOT of experience doing this. It is not quick and easy with 
 large masses of code that one is unfamiliar with.

I swear, sometimes it seems like my posts must not be showing up or something. When this sort of trouble arises, what's wrong with just quickly cranking out a D1.0 release with ONLY regression fixes? --bb
Jul 10 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Steven Schveighoffer wrote:
 No, Tango devs will be debugging it.  Hell, let them do the work with a 
 pre-release compiler.  I'll volunteer to do it.  If they determine it is a 
 DMD bug, they give you a minimal case, and then you go back and fix it, or 
 you determine that it can't be fixed for this release (with appropriate 
 bugzilla entry logged).

This is a bad idea. Why not just release it and let the whole community test it? After all, there is a "stable" version of the 1.x branch, the newer releases are all possibly breaking.
Jul 09 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Robert Fraser" wrote
 Steven Schveighoffer wrote:
 No, Tango devs will be debugging it.  Hell, let them do the work with a 
 pre-release compiler.  I'll volunteer to do it.  If they determine it is 
 a DMD bug, they give you a minimal case, and then you go back and fix it, 
 or you determine that it can't be fixed for this release (with 
 appropriate bugzilla entry logged).

This is a bad idea. Why not just release it and let the whole community test it? After all, there is a "stable" version of the 1.x branch, the newer releases are all possibly breaking.

Tango is 1.x only. It is the new releases in the stable branch (e.g. 1.032) that break Tango. When a new release in a stable branch breaks something, it's by definition, not stable :) For 2.x, I agree, because it's not a release anyways. It's just a pre-release until 2.x is blessed. -Steve
Jul 10 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:g5555l$gji$1 digitalmars.com...
 "Robert Fraser" wrote
 Steven Schveighoffer wrote:
 No, Tango devs will be debugging it.  Hell, let them do the work with a 
 pre-release compiler.  I'll volunteer to do it.  If they determine it is 
 a DMD bug, they give you a minimal case, and then you go back and fix 
 it, or you determine that it can't be fixed for this release (with 
 appropriate bugzilla entry logged).

This is a bad idea. Why not just release it and let the whole community test it? After all, there is a "stable" version of the 1.x branch, the newer releases are all possibly breaking.

Tango is 1.x only. It is the new releases in the stable branch (e.g. 1.032) that break Tango. When a new release in a stable branch breaks something, it's by definition, not stable :) For 2.x, I agree, because it's not a release anyways. It's just a pre-release until 2.x is blessed.

I think what Robert means is that on the DMD download page there's typically a less-than-most-recent version of D1 that's marked as the latest stable version of D1.
Jul 10 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Steven Schveighoffer Wrote:

 "Robert Fraser" wrote
 Steven Schveighoffer wrote:
 No, Tango devs will be debugging it.  Hell, let them do the work with a 
 pre-release compiler.  I'll volunteer to do it.  If they determine it is 
 a DMD bug, they give you a minimal case, and then you go back and fix it, 
 or you determine that it can't be fixed for this release (with 
 appropriate bugzilla entry logged).

This is a bad idea. Why not just release it and let the whole community test it? After all, there is a "stable" version of the 1.x branch, the newer releases are all possibly breaking.

Tango is 1.x only. It is the new releases in the stable branch (e.g. 1.032) that break Tango. When a new release in a stable branch breaks something, it's by definition, not stable :) For 2.x, I agree, because it's not a release anyways. It's just a pre-release until 2.x is blessed. -Steve

That. It can be said that everything released is a "pre-release" until one of them is stable enough to make it to the download page. This way, everyone who is active can continue testing their projects & reporting regressions, not only a few people considered special.
Jul 10 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Robert Fraser" wrote
 Steven Schveighoffer Wrote:

 "Robert Fraser" wrote
 Steven Schveighoffer wrote:
 No, Tango devs will be debugging it.  Hell, let them do the work with 
 a
 pre-release compiler.  I'll volunteer to do it.  If they determine it 
 is
 a DMD bug, they give you a minimal case, and then you go back and fix 
 it,
 or you determine that it can't be fixed for this release (with
 appropriate bugzilla entry logged).

This is a bad idea. Why not just release it and let the whole community test it? After all, there is a "stable" version of the 1.x branch, the newer releases are all possibly breaking.

Tango is 1.x only. It is the new releases in the stable branch (e.g. 1.032) that break Tango. When a new release in a stable branch breaks something, it's by definition, not stable :) For 2.x, I agree, because it's not a release anyways. It's just a pre-release until 2.x is blessed. -Steve

That. It can be said that everything released is a "pre-release" until one of them is stable enough to make it to the download page. This way, everyone who is active can continue testing their projects & reporting regressions, not only a few people considered special.

OK, I didn't get what you were saying earlier. I thought you were saying that D 1.0 is the stable branch, not that there is a stable version of D1.0 on the download page. Sorry for the misunderstanding. But regardless of that, I think Tango is special because it is a critical basis for many many projects. Here is what ends up happening: 1. Someone using tango finds a bug in DMD 1.x, files it 2. Walter releases code to fix the bug, but inadvertantly adds a bug that makes it so tango cannot build 3. Walter fixes tango bug, and 1 month later, releases another version with another bug that makes it so tango can't build ... rinse and repeat 10. Person who found original DMD bug still can't use DMD, because he is relying on a good build of Tango, which requires the compiler that has the bug in it. Besides this annoyance, Tango can be looked at as a really good exercise for DMD. If Tango compiles, and Phobos compiles, then most likely DMD is stable enough to be useful for everyone. I can't see any down side to having Tango devs test a pre-release version of DMD. It should just be one of the screen tests that helps make DMD a better product, and helps make D less frustrating to those of us who rely on Tango. -Steve
Jul 10 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Steven Schveighoffer Wrote:

 "Robert Fraser" wrote
 Steven Schveighoffer Wrote:

 "Robert Fraser" wrote
 Steven Schveighoffer wrote:
 No, Tango devs will be debugging it.  Hell, let them do the work with 
 a
 pre-release compiler.  I'll volunteer to do it.  If they determine it 
 is
 a DMD bug, they give you a minimal case, and then you go back and fix 
 it,
 or you determine that it can't be fixed for this release (with
 appropriate bugzilla entry logged).

This is a bad idea. Why not just release it and let the whole community test it? After all, there is a "stable" version of the 1.x branch, the newer releases are all possibly breaking.

Tango is 1.x only. It is the new releases in the stable branch (e.g. 1.032) that break Tango. When a new release in a stable branch breaks something, it's by definition, not stable :) For 2.x, I agree, because it's not a release anyways. It's just a pre-release until 2.x is blessed. -Steve

That. It can be said that everything released is a "pre-release" until one of them is stable enough to make it to the download page. This way, everyone who is active can continue testing their projects & reporting regressions, not only a few people considered special.

OK, I didn't get what you were saying earlier. I thought you were saying that D 1.0 is the stable branch, not that there is a stable version of D1.0 on the download page. Sorry for the misunderstanding. But regardless of that, I think Tango is special because it is a critical basis for many many projects. Here is what ends up happening: 1. Someone using tango finds a bug in DMD 1.x, files it 2. Walter releases code to fix the bug, but inadvertantly adds a bug that makes it so tango cannot build 3. Walter fixes tango bug, and 1 month later, releases another version with another bug that makes it so tango can't build ... rinse and repeat 10. Person who found original DMD bug still can't use DMD, because he is relying on a good build of Tango, which requires the compiler that has the bug in it. Besides this annoyance, Tango can be looked at as a really good exercise for DMD. If Tango compiles, and Phobos compiles, then most likely DMD is stable enough to be useful for everyone. I can't see any down side to having Tango devs test a pre-release version of DMD. It should just be one of the screen tests that helps make DMD a better product, and helps make D less frustrating to those of us who rely on Tango. -Steve

Bill Baxter already commented on this. Walter just needs to quickly release a version with only regression fixes (maybe only if those regressions are big enough to be blockers without simple work-arounds).
Jul 10 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Steven Schveighoffer wrote:
 Besides this annoyance, Tango can be looked at as a really good exercise for 
 DMD.  If Tango compiles, and Phobos compiles, then most likely DMD is stable 
 enough to be useful for everyone.  I can't see any down side to having Tango 
 devs test a pre-release version of DMD.  It should just be one of the screen 
 tests that helps make DMD a better product, and helps make D less 
 frustrating to those of us who rely on Tango.

The down sides of such a devs-only pre-release are that 1) It deprives the majority of D users the opportunity to find bugs. 2) it deprives everyone not affected by the bugs from getting their hands on every new D release for about a week (while the selected devs work on testing the release, reporting results back to Walter, and then fixing any problems found). And since Phobos seems to be getting tested pretty well, that means basically Phobos users have to wait while things get fixed for Tango. Ok, so maybe you say "fine -- make the pre-release public so that anyone interested can try it out". Ok, that would be great. But let's be realistic: Walter has proven quite reluctant to change anything about how he does D releases, despite repeated pleas to change to a different system. Whether it be adding a major/minor, stable/unstable, even/odd, or alpha/beta distinctions, or whatever. He has his system and he's sticking to it as far as I can tell. He's been using it basically since version 0.001, and the only change he's made in all that time is when 2.x was released and required a split. So what can you do given that the release process itself isn't likely to change? Answer: put out quick regression-fix releases as soon as possible. I think Tango-breaking regressions like these are kind of like "breaking the build". When you break the build you don't just tell your co-workers, "oh well, I'll fix it the next time I have some code that needs checking in". You fix it ASAP. It becomes the *only* item on your TODO list until it is fixed. --bb
Jul 10 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote
 Steven Schveighoffer wrote:
 Besides this annoyance, Tango can be looked at as a really good exercise 
 for DMD.  If Tango compiles, and Phobos compiles, then most likely DMD is 
 stable enough to be useful for everyone.  I can't see any down side to 
 having Tango devs test a pre-release version of DMD.  It should just be 
 one of the screen tests that helps make DMD a better product, and helps 
 make D less frustrating to those of us who rely on Tango.

The down sides of such a devs-only pre-release are that 1) It deprives the majority of D users the opportunity to find bugs.

It already deprives the majority of users (who use Tango) from finding bugs since we can't use the compiler! If anything, this will increase the number of users that can log bugs against it.
 2) it deprives everyone not affected by the bugs from getting their hands 
 on every new D release for about a week (while the selected devs work on 
 testing the release, reporting results back to Walter, and then fixing any 
 problems found).  And since Phobos seems to be getting tested pretty well, 
 that means basically Phobos users have to wait while things get fixed for 
 Tango.

This is a pretty lousy reason to not have interim releases. Waiting a week for more bug fixes that could potentially affect you is not that bad. Tango users already sometimes have to wait several extra weeks or months. It's just amazing what a slow pace Phobos and DMD move compared to Tango, and Phobos users would be complaining about slow releases. All this would be a moot point if Tango devs could build dmd directly. That is my first preference.
 I think Tango-breaking regressions like these are kind of like "breaking 
 the build".  When you break the build you don't just tell your co-workers, 
 "oh well, I'll fix it the next time I have some code that needs checking 
 in".  You fix it ASAP.  It becomes the *only* item on your TODO list until 
 it is fixed.

If this is what happens, it's fine with me. This is essentially the same as pre-releasing except you are going to have lots of extra version increments :) -Steve
Jul 10 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Steven Schveighoffer wrote:
 "Bill Baxter" wrote
 Steven Schveighoffer wrote:


 All this would be a moot point if Tango devs could build dmd directly.  That 
 is my first preference.

Yeh, me too. :-) --bb
Jul 10 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Koroskin Denis" <2korden gmail.com> wrote in message 
news:op.ud4z0co4enyajd proton.creatstudio.intranet...
 On Fri, 11 Jul 2008 20:46:31 +0400, Charles Hixson 
 <charleshixsn earthlink.net> wrote:

 On Wed, 09 Jul 2008 12:40:05 -0700, Walter Bright wrote:

 BCS wrote:
 If you could test dmd with tango from a single shell script (runs SVN
 up; some tests; etc) would you add that to the pre release tests?

The problem with that is if it fails, then I will be debugging Tango (and every other project). It's not practical.

Maybe new releases of dmd 1.x could be called rc (release candidate) until they'd been tested for unexpected regressions? I *do* think that limiting the testing to "approved major projects" is a bad idea, but it might be a *very* good idea to have different labels when a release is hoped to be ready, and when it's been tested by many users.

Stable versions are marked as such in a download page (http://www.digitalmars.com/d/download.html). Latest stable version to date is 1.030, but not 1.032.

Yes, although it might be nice to have a way (such as the "rc" suffix) for the information about which releases are and are not stable to be retained farther back than just the most recent stable version.
Jul 11 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Lars Ivar Igesund wrote:
 I agree that there is no particular need to upgrade, although new DMD
 releases tend to have bugfixes that are important to Tango users.
 Furthermore, D users expect any D 1.0 library to work with the next DMD
 1.0xx compiler release, it is a stable branch after all. When this 
 does not
 happen, i.e the compiler has a breaking change, there is some furious 
 work
 at our end to figure out what the heck is wrong, with potentially quite a
 few requests and pings from the users (I speak from experience).

I apologize for that.

Maybe you can demonstrate the sincerity of your apology by getting a 1.032r1 version out the door in the next few days, which does nothing but fix these regressions. The problem as I see it is that you keep changing too many things. If after reports of regressions came in you just regularly cranked out a new release that fixed *only* those, then everybody could be satisfied I think. In effect it would be like a pre-release system, except _everybody_ would get the same chance to try the pre-releases, and in the event that no regressions are found in the release, there's no need to re-release. Anyway I think it's clear that /something/ needs to be done if you're really serious about making D1 a stable branch. And this seems like it would be the least painful option for you. --bb
Jul 09 2008
prev sibling next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
On Wed, 09 Jul 2008 12:40:05 -0700, Walter Bright wrote:

 BCS wrote:
 If you could test dmd with tango from a single shell script (runs SVN
 up; some tests; etc) would you add that to the pre release tests?

The problem with that is if it fails, then I will be debugging Tango (and every other project). It's not practical.

Maybe new releases of dmd 1.x could be called rc (release candidate) until they'd been tested for unexpected regressions? I *do* think that limiting the testing to "approved major projects" is a bad idea, but it might be a *very* good idea to have different labels when a release is hoped to be ready, and when it's been tested by many users.
Jul 11 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Fri, 11 Jul 2008 20:46:31 +0400, Charles Hixson  
<charleshixsn earthlink.net> wrote:

 On Wed, 09 Jul 2008 12:40:05 -0700, Walter Bright wrote:

 BCS wrote:
 If you could test dmd with tango from a single shell script (runs SVN
 up; some tests; etc) would you add that to the pre release tests?

The problem with that is if it fails, then I will be debugging Tango (and every other project). It's not practical.

Maybe new releases of dmd 1.x could be called rc (release candidate) until they'd been tested for unexpected regressions? I *do* think that limiting the testing to "approved major projects" is a bad idea, but it might be a *very* good idea to have different labels when a release is hoped to be ready, and when it's been tested by many users.

Stable versions are marked as such in a download page (http://www.digitalmars.com/d/download.html). Latest stable version to date is 1.030, but not 1.032.
Jul 11 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 09 Jul 2008 15:17:29 +0200, Lars Ivar Igesund wrote:

 Lars Ivar Igesund wrote:
  
 It would be nice if the release process could stop this from happening.

I wrote a short piece on this topic : http://larsivi.net/node/114 As it is, I will recommend against using this release for Tango users.

I would really appreciate it if W would send release candidates (for the intended stable branch) to some bigger projects for testing. I just found another issue with dmd that breaks Tango (looks like a bug in dmd rather than Tango). (bugzilla is coming..)
Jul 09 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 09 Jul 2008 13:33:38 +0000, Moritz Warning wrote:

 On Wed, 09 Jul 2008 15:17:29 +0200, Lars Ivar Igesund wrote:
 
 Lars Ivar Igesund wrote:
  
 It would be nice if the release process could stop this from
 happening.

I wrote a short piece on this topic : http://larsivi.net/node/114 As it is, I will recommend against using this release for Tango users.

I would really appreciate it if W would send release candidates (for the intended stable branch) to some bigger projects for testing. I just found another issue with dmd that breaks Tango (looks like a bug in dmd rather than Tango). (bugzilla is coming..)

Maybe someone with Tango and dmd 1.032 could test if isStaticArrayType!(char[]) compiles.
Jul 09 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Wed, 09 Jul 2008 18:42:41 +0400, Moritz Warning <moritzwarning web.de>  
wrote:

 On Wed, 09 Jul 2008 13:33:38 +0000, Moritz Warning wrote:

 On Wed, 09 Jul 2008 15:17:29 +0200, Lars Ivar Igesund wrote:

 Lars Ivar Igesund wrote:

 It would be nice if the release process could stop this from
 happening.

I wrote a short piece on this topic : http://larsivi.net/node/114 As it is, I will recommend against using this release for Tango users.

I would really appreciate it if W would send release candidates (for the intended stable branch) to some bigger projects for testing. I just found another issue with dmd that breaks Tango (looks like a bug in dmd rather than Tango). (bugzilla is coming..)

Maybe someone with Tango and dmd 1.032 could test if isStaticArrayType!(char[]) compiles.

No, it doesn't.
Jul 09 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 09 Jul 2008 18:53:24 +0400, Koroskin Denis wrote:
[..]
 No, it doesn't.

Ok, thanks. http://d.puremagic.com/issues/show_bug.cgi?id=2210
Jul 09 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Wed, 09 Jul 2008 19:45:16 +0400, Moritz Warning <moritzwarning web.de>  
wrote:

 On Wed, 09 Jul 2008 18:53:24 +0400, Koroskin Denis wrote:
 [..]
 No, it doesn't.

Ok, thanks. http://d.puremagic.com/issues/show_bug.cgi?id=2210

Arrrgh!
Jul 09 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Wed, 09 Jul 2008 21:03:38 +0400, Tomas Lindquist Olsen  
<tomas famolsen.dk> wrote:

 Lars Ivar Igesund wrote:
 Lars Ivar Igesund wrote:

 It would be nice if the release process could stop this from happening.

As it is, I will recommend against using this release for Tango users.

After reading larsivi's blog post, I can only say I couldn't agree more! I would personally not mind getting a release candidate and running it through some dstress/tango testing. Obviously this is not done already... I would probably even try merging the changes into LLVMDC and see if anything shows up there. Consider it an offer!

I don't agree, it's useless to have a group of reviewers for DMD releases *unless* you are targeting a simultaneous DMD/Tango or DMD/GDC or DMD/<something-else> release. Now you know that stuff doesn't compile, and what? The breaking changes won't be reverter anyway, the bugs weren't fixed just to know that this bugfix breaks existing code, although I understand that it's frustrating to see that your code doesn't compile anymore. Just continue using DMD1.031, this release doesn't introduce any great features anyway.
Jul 09 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 09 Jul 2008 15:45:16 +0000, Moritz Warning wrote:

 On Wed, 09 Jul 2008 18:53:24 +0400, Koroskin Denis wrote: [..]
 No, it doesn't.

Ok, thanks. http://d.puremagic.com/issues/show_bug.cgi?id=2210

As Koroskin found out, it's a typeof(int) issue. Bugzilla report was closed. Tango got a nicer implementation that avoids this problem.
Jul 09 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 10 Jul 2008 02:56:29 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:
 Clearly this function isn't valid for all types if T can't be a static  
 array type.

Right. Andrei has also pointed out that this lack of consistency is a problem and should be fixed, but at the moment, that's the way it is.

The same goes for Tuple. Honestly, I don't see a reason why tuples can't be returned. And since Tuple!(char,char,char,char) is no different from char[4], I think that static arrays should also be allowed as a return type.
Jul 10 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 10 Jul 2008 22:58:19 +0400, Nick Sabalausky <a a.a> wrote:

 "Koroskin Denis" <2korden gmail.com> wrote in message
 news:op.ud24ipehenyajd proton.creatstudio.intranet...
 On Thu, 10 Jul 2008 02:56:29 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Sean Kelly wrote:
 Clearly this function isn't valid for all types if T can't be a static
 array type.

Right. Andrei has also pointed out that this lack of consistency is a problem and should be fixed, but at the moment, that's the way it is.

The same goes for Tuple. Honestly, I don't see a reason why tuples can't be returned. And since Tuple!(char,char,char,char) is no different from char[4], I think that static arrays should also be allowed as a return type.

The problem with returning static arrays is that they live on the stack. Function goes out of scope, bye bye array. Or are you suggesting that the static array be automatically .dup()ed?

I expect that a bitwise copy returned. Just like with structs. What's the difference between char[2] and struct { char[2]; }?
Jul 10 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
is it correct that 2.016 treats deprecated as errors now (always, no 
matter what compile flags) ??


Walter Bright schrieb:
 Mostly bug fixing.

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

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

Jul 09 2008
parent Extrawurst <spam extrawurst.org> writes:
ok i see its a brand new bug, bugzilla: #2208


Extrawurst schrieb:
 is it correct that 2.016 treats deprecated as errors now (always, no 
 matter what compile flags) ??


 Walter Bright schrieb:
 Mostly bug fixing.

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

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


Jul 09 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Mostly bug fixing.

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

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

BTW, Don, thanks for commenting all the bugs as 'fixed' (at least for 1.032). Walter can you please at least delegate someone to do this for every release? I can't always remember which bugs I am CC'd on or have reported, so it is nice to see that it is fixed in my email. -Steve
Jul 09 2008
parent Don <nospam nospam.com.au> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Mostly bug fixing.

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

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

BTW, Don, thanks for commenting all the bugs as 'fixed' (at least for 1.032). Walter can you please at least delegate someone to do this for every release? I can't always remember which bugs I am CC'd on or have reported, so it is nice to see that it is fixed in my email. -Steve

BTW: All known 'missing line number' bugs are now fixed, except for #870. There were 16 such bugs in bugzilla.
Jul 09 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Mostly bug fixing.
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.032.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.016.zip

I don't suppose there's any chance that bugzilla 288 could be fixed in 1.0 as well? I know it's a breaking change from a code perspective, but it was clearly considered a bug in 1.0, and it makes maintaining cross-compatible code between 1.0 and 2.0 difficult at best. Sean
Jul 09 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I don't suppose there's any chance that bugzilla 288 could be fixed
 in 1.0 as well?  I know it's a breaking change from a code perspective,
 but it was clearly considered a bug in 1.0, and it makes maintaining
 cross-compatible code between 1.0 and 2.0 difficult at best.

The problem is it's a breaking change.
Jul 09 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Sean Kelly wrote:
 I don't suppose there's any chance that bugzilla 288 could be fixed
 in 1.0 as well?  I know it's a breaking change from a code perspective,
 but it was clearly considered a bug in 1.0, and it makes maintaining
 cross-compatible code between 1.0 and 2.0 difficult at best.

The problem is it's a breaking change.

I'm not convinced that is worrying you ;) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 09 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 I don't suppose there's any chance that bugzilla 288 could be fixed
 in 1.0 as well?  I know it's a breaking change from a code perspective,
 but it was clearly considered a bug in 1.0, and it makes maintaining
 cross-compatible code between 1.0 and 2.0 difficult at best.

The problem is it's a breaking change.

But it's a breaking change that people asked for two years ago, before D 2.0 was announced. Besides, breaking changes are made to D 1.0 all the time anyway, as evidenced by the fact that all of the past 4 DMD 1.x releases have broken Tango in one way or another. I grant that, as a silent breaking change this is somewhat of a bigger deal, but I suspect that our users would gladly change their code to have this in 1.0. Sean
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 But it's a breaking change that people asked for two years ago, before D 
 2.0 was announced.  Besides, breaking changes are made to D 1.0 all the 
 time anyway, as evidenced by the fact that all of the past 4 DMD 1.x 
 releases have broken Tango in one way or another.  I grant that, as a 
 silent breaking change this is somewhat of a bigger deal, but I suspect 
 that our users would gladly change their code to have this in 1.0.

Creating a spec-changing breaking change for D 1.0 is not its charter, which is to be a stable release of D that is not getting breaking spec changes.
Jul 09 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g534cj$1jav$2 digitalmars.com...
 Sean Kelly wrote:
 But it's a breaking change that people asked for two years ago, before D 
 2.0 was announced.  Besides, breaking changes are made to D 1.0 all the 
 time anyway, as evidenced by the fact that all of the past 4 DMD 1.x 
 releases have broken Tango in one way or another.  I grant that, as a 
 silent breaking change this is somewhat of a bigger deal, but I suspect 
 that our users would gladly change their code to have this in 1.0.

Creating a spec-changing breaking change for D 1.0 is not its charter, which is to be a stable release of D that is not getting breaking spec changes.

Uh, .init?
Jul 09 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g534cj$1jav$2 digitalmars.com...
 Sean Kelly wrote:
 But it's a breaking change that people asked for two years ago, before D 
 2.0 was announced.  Besides, breaking changes are made to D 1.0 all the 
 time anyway, as evidenced by the fact that all of the past 4 DMD 1.x 
 releases have broken Tango in one way or another.  I grant that, as a 
 silent breaking change this is somewhat of a bigger deal, but I suspect 
 that our users would gladly change their code to have this in 1.0.

which is to be a stable release of D that is not getting breaking spec changes.

Uh, .init?

If you want to beat me over the head with that one, I deserve it. But it was also shortly after 1.0 was released, not years later.
Jul 09 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 But it's a breaking change that people asked for two years ago, before 
 D 2.0 was announced.  Besides, breaking changes are made to D 1.0 all 
 the time anyway, as evidenced by the fact that all of the past 4 DMD 
 1.x releases have broken Tango in one way or another.  I grant that, 
 as a silent breaking change this is somewhat of a bigger deal, but I 
 suspect that our users would gladly change their code to have this in 
 1.0.

Creating a spec-changing breaking change for D 1.0 is not its charter, which is to be a stable release of D that is not getting breaking spec changes.

So basically, even if bug reports were opened against D 1.0 before D 1.0 was finalized, if fixing them involves a breaking change then we'll never see them in D 1.0. Is this correct? On a related note, there were some other issues fixed in D 2.0 but not 1.0 that I don't believe were spec-related and which were also reported against 1.0 before 2.0 was announced. I can't recall what they were offhand... IFTI issues perhaps? What was the reasoning behind this decision? Sean
Jul 09 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 So basically, even if bug reports were opened against D 1.0 before D 1.0 
 was finalized, if fixing them involves a breaking change then we'll 
 never see them in D 1.0.  Is this correct?

The opEquals thing was not a bug, it was a change requested in the spec. Bugs are when the compiler does not operate according to the spec. Bugs in 1.0 will be fixed, and are being fixed. The only changes to the 1.0 spec are clarifications.
 On a related note, there were some other issues fixed in D 2.0 but not 
 1.0 that I don't believe were spec-related and which were also reported 
 against 1.0 before 2.0 was announced.  I can't recall what they were 
 offhand... IFTI issues perhaps?  What was the reasoning behind this 
 decision?

All the bugs fixed in 2.0 that also apply to 1.0 are folded back in to 1.0. There are even bugs fixed in 1.0 that do not apply to 2.0. This is pretty clear from the changelog. I have been accused from time to time of abandoning 1.0, but this is simply not true and the changelog will show otherwise. I *am* trying to make it stable and reliable and suitable for production use. For those who need enhancements, 2.0 is the ticket. I should also point out that D 1.0 has been getting new features that are not language changing ones, such as the recent addition of being able to generate library files directly, and improved symbolic debugging support. D 1.0 also just got a completely new data flow analysis package, which increases the reliability and accuracy of the "statement not reached" kinds of diagnostics. Where bug fixes in 1.0 have broken valid 1.0 code, such as the recent Tango breaks reported in this thread, those are entirely my fault and I apologize for that, and plan to get them fixed soon.
Jul 09 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 09 Jul 2008 16:56:52 +0000, Sean Kelly wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Mostly bug fixing.
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.032.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.016.zip

I don't suppose there's any chance that bugzilla 288 could be fixed in 1.0 as well? I know it's a breaking change from a code perspective, but it was clearly considered a bug in 1.0, and it makes maintaining cross-compatible code between 1.0 and 2.0 difficult at best. Sean

I see it as a plus. To leave this issue behind once for all. Sure, it's a breaking change (most bugs are). In perspective of the breaking changes we had already, I would welcome this change. my2cents
Jul 09 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Mostly bug fixing.
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.032.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.016.zip

I don't suppose there's any chance that bugzilla 288 could be fixed in 1.0 as well? I know it's a breaking change from a code perspective, but it was clearly considered a bug in 1.0, and it makes maintaining cross-compatible code between 1.0 and 2.0 difficult at best.

This one seems easier than many other things to make cross-version compatible. Can't you pretty much just do version(D_Version2) { alias bool OpEqBool; } else { alias int OpEqBool; } And use int inside opEquals itself, but throw in a cast to bool on the return value for D2. Seems like that would work. --bb
Jul 09 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Mostly bug fixing.
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.032.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.016.zip

I don't suppose there's any chance that bugzilla 288 could be fixed in 1.0 as well? I know it's a breaking change from a code perspective, but it was clearly considered a bug in 1.0, and it makes maintaining cross-compatible code between 1.0 and 2.0 difficult at best.

This one seems easier than many other things to make cross-version compatible. Can't you pretty much just do version(D_Version2) { alias bool OpEqBool; } else { alias int OpEqBool; } And use int inside opEquals itself, but throw in a cast to bool on the return value for D2. Seems like that would work.

So long as all users of Tango do the same thing. I'm fine with doing this sort of thing behind the scenes in Tango, but not if it imposes similar requirements on our users. Sean
Jul 09 2008
prev sibling parent reply user <e mail.com> writes:
New bug introduced in 2.016  (2.015, 2.013 are ok)

$ ../dmd-v2.016/bin/dmd -c staticif.d
staticif.d(27): Error: no property 'f' for type 'staticif.AA'
staticif.d(27): Error: function expected before (), not 1 of type int
staticif.d(28): Error: no property 'f' for type 'staticif.BB'
staticif.d(28): Error: function expected before (), not 1 of type int

$ cat staticif.d

class A {
}

class B {
}

template T(X) {
static if (is(typeof(X) : A) ||
           is(typeof(X) : B) ) {
void f() {
}
}

}

class AA {
  mixin T!(A);
}

class BB {
  mixin T!(B);
}

int main() {
  AA a = new AA();
  BB b = new BB();
  a.f();
  b.f();

  return 0;
}
Jul 09 2008
next sibling parent bearophile <bearophileHUGS mailas.com> writes:
user Wrote:
 New bug introduced in 2.016  (2.015, 2.013 are ok)
 template T(X) {
 static if (is(typeof(X) : A) ||
            is(typeof(X) : B) ) {

The situation applies to 1.031 too. Try changing that to: static if (is(X : A) || is(X : B) ) { Bye, bearophile
Jul 09 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
user wrote:
 New bug introduced in 2.016  (2.015, 2.013 are ok)

It's not a bug. typeof(X), where X is a type, is not valid D and never was. It was a quirk in the compiler (and a bugzilla bug report) that it ever accepted it.
Jul 09 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright Wrote:
 It's not a bug. typeof(X), where X is a type, is not valid D and never 
 was. It was a quirk in the compiler (and a bugzilla bug report) that it 
 ever accepted it.

I did assume that typeof(x) == typeof(typeof(x)) for any x (value or type) (but it seems that semantic of mine was wrong). Bye, bearophile
Jul 09 2008
parent reply Don <nospam nospam.com.au> writes:
bearophile wrote:
 Walter Bright Wrote:
 It's not a bug. typeof(X), where X is a type, is not valid D and never 
 was. It was a quirk in the compiler (and a bugzilla bug report) that it 
 ever accepted it.

I did assume that typeof(x) == typeof(typeof(x)) for any x (value or type) (but it seems that semantic of mine was wrong).

Yup, a lot of us did that. Because it worked most of the time, except that atomic types didn't work (such as typeof(int)). Fortunately, the fix is easy -- I think typeof(x.init) will always work.
Jul 10 2008
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Don wrote:
 Fortunately, the fix is easy -- I think typeof(x.init) will always work.

Except for static arrays: typeof((int[2]).init) == int -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jul 10 2008
parent Don <nospam nospam.com.au> writes:
Tom S wrote:
 Don wrote:
 Fortunately, the fix is easy -- I think typeof(x.init) will always work.

Except for static arrays: typeof((int[2]).init) == int

Jul 10 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 10 Jul 2008 15:13:40 +0400, Don <nospam nospam.com.au> wrote:

 Tom S wrote:
 Don wrote:
 Fortunately, the fix is easy -- I think typeof(x.init) will always  
 work.



Why so?
Jul 10 2008