[bug#57757] gnu: Add sbcl-stumpwm-pamixer

---
 gnu/packages/wm.scm | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
  

On 19-09-2022 19:47, Trevor Richards wrote:
> +      (arguments
> +       `(#:asd-systems '(:pamixer)
> +         #:phases
> +         ,#~(modify-phases %standard-phases
> +             (add-after 'unpack 'patch-pamixer
> +               (lambda _
> +                 (substitute* "pamixer.lisp"
> +                   (("\"pamixer \"")
> +                    (string-append
> +                     "\"" #$pamixer "/bin/pamixer \""))))))))

To support --with-input transformations, you can't do #$input, you have 
to do #$(this-package-input "pamixer") instead -- or better, don't 
depend on input labels, by using (search-input-file inputs 
"bin/pamixer") instead.

Greetings,
Maxime.
  

Maxime Devos <maximedevos@telenet.be> writes:

> On 19-09-2022 19:47, Trevor Richards wrote:
>> +      (arguments
>> +       `(#:asd-systems '(:pamixer)
>> +         #:phases
>> +         ,#~(modify-phases %standard-phases
>> +             (add-after 'unpack 'patch-pamixer
>> +               (lambda _
>> +                 (substitute* "pamixer.lisp"
>> +                   (("\"pamixer \"")
>> +                    (string-append
>> +                     "\"" #$pamixer "/bin/pamixer \""))))))))
>
> To support --with-input transformations, you can't do #$input, you have 
> to do #$(this-package-input "pamixer") instead -- or better, don't 
> depend on input labels, by using (search-input-file inputs 
> "bin/pamixer") instead.
>

Thanks for the feedback. It's hard to tell when a gexp is appropriate
and where it's not, or how to properly evaluate it all at the right
time. The current patch builds. Is this problematic in the sense that
it's using some reference to #$pamixer that is not actually a part of
the build environment?

Note I had to use a quasiqote and unquote for the `gexp` to work.
Transforming the arguments into a list so I would not have to do this
breaks the #:asd-systems keyword value somehow.

When I observe the source code it's kinda all over the place when it
comes to using gexps in some way or when not to.

I will patch this again and document a note about this but if there's
any clarifying documentation I would happily read it. Apologies in
advance if I have missed existing documentation.
  

On 19-09-2022 20:22, Trev wrote:
> Maxime Devos <maximedevos@telenet.be> writes:
> 
>> On 19-09-2022 19:47, Trevor Richards wrote:
>>> +      (arguments
>>> +       `(#:asd-systems '(:pamixer)
>>> +         #:phases
>>> +         ,#~(modify-phases %standard-phases
>>> +             (add-after 'unpack 'patch-pamixer
>>> +               (lambda _
>>> +                 (substitute* "pamixer.lisp"
>>> +                   (("\"pamixer \"")
>>> +                    (string-append
>>> +                     "\"" #$pamixer "/bin/pamixer \""))))))))
>>
>> To support --with-input transformations, you can't do #$input, you have
>> to do #$(this-package-input "pamixer") instead -- or better, don't
>> depend on input labels, by using (search-input-file inputs
>> "bin/pamixer") instead.
>>
> 
> Thanks for the feedback. It's hard to tell when a gexp is appropriate
> and where it's not, or how to properly evaluate it all at the right
> time. The current patch builds. Is this problematic in the sense that
> it's using some reference to #$pamixer that is not actually a part of
> the build environment?

It is inappropriate in the sense that '--with-input' rewrites the 
'inputs', 'native-inputs' and 'propagated-inputs' fields, but not the 
contents of the G-exp.

> Note I had to use a quasiqote and unquote for the `gexp` to work.
> Transforming the arguments into a list so I would not have to do this
> breaks the #:asd-systems keyword value somehow.

How about:

(arguments
   (list #:asd-systems ''(:pa-mixers)
         #:phases
         #~(modify-phases [...])))

(i.e., you are removing a layer of quoting by turning the quasiquote 
into a quote, so it needs to be readded for the #:asd-systems).

> 
> When I observe the source code it's kinda all over the place when it
> comes to using gexps in some way or when not to.
> 
> I will patch this again and document a note about this but if there's
> any clarifying documentation I would happily read it. Apologies in
> advance if I have missed existing documentation.

I'm not aware of any, though I'd like to note that G-exps are new-ish 
and hence the 'all over the place' is more "guix style doesn't know how 
to transform this kind of old thing yet" than "we chose for s-exps 
instead of G-exps".

Greetings,
Maxime.
  

Maxime Devos <maximedevos@telenet.be> writes:

> On 19-09-2022 20:22, Trev wrote:
>> Maxime Devos <maximedevos@telenet.be> writes:
>> 
>>> On 19-09-2022 19:47, Trevor Richards wrote:
>>>> +      (arguments
>>>> +       `(#:asd-systems '(:pamixer)
>>>> +         #:phases
>>>> +         ,#~(modify-phases %standard-phases
>>>> +             (add-after 'unpack 'patch-pamixer
>>>> +               (lambda _
>>>> +                 (substitute* "pamixer.lisp"
>>>> +                   (("\"pamixer \"")
>>>> +                    (string-append
>>>> +                     "\"" #$pamixer "/bin/pamixer \""))))))))
>>>
>>> To support --with-input transformations, you can't do #$input, you have
>>> to do #$(this-package-input "pamixer") instead -- or better, don't
>>> depend on input labels, by using (search-input-file inputs
>>> "bin/pamixer") instead.
>>>
>> 
>> Thanks for the feedback. It's hard to tell when a gexp is appropriate
>> and where it's not, or how to properly evaluate it all at the right
>> time. The current patch builds. Is this problematic in the sense that
>> it's using some reference to #$pamixer that is not actually a part of
>> the build environment?
>
> It is inappropriate in the sense that '--with-input' rewrites the 
> 'inputs', 'native-inputs' and 'propagated-inputs' fields, but not the 
> contents of the G-exp.
>

I see.  I am not yet familiar with the --with-input flag.  I will
explore this feature, thank you.

>> Note I had to use a quasiqote and unquote for the `gexp` to work.
>> Transforming the arguments into a list so I would not have to do this
>> breaks the #:asd-systems keyword value somehow.
>
> How about:
>
> (arguments
>    (list #:asd-systems ''(:pa-mixers)
>          #:phases
>          #~(modify-phases [...])))
>
> (i.e., you are removing a layer of quoting by turning the quasiquote 
> into a quote, so it needs to be readded for the #:asd-systems).
>

I see a double-quote there with ~''(:pamixer)~ - which is not something
I have ever tried to do before.  Is this a typo?

I had tried (list #:asd-systems '(:pamixer) #:phases #~([...])) and the
build failed due '(:pamixer) somehow not returning anything from a (car)
function.

Sometimes errors elsewhere cause nebulous tracebacks.  I will try this again.

>> 
>> When I observe the source code it's kinda all over the place when it
>> comes to using gexps in some way or when not to.
>> 
>> I will patch this again and document a note about this but if there's
>> any clarifying documentation I would happily read it. Apologies in
>> advance if I have missed existing documentation.
>
> I'm not aware of any, though I'd like to note that G-exps are new-ish 
> and hence the 'all over the place' is more "guix style doesn't know how 
> to transform this kind of old thing yet" than "we chose for s-exps 
> instead of G-exps".

I like the new way of using gexps.  They are more terse than needing to
assoc reference inputs/outputs.  The thought of as slow transition
happening had occured to me.  I appreciate your insight.
  

On 19-09-2022 23:34, Trev wrote:
>> (arguments
>>     (list #:asd-systems ''(:pa-mixers)
>>           #:phases
>>           #~(modify-phases [...])))
>>
>> (i.e., you are removing a layer of quoting by turning the quasiquote
>> into a quote, so it needs to be readded for the #:asd-systems).
>>
> I see a double-quote there with ~''(:pamixer)~ - which is not something
> I have ever tried to do before.  Is this a typo?

No, it's intentional -- if you do '(:pa-mixers), the code (:pa-mixers) 
is passed to the builder, but that can't work, as :pa-mixers is 
undefined (or a keyword, depending on how the Guile reader is 
configured).  If you do ''(:pa-mixers), the code '(:pa-mixers) is passed 
to the builder, as intended.

If you change ''(:pa-mixers) to '(pa-mixers), then I expect you'll get a 
build failure.

Greetings,
Maxime.
  

Maxime Devos <maximedevos@telenet.be> writes:

> On 19-09-2022 23:34, Trev wrote:
>>> (arguments
>>>     (list #:asd-systems ''(:pa-mixers)
>>>           #:phases
>>>           #~(modify-phases [...])))
>>>
>>> (i.e., you are removing a layer of quoting by turning the quasiquote
>>> into a quote, so it needs to be readded for the #:asd-systems).
>>>
>> I see a double-quote there with ~''(:pamixer)~ - which is not something
>> I have ever tried to do before.  Is this a typo?
>
> No, it's intentional -- if you do '(:pa-mixers), the code (:pa-mixers) 
> is passed to the builder, but that can't work, as :pa-mixers is 
> undefined (or a keyword, depending on how the Guile reader is 
> configured).  If you do ''(:pa-mixers), the code '(:pa-mixers) is passed 
> to the builder, as intended.
>
> If you change ''(:pa-mixers) to '(pa-mixers), then I expect you'll get a 
> build failure.
>

I feel a little silly because after I asked my question I went ahead and
ran a ripgrep on the project root for a pattern of ''( and found
numerous occurences of it.  Of course it failed without the double
quote.

Thanks for all of your helpful feedback.  I have made notes so that I
can recall these concepts later.