unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Pierre Langlois <pierre.langlois@gmx.com>, 59423@debbugs.gnu.org
Subject: bug#59423: Invalid 'location' field generated in dovecot configuration
Date: Mon, 28 Nov 2022 20:58:57 -0500	[thread overview]
Message-ID: <87a64aseqm.fsf@gmail.com> (raw)
In-Reply-To: <8735a2ahmi.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 28 Nov 2022 22:33:57 +0100")

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> We have this:
>>>
>>>          (define-record-type* #,(id #'stem #'< #'stem #'>)
>>>            stem
>>>            #,(id #'stem #'make- #'stem)
>>>            #,(id #'stem #'stem #'?)
>>>            #,@(map (lambda (name getter def)
>>>                      #`(#,name #,getter (default #,def)
>>>                                (sanitize
>>>                                 #,(id #'stem #'validate- #'stem #'- name))))
>>>                    #'(field ...)
>>>                    #'(field-getter ...)
>>>                    #'(field-default ...))
>>>            (%location #,(id #'stem #'stem #'-location)
>>>                       (default (and=> (current-source-location)
>>>                                       source-properties->location))
>>>                       (innate)))
>>>
>>> That generates two accessors called ‘namespace-configuration-location’.
>>> The second one shadows the first one.
>>
>> Yes.  You didn't address my question directly though, so let me ask it
>> again: where is this %location field access (named "location") used?

[...]

> … the field is accessed via its accessor,
> ‘name-configuration-location’.  We can kinda see it here:

[...]

> Each <configuration-field> record has a ‘getter’ field that refers to
> the accessor.  In the case of ‘location’, that’s the “wrong”
> accessor—the accessor of ‘%location’.
>
> I hope that addresses your question!

No :-).  I meant why do we even set a default accessor for the *source
location* information (in the (gnu service configuration) macros); it's
that one that doesn't seem to get used (or I'm blind to it!), at least
via this accessor.  If it's not strictly necessary, we can stop
producing it, and that would solve the problem.

Does that make sense?  I'm not talking about namespace-location; that
one has the right to be!  I'm talking about the auto-generated
x-location or y-location, where x and y are configuration records that
were specified via 'define-configuration'.

[...]

> What would need renaming in this case is the accessor, not the field.
> In <https://issues.guix.gnu.org/48284> you proposed renaming the
> accessor to *-source-location instead of *-location.  That sounds like a
> good idea to me.  We should get unbound-variable warnings in modules
> that use the previous name, so we’ll see if that breaks something.
>
> The only downside is that the convention elsewhere in the code is
> -location, not -source-location.

What about giving it an even more cryptic accessor name like -%location
or dropping it entirely as suggested above?

> So the other option is to rename ‘location’ in
> <namespace-configuration>.  That also has the advantage of being less
> intrusive.

I don't like that alternative, because 'location' seems likely to be
used for future services and reintroduce the same name clash problem.

-- 
Thanks,
Maxim




  reply	other threads:[~2022-11-29  2:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-20 21:53 bug#59423: Invalid 'location' field generated in dovecot configuration Pierre Langlois
2022-11-22  8:10 ` Ludovic Courtès
2022-11-25 15:36   ` Maxim Cournoyer
2022-11-25 20:19     ` Pierre Langlois
2022-11-25 19:17 ` mirai
2022-11-25 20:06 ` Maxim Cournoyer
2022-11-25 20:25   ` Pierre Langlois
2022-11-25 20:50     ` Pierre Langlois
2022-11-25 21:09       ` Pierre Langlois
2022-11-26  2:54         ` Maxim Cournoyer
2022-11-26 19:32           ` Pierre Langlois
2022-11-27  2:33             ` Maxim Cournoyer
2022-11-28 15:01               ` Ludovic Courtès
2022-11-28 20:00                 ` Maxim Cournoyer
2022-11-28 21:33                   ` Ludovic Courtès
2022-11-29  1:58                     ` Maxim Cournoyer [this message]
2022-12-02  9:30                       ` Ludovic Courtès
2022-12-02 21:18                         ` Ludovic Courtès
2022-12-03  3:05                           ` Maxim Cournoyer
2022-12-04 16:53                             ` Ludovic Courtès
2022-12-04 21:43                               ` Maxim Cournoyer
2022-12-06  8:53                                 ` Ludovic Courtès
2022-12-01 20:29                   ` Pierre Langlois
2022-11-26 23:17 ` Fredrik Salomonsson
2022-12-01 21:55 ` Pierre Langlois
2022-12-03  2:24   ` Maxim Cournoyer

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=87a64aseqm.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=59423@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=pierre.langlois@gmx.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).