"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

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

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

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.

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.

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

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?

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.