GNU bug report logs -
#68946
[RFC PATCH 0/1] Add logging capability to Guix
Previous Next
Full log
Message #23 received at 68946 <at> debbugs.gnu.org (full text, mbox):
Hi Maxim,
On ven., 16 févr. 2024 at 14:03, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> Most of that code also exists in guile-hall, was released in 2023, hence
> the copyright year start [0].
I think it would be best something like:
--8<---------------cut here---------------start------------->8---
;;; Copyright © 2024 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
;;;
;;; The procedures ’define-log-level', ’setup-logging’ and
;;; ’shutdown-logging’ are taken from the 'hall/logging.scm' file of
;;; Guile-lib (guile-hall). That file has the following copyright
;;; notice:
;;;
;;; Copyright © 2023 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
;;;
;;; This file is part of Guix.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
…
--8<---------------cut here---------------end--------------->8---
> [0] https://gitlab.com/a-sassmannshausen/guile-hall/-/blob/master/hall/logging.scm
>
>>> +(define-syntax define-log-level
>>> + ;; This macro defines a log-level enum type bound to ENUM-NAME for the
>>> + ;; provided levels. The levels should be specified in increasing order of
>>> + ;; severity. It also defines 'log-LEVEL' syntax to more conveniently log at
>>> + ;; LEVEL, with location information.
>>
>> Why not also a docstring?
>
> Only procedures can have docstrings, unfortunately.
Ah? For instance ’define-with-syntax-properties’ or ’define-diagnostic’
or ’leave’ from (guix diagnostics); other instance in (gnu build
accounts) or (gnu build secret-service) etc.
Do I miss something?
>> This make “--log-level debug” valid, right?
>>
>> I think the convention is --long-option[=PARAMETER] and that
>> --long-option PARAMTER is unconventional. Although I do not find the
>> reference.
>
> It's not as much a convention as a limitation of the SRFI 37 option
> parser. GNU getopt, which SRFI 37 aims to emulate, doesn't have such a
> limitation, for example. We should improve SRFI 37 to lift such
> limitation, in my opinion.
I think that’s a bad choice. For two reasons,
1. Let’s keep an uniform across subcommands
2. It potentially opens bug as #50472; no space avoids ambiguous
implementations as explained. :-)
https://issues.guix.gnu.org/issue/50472
Cheers,
simon]
This bug report was last modified 209 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.