[plt-dev] file/zip file sizes

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!