On Sun, 22 May 2011 11:56:33 +0300, KennyTM~ <[email protected]> wrote:
Nice tool! I tried to use it to reduce bug 6044, but encountered 2
problems:
1. DustMite will load _all_ files, including the _binary_ ones, which
is seldom in valid UTF-8 encoding, and that causes a UtfException to
be thrown from 'save.dump' because 'e.header' contains those invalid
character. (BTW, Andrei, is it really necessary to include the whole
invalid string in the exception?!)
The real question here is why would appender validate UTF when appending a
string to a string? This reduces the complexity of whatever a GC
allocation COULD be to linear, so for large strings it might be slower
than appending to an array. The following comment is in Phobos, but I
don't understand it:
// note, we disable this branch for appending one type of char to
// another because we can't trust the length portion.
The tool should have been able to handle binary files (it only attempts to
reduce them by completely removing them), but I never tested this
functionality.
Anyway, I've made it use ubyte[] for the appender type, so there won't be
any problems now.
2. For 6044, DustMite has overdone. It has reduced to an obviously
invalid program
void main() {
alias Maybe A;
// ok
A.Impl!int u; // error
}
but I guess it can't be avoided, since its error message is exactly
the same as the correct one I reported.
DustMite is only as smart as the test command you specify. You could
formulate your test command to check if the source code still includes
whatever bits should not be removed.
Generally, though, DustMite is most useful for reducing large programs you
don't want to reduce by hand, but especially when the error message is
cryptic, makes no indication of the real location (such as some templated
functions in Phobos), or is so fragile that removing seemingly unrelated
code makes the problem vanish.
--
Best regards,
Vladimir mailto:[email protected]
