Don, el  3 de septiembre a las 17:30 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el  3 de septiembre a las 01:16 me escribiste:
> >>This will probably be the last OSX 10.5 release, the next should be 10.6.
> >>
> >>http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip
> >>
> >>
> >>http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip
> >>
> >>Many thanks to the numerous people who contributed to this update.
> >These are a very good release, thanks for your work.
> >Aren't the new CTFE capabilities new features?
> 
> They're basically bug fixes. All that stuff should have worked.

Not all of them, I've seen the spacs have changed for D2: http://www.dsource.org/projects/phobos/changeset/1262

I'm just talking about the changes that relaxed the CTFE restrictions imposed in the specs. Again, that can be called simply a non-standard DMD extension to D1 and that would be fine with me.

> >Don't get me wrong, as I stated before, I'm really glad D1 get some new features/improvements, I just think the changes should be a little more tested before hit D1 (and new aditions to D1 should be more planned, for example, leaving them in D2 for a few releases only, so you can get real feedback from users before puting them in D1, and having some version scheme to indicate when new features are added).
>
> I believe you will find the new CTFE very stable. In implementing the improvements, many structural problems were fixed. It turns out to be a very effective way of diagnosing bugs.

You never know. People use features in extremely different ways, sometimes in ways you can't possibly foreseen (I think once Walter said that about the kind of magic you do with CTFE =). Maybe you break some code that relied on something that doesn't compile (as Bartoz shows in his last post =). I'm not saying that would happen, I'm just saying that there is a lot of D out there, and even a simple change should be taken with care. There are 2 versions of D, one stable and one in development, I think that should be used and put new features out there in the development version only for some time, just to be sure, and then move them to the stable version (some sort of Debian testing/stable =P).

And I want to say again that all your contribution, in this release in the CTFE front specially, is really impressive, and I hope you keep doing what you're doing for a long time, even if changes are folded in D1 with blind trust =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Y serán tiempos de vanos encuentros entre humano y humano; en que las
fieras se comerán entre ellas y después del final; en que se abríran las
tierras y los cielos... y en el medio de la nada Racing saldrá campeón.
	-- Ricardo Vaporeso

On Thu, Sep 3, 2009 at 4:16 AM, Walter Bright<newshound1@digitalmars.com> wrote:
> This will probably be the last OSX 10.5 release, the next should be 10.6.
>
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip
>
> Many thanks to the numerous people who contributed to this update.
>

Oh my god. The "compiler now tells you *why* a function is not CTFE-able" ALONE is like, man, total show-changer.

Thanks for your, Andrei's, Don's, and all others' work on this update :)

Don wrote:
> A few bugs are fixed but not listed in the changelog:
> 3077 crash exiting main() without result code
> 3100 ICE(cast.c) struct with members is shared
> 3253 DMD crashes on function pointer struct member initialization with function literal
> 3281 ICE(cod1.c) append returned struct to array

Ok, I put 'em in.

Andrei Alexandrescu wrote:
> Walter, could you please update changelog.dd from svn and then update the html changelog?

done.

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Walter, could you please update changelog.dd from svn and then update the html changelog?
> 
> done.

I counted 102 fixed bugs in this release.

Andrei

Don wrote:
> Leandro Lucarella wrote:
>> Walter Bright, el  3 de septiembre a las 01:16 me escribiste:
> 
>> Don't get me wrong, as I stated before, I'm really glad D1 get some new
>> features/improvements, I just think the changes should be a little more
>> tested before hit D1 (and new aditions to D1 should be more planned, for
>> example, leaving them in D2 for a few releases only, so you can get real
>> feedback from users before puting them in D1, and having some version
>> scheme to indicate when new features are added).
> 
> I believe you will find the new CTFE very stable. In implementing the improvements, many structural problems were fixed. It turns out to be a very effective way of diagnosing bugs.
> 

Don - can you give an example of how CTFE helps in diagnosing a bug ?

On Thu, Sep 3, 2009 at 7:01 PM, Nick B<nick.barbalich@gmail.com> wrote:
> Don wrote:
>>
>> Leandro Lucarella wrote:
>>>
>>> Walter Bright, el  3 de septiembre a las 01:16 me escribiste:
>>
>>> Don't get me wrong, as I stated before, I'm really glad D1 get some new features/improvements, I just think the changes should be a little more tested before hit D1 (and new aditions to D1 should be more planned, for example, leaving them in D2 for a few releases only, so you can get real feedback from users before puting them in D1, and having some version scheme to indicate when new features are added).
>>
>> I believe you will find the new CTFE very stable. In implementing the improvements, many structural problems were fixed. It turns out to be a very effective way of diagnosing bugs.
>>
>
> Don - can you give an example of how CTFE helps in diagnosing a bug ?

I think he means that in implementing the improvements to CTFE's capabilities, it made other CTFE bugs more obvious and diagnosable.

Thanks for yet another great release, but.. has anyone else gotten DFL to compile? (The latest svn of DFL worked fine in 2.031)

I've been trying to get it up and running but I've been seeing really weird errors. It appears in several cases that various import statements are not being imported. For example:

    import dfl.menu;
    import dfl.form;

Seems to import the menu classes, but not the form classes. And

    import dfl.form;
    import dfl.menu;

does the opposite.

I tried tracing the issue down (from control.d -> menu.d -> application.d -> form.d, testing using dfl.internal.winapi) and it looked like I found a single line of code in form.d

version(NO_MDI) {} else {
// commented out source
}

in which a public import dfl.internal.winapi worked above and didn't work below. But, when I tried to make a simple test case, everything worked. And then when I came back to full source, that test worked too, as did form (But that was only because I had publicly imported it from application.d & application from menu.d)

Jarrett Billingsley wrote:
> On Thu, Sep 3, 2009 at 7:01 PM, Nick B<nick.barbalich@gmail.com> wrote:
>> Don wrote:
>>> Leandro Lucarella wrote:
>>>> Walter Bright, el  3 de septiembre a las 01:16 me escribiste:
>>>> Don't get me wrong, as I stated before, I'm really glad D1 get some new
>>>> features/improvements, I just think the changes should be a little more
>>>> tested before hit D1 (and new aditions to D1 should be more planned, for
>>>> example, leaving them in D2 for a few releases only, so you can get real
>>>> feedback from users before puting them in D1, and having some version
>>>> scheme to indicate when new features are added).
>>> I believe you will find the new CTFE very stable. In implementing the
>>> improvements, many structural problems were fixed. It turns out to be a very
>>> effective way of diagnosing bugs.
>>>
>> Don - can you give an example of how CTFE helps in diagnosing a bug ?
> 
> I think he means that in implementing the improvements to CTFE's
> capabilities, it made other CTFE bugs more obvious and diagnosable.

Not just that. It shows up problems in the semantic pass elsewhere in the compiler. I've just used it to discover what's wrong with D2 struct constructors. To a limited extent, CTFE is like an alternative back-end.
I was talking about compiler bugs, not user bugs, although it does now detect a couple of run-time bugs (CTFE will now tell you which line a null pointer dereference occurs on).

Leandro Lucarella wrote:
> Don, el  3 de septiembre a las 17:30 me escribiste:
>> Leandro Lucarella wrote:
>>> Walter Bright, el  3 de septiembre a las 01:16 me escribiste:
>>>> This will probably be the last OSX 10.5 release, the next should be 10.6.
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.1.047.zip
>>>>
>>>>
>>>> http://www.digitalmars.com/d/2.0/changelog.html
>>>> http://ftp.digitalmars.com/dmd.2.032.zip
>>>>
>>>> Many thanks to the numerous people who contributed to this update.
>>> These are a very good release, thanks for your work.
>>> Aren't the new CTFE capabilities new features? 
>> They're basically bug fixes. All that stuff should have worked.
> 
> Not all of them, I've seen the spacs have changed for D2:
> http://www.dsource.org/projects/phobos/changeset/1262
> 
> I'm just talking about the changes that relaxed the CTFE restrictions
> imposed in the specs. Again, that can be called simply a non-standard DMD
> extension to D1 and that would be fine with me.
> 
>>> Don't get me wrong, as I stated before, I'm really glad D1 get some new
>>> features/improvements, I just think the changes should be a little more
>>> tested before hit D1 (and new aditions to D1 should be more planned, for
>>> example, leaving them in D2 for a few releases only, so you can get real
>>> feedback from users before puting them in D1, and having some version
>>> scheme to indicate when new features are added).
>> I believe you will find the new CTFE very stable. In implementing the
>> improvements, many structural problems were fixed. It turns out to be
>> a very effective way of diagnosing bugs.
> 
> You never know. People use features in extremely different ways, sometimes
> in ways you can't possibly foreseen (I think once Walter said that about
> the kind of magic you do with CTFE =). Maybe you break some code that
> relied on something that doesn't compile (as Bartoz shows in his last post
> =).

Yes, but that's true of ANY bug fix. In fact, the CTFE "features" are much smaller changes than many of the bug fixes. The biggest CTFE change was actually the fact that references didn't work properly. (They compiled but generated wrong code).

I'm not so worried about CTFE stuff, because the compiler behaviour has, up to now, departed so radically from the spec that it hasn't been possible to depend on it.  Eg, x[x.length - 4]='c'; compiled, but x[$-4]='c' did not compile! More importantly, CTFE is almost completely isolated from the rest of the compiler: it can't break anything that's not CTFE.

AFAIK, the only areas where DMD1 can still get "new features" is CTFE, array operations, and contract inheritance. They are the three areas where the implementation wasn't finished when D2 began, and where the compiler behaviour has never been close to the spec. It is likely, for example, that unions will need to be disallowed in CTFE, but there's absolutely no reason why 'new' expressions should be disallowed.
Similarly, the specs say nothing about whether array expressions are legal in CTFE.

> I'm not saying that would happen, I'm just saying that there is a lot
> of D out there, and even a simple change should be taken with care. 

Indeed. There are still D1 bugs which can only be fixed by some fairly large compiler changes. On the CTFE side, fixing bug 1330 is going to be far more disruptive than anything in this release.

> There
> are 2 versions of D, one stable and one in development, I think that
> should be used and put new features out there in the development version
> only for some time, just to be sure, and then move them to the stable
> version (some sort of Debian testing/stable =P).

In theory, that already happens to an extent. The version recommended for download is not the latest one. I do wonder if anyone actually *uses* the recommended one, though!

> And I want to say again that all your contribution, in this release in the
> CTFE front specially, is really impressive, and I hope you keep doing what
> you're doing for a long time, even if changes are folded in D1 with blind
> trust =)

Thanks. I figured that right now, the most useful thing I can do is to patch the compiler. So I've put everything else on hold.