> Well, as threatened: http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports
> 
> Hopefully, it makes a little sense. I'm crossing my fingers that I didn't end every sentence with a preposition. and used some good Capitalization. And no sentence fragments...
> 

What about runnons that would be bad!

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cdhn59$so6$1@digitaldaemon.com...
> I think it's part skill - and no surprise that you're the most skilled -
and part
> other things. For me, those "other things" are generally a combination of
time
> pressure and a genuine confusion as to where the error may lie due to the complexity and unfamiliarity with D; if it were C++ I could boil things
down
> more.

Part of boiling it down is turning off one's brain about what might be wrong, and simply whacking away at it. (And there's just no way I understand complex template code, I just whack away at it.) Get rid of aliases, replace complex types with 'int', delete statements with wild abandon, remove every unused declaration, delete the function bodies, etc. Part of it is to create a simple cc.bat file to compile it, then the 'whack-compile-whack-compile' loop is pretty quick. I also use a text editor that automatically creates backup files, so if a whack removed the failure, then I just copy back the backup and whack off something else.

"J C Calvarese" <jcc7@cox.net> wrote in message news:cdhm8t$sen$1@digitaldaemon.com...
> 2. Perhaps after spending 5 hours condensing it from 50,000 lines to 100 lines, we decide we're tired and it's small enough for you to work with. (And yes, the TV was on the entire time, and I'm sure it wouldn't have taken so long to do if I turned it off.)

100 lines isn't bad, but I get a lot of "I'll ship you my whole 5 mb of source", and that's a tough slog since I have no idea what the code is and what it's supposed to be doing.


> I really doubt it's lack of ability though. I think it's lack of time.

But also everyone wants their particular bug addressed. And I want to get to them all. But to be frank, the ones that are reduced to the minimum move to the front of the queue, the ones that are 5 Mb of source fall to the back. Also, reducing the code to the minimum usually suggests a workaround, and that'll keep your project moving.


> By the way, I've thought about writing up some hints for how to condense down bug reports, but I suspect I'm the only one who would read it. :)

If it's good, I'll put it up on the web site. Anyone want to see consistently top drawer bug reports, just check out Christof's work in the digitalmars C++ group.

"J C Calvarese" <jcc7@cox.net> wrote in message news:cdi2tj$10io$1@digitaldaemon.com...
> Well, as threatened: http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports

I put a link to it on www.digitalmars.com/bugs.html. Thanks!

In article <cdhf4o$pur$1@digitaldaemon.com>, Walter says...
>
[...]
>I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?

I speak out of my own experience: I've finally found a bug in the embedded OS we are using that was bugging me for months. Not that I worked full time to the bug discovering task, but I've dedicated many days to it. It was a nightmare: every test case I put up was perfectly working, while the full app was not. Obviously, I was searching the bug where it wasn't. One day, to do some unrelated testing, I completely excluded the part of the program that (I thougth) contained the bug, and the bug was still there! Now it was easy to track it down, looking where I never looked before.

I think the main problem was the little I knew of the underlying OS internals, that made me look in the wrong places (enlarging the size of a buffer made the bug appear less than 1/100 than before, but the bug was elsewhere).

Apart from lazyness and short time, IMHO the main reason for the difficulty to find a short test case resides in the little knowing of the language syntax and the compiler internals. So for me it's not surprising that you, knowing better than anyone else the language and the compiler, are the bes test case maker.

Ciao

Walter wrote:
----------------------------------------------------------
> 
> I'm a bit befuddled, though. While I believe it is straightforward to boil
> these problems down to their essentials, almost nobody else (besides
> Christof Meerwald) seems to be able to do it. Am I sadly mistaken in
> thinking this is straightforward, or is it an unusual skill? Can it be
> taught?
> 
>

I believe the lack of this skill in most cases turns out to be lazyness.

Lars Ivar Igesund