GNU bug report logs - #43159
[PATCH 0/2] Make 'guix help' helpful

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Tue, 1 Sep 2020 20:36:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 43159 <at> debbugs.gnu.org
Subject: [bug#43159] [PATCH 1/2] scripts: Use 'define-command' and have 'guix help' use that.
Date: Sun, 13 Sep 2020 15:03:04 +0200
Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Sorry I couldn't reply faster.

No problem.  I went ahead with this patch series, but nothing’s set in
stone and I’m open to further changes.

> Thanks for the detailed measurements!  It does indeed seem your approach
> is better, especially considering memory usage.  Perhaps the commands
> could have been moved to dedicated modules not using much dependency at
> all so that their closure would have been small hence fast to load, but
> keeping the commands definitions local to where they are useful is
> definitely a nice property.

We can’t really reduce the closure of commands.  In particular, (guix
scripts system) has to load pretty much “everything”.

What we could do is use #:autoload aggressively in the (guix scripts …)
modules, such that startup time would be as small as possible—e.g.,
‘--help’ would not trigger loading of a zillion modules.

It’s a bit tedious though and not necessarily helpful in the general
case where one is doing something non-trivial with the command.  Well
dunno, we could try!

>> In summary, while this approach undoubtedly looks awkward to any Lisper,
>> I think it’s a good way to not contribute to the general impression of
>> sluggishness and resource-hungriness of ‘guix’ commands.  :-)
>>
>>>> +  (define (display-commands commands)
>>>> +    (let* ((names     (map (lambda (command)
>>>> +                             (string-join (command-name command)))
>>>> +                           commands))
>>>> +           (max-width (reduce max 0 (map string-length names))))
>>>
>>> You can drop reduce and use (max (map string-length names)) instead.
>>
>> I could do (apply max (map …)) but I don’t like the idea of abusing
>> variadic argument lists in that way—I know, it’s very subjective.  ;-)
>
> Eh, I wonder why?  I may be missing something, but if max allows it,
> doesn't it mean it's a valid use?  Anyway, just curious to know what are
> the grounds for this personal preference :-).

It’s mostly aesthetic, but it comes from the idea that there could be
limitations on the maximum number of arguments a procedure can take, or
inefficiencies with dealing with many arguments.  Now, in today’s Guile,
there are no such issues…  (And now I look really silly!)  :-)

Ludo’.




This bug report was last modified 4 years and 344 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.