From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:39447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVcSS-0000h6-Mp for guix-patches@gnu.org; Tue, 28 May 2019 09:48:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVcSQ-0005zo-Nn for guix-patches@gnu.org; Tue, 28 May 2019 09:48:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:41779) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hVcSQ-0005z0-3M for guix-patches@gnu.org; Tue, 28 May 2019 09:48:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hVcSP-00062P-Vt for guix-patches@gnu.org; Tue, 28 May 2019 09:48:02 -0400 Subject: [bug#35880] [PATCH 1/7] lzlib: Add 'make-lzip-input-port/compressed'. Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20190524134238.22802-1-ludo@gnu.org> <87d0k6o3am.fsf@ambrevar.xyz> <87ftp1m1te.fsf@gnu.org> <87blznsxym.fsf@gnu.org> <87ef4jlvbr.fsf@ambrevar.xyz> <87lfyrr554.fsf@gnu.org> <87sgszk3ev.fsf@ambrevar.xyz> <877eab3tjq.fsf@gnu.org> <87k1ebj7a8.fsf@ambrevar.xyz> Date: Tue, 28 May 2019 15:47:13 +0200 In-Reply-To: <87k1ebj7a8.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Tue, 28 May 2019 10:46:23 +0200") Message-ID: <871s0i1yji.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Pierre Neidhardt Cc: 35880-done@debbugs.gnu.org Pierre Neidhardt skribis: > Ludovic Court=C3=A8s writes: [...] >>> 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=E2=80=99re using it the way it=E2=80=99s meant to be used, ro= ughly along the >> lines of the examples of its manual (info "(lzlib) Examples"). >> >> (I/O ports are not very =E2=80=9Cfunctional=E2=80=9D.) > > In the sense that we define "read!" and "write!" functions which don't > allow us to call the "finish" functions properly. > > So maybe we are following the doc too "roughly" :p > > This has multiple implications, e.g. it impedes support for multiple > members, (which is OK as long as we don't accept archives produced by a > third-party) and more importantly it lifts the guarantee that the > library is going to work as per the documentation. I=E2=80=99m not sure I follow. I think =E2=80=98make-lzip-input-port/compr= essed=E2=80=99 corresponds to Example 2 in the manual (info "(lzlib) Examples"), =E2=80=98make-lzip-output-port=E2=80=99 corresponds to Example 1, and =E2=80=98make-lzip-input-port=E2=80=99 corresponds to Example 4 (with the e= xception that =E2=80=98lzread!=E2=80=99 doesn=E2=80=99t call =E2=80=98lz-decompress-finis= hed?=E2=80=99, but it has other means to tell whether we=E2=80=99re done processing input.) What do you think is not done as documented? Thanks, Ludo=E2=80=99.