[plt-dev] file/zip file sizes

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!
>