emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#30657: closed (Add support for file-like objects t


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#30657: closed (Add support for file-like objects to the Prosody configuration)
Date: Sat, 03 Mar 2018 17:39:01 +0000

Your message dated Sat, 03 Mar 2018 18:38:22 +0100
with message-id <address@hidden>
and subject line Re: [PATCH] services: messaging: Prosody config supports 
file-like objects.
has caused the debbugs.gnu.org bug report #30657,
regarding Add support for file-like objects to the Prosody configuration
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
30657: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30657
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Add support for file-like objects to the Prosody configuration Date: Wed, 28 Feb 2018 23:25:25 +0100 User-agent: mu4e 1.0; emacs 25.3.1
Hello,

These patches add support for file-like objects to the Prosody service
configuration.  The idea is to replace this mechanism (which is used
very often):

    (plain-file
      (with-output-to-string
         ...
         (format #t ...)
         ...))

with this one:

    (mixed-text-file
      (flatten
        (with-tokens-to-list
           ...
           (push-tokens ...)
           ...))

The point is that tokens don't have to be strings.

Comments are welcome!
Clément



--- End Message ---
--- Begin Message --- Subject: Re: [PATCH] services: messaging: Prosody config supports file-like objects. Date: Sat, 03 Mar 2018 18:38:22 +0100 User-agent: mu4e 1.0; emacs 25.3.1
Ludovic Courtès <address@hidden> writes:

>> +(define (file-like? val)
>> +  (and (struct? val) ((@@ (guix gexp) lookup-compiler) val)))
>
> I’m not fond of the idea of using @@ in real code.  :-)
>
> Could you move ‘file-like?’ to (guix gexp), with a docstring, and with
> ‘->bool’ to avoid exposing internal details:
>
>   (define (file-like? value)
>     (and (struct? value) (->bool (lookup-compiler value))))
>
> ?

I did it.

>> +(define (file-object? val)
>> +  (or (file-like? val) (file-name? val)))
>
> Do we need this predicate?  After all, all we can say is that a file
> name is necessarily a string (or a string-valued gexp), but a string is
> not necessarily a file name (IOW there’s no disjoint type for file
> names.)
>
> I suppose the configuration mechanism needs it though, right?  In that
> context it’s probably OK.

The problem is that the check happens when the user evaluates
(prosody-configuration), which allow them to know right away about type
errors, without running "guix system reconfigure".  So the user doesn't
even need a store.

Plus, not everything should go to the store.  For example, certificate
keys shouldn't, as they are private.  Thus, having both 'file-object?'
and 'file-name?' makes sense to me.

> Apart from this the patch LGTM, thank you!

Pushed as bdcf0e6fd484a54240a98ddf8b6fa433c1b9bd6c, with the
modifications you suggested.

Thank you for the review!
Clément


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]