It's been a month, and we've got 64 bugs logged as fixed. Should we do a release?

IMHO it depends on how close we are to fixing enough 64 bugs to make 64 support usable.  I define "usable" as at least successfully compiling, linking and running a version of "hello, world" that uses std.stdio, not printf, so that people can test it on more complex code and file bug reports.

If there's likely still another month's work or more there, then yeah, now's a good time for a release because we just got rid of some nasty and important bugs.  On the other hand, if there's only maybe a week or two more worth of work (at least plausibly; I know it's somewhat unpredictable), I suggest getting these last 64 bugs fixed before releasing.

On Mon, Dec 6, 2010 at 6:18 PM, Walter Bright <walter at digitalmars.com>wrote:

> It's been a month, and we've got 64 bugs logged as fixed. Should we do a
> release?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20101206/79f9b4fc/attachment.html>

I don't know how much work is left for 64 bits to work.

David Simcha wrote:
> IMHO it depends on how close we are to fixing enough 64 bugs to make 64 support usable.  I define "usable" as at least successfully compiling, linking and running a version of "hello, world" that uses std.stdio, not printf, so that people can test it on more complex code and file bug reports.
>
> If there's likely still another month's work or more there, then yeah, now's a good time for a release because we just got rid of some nasty and important bugs.  On the other hand, if there's only maybe a week or two more worth of work (at least plausibly; I know it's somewhat unpredictable), I suggest getting these last 64 bugs fixed before releasing.
>

Timing releases based on the 64 bit work is premature still.  So, I'd say go for it... with one reservation.

Have the os/x issue been resolved yet?

Ok two.. it'd be nice to get the bug fixes that are blocking the integration of std.process fixed as well.  I think there's patches included for them, right?  (I don't have the bug numbers in front of me right now, but I'll bet someone else does and will chime in shortly).

Later,
Brad

On Mon, 6 Dec 2010, Walter Bright wrote:

> Date: Mon, 06 Dec 2010 15:42:54 -0800
> From: Walter Bright <walter at digitalmars.com>
> Reply-To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Subject: Re: [dmd-beta] Do a new release?
> 
> I don't know how much work is left for 64 bits to work.
> 
> David Simcha wrote:
> > IMHO it depends on how close we are to fixing enough 64 bugs to make 64
> > support usable.  I define "usable" as at least successfully compiling,
> > linking and running a version of "hello, world" that uses std.stdio, not
> > printf, so that people can test it on more complex code and file bug
> > reports.
> > If there's likely still another month's work or more there, then yeah, now's
> > a good time for a release because we just got rid of some nasty and
> > important bugs.  On the other hand, if there's only maybe a week or two more
> > worth of work (at least plausibly; I know it's somewhat unpredictable), I
> > suggest getting these last 64 bugs fixed before releasing.
> > 
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 

Well, the recent thread in the newsgroup

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=123680

says its  bug 3979

On Mon, Dec 6, 2010 at 6:42 PM, Brad Roberts <braddr at puremagic.com> wrote:
> Timing releases based on the 64 bit work is premature still. ?So, I'd say go for it... with one reservation.
>
> Have the os/x issue been resolved yet?
>
> Ok two.. it'd be nice to get the bug fixes that are blocking the integration of std.process fixed as well. ?I think there's patches included for them, right? ?(I don't have the bug numbers in front of me right now, but I'll bet someone else does and will chime in shortly).
>
> Later,
> Brad
>
> On Mon, 6 Dec 2010, Walter Bright wrote:
>
>> Date: Mon, 06 Dec 2010 15:42:54 -0800
>> From: Walter Bright <walter at digitalmars.com>
>> Reply-To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
>> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
>> Subject: Re: [dmd-beta] Do a new release?
>>
>> I don't know how much work is left for 64 bits to work.
>>
>> David Simcha wrote:
>> > IMHO it depends on how close we are to fixing enough 64 bugs to make 64
>> > support usable. ?I define "usable" as at least successfully compiling,
>> > linking and running a version of "hello, world" that uses std.stdio, not
>> > printf, so that people can test it on more complex code and file bug
>> > reports.
>> > If there's likely still another month's work or more there, then yeah, now's
>> > a good time for a release because we just got rid of some nasty and
>> > important bugs. ?On the other hand, if there's only maybe a week or two more
>> > worth of work (at least plausibly; I know it's somewhat unpredictable), I
>> > suggest getting these last 64 bugs fixed before releasing.
>> >
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>



-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw

On 7 December 2010 00:18, Walter Bright <walter at digitalmars.com> wrote:
> It's been a month, and we've got 64 bugs logged as fixed. Should we do a
> release?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

I think we should get ready for a release.

There is a backend wrong-code bug which I think is urgent.
Bug 5294 "-O optimization breaks for loop"
I've done some work on it but unfortunately haven't got a patch yet. I
won't be able to do any more work on it for nearly a day.

These other patches for wrong-code bugs should also probably be included:

4389 ICE(constfold.c, expression.c), or wrong code: string~=dchar in CTFE
mitigation only:
4860 Taking delegates to a member function broken if method is also
aliased in from a base class

Don Clugston wrote:
> On 7 December 2010 00:18, Walter Bright <walter at digitalmars.com> wrote:
> 
>> It's been a month, and we've got 64 bugs logged as fixed. Should we do a release?
>>
>> 
>
> I think we should get ready for a release.
>
> There is a backend wrong-code bug which I think is urgent.
> Bug 5294 "-O optimization breaks for loop"
> I've done some work on it but unfortunately haven't got a patch yet. I
> won't be able to do any more work on it for nearly a day.
> 

I'm not sure how to fix that one yet, but it has been there for 25 years now, so I am not sure it is urgent!

> These other patches for wrong-code bugs should also probably be included:
>
> 4389 ICE(constfold.c, expression.c), or wrong code: string~=dchar in CTFE
> mitigation only:
> 4860 Taking delegates to a member function broken if method is also
> aliased in from a base class
>
> 

I'll check those out.

----- Original Message ----
> From: Walter Bright <walter at digitalmars.com>
> To: Discuss the dmd beta releases for D <dmd-beta at puremagic.com>
> Sent: Tue, December 7, 2010 1:28:00 AM
> Subject: Re: [dmd-beta] Do a new release?
> 
> 
> 
> Don Clugston wrote:
> > On 7 December 2010 00:18, Walter Bright  <walter at digitalmars.com>  wrote:
> > 
> >> It's been a month, and we've got 64 bugs  logged as fixed. Should we do a
> >>  release?
> >>
> >> 
> >
> > I think we  should get ready for a release.
> >
> > There is a backend wrong-code  bug which I think is urgent.
> > Bug 5294 "-O optimization breaks for  loop"
> > I've done some work on it but unfortunately haven't got a patch  yet. I
> > won't be able to do any more work on it for nearly a  day.
> > 
> 
> I'm not sure how to fix that one yet, but it has  been there for 25 years now, so I am not sure it is urgent!

A bug like that is more urgent than memory corruption issues IMO.  Blaming the compiler is the last thing anyone wants to do, so it's a bug likely to cause hours of frustration for anyone who encounters it.

As an idea of how to temporarily fix it, could you disable the optimization that forces unsigned comparisons in the loop?  That seems like a very small optimization we could afford to lose until you can fix this properly.

-Steve

On 7 December 2010 14:56, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>> Don Clugston wrote:
>> > On 7 December 2010 00:18, Walter Bright ?<walter at digitalmars.com> ?wrote:
>> >
>> >> It's been a month, and we've got 64 bugs ?logged as fixed. Should we do a ?release?
>> >>
>> >>
>> >
>> > I think we ?should get ready for a release.
>> >
>> > There is a backend wrong-code ?bug which I think is urgent.
>> > Bug 5294 "-O optimization breaks for ?loop"
>> > I've done some work on it but unfortunately haven't got a patch ?yet. I
>> > won't be able to do any more work on it for nearly a ?day.
>>
>> I'm not sure how to fix that one yet, but it has ?been there for 25 years now, so I am not sure it is urgent!
>
> A bug like that is more urgent than memory corruption issues IMO. ?Blaming the compiler is the last thing anyone wants to do, so it's a bug likely to cause hours of frustration for anyone who encounters it.
>
> As an idea of how to temporarily fix it, could you disable the optimization that forces unsigned comparisons in the loop? ?That seems like a very small optimization we could afford to lose until you can fix this properly.
>
> -Steve

To disable it, gother.c, line 802:

            else if (final >= 0)
            {   /* 0 <= final < initial */
                if (increment < 0 && ((final - initial) % increment) == 0 &&
                    !(final + increment < 0 &&
                        (relatop == OPge || relatop == OPlt)
                     )
                   )
                {
                makeuns:

-                    if (0 && !tyuns(rel->pelem->E2->Ety))
+                    if ( !tyuns(rel->pelem->E2->Ety))
                    {
                        rel->pelem->E2->Ety = touns(rel->pelem->E2->Ety);
#ifdef DEBUG

But actually, I don't understand the value in making it an unsigned compare.
It seems that it could also be turned into   (OPne  final).
The conversion only happens if final will eventually be reached
((final-initial)%increment == 0)
which suggests to me that originally, it was converted into !=.  I
wonder why it doesn't do that now.
Maybe it just doesn't help.

On 8 December 2010 08:44, Don Clugston <dclugston at googlemail.com> wrote: Something that made him look foolish: a workaround for a bug which had already been fixed.

Thanks, Walter!