[plt-dev] file/zip file sizes

From: Eli Barzilay (eli at barzilay.org)
Date: Fri Mar 6 21:34:59 EST 2009

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!


Posted on the dev mailing list.