digitalmars.D - DustMite, a D test case minimization tool
- Vladimir Panteleev (34/34) May 20 2011 Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a
- KennyTM~ (16/47) May 22 2011 Nice tool! I tried to use it to reduce bug 6044, but encountered 2 probl...
- Vladimir Panteleev (24/40) May 22 2011 The real question here is why would appender validate UTF when appending...
- Robert Jacques (11/28) May 22 2011 Essentially, this comment is about how you have to decode and then encod...
- Vladimir Panteleev (7/9) May 22 2011 I don't think using ~= when appending a string to a string will validate...
- Robert Jacques (4/10) May 22 2011 For string ~= string, appender calls string[] = string, which does a
- Vladimir Panteleev (7/20) May 22 2011 Right, so my complexity rant was BS, but appender will still validate UT...
- Robert Jacques (15/34) May 22 2011 Appender doesn't validate UTF when the character widths are the same.
- Vladimir Panteleev (14/15) May 22 2011 Yes it does. That's what I've been trying to explain this entire subthre...
- Robert Jacques (5/18) May 22 2011 Well, all I can say is that it doesn't throw on my install. (Windows, DM...
- Vladimir Panteleev (6/9) May 22 2011 2.053.
- Robert Jacques (14/20) May 22 2011 Ah. I think I've tracked down the problem. The term is(Range ==
- Bernard Helyer (3/3) May 22 2011 This seems very cool. It's churning away at a DMD64 bug that's manifeste...
- Robert Clipsham (10/41) May 23 2011 Just attempted to use it, I get the following when trying to compile:
- Vladimir Panteleev (6/12) May 23 2011 Please update your compiler and standard library?
- Robert Clipsham (5/16) May 23 2011 Ah, that sorted it, thanks.
- Robert Clipsham (19/21) May 23 2011 Wow, this tool works fantastically! Narrowed down a 5000 line test case
- Vladimir Panteleev (8/26) May 24 2011 Thanks! I've improved it based on your and others' feedback, and wrote
- Don (30/69) May 25 2011 This is fantastic for ICE bugs. But it doesn't work well for certain
- Don (11/85) May 25 2011 Specific suggestion:
- Vladimir Panteleev (13/16) May 27 2011 I've improved DustMite with your suggestions, and added the
Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a
simple utility" thread from digitalmars.D.learn. I hope the DMD
development team will find this useful.
Advantages over Tigris delta:
* Easy to use (takes only two arguments, no need to fiddle with levels)
* Readable output (comments and indentation are preserved)
* Native support for multiple files (accepts a path to an entire directory
for input)
* Written for D
* Written in D
* Not written in Perl
* Can recognize constructs such as try/catch, function invariants
(in/out/body)
* Only 440 lines of source code
If you've never used delta: this is a tool which attempts to shrink files
by deleting fragments iteratively, as long as the file satisfies a
user-specified condition (for example, a specific error message when
passed through the compiler).
Usage:
1. Formulate a condition command, which should exit with a status code of
0 when DustMite is on the right track, and anything else otherwise.
Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
2. Place all the files that dustmite is to minimize in a new directory.
3. If you'd like to test your condition command, don't forget to clean up
temporary files afterwards.
4. Run: dustmite path/to/directory test-command
5. After a while, dustmite will finish working and create
path/to/directory.reduced
I've tested it with a self-induced "bug" in std.datetime, it seems to work
great. If you find that it breaks on something, let me know.
https://github.com/CyberShadow/DustMite
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net
May 20 2011
On May 21, 11 06:01, Vladimir Panteleev wrote:Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a simple utility" thread from digitalmars.D.learn. I hope the DMD development team will find this useful. Advantages over Tigris delta: * Easy to use (takes only two arguments, no need to fiddle with levels) * Readable output (comments and indentation are preserved) * Native support for multiple files (accepts a path to an entire directory for input) * Written for D * Written in D * Not written in Perl * Can recognize constructs such as try/catch, function invariants (in/out/body) * Only 440 lines of source code If you've never used delta: this is a tool which attempts to shrink files by deleting fragments iteratively, as long as the file satisfies a user-specified condition (for example, a specific error message when passed through the compiler). Usage: 1. Formulate a condition command, which should exit with a status code of 0 when DustMite is on the right track, and anything else otherwise. Example: dmd test.d 2>&1 | grep -qF "Assertion failed" 2. Place all the files that dustmite is to minimize in a new directory. 3. If you'd like to test your condition command, don't forget to clean up temporary files afterwards. 4. Run: dustmite path/to/directory test-command 5. After a while, dustmite will finish working and create path/to/directory.reduced I've tested it with a self-induced "bug" in std.datetime, it seems to work great. If you find that it breaks on something, let me know. https://github.com/CyberShadow/DustMiteNice 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?!) 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.
May 22 2011
On Sun, 22 May 2011 11:56:33 +0300, KennyTM~ <kennytm gmail.com> 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:vladimir thecybershadow.net
May 22 2011
On Sun, 22 May 2011 09:40:19 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:On Sun, 22 May 2011 11:56:33 +0300, KennyTM~ <kennytm gmail.com> wrote:Essentially, this comment is about how you have to decode and then encode anytime one changes the character type. i.e. the fact that 1 dchar != 1 wchar != 1 char. So a 5 dchar string, might require 20 chars to represent. As for performance, using appender is never slower than ~=, as it uses essentially the same code. Furthermore, you actually can not make appender use linear allocation, even when you are doing a transcoding operation, as it always grows by max(needed, newCapacity() ), which gives it a roughly an exponential growth rate. Also, if you're concerned about appender performance, I'd recommend using the patch from Issue 5813.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.
May 22 2011
On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu> wrote:As for performance, using appender is never slower than ~=, as it uses essentially the same code.I don't think using ~= when appending a string to a string will validate the UTF. Will it? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
On Sun, 22 May 2011 19:30:58 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu> wrote:For string ~= string, appender calls string[] = string, which does a memcopy, iirc.As for performance, using appender is never slower than ~=, as it uses essentially the same code.I don't think using ~= when appending a string to a string will validate the UTF. Will it?
May 22 2011
On Mon, 23 May 2011 04:14:32 +0300, Robert Jacques <sandford jhu.edu> wrote:On Sun, 22 May 2011 19:30:58 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:Right, so my complexity rant was BS, but appender will still validate UTF on every append, unlike ~=. Isn't that a bug? -- Best regards, Vladimir mailto:vladimir thecybershadow.netOn Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu> wrote:For string ~= string, appender calls string[] = string, which does a memcopy, iirc.As for performance, using appender is never slower than ~=, as it uses essentially the same code.I don't think using ~= when appending a string to a string will validate the UTF. Will it?
May 22 2011
On Sun, 22 May 2011 21:39:55 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:On Mon, 23 May 2011 04:14:32 +0300, Robert Jacques <sandford jhu.edu> wrote:Appender doesn't validate UTF when the character widths are the same. For example, string test = "\<" ~ "\>" ~ "\Α" ~ "\Β" ~ "\Γ"~ "\♠" ~ "\♦"~ "\U0001D11E"; Appender!string app; foreach(i;0..ds.length-1) { app.put(test[i..$]); } Runs fine, even though at times test[i..$] is an invalid string, because the type of test and appender are both strings. However, if you change Appender to a wstring, then encoding and decoding occur and those routines always validate. Hence, if app is a Appender!wstring, it will throw a UTF validation error.On Sun, 22 May 2011 19:30:58 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:Right, so my complexity rant was BS, but appender will still validate UTF on every append, unlike ~=. Isn't that a bug?On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu> wrote:For string ~= string, appender calls string[] = string, which does a memcopy, iirc.As for performance, using appender is never slower than ~=, as it uses essentially the same code.I don't think using ~= when appending a string to a string will validate the UTF. Will it?
May 22 2011
On Mon, 23 May 2011 05:21:04 +0300, Robert Jacques <sandford jhu.edu> wrote:Appender doesn't validate UTF when the character widths are the same.Yes it does. That's what I've been trying to explain this entire subthread. import std.array; void main() { string invalid = "\xAA\xBB\xCC\xDD\xEE\xFF"; string str; str ~= invalid; // OK auto app = appender!string(); app.put(str); // throws } -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
On Sun, 22 May 2011 22:31:51 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:On Mon, 23 May 2011 05:21:04 +0300, Robert Jacques <sandford jhu.edu> wrote:Well, all I can say is that it doesn't throw on my install. (Windows, DMD 2.052) for either the patched nor un-patched appender implementation. What version are you using?Appender doesn't validate UTF when the character widths are the same.Yes it does. That's what I've been trying to explain this entire subthread. import std.array; void main() { string invalid = "\xAA\xBB\xCC\xDD\xEE\xFF"; string str; str ~= invalid; // OK auto app = appender!string(); app.put(str); // throws }
May 22 2011
On Mon, 23 May 2011 07:41:22 +0300, Robert Jacques <sandford jhu.edu> wrote:Well, all I can say is that it doesn't throw on my install. (Windows, DMD 2.052) for either the patched nor un-patched appender implementation. What version are you using?2.053. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
"Robert Jacques" <sandford jhu.edu> On Mon, 23 May 2011 00:48:07 -0400, Vladimir Panteleev <vladimir thecybershadow.net> wrote:On Mon, 23 May 2011 07:41:22 +0300, Robert Jacques <sandford jhu.edu> wrote:Ah. I think I've tracked down the problem. The term is(Range == Unqual!(T)[]) used to be true for a string and char[], and now it's properly being evaluated to false, which in turn causes the wrong static if branch to compile. So yes, this is a regression bug. You can fix by replacing the conditional (at line 1594) with: // note, we disable this branch for appending one type of char to // another because we can't trust the length portion. static if (is(typeof(_data.arr[0..1] = items[0..1])) && is(typeof(items.length) == size_t)) Or you can try out my patch to appender: http://d.puremagic.com/issues/show_bug.cgi?id=5813Well, all I can say is that it doesn't throw on my install. (Windows, DMD 2.052) for either the patched nor un-patched appender implementation. What version are you using?2.053.
May 22 2011
This seems very cool. It's churning away at a DMD64 bug that's manifested in SDC. If it produces something usable, I'll be very impressed. (I'm really only posting to see my name on the IRC DSpamBot :P)
May 22 2011
On 20/05/2011 23:01, Vladimir Panteleev wrote:Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a simple utility" thread from digitalmars.D.learn. I hope the DMD development team will find this useful. Advantages over Tigris delta: * Easy to use (takes only two arguments, no need to fiddle with levels) * Readable output (comments and indentation are preserved) * Native support for multiple files (accepts a path to an entire directory for input) * Written for D * Written in D * Not written in Perl * Can recognize constructs such as try/catch, function invariants (in/out/body) * Only 440 lines of source code If you've never used delta: this is a tool which attempts to shrink files by deleting fragments iteratively, as long as the file satisfies a user-specified condition (for example, a specific error message when passed through the compiler). Usage: 1. Formulate a condition command, which should exit with a status code of 0 when DustMite is on the right track, and anything else otherwise. Example: dmd test.d 2>&1 | grep -qF "Assertion failed" 2. Place all the files that dustmite is to minimize in a new directory. 3. If you'd like to test your condition command, don't forget to clean up temporary files afterwards. 4. Run: dustmite path/to/directory test-command 5. After a while, dustmite will finish working and create path/to/directory.reduced I've tested it with a self-induced "bug" in std.datetime, it seems to work great. If you find that it breaks on something, let me know. https://github.com/CyberShadow/DustMiteJust attempted to use it, I get the following when trying to compile: $ dmd -O -release -inline dustmite.d dsplit.d dsplit.d(245): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(253): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(259): Error: undefined identifier module dsplit.replaceInPlace With git revision 0699cca148a59beb4d4def44bea0e7b49f558d58. -- Robert http://octarineparrot.com/
May 23 2011
On Mon, 23 May 2011 22:48:52 +0300, Robert Clipsham <robert octarineparrot.com> wrote:Just attempted to use it, I get the following when trying to compile: $ dmd -O -release -inline dustmite.d dsplit.d dsplit.d(245): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(253): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(259): Error: undefined identifier module dsplit.replaceInPlace With git revision 0699cca148a59beb4d4def44bea0e7b49f558d58.Please update your compiler and standard library? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 23 2011
On 23/05/2011 20:50, Vladimir Panteleev wrote:On Mon, 23 May 2011 22:48:52 +0300, Robert Clipsham <robert octarineparrot.com> wrote:Ah, that sorted it, thanks. -- Robert http://octarineparrot.com/Just attempted to use it, I get the following when trying to compile: $ dmd -O -release -inline dustmite.d dsplit.d dsplit.d(245): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(253): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(259): Error: undefined identifier module dsplit.replaceInPlace With git revision 0699cca148a59beb4d4def44bea0e7b49f558d58.Please update your compiler and standard library?
May 23 2011
On 20/05/2011 23:01, Vladimir Panteleev wrote:I've tested it with a self-induced "bug" in std.datetime, it seems to work great. If you find that it breaks on something, let me know.Wow, this tool works fantastically! Narrowed down a 5000 line test case to about 80 lines (I've managed to get it down to 26 lines by removing comments/make semantic changes there's no way it would be able to do without some sort of semantic analysis). I'd note that the code wasn't the most simple either, involving templates, mixins, ctfe, objects, etc. A couple of notes that we've already discussed, but I'll paste here for others: * The tool spent about 10 minutes figuring out if it was ok to delete files in .git, then deleting them - this pretty much doubled the time taken to run the tool! * It took me a while to figure out, the test command is run from the directory you pass on the command line. You also score bonus points for being far simpler to set up than delta, and working *a lot* better than it (for D at least, I haven't tried it with anything else). Well done. -- Robert http://octarineparrot.com/
May 23 2011
On Tue, 24 May 2011 00:04:39 +0300, Robert Clipsham <robert octarineparrot.com> wrote:On 20/05/2011 23:01, Vladimir Panteleev wrote:Thanks! I've improved it based on your and others' feedback, and wrote some documentation: https://github.com/CyberShadow/DustMite/wiki -- Best regards, Vladimir mailto:vladimir thecybershadow.netI've tested it with a self-induced "bug" in std.datetime, it seems to work great. If you find that it breaks on something, let me know.Wow, this tool works fantastically! Narrowed down a 5000 line test case to about 80 lines (I've managed to get it down to 26 lines by removing comments/make semantic changes there's no way it would be able to do without some sort of semantic analysis). I'd note that the code wasn't the most simple either, involving templates, mixins, ctfe, objects, etc. A couple of notes that we've already discussed, but I'll paste here for others: * The tool spent about 10 minutes figuring out if it was ok to delete files in .git, then deleting them - this pretty much doubled the time taken to run the tool! * It took me a while to figure out, the test command is run from the directory you pass on the command line. You also score bonus points for being far simpler to set up than delta, and working *a lot* better than it (for D at least, I haven't tried it with anything else). Well done.
May 24 2011
Vladimir Panteleev wrote:
Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a
simple utility" thread from digitalmars.D.learn. I hope the DMD
development team will find this useful.
Advantages over Tigris delta:
* Easy to use (takes only two arguments, no need to fiddle with levels)
* Readable output (comments and indentation are preserved)
* Native support for multiple files (accepts a path to an entire
directory for input)
* Written for D
* Written in D
* Not written in Perl
* Can recognize constructs such as try/catch, function invariants
(in/out/body)
* Only 440 lines of source code
If you've never used delta: this is a tool which attempts to shrink
files by deleting fragments iteratively, as long as the file satisfies a
user-specified condition (for example, a specific error message when
passed through the compiler).
Usage:
1. Formulate a condition command, which should exit with a status code
of 0 when DustMite is on the right track, and anything else otherwise.
Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
2. Place all the files that dustmite is to minimize in a new directory.
3. If you'd like to test your condition command, don't forget to clean
up temporary files afterwards.
4. Run: dustmite path/to/directory test-command
5. After a while, dustmite will finish working and create
path/to/directory.reduced
I've tested it with a self-induced "bug" in std.datetime, it seems to
work great. If you find that it breaks on something, let me know.
https://github.com/CyberShadow/DustMite
This is fantastic for ICE bugs. But it doesn't work well for certain
types of bugs, such as the one I tracked down recently, which are of the
form:
assert(foo()==30);
int foo()
{
if (func1())
return 0;
return func2();
}
It reduces foo() to: int foo() { return 0; }
which causes the test to still fail, but the bug is gone.
The --noremove option doesn't help much because you have to name all of
the functions which have that behaviour, and you don't know them in advance.
I was pretty surprised to find that reduced test cases still had
comments in them. They should be the first things to be stripped out.
----
Something which has occured to me is that nearly always when I'm
reducing a bug, the code which is actually getting run is close to
minimal. So running with -cov and then removing any line with 0000 hits
would probably be pretty effective. Of course, you need to make sure it
still compiles, which could be quite difficult. You could run -cov in
the first run, and then when you slice up the file, you could mark
sections as 'hit' (count>0), 'missed'(count==0), or 'void' (no count,
could be a declaration, or a comment).
Generally any section with a 'hit' shouldn't be removed, but the test
case isn't minimal until all 'missed' lines are gone. Most of the 'void'
lines are probably removable too (it just won't compile, if they are
necessary).
May 25 2011
Don wrote:Vladimir Panteleev wrote:Specific suggestion: When dustmite does the initial slicing of the file, it should look for a matching .lst file. If it exists, then for any line in the .lst file where there is a '1'..'9' before the first non-numeric character on that line, that corresponding line in the .d file should be ineligible for deletion. (This is recursive; the function it's in shouldn't be deletable in its entirity). Everything else should be unchanged. Then, for these unstable bugs, the user just needs to compile with -cov first, and retain the .lst files in the directory.Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a simple utility" thread from digitalmars.D.learn. I hope the DMD development team will find this useful. Advantages over Tigris delta: * Easy to use (takes only two arguments, no need to fiddle with levels) * Readable output (comments and indentation are preserved) * Native support for multiple files (accepts a path to an entire directory for input) * Written for D * Written in D * Not written in Perl * Can recognize constructs such as try/catch, function invariants (in/out/body) * Only 440 lines of source code If you've never used delta: this is a tool which attempts to shrink files by deleting fragments iteratively, as long as the file satisfies a user-specified condition (for example, a specific error message when passed through the compiler). Usage: 1. Formulate a condition command, which should exit with a status code of 0 when DustMite is on the right track, and anything else otherwise. Example: dmd test.d 2>&1 | grep -qF "Assertion failed" 2. Place all the files that dustmite is to minimize in a new directory. 3. If you'd like to test your condition command, don't forget to clean up temporary files afterwards. 4. Run: dustmite path/to/directory test-command 5. After a while, dustmite will finish working and create path/to/directory.reduced I've tested it with a self-induced "bug" in std.datetime, it seems to work great. If you find that it breaks on something, let me know. https://github.com/CyberShadow/DustMiteThis is fantastic for ICE bugs. But it doesn't work well for certain types of bugs, such as the one I tracked down recently, which are of the form: assert(foo()==30); int foo() { if (func1()) return 0; return func2(); } It reduces foo() to: int foo() { return 0; } which causes the test to still fail, but the bug is gone. The --noremove option doesn't help much because you have to name all of the functions which have that behaviour, and you don't know them in advance. I was pretty surprised to find that reduced test cases still had comments in them. They should be the first things to be stripped out. ---- Something which has occured to me is that nearly always when I'm reducing a bug, the code which is actually getting run is close to minimal. So running with -cov and then removing any line with 0000 hits would probably be pretty effective. Of course, you need to make sure it still compiles, which could be quite difficult. You could run -cov in the first run, and then when you slice up the file, you could mark sections as 'hit' (count>0), 'missed'(count==0), or 'void' (no count, could be a declaration, or a comment). Generally any section with a 'hit' shouldn't be removed, but the test case isn't minimal until all 'missed' lines are gone. Most of the 'void' lines are probably removable too (it just won't compile, if they are necessary).
May 25 2011
On Thu, 26 May 2011 09:58:33 +0300, Don <nospam nospam.com> wrote:I've improved DustMite with your suggestions, and added the --strip-comments and --coverage options. The algorithm itself has been substantially improved as well. As an example, I tried to reduce rdmd to see why it didn't compile with latest DMD/Phobos (with an unhelpful error message pointing inside std.array). Old version: https://gist.github.com/994106 New version: https://gist.github.com/994108 The first and last imports couldn't be reduced, but it's still a great improvement. -- Best regards, Vladimir mailto:vladimir thecybershadow.netThis is fantastic for ICE bugs. But it doesn't work well for certain types of bugs, such as the one I tracked down recently, which are of the form:
May 27 2011