From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: 01/01: guix: Simplify and robustify lzread!. Date: Thu, 09 May 2019 16:27:24 +0200 Message-ID: <87imujem9f.fsf@gnu.org> References: <20190507164442.23834.73953@vcs0.savannah.gnu.org> <20190507164443.0BEE2207FC@vcs0.savannah.gnu.org> <87sgtp1des.fsf@gnu.org> <8736lpxm8i.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:33243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOk1C-0006mH-5U for guix-devel@gnu.org; Thu, 09 May 2019 10:27:31 -0400 In-Reply-To: <8736lpxm8i.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Wed, 08 May 2019 12:40:45 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: guix-devel@gnu.org Hi Pierre, Pierre Neidhardt skribis: > Ludovic Court=C3=A8s writes: > >> Hi Pierre! >> >> guix-commits@gnu.org skribis: >> >>> commit ecfc54403e2a1934b4f6e84ddad429b7970091fa >>> Author: Pierre Neidhardt >>> Date: Tue May 7 18:40:40 2019 +0200 >>> >>> guix: Simplify and robustify lzread!. >> ^ >> Should be lzlib. > > Oops! > I must confess that I never really understood the whole logic behind > GNU-style commit message :p It=E2=80=99s really Guix-specific here, but the idea is that the word before colon indicates the part of the code being modified, to provide a bit of context. >> Could you add a test for this corner case? It=E2=80=99s corner cases li= ke that >> that can spoil the whole experience, so it feels safer to add tests as >> soon as we encounter them. :-) > > I would have, but I don't know how. The problem is that I don't control > the chunk size passed to the read! callback of the custom port. That's > all up to Guile's implementation of custom ports. > > In practice, it seems that the BV is always big enough so the potential > issue can never arise. But the new code is better on all aspects. Didn=E2=80=99t you encounter the bug on an actual use case, though? If you= did, you could just write that use case in the test file. If not, that=E2=80=99s okay. (I=E2=80=99m super cautious here but that=E2=80=99s because I spent countle= ss hours debugging code that used zlib and libbz2 and lzo in the past. :-)) Thanks, Ludo=E2=80=99.