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.

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.

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.

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.

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.

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.

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.

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

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.

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