From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: 01/01: guix: Simplify and robustify lzread!. Date: Thu, 09 May 2019 17:42:20 +0200 Message-ID: <87a7fvfxcz.fsf@ambrevar.xyz> References: <20190507164442.23834.73953@vcs0.savannah.gnu.org> <20190507164443.0BEE2207FC@vcs0.savannah.gnu.org> <87sgtp1des.fsf@gnu.org> <8736lpxm8i.fsf@ambrevar.xyz> <87imujem9f.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:51479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOlBl-0005G0-5g for guix-devel@gnu.org; Thu, 09 May 2019 11:42:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOlBk-0003ej-54 for guix-devel@gnu.org; Thu, 09 May 2019 11:42:29 -0400 In-Reply-To: <87imujem9f.fsf@gnu.org> 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>>> 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 bef= ore > colon indicates the part of the code being modified, to provide a bit of > context. That makes sense. Where it makes less sense to me is when we prefix with "gnu:" for packages. Why GNU? Why not "packages:"? >>> Could you add a test for this corner case? It=E2=80=99s corner cases l= ike 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 y= ou did, > you could just write that use case in the test file. If not, that=E2=80= =99s > okay. No bug on an actual use case. I kept discussing with Antonio and he pointed out the potential issue. The solution occurred to me on a fresh sunny morning :D > (I=E2=80=99m super cautious here but that=E2=80=99s because I spent count= less hours > debugging code that used zlib and libbz2 and lzo in the past. :-)) Yup, tell me about it... Took me weeks just to figure out basic (de)compression ;) But now that I have a better understanding of the library, I'm much more confident about the robustness and debugability of the bindings. Once things start adding up in your head, it's much more straightforward to see what goes wrong and how to fix it. (Stating the obvious here, but that's only true with good libraries, and lzlib is a good one.) Well, time will tell :) =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlzUSlwACgkQm9z0l6S7 zH9nGAf+IKqCdcazbHYxzar3Kvl+OEQjdUYhCLa5s2pLXyra/o3wcjSZ5snHygaq ddK/9Q2qtcP5SVes/4gbcpbgy6q3h9nnKAlawmOa5yr9ChiictXID7OPDmXR3D8L XkByOdFgZreUhoC5gAdpj6zla3LTH0TzBznfeBRbah9T3K7RHq066YG0qti5Izz/ VEc8hJhuiUKBfeOfgdCyjRDttk0MgAi3apyan/27VNZ+84eoCe/2elNOXojU3kXQ nx24zBtuhXmv5mXD4Wv8ZLfpaNfhVVR7YPdhjKaW9H5s6dYez1JJDbspbDLxMiaK 9Q7zJIsu1L+vbCp+f3tN9WXvk7VqUg== =TloY -----END PGP SIGNATURE----- --=-=-=--