[plt-dev] file/zip file sizes

If I understand this properly, your fix changes INSERT_STRING from
doing nothing to doing something. And INSERT_STRING is a macro, but
one that behaves like a function of its arguments.

In other words, the most trivial unit test of INSERT_STRING would have
caught this bug. (Did you maybe not understand what I meant by 'unit
test'?)

Here's a test case. This should produce 'vec-entry. It produced 'dummy
before the bug fix.

(let ([x 'dummy])
    (INSERT_STRING 0 x void #"abc" (build-vector 32769 (λ (i)
'vec-entry)) (build-vector 32769 (λ (i) 'vec-entry2)) 0)
    x)

Robby

On Fri, Mar 6, 2009 at 10:40 PM, Eli Barzilay <eli at barzilay.org> wrote:
> 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!
>