[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#35880] [PATCH 1/7] lzlib: Add 'make-lzip-input-port/compressed'.

From: Ludovic Courtès
Subject: [bug#35880] [PATCH 1/7] lzlib: Add 'make-lzip-input-port/compressed'.
Date: Sun, 26 May 2019 21:51:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)


Pierre Neidhardt <address@hidden> skribis:

> As an Lzip enthusiast, I have some questions ;)
> I see you are using make-lzip-input-port/compressed in a subsequent
> patch, but this does not map how it's done for gzip et al., the latter
> being invoked via it's system command "gzip -c ...".  Why did you decide
> to do it differently for lzip?
> Much of the code induced by make-lzip-input-port/compressed seems to
> repeat the lzread! / lzwrite business, maybe there is a way to factor
> some of it?

Actually, ‘make-lzip-input-port/compressed’ exists solely so we can have
‘compressed-port’ for lzip, which in turn allows us to write tests.

It uses (guix lzlib) instead of invoking the ‘lzip’ command because we
can.  :-)  Invoking commands is not as nice, because it’s more
expensive, requires us to spawn an additional process when the input is
not a file port (e.g., it’s a string port), and it’s forking is not
possible in multi-threaded programs like ‘guix publish’.

>> +(define (lzwrite! encoder source source-offset source-count
>> +                  target target-offset target-count)
>> +  "Write up to SOURCE-COUNT bytes from SOURCE to ENCODER, and read up to
>> +TARGET-COUNT bytes into TARGET at TARGET-OFFSET.  Return two values: the
>> +number of bytes read from SOURCE, and the number of bytes written to 
>> +  (define read
>> +    (if (< 0 (lz-compress-write-size encoder))
>> +        (match (lz-compress-write encoder source source-offset source-count)
>> +          (0 (lz-compress-finish encoder) 0)
>> +          (n n))
>> +        0))
>> +
>> +  (let loop ()
>> +    (match (lz-compress-read encoder target target-offset target-count)
>> +      (0       (loop))
>> +      (written (values read written)))))
> Why looping on 0?  If there is no byte to read, wouldn't this loop 
> indefinitely?

Hmm, good point.  The idea is that ‘lzwrite!’ should return 0 only on
end-of-file, but then the loop should include reading more from SOURCE.
I’ll follow up on this one.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]