GNU bug report logs - #34807
[PATCH 1/2] Add (guix lzlib).

Previous Next

Full log

Message #14 received at 34807 <at> debbugs.gnu.org (full text, mbox):

From: Pierre Neidhardt <mail <at> ambrevar.xyz>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34807 <at> debbugs.gnu.org
Subject: Re: [bug#34807] [PATCH 1/2] Add (guix lzlib).
Date: Wed, 01 May 2019 18:46:44 +0200

[Message part 1 (text/plain, inline)]

Hi,

thanks for the review.  I've worked on it and I've managed to address
almost all issues.

Now I'm stuck with the stream decompression.

Lzip expects some special terminating bytes for each member.  In
tests/lzlib.scm, we produce a compressed stream and decompress it in
parallel.  But more often than not, before the compression is done, the
decompression will exhaust the port's byte and terminate prematurely.  I
don't know what to do in this case.  From the Guile manual:

--8<---------------cut here---------------start------------->8---
 -- Scheme Procedure: make-custom-binary-input-port id read!
          get-position set-position! close
     Return a new custom binary input port(1) named ID (a string) whose
     input is drained by invoking READ! and passing it a bytevector, an
     index where bytes should be written, and the number of bytes to
     read.  The ‘read!’ procedure must return an integer indicating the
     number of bytes read, or ‘0’ to indicate the end-of-file.
--8<---------------cut here---------------end--------------->8---

The decompression will sometime decompress 0 byte (when it's faster
then the compression).  But if I return 0 in lzread!, then the custom
port will be closed too early, before we could decompress the
terminating bytes.

Is there a way to wait on the port instead of reading 0 bytes?

Note that lzip can test whether the decompressed stream is terminated or
not with lz-decompress-member-finished?.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.