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
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 reply 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
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 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 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


 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.




Yup. But I would have caught these before release if I hadn't had an 
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


 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.




 Yup. But I would have caught these before release if I hadn't had an 
 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).
 
 


Bug 870 is not completely fixed. It still gives missing line numbers.
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.


 Not necessarily. It might have uncovered a pre-existing bug. (Any
 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 "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
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 "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
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 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
next sibling parent reply 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
parent reply 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..)


Hm, I can't reproduce the problem after messing up my system a bit.
Maybe someone with Tango and dmd 1.032 could test if
isStaticArrayType!(char[])
compiles.
Jul 09 2008
parent reply "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..)


 Hm, I can't reproduce the problem after messing up my system a bit.
 Maybe someone with Tango and dmd 1.032 could test if
 isStaticArrayType!(char[])
 compiles.


No, it doesn't.
Jul 09 2008
parent reply 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
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 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 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 "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.


  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!


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
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.


  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!


 
 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).
 


 I apologize for that.
 


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?


 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.


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?
 


 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.
 


 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.
 


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).
 


 That is a practical way.
 


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?


 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.


 
 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 reply 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
parent reply "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
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 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 reply bearophile <bearophileHUGS lycos.com> writes:
Lars Ivar Igesund:

 There is another one triggered by the Tango unittests:
 tango/core/Variant.d(361): Error: functions cannot return static array
 char[3u]


That's a bug in older versions of DMD, I think.

Bye,
bearophile
Jul 09 2008
parent reply "Koroskin Denis" <2korden gmail.com> writes:
On Wed, 09 Jul 2008 15:12:34 +0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Lars Ivar Igesund:

 There is another one triggered by the Tango unittests:
 tango/core/Variant.d(361): Error: functions cannot return static array
 char[3u]


 That's a bug in older versions of DMD, I think.

 Bye,
 bearophile


Maybe, but so-called stable version should provide bug-compatibility as  
well :)
But then, there are people who want to have certain breaking bugs fixed.  
Can't please everyone.
Jul 09 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Koroskin Denis wrote:

 Maybe, but so-called stable version should provide bug-compatibility as 
 well :)
 But then, there are people who want to have certain breaking bugs fixed. 
 Can't please everyone.



into 1.0. I cannot justify that, but fixing bugs where invalid code was 
accepted is justifiable.
Jul 09 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g52v0a$13hh$5 digitalmars.com...

 Koroskin Denis wrote:

 Maybe, but so-called stable version should provide bug-compatibility as 
 well :)
 But then, there are people who want to have certain breaking bugs fixed. 
 Can't please everyone.



 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


I agree with your decision not to fix 288 in D1, but it *is* frustrating to 
have bugs that were reported when D2 was not even a twinkle in your eye not 
being fixed until D2.
Jul 09 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jarrett Billingsley" wrote

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g52v0a$13hh$5 digitalmars.com...

 Koroskin Denis wrote:

 Maybe, but so-called stable version should provide bug-compatibility as 
 well :)
 But then, there are people who want to have certain breaking bugs fixed. 
 Can't please everyone.



 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 I agree with your decision not to fix 288 in D1, but it *is* frustrating 
 to have bugs that were reported when D2 was not even a twinkle in your eye 
 not being fixed until D2.


I have to say I wish D1 did have opEquals returning bool, but I'm on 
Walter's side on not changing it now.  This is not a bug, but a design 
change.  The original version (returning int) worked as designed, there was 
nothing 'broken' about it.

-Steve
Jul 09 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:

 "Jarrett Billingsley" wrote

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g52v0a$13hh$5 digitalmars.com...

 Koroskin Denis wrote:

 Maybe, but so-called stable version should provide bug-compatibility as 
 well :)
 But then, there are people who want to have certain breaking bugs fixed. 
 Can't please everyone.



 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 I agree with your decision not to fix 288 in D1, but it *is* frustrating 
 to have bugs that were reported when D2 was not even a twinkle in your eye 
 not being fixed until D2.


 
 I have to say I wish D1 did have opEquals returning bool, but I'm on 
 Walter's side on not changing it now.  This is not a bug, but a design 
 change.  The original version (returning int) worked as designed, there was 
 nothing 'broken' about it.


I'd consider this broken about it:

     bool isEqual( Object x, Object y )
     {
         return x == y; // fails
     }

You have to cast the result to bool.


Sean
Jul 09 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote

 Steven Schveighoffer wrote:

 "Jarrett Billingsley" wrote

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g52v0a$13hh$5 digitalmars.com...

 Koroskin Denis wrote:

 Maybe, but so-called stable version should provide bug-compatibility 
 as well :)
 But then, there are people who want to have certain breaking bugs 
 fixed. Can't please everyone.



 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 I agree with your decision not to fix 288 in D1, but it *is* frustrating 
 to have bugs that were reported when D2 was not even a twinkle in your 
 eye not being fixed until D2.


 I have to say I wish D1 did have opEquals returning bool, but I'm on 
 Walter's side on not changing it now.  This is not a bug, but a design 
 change.  The original version (returning int) worked as designed, there 
 was nothing 'broken' about it.


 I'd consider this broken about it:

     bool isEqual( Object x, Object y )
     {
         return x == y; // fails
     }

 You have to cast the result to bool.


Again, behaves as designed :)  The compiler and the runtime both behave 
exactly as the spec dictates.  Designs decisions can suck, and be 
inconsistent with the philosophy of the project (as in this case), but that 
doesn't make them bugs.  They are still arbitrary decisions, with no clear 
cut 'right' or 'wrong'.

Take Tango's 'anti import' design philosophy.  It was made because a goal of 
Tango is to not bloat code, and the compiler happens not to trim out unused 
coded from modules.  I disagree with that decision, as I think D 
applications are bloated inherently anyways, and once dynamic libraries are 
natively supported, this becomes a moot issue.  But that doesn't mean I 
consider the design decision to be a 'bug', it just is something I disagree 
with, but live with.

-Steve
Jul 09 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:

 "Sean Kelly" wrote

 Steven Schveighoffer wrote:

 "Jarrett Billingsley" wrote

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g52v0a$13hh$5 digitalmars.com...

 Koroskin Denis wrote:

 Maybe, but so-called stable version should provide bug-compatibility 
 as well :)
 But then, there are people who want to have certain breaking bugs 
 fixed. Can't please everyone.



 into 1.0. I cannot justify that, but fixing bugs where invalid code was 
 accepted is justifiable.


 I agree with your decision not to fix 288 in D1, but it *is* frustrating 
 to have bugs that were reported when D2 was not even a twinkle in your 
 eye not being fixed until D2.


 I have to say I wish D1 did have opEquals returning bool, but I'm on 
 Walter's side on not changing it now.  This is not a bug, but a design 
 change.  The original version (returning int) worked as designed, there 
 was nothing 'broken' about it.


 I'd consider this broken about it:

     bool isEqual( Object x, Object y )
     {
         return x == y; // fails
     }

 You have to cast the result to bool.


 
 Again, behaves as designed :)  The compiler and the runtime both behave 
 exactly as the spec dictates.  Designs decisions can suck, and be 
 inconsistent with the philosophy of the project (as in this case), but that 
 doesn't make them bugs.  They are still arbitrary decisions, with no clear 
 cut 'right' or 'wrong'.


Okay, fair enough :-)  I'd still consider this to be a flaw in the spec 
since the result of a logical operation should always be boolean, but 
that's obviously just my opinion.


Sean
Jul 09 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:



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 
 
 


I've only done the 'missing line number' bugs, and the ones I'd reported.
BTW: All known 'missing line number' bugs are now fixed, except for
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.


 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? 



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 next 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 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 reply 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
 
 


Ouch.
Jul 10 2008
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.


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


 Ouch.


Why so?
Jul 10 2008
prev sibling next sibling parent Jason House <jason.james.house gmail.com> 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.
 
 -- 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


What if the community used some kind of continous integration methodology?  If
Walter updated a particular location with the latest and greatest dmd build,
then an automated process could grab copies of libraries (latest release and
svn version).  Compiling and running unit tests is a great start.

This could allow Walter, the Tango team, etc to get feedback prior to a
release.  I may be dreaming, but I could even imagine the automated
testing/integration process packaging functional combinations of compilers and
libraries together.  Then we could have tango, phobos, dmd, gdc, and llvmdc all
getting released together!
Jul 11 2008
prev sibling parent Flippeh <ng nospam.flippeh.de> 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.


Comparing 2 different version of my program, the size has increased by about
200kb. When compiling it in debug code on 1.030, it was as big as the release
version of it in 1.033. I didn't use any new compiler flags than I did before,
basically changed nothing, and only minor changes in the code that would at
maximum cost a few bytes.
Jul 23 2008