Hi Ludovic, Ludovic Courtès <[email protected]> writes:
> Hi, > > Maxim Cournoyer <[email protected]> skribis: > >>>> The issue seems to be with the serialization of the >>>> <namespace-configuration> object nested in the <dovecot-configuration> >>>> record. I tried this at the REPL: >>>> >>>> scheme@(guile-user)> ,m (gnu services mail) >>>> scheme@(gnu services mail)> (namespace-configuration (name "inbox")) >>>> $8 = #<<namespace-configuration> name: "inbox" type: "private" >>>> separator: "" prefix: "" location: "" inbox?: #f hidden?: #f >>>> list?: #t subscriptions?: #t mailboxes: () %location: #f> >>>> scheme@(gnu services mail)> (serialize-configuration $8 >>>> namespace-configuration-fields) >>>> name=inbox >>>> type=private >>>> separator= >>>> prefix= >>>> location=#f >>> >>> The location here should probably be empty rather than `#f' no? It looks >>> as though the value is coming from the internal %location, rather than >>> the user-provided location. > > Uh. > >>> I'll if I can find anything the macro, it looks quite complex to me :-). >> >> It's not only to you, if that helps. It's rather... intimidating ^^'. > > [...] > >> Ludovic, would you have an idea of where the %location field or its >> CONFIGURATION-location accessor come into play? > > 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? It seems nowhere. Thus, we can simply rename it without impacting anything, right (except theoretical usages in the wild, since in the API). > With commit 44554e7133aa60e1b453436be1e80394189cabd9, the second one > is the “wrong” one: ‘namespace-configuration-location’ now returns the > ‘%location’ field, not the user-specified ‘location’ field. (I > reported that issue in <https://issues.guix.gnu.org/48284>.) > > What do you think of reverting 44554e7133aa60e1b453436be1e80394189cabd9? No. If we revert something, it won't be that whole commit, but just the moving of the field in the define-configuration produced record. > After that we can work on renaming the ‘location’ field of > <namespace-configuration> while preserving backward compatibility. Why do we have to massage the user facing record (namespace-configuration) instead of the underlying mechanics? The macro should serve us, not the other way around :-). See my idea to simply rename/remove that automatically produced "location" accessor which appears unused to me. Would that work? -- Thanks, Maxim
