GNU bug report logs - #35880
[PATCH 0/7] Lzip support for 'guix publish' and 'guix substitute'

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Fri, 24 May 2019 13:34:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #73 received at 35880-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Pierre Neidhardt <mail <at> ambrevar.xyz>
Cc: 35880-done <at> debbugs.gnu.org
Subject: Re: [bug#35880] [PATCH 1/7] lzlib: Add
 'make-lzip-input-port/compressed'.
Date: Tue, 28 May 2019 09:52:09 +0200
Pierre Neidhardt <mail <at> ambrevar.xyz> skribis:

> Ludovic Courtès <ludo <at> gnu.org> 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.

I fixed this one in e13354a7ca5a0d5e28e02c4cfce6fecb1ab770e4.

>> 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 ;)

Definitely!

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

I think we’re using it the way it’s meant to be used, roughly along the
lines of the examples of its manual (info "(lzlib) Examples").

(I/O ports are not very “functional”.)

>> And I pushed the whole thing! :-)
>
> Hurray!  Can't wait to say lz-compressed archives coming to Guix! :)

I’ve updated the ‘guix’ package so people can start using
‘guix publish -C lzip’ and fetch substitute from there.

Thanks for making it possible!

Ludo’.




This bug report was last modified 5 years and 350 days ago.

Previous Next


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