Ludovic Courtès writes: >> That said, if the encoder buffer is not empty, I think lz-compress-read >> should always return something >0. > > Yes, probably. The docstring for ‘lz-compress-read’ says: Oops, I read the docstring of lz-DEcompress-read. My bad. > "Read up to COUNT bytes from the encoder stream, storing the results in LZFILE-BV. > Return the number of uncompressed bytes written, a strictly positive integer." > ^~~~~~~~~~~~~~~~~ Bigger oops! This comes from a copy-paste of the gzip docstring which I forgot to update properly (I did for the decompression functions, but not for the compression functions). The docstrings should be fixed. > But that’s OK: the ‘read!’ method in ‘make-lzip-input-port/compressed’ > can just call ‘lzwrite!’ again with more data when that happens, so I’ve > done that. This could work, but I've had some headaches on such assumptions before. Tests are very necessary here to validate those assumptions ;) The thing is that we are not using lzlib as it is meant to be used (i.e. with the finish* functions) because of the functional approach of the binary ports which don't really play well with the procedural approach of the C library. > And I pushed the whole thing! :-) Hurray! Can't wait to say lz-compressed archives coming to Guix! :) -- Pierre Neidhardt https://ambrevar.xyz/