unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pierre Neidhardt <mail@ambrevar.xyz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: 01/01: guix: Simplify and robustify lzread!.
Date: Thu, 09 May 2019 17:42:20 +0200	[thread overview]
Message-ID: <87a7fvfxcz.fsf@ambrevar.xyz> (raw)
In-Reply-To: <87imujem9f.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]


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

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’s corner cases like 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’t 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’s
> 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’m super cautious here but that’s because I spent countless 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 :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2019-05-09 15:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190507164442.23834.73953@vcs0.savannah.gnu.org>
     [not found] ` <20190507164443.0BEE2207FC@vcs0.savannah.gnu.org>
2019-05-08  9:52   ` 01/01: guix: Simplify and robustify lzread! Ludovic Courtès
2019-05-08 10:40     ` Pierre Neidhardt
2019-05-09 14:27       ` Ludovic Courtès
2019-05-09 15:42         ` Pierre Neidhardt [this message]
2019-05-10 21:40           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7fvfxcz.fsf@ambrevar.xyz \
    --to=mail@ambrevar.xyz \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).