We should consider Thrift breakages quite severe because modifying the code committed to Apache is quite difficult.

Andrei

On 4/8/12 5:33 PM, David Nadlinger wrote:
> On 8 Apr 2012, at 20:44, David Nadlinger wrote:
>> Still working on tracking down the mixin forward ref related
>> regression, […]
>
> Another bug probably somehow related to the Thrift test suite breakage;
> at least, I am having a hard time figuring out what is really going on
> with the confusion it causes:
> http://d.puremagic.com/issues/show_bug.cgi?id=7862
>
> I don't want to spoil the excitement, but DMD has not caused me as much
> trouble for quite some time - I think we should take extra care to
> ensure that this release is solid.
>
> David
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Maybe we should really consider making the auto-tester run builds of large, active D projects to catch breakage.

Regards,
Alex

On Mon, Apr 9, 2012 at 12:35 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
> We should consider Thrift breakages quite severe because modifying the code committed to Apache is quite difficult.
>
> Andrei
>
>
> On 4/8/12 5:33 PM, David Nadlinger wrote:
>>
>> On 8 Apr 2012, at 20:44, David Nadlinger wrote:
>>>
>>> Still working on tracking down the mixin forward ref related regression, […]
>>
>>
>> Another bug probably somehow related to the Thrift test suite breakage; at least, I am having a hard time figuring out what is really going on with the confusion it causes: http://d.puremagic.com/issues/show_bug.cgi?id=7862
>>
>> I don't want to spoil the excitement, but DMD has not caused me as much trouble for quite some time - I think we should take extra care to ensure that this release is solid.
>>
>> David
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Doesn't scale at all.  This is what betas are for.  The process is working.

On Apr 8, 2012, at 3:37 PM, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> Maybe we should really consider making the auto-tester run builds of large, active D projects to catch breakage.
> 
> Regards,
> Alex
> 
> On Mon, Apr 9, 2012 at 12:35 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
>> We should consider Thrift breakages quite severe because modifying the code committed to Apache is quite difficult.
>> 
>> Andrei
>> 
>> 
>> On 4/8/12 5:33 PM, David Nadlinger wrote:
>>> 
>>> On 8 Apr 2012, at 20:44, David Nadlinger wrote:
>>>> 
>>>> Still working on tracking down the mixin forward ref related regression, […]
>>> 
>>> 
>>> Another bug probably somehow related to the Thrift test suite breakage; at least, I am having a hard time figuring out what is really going on with the confusion it causes: http://d.puremagic.com/issues/show_bug.cgi?id=7862
>>> 
>>> I don't want to spoil the excitement, but DMD has not caused me as much trouble for quite some time - I think we should take extra care to ensure that this release is solid.
>>> 
>>> David
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta@puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> 
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

The thing is that some parts of Thrift are rather metaprogramming-heavy, and these parts at the same time are quite well covered by its test suite. Thus, it does rather well in finding related DMD regressions – at least I don't recall a recent release where this hasn't been the case.

David


On 9 Apr 2012, at 0:37, Alex Rønne Petersen wrote:
> Maybe we should really consider making the auto-tester run builds of
> large, active D projects to catch breakage.
>
> Regards,
> Alex
>
> On Mon, Apr 9, 2012 at 12:35 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
>> We should consider Thrift breakages quite severe because modifying the code
>> committed to Apache is quite difficult.
>>
>> Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Monday, April 09, 2012 01:11:03 David Nadlinger wrote:
> The thing is that some parts of Thrift are rather metaprogramming-heavy, and these parts at the same time are quite well covered by its test suite. Thus, it does rather well in finding related DMD regressions – at least I don't recall a recent release where this hasn't been the case.

Well, beta testing should give us the oportunity to catch these errors, but if there are things which thrift obviously tests and dmd's test suite doesn't, and they can be reasonably be put into dmd's test suite, then maybe they should be put in dmd's test suite. Obviously, dmd's test suite can't catch everything, but any case where it's obviously not testing something, and we can reasonably make it test it is probably a case where we should make it test it. Still, there's no question that dmd needs to be tested against large 3rd party projects in addition to its own tests, and thrift does provide a good opportunity for that.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Saturday, April 07, 2012 22:15:53 Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip

With this release, it looks like opCmp (like opEquals) needs to have overloads which take both const ref and non-ref, which is fine. But the obvious way to implement this seems to result in infinite recursion:

import std.string;

struct S
{
    string s;

    int opCmp(S rhs) const
    {
        return opCmp(rhs);
    }

    int opCmp(const ref S rhs) const
    {
        return cmp(s, rhs.s);
    }
}

void main()
{
    assert(S("h") < S("w"));
    assert(S("w") > S("h"));

    auto h = S("h");
    auto w = S("w");

    assert(h < w);
    assert(w > h);
}


Shouldn't the non-ref opCmp being calling the ref one and not itself? Right now, it's resulting in a segfault, because it's calling itself. Is this a bug, or is it expected behavior? I'm inclined to say that it's a bug and a rather serious issue in light of needing to duplicate functions like opEquals and opCmp. But I may be missing something here.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/8/12 6:11 PM, David Nadlinger wrote:
> The thing is that some parts of Thrift are rather metaprogramming-heavy,
> and these parts at the same time are quite well covered by its test
> suite. Thus, it does rather well in finding related DMD regressions – at
> least I don't recall a recent release where this hasn't been the case.

Interesting. I wonder whether it's worth making building and testing Thrift a part of the normal benchmarks.

Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Saturday, April 07, 2012 22:15:53 Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip
> 
> The only thing is 7815 is addressed again.

Another regression:

http://d.puremagic.com/issues/show_bug.cgi?id=7864

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2012$BG/(B4$B7n(B9$BF|(B8:36 Jonathan M Davis <jmdavisProg@gmx.com>:
> On Saturday, April 07, 2012 22:15:53 Walter Bright wrote:
>> http://ftp.digitalmars.com/dmd2beta.zip
>
> With this release, it looks like opCmp (like opEquals) needs to have overloads which take both const ref and non-ref, which is fine. But the obvious way to implement this seems to result in infinite recursion:
>
> import std.string;
>
> struct S
> {
>    string s;
>
>    int opCmp(S rhs) const
>    {
>        return opCmp(rhs);
>    }
>
>    int opCmp(const ref S rhs) const
>    {
>        return cmp(s, rhs.s);
>    }
> }
>
> void main()
> {
>    assert(S("h") < S("w"));
>    assert(S("w") > S("h"));
>
>    auto h = S("h");
>    auto w = S("w");
>
>    assert(h < w);
>    assert(w > h);
> }
>
>
> Shouldn't the non-ref opCmp being calling the ref one and not itself? Right now, it's resulting in a segfault, because it's calling itself. Is this a bug, or is it expected behavior? I'm inclined to say that it's a bug and a rather serious issue in light of needing to duplicate functions like opEquals and opCmp. But I may be missing something here.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

I think this is an expected behavior.

struct S should have two opCmps, int opCmp(const ref S rhs) const and int opCmp(const S rhs) const, both parameter rhs should be const. Whole S is 'a type has mutable indirection' because S has a string field s,  then copying const S to mutabe S is always forbidden.

>    int opCmp(S rhs) const
>    {
>        return opCmp(rhs);  // copy conversion from S to const S never run, so makes self-recursion.
>    }

I think the cause of issue 7864 is same.

Kenji Hara
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Monday, April 09, 2012 09:39:16 kenji hara wrote:
> 2012年4月9日8:36 Jonathan M Davis <jmdavisProg@gmx.com>:
> > On Saturday, April 07, 2012 22:15:53 Walter Bright wrote:
> >> http://ftp.digitalmars.com/dmd2beta.zip
> > 
> > With this release, it looks like opCmp (like opEquals) needs to have overloads which take both const ref and non-ref, which is fine. But the obvious way to implement this seems to result in infinite recursion:
> > 
> > import std.string;
> > 
> > struct S
> > {
> > 
> >    string s;
> > 
> >    int opCmp(S rhs) const
> >    {
> > 
> >        return opCmp(rhs);
> > 
> >    }
> > 
> >    int opCmp(const ref S rhs) const
> >    {
> > 
> >        return cmp(s, rhs.s);
> > 
> >    }
> > 
> > }
> > 
> > void main()
> > {
> > 
> >    assert(S("h") < S("w"));
> >    assert(S("w") > S("h"));
> > 
> >    auto h = S("h");
> >    auto w = S("w");
> > 
> >    assert(h < w);
> >    assert(w > h);
> > 
> > }
> > 
> > 
> > Shouldn't the non-ref opCmp being calling the ref one and not itself?
> > Right
> > now, it's resulting in a segfault, because it's calling itself. Is this a
> > bug, or is it expected behavior? I'm inclined to say that it's a bug and
> > a rather serious issue in light of needing to duplicate functions like
> > opEquals and opCmp. But I may be missing something here.
> > 
> > - Jonathan M Davis
> > _______________________________________________
> > dmd-beta mailing list
> > dmd-beta@puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/dmd-beta
> 
> I think this is an expected behavior.
> 
> struct S should have two opCmps, int opCmp(const ref S rhs) const and int opCmp(const S rhs) const, both parameter rhs should be const. Whole S is 'a type has mutable indirection' because S has a string field s,  then copying const S to mutabe S is always forbidden.
> 
> >    int opCmp(S rhs) const
> >    {
> > 
> >        return opCmp(rhs);  // copy conversion from S to const S never run,
> >        so makes self-recursion.>
> >    }
> 
> I think the cause of issue 7864 is same.

There really should be errors for opEquals, opCmp, toString, and toHash with incorrect signatures, and for any of them that need multiple overloads, it should complain not only if any of the overloads are incorrect but if any are missing. The fact that it's sort that's complaining makes it very hard to determine what's actually wrong.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta