On Mar 6, Robby Findler wrote: > Can you please point me to the code and explain the fix?
It's just the bug that I described below. Revision 13971. > 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! > > -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life!
