From: Ricardo Wurmus <rekado@elephly.net>
To: Hartmut Goebel <h.goebel@crazy-compilers.com>
Cc: guix-devel@gnu.org
Subject: Re: All updaters are broken
Date: Mon, 02 Jan 2023 20:17:05 +0100 [thread overview]
Message-ID: <87wn644u9y.fsf@elephly.net> (raw)
In-Reply-To: <dd64edde-90c9-d2fd-f150-498c09f24957@crazy-compilers.com>
Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
> Hello Ricardo,
>
> Am 02.01.23 um 14:16 schrieb Ricardo Wurmus:
>> Attached is a crude implementation of that. I just consed the lists
>> together instead of returning multiple values, because the compound
>> value is to be used inside the store monad where we can’t easily access
>> multiple values.
>
> Thanks for providing the patch. For me this looks huge and hard to
> maintain.
“Hard to maintain”? How so?
It’s no larger than your patch. The big diff is due to indentation
changes inside the mlet (as I introduce a “match” to split the compound
value). The actual difference is pretty small.
> I'd rather make "options->update-specs" return update-specs
> in any cases. This adds a small overhead only in the case of
> --recursive.
I think it’s rather inelegant to wrap packages in a structure that we
throw away moments later because we only do the wrapping so that we can
access the wrapped package again — and we *know* the contents already,
so this whole wrapping and unwrapping is just obscuring the purpose.
The overhead is also substantial, because it happens in the worst case:
when no single package is provided, e.g. with “guix refresh -t cran -u”.
This means that *a lot* of packages may get wrapped up and unwrapped
again. Certainly not ideal.
--
Ricardo
next prev parent reply other threads:[~2023-01-02 19:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-31 14:27 All updaters are broken Ricardo Wurmus
2022-12-31 14:36 ` Ricardo Wurmus
2023-01-01 17:54 ` Hartmut Goebel
2023-01-01 23:24 ` Hartmut Goebel
2023-01-02 12:32 ` Ricardo Wurmus
2023-01-02 13:16 ` Ricardo Wurmus
2023-01-02 16:17 ` Hartmut Goebel
2023-01-02 19:17 ` Ricardo Wurmus [this message]
2023-01-02 19:41 ` Hartmut Goebel
2023-01-03 9:16 ` Ricardo Wurmus
2023-01-03 9:49 ` Ludovic Courtès
2023-01-03 18:29 ` Hartmut Goebel
2023-01-03 21:07 ` 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=87wn644u9y.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=guix-devel@gnu.org \
--cc=h.goebel@crazy-compilers.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).