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

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.

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.

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

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.

I have a LOT of experience doing this. It is not quick and easy with large masses of code that one is unfamiliar with.

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

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.

"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

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?