On Feb 24, 2013 10:41 PM, "Timon Gehr" <timon.gehr@gmx.ch> wrote:
>
> On 02/24/2013 11:22 PM, Walter Bright wrote:
>>
>> On 2/24/2013 9:05 AM, Timon Gehr wrote:
>>>
>>> For the moment I'm just sticking with 2.060, because I have failed to
>>> reduce all
>>> the forward reference regressions introduced in 2.061.
>>
>>
>> I've found dustmite to be pretty helpful reducing things down.
>
>
> The problem is that there are many other spurious errors emitted and
dustmite finds reduced code that is not valid, but still emits the same forward reference error. Fixing the other compile errors then also gets rid of the forward reference error. So I am quite certain that the original problem is not exposed by the reduced code any more.

Might be...  No, I AM pointing out the obvious, but use 'git bisect' instead!

Maybe someone should write a nice handy D app that works like dustmite, but instead of reduces code, interacts with gut instead to help automate finding the bad commit.  :)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Feb 24, 2013 10:16 PM, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> On 2/24/2013 8:48 AM, SiegeLord wrote:
>>
>> I am quite sick of DMDFE breaking my code every release with bugs that are then solved for the next release (that is, if they are solved).
>
>
> Here's the current regression list:
>
>
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>

All regressions should have a link to the commit where the issue first recurred.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Sun, Feb 24, 2013 at 02:55:07PM -0800, Jonathan M Davis wrote:
> On Sunday, February 24, 2013 14:22:42 Walter Bright wrote:
> > On 2/24/2013 9:05 AM, Timon Gehr wrote:
> > > For the moment I'm just sticking with 2.060, because I have failed to reduce all the forward reference regressions introduced in 2.061.
> > 
> > I've found dustmite to be pretty helpful reducing things down.
> 
> I really need to figure out how to use dustmite one of these days. The last time that I tried to use it, I couldn't get it to work, but it may have been because rather than trying to find where the code stopped compiling, I was trying to find when the error message changed (the bug being encountered changed rather than a bug simply being introduced).
[...]

I started using dustmite a few days ago, and it's dead simple to use. Just put your source code in some directory, say src, then construct a command (or shell script) that returns exit status 0 if said code still exhibits the problem you're trying to minimize, non-zero otherwise. Then just run 'dustmite src $command', and it takes care of the rest.

Having said that, though, constructing the script can be a bit tricky, depending on what bug you're trying to isolate. Like you said, simply running dmd may not be enough (the compile error could have changed, etc.). So you probably need to use grep -qF to grep for the exact error message you're trying to isolate, and specifically test for that.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:
> On Feb 24, 2013 10:16 PM, "Walter Bright" <newshound2@digitalmars.com>
> wrote:
>>
>> On 2/24/2013 8:48 AM, SiegeLord wrote:
>>>
>>> I am quite sick of DMDFE breaking my code every release with bugs
>>> that are then solved for the next release (that is, if they are
>>> solved).
>>
>>
>> Here's the current regression list:
>>
>>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>>
>
> All regressions should have a link to the commit where the issue first
> recurred.

In my experience, that's nearly always a waste of time. In almost
all cases, there is nothing wrong with the offending commit, it
merely triggered an existing latent bug. This is particularly
true of forward reference bugs.

Knowing what the commit was, that exposed the bug, does not help
at all in fixing it. It's enough to know one commit where it
worked, and one where it failed, in order to be certain that it's
a regression.

OTOH making sure that the test case is truly minimal, is a huge
help in fixing the bug.

On 25 February 2013 09:35, Don <turnyourkidsintocash@nospam.com> wrote:

> On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:
>
>> On Feb 24, 2013 10:16 PM, "Walter Bright" <newshound2@digitalmars.com> wrote:
>>
>>>
>>> On 2/24/2013 8:48 AM, SiegeLord wrote:
>>>
>>>>
>>>> I am quite sick of DMDFE breaking my code every release with bugs that are then solved for the next release (that is, if they are solved).
>>>>
>>>
>>>
>>> Here's the current regression list:
>>>
>>>
>>>  http://d.puremagic.com/issues/**buglist.cgi?query_format=**
>> advanced&bug_severity=**regression&bug_status=NEW&bug_** status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>
>>
>>>
>>>
>> All regressions should have a link to the commit where the issue first recurred.
>>
>
> In my experience, that's nearly always a waste of time. In almost all cases, there is nothing wrong with the offending commit, it merely triggered an existing latent bug. This is particularly true of forward reference bugs.
>
>
I didn't imply that there was anything wrong with the offending commit.  It does help to give a reference point on where to start looking for tracing the different code paths down and find a resolution to the regression, as opposed to "removing this line" or "adding this safegaurd seems to work".


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 25 February 2013 at 10:09:18 UTC, Iain Buclaw wrote:
> On 25 February 2013 09:35, Don <turnyourkidsintocash@nospam.com> wrote:
>
>> On Monday, 25 February 2013 at 01:04:01 UTC, Iain Buclaw wrote:
>>
>>> On Feb 24, 2013 10:16 PM, "Walter Bright" <newshound2@digitalmars.com>
>>> wrote:
>>>
>>>>
>>>> On 2/24/2013 8:48 AM, SiegeLord wrote:
>>>>
>>>>>
>>>>> I am quite sick of DMDFE breaking my code every release with bugs
>>>>> that are then solved for the next release (that is, if they are
>>>>> solved).
>>>>>
>>>>
>>>>
>>>> Here's the current regression list:
>>>>
>>>>
>>>>  http://d.puremagic.com/issues/**buglist.cgi?query_format=**
>>> advanced&bug_severity=**regression&bug_status=NEW&bug_**
>>> status=ASSIGNED&bug_status=**REOPENED<http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED>
>>>
>>>>
>>>>
>>> All regressions should have a link to the commit where the issue first
>>> recurred.
>>>
>>
>> In my experience, that's nearly always a waste of time. In almost
>> all cases, there is nothing wrong with the offending commit, it
>> merely triggered an existing latent bug. This is particularly
>> true of forward reference bugs.
>>
>>
> I didn't imply that there was anything wrong with the offending commit.

I didn't intend to imply that you did. My experience is that it doesn't even have any useful relationship to the bug, and that (even worse) you waste a lot of time trying to figure out what the relationship is.

> It
> does help to give a reference point on where to start looking for tracing
> the different code paths down and find a resolution to the regression, a
> opposed to "removing this line" or "adding this safegaurd seems to work".

Intuitively, I used to think that, but I personally have not found that to be true in practice. I think tracking down the exact commit is a complete waste of time. In the cases I've seen where it had a clear relationship to the bug, it was obvious what part of the code contained the bug, anyway.