Can you please point me to the code and explain the fix? Thank you.
Robby On 3/6/09, Eli Barzilay <eli at barzilay.org> wrote: > On Fri, Mar 6, 2009 at 2:52 AM, Matthias Felleisen <matthias at ccs.neu.edu> > wrote: >> >> It sounds to me like one could formulate a test suite for this >> program: >> >> -- create correct format >> -- compress some file by a well-known factor. >> >> Did you add this to the test suite? -- Matthias > > No, I still have it on my todo list. There is a file in > tests/mzcheme/gzip.ss which is not used, which uses gzip+gunzip to > check that data is the same, and some commented code seems like it's > comparing it to the unix gzip. I'm not sure that comparing it to gzip > is a good idea, since it's likely that it will change in small ways -- > which is why I thought that I should try it first and find if there is > some way to make it work sensibly. > > But I think that comparing just the size would work much better, so > there's no need for gzip headache for the tests. > > (BTW, I'll also make a new test collection and remove the above file > from the mzscheme pile.) > > > On Mar 6, Robby Findler wrote: >> If you fix the input, you shoul dbe able to predict the compression >> precisely, right? It is deterministic! > > I don't think that it's a good idea for roughly the same reason as > above; but also because this would be a classic example of a > copy-paste test. (IOW, how do you know that this deterministic output > is the correct one?) > > >> And likely there is some simple unit test for the actual bug that >> Eli found. > > No -- in fact the unused gzip+gunzip test wouldn't discover it, for > the same reason that the code actually worked. The bug was roughly > this: > > (define-syntax foo > (syntax-rules () > [(foo x y z) > #'(some output with x y and z)])) > > Here's a tricky exercise: try to guess what the bug is... > > Anyway, since the code is extremely imperative, the usual result would > be some kind of failure -- but this happened to be a macro that didn't > do any real damage if its body is not executed -- it just didn't do > the compression (or maybe didn't compress as well as it should have). > The bottom line is that the output was still valid, and gunzip would > get you back the proper result. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! >
