unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Vollmert <rob@vllmrt.net>
To: Timothy Sample <samplet@ngyro.com>
Cc: 36048@debbugs.gnu.org
Subject: [bug#36048] [PATCH] guix: import: hackage: handle hackage revisions
Date: Thu, 13 Jun 2019 21:40:15 +0200	[thread overview]
Message-ID: <635BD0E2-BADE-4385-8A4C-A3AE36A392BC@vllmrt.net> (raw)
In-Reply-To: <87lfy59x2x.fsf@ngyro.com>



> On 13. Jun 2019, at 20:09, Timothy Sample <samplet@ngyro.com> wrote:
> 
> Hi Robert,
> 
> Robert Vollmert <rob@vllmrt.net> writes:
> 
>> Hi Timothy,
>> 
>> thanks for the detailed feedback, this is very helpful!
> 
> You’re welcome!
> 
>> I’ve sent an updated patch addressing some of the concerns, but have
>> some questions regarding others. (I just realized that the documentation
>> updates probably anticipate multiple return values.)
> 
> Yes.
> 
>>> On 13. Jun 2019, at 04:28, Timothy Sample <samplet@ngyro.com> wrote:
>>>> +  (let-values (((port get-hash) (open-sha256-input-port port)))
>> 
>>>> +    (cons
>>>> +      (read-cabal (canonical-newline-port port))
>>>> +      (bytevector->nix-base32-string (get-hash)))))
>> 
>> […]
>> 
>>> Also, I think returning multiple values would be more natural here
>>> (i.e., replace “cons” with “values”).
>> 
>> I tried building it that way to begin with, but I’m having issues
>> making it work (nicely, or maybe at all). I think it comes down to
>> later functions optionally failing with a single #f-value. Judging
>> by the lack of infrastructure, I imagine functions that return different
>> numbers of values are not idiomatic scheme. Should this be changed to
>> return two values (#f #f) on failure? Or to raise an exception and
>> handle it higher up when we want to ignore a failure?
>> 
>> Currently, implementing this with values/let-values results in me
>> doing more or less a combination of let-values and match, at which
>> point it seems that any potential benefits of using multiple values
>> as opposed to a pair/list are lost. (There’s no match-values form is
>> there?)
> 
> I’m not sure I understand the problem.  Here’s what I had in mind:
> 
> diff --git a/guix/import/hackage.scm b/guix/import/hackage.scm
> index 2853037797..9ba3c4b58e 100644
> --- a/guix/import/hackage.scm
> +++ b/guix/import/hackage.scm
> @@ -120,8 +120,8 @@ version is returned."
> (define (read-cabal-and-hash port)
>   "Read a cabal file and its base32 hash from a port."
>   (let-values (((port get-hash) (open-sha256-input-port port)))
> -    (cons (read-cabal (canonical-newline-port port))
> -          (bytevector->nix-base32-string (get-hash)))))
> +    (values (read-cabal (canonical-newline-port port))
> +            (bytevector->nix-base32-string (get-hash)))))
> 
> (define (hackage-fetch-and-hash name-version)
>   "Return the Cabal file and hash for the package NAME-VERSION, or #f on
> @@ -129,7 +129,7 @@ failure. If the version part is omitted from the package name, then return
> the latest version."
>   (guard (c ((and (http-get-error? c)
>                   (= 404 (http-get-error-code c)))
> -             #f))                       ;"expected" if package is unknown
> +             (values #f #f)))           ;"expected" if package is unknown

This is the point: I tried to keep returning a single #f to signal failure.

I sent an updated patch, let me know if I missed something. Thanks!

Robert

  reply	other threads:[~2019-06-13 19:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01 22:36 [bug#36048] [PATCH] guix: import: hackage: handle hackage revisions Robert Vollmert
2019-06-13  2:28 ` Timothy Sample
2019-06-13 16:11   ` Robert Vollmert
2019-06-13 18:09     ` Timothy Sample
2019-06-13 19:40       ` Robert Vollmert [this message]
2019-06-13 16:02 ` Robert Vollmert
2019-06-13 19:39 ` Robert Vollmert
2019-06-14  2:28   ` bug#36048: " Timothy Sample

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=635BD0E2-BADE-4385-8A4C-A3AE36A392BC@vllmrt.net \
    --to=rob@vllmrt.net \
    --cc=36048@debbugs.gnu.org \
    --cc=samplet@ngyro.com \
    /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).