On 08/30/2012 09:17 AM, Dmitry Olshansky wrote:
> On 30-Aug-12 09:40, Charles Hixson wrote:
>> On 08/29/2012 06:46 PM, Andrei Alexandrescu wrote:
>>> On 8/29/12 4:52 PM, Charles Hixson wrote:
>>>> On 08/29/2012 04:15 PM, Andrei Alexandrescu wrote:
>>>>> On 8/29/12 3:47 PM, Charles Hixson wrote:
>>>>>> Where should I look to better understand
>>>>>> rdmd? I expected to need to list all the local files that were
>>>>>> needed,
>>>>>> but clearly that's the wrong approach.
>>>>>
>>>>> http://dlang.org/rdmd.html
>>>>>
>>>>> To my surprise, it's not in the top Google search results. However,
>>>>> Dmitry's shadow page is: http://blackwhale.github.com/rdmd.html
>>>>>
>>>>> Andrei
>>>> Thank you. Unfortunately, that page doesn't address the symptoms that
>>>> I've been experiencing, which while they don't halt development
>>>> certainly confuse it.
>>>>
>>>> It's starting to look as if while I use rdmd I'll need to keep
>>>> everything in one file, as otherwise I can't share exceptions between
>>>> classes. (And I'm only guessing that the problem is limited to
>>>> exceptions, as I haven't tested with other functions.)
>>>>
>>>> Since the small test programs DO call successfully between different
>>>> files (including for exceptions) I don't really have a clue as to
>>>> what's
>>>> going on, except that it appears to happen during linking. And
>>>> combining
>>>> the routines into one file appears to "fix" the problem. And that dmd
>>>> doesn't seem to have the same problem. (I.e., if I add a dummy main
>>>> routine to the avl.d file, then
>>>> dmd -unittest avl.d utils.d
>>>> compiles and executes without problems, even though it doesn't do
>>>> anything.
>>>
>>> You should be able to use rdmd for that dependency pattern, and if not
>>> there's a bug in it. However, nobody can work on that without a test
>>> case.
>>>
>>> Andrei
>>>
>>
>> The only one I have is about 450 lines long. If you want I could send
>> it to you. (I probably shouldn't just post it.)
>
> This is the place to report bugs (including big and obscure ones):
> http://d.puremagic.com/issues/
>
> The only requirement is to clear reproducible problem statement like
> this command fails with this on dmd version xx.
>
> As for size, well there is dustmite test case reduction tool that
> sometimes does miracles.
>
Perhaps I don't know enough to file a decent bug report...at least when I can't reduce the test case that shows it significantly.

I think you know a lot more than I do.  E.g., "dustmite test case reduction" doesn't mean much of anything to me.  Google, as expected, leads me to a bunch of adds for insect control.  (Well, not literally, as mites aren't insects.)  Even though Google had to add a space into dustmite and ignore the search term "computer program".  I can sort of tell what you mean from context, but "sort of" doesn't lead to an idea of how to proceed.

(FWIW, even debuggers are tools that I'm rather unfamiliar with.  I generally finesse that by using print statements.  But anything fancier and I don't even understand the terminology.  I may have programmed Fortran on 7094 IBSYS, but I came to D from Python and Ruby, and I've never learned the compiler code tools on Linux.  I'd have better luck debugging CDC Fortran...and that's 3-4 decades ago.)

On Friday, 31 August 2012 at 04:00:34 UTC, Charles Hixson wrote:
> Perhaps I don't know enough to file a decent bug report...at least when I can't reduce the test case that shows it significantly.

Dustmite refers to this tool: https://github.com/CyberShadow/DustMite

Basically it tries to compile your program, and while compilation continues to fail, it repeatedly tries to strip away parts of the program until your are left with the minimal amount of code required for compilation to fail. It is rather neat.

You could throw your code up on http://dpaste.dzfl.pl/new or something and someone could take a look, it is just hard to speculate without seeing any code...

On 08/30/2012 10:46 PM, cal wrote:
> On Friday, 31 August 2012 at 04:00:34 UTC, Charles Hixson wrote:
>> Perhaps I don't know enough to file a decent bug report...at least
>> when I can't reduce the test case that shows it significantly.
>
> Dustmite refers to this tool: https://github.com/CyberShadow/DustMite
>
> Basically it tries to compile your program, and while compilation
> continues to fail, it repeatedly tries to strip away parts of the
> program until your are left with the minimal amount of code required for
> compilation to fail. It is rather neat.
>
> You could throw your code up on http://dpaste.dzfl.pl/new or something
> and someone could take a look, it is just hard to speculate without
> seeing any code...

Thank you for the pointer to DustMite.  It looks like it might be quite useful in other cases.  But...

So I tried to use DustMite.  This just got weirder.  Apparently if the name of the containing folder isn't Parser (I was working with a copy), then the error doesn't occur.  If I ran DustMite on the original, the program got reduced down to "void main () { }" (with some extra whitespace).

N.B.:  dmd doesn't have a problem with the code, only rdmd.

On Friday, 31 August 2012 at 17:14:25 UTC, Charles Hixson wrote:
> If I ran DustMite on the original, the program got reduced down to "void main () { }" (with some extra whitespace).

And does rdmd compilation still fail with the reduced case?

On 08/31/2012 11:28 AM, cal wrote:
> On Friday, 31 August 2012 at 17:14:25 UTC, Charles Hixson wrote:
>> If I ran DustMite on the original, the program got reduced down to
>> "void main () { }" (with some extra whitespace).
>
> And does rdmd compilation still fail with the reduced case?
>
No.  But there were even more complex versions in which it also didn't fail.  For instance I could import utils.d (the addition of which caused the original to stop working) and throw a LogicError (defined in utils.d) and it didn't crash.

So I only have the large case...and even there, I've been working on the project, as dmd doesn't give any problems, and so I can't guarantee without checking again that it still fails.  But since nobody wants a 500 line test case (and I don't blame them...particularly since it appears that if I move it into a folder with a different name it stops failing), I haven't been preserving the case.  Last time I checked it still failed with rdmd in the Parser folder, but that was hours ago. There haven't been many changes, but there've been some.  And I can't even preserve it by copying it into another folder, because then it stops failing.

On Friday, 31 August 2012 at 20:20:42 UTC, Charles Hixson wrote:
> So I only have the large case...and even there, I've been working on the project, as dmd doesn't give any problems, and so I can't guarantee without checking again that it still fails.  But since nobody wants a 500 line test case (and I don't blame them...particularly since it appears that if I move it into a folder with a different name it stops failing), I haven't been preserving the case.  Last time I checked it still failed with rdmd in the Parser folder, but that was hours ago. There haven't been many changes, but there've been some.  And I can't even preserve it by copying it into another folder, because then it stops failing.

A big test is worse than a small one, but still better than no test case whatsoever. If you provide your 500 lines, someone might be able to spot an already known issue (e.g. you may be hitting issue 7016 [1]), or someone is willing to reduce it further. At the very least, it's in the database and can be dealt with sooner or later.

[1] "local import does not create -deps dependency" - http://d.puremagic.com/issues/show_bug.cgi?id=7016