diff mbox series

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

Message ID eac2dee14619f97f9064c3c87c37f3f2f806b8dc.1663608658.git.trev@trevdev.ca
State Accepted
Headers show
Series [bug#57757] gnu: Add sbcl-stumpwm-pamixer | expand

Checks

Context Check Description
cbaines/comparison success View comparision
cbaines/git-branch success View Git branch
cbaines/applying patch success View Laminar job
cbaines/issue success View issue

Commit Message

Trevor Richards Sept. 19, 2022, 5:47 p.m. UTC
---
 gnu/packages/wm.scm | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

Comments

M Sept. 19, 2022, 6:05 p.m. UTC | #1
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.
Trevor Richards Sept. 19, 2022, 6:22 p.m. UTC | #2
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.
M Sept. 19, 2022, 6:33 p.m. UTC | #3
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.
Trevor Richards Sept. 19, 2022, 9:34 p.m. UTC | #4
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.
M Sept. 22, 2022, 7:08 p.m. UTC | #5
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.
Trevor Richards Sept. 22, 2022, 8:35 p.m. UTC | #6
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.
diff mbox series

Patch

diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index 451dfce516..dd1e81544f 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -1986,6 +1986,40 @@  (define-public stumpish
     (description "This package provides a StumpWM interactive shell.")
     (license (list license:gpl2+ license:gpl3+ license:bsd-2))))
 
+(define-public sbcl-stumpwm-pamixer
+  (let ((commit "aa820533c80ea1af5a0e107cea25eaf34e69dc24")
+        (revision "1"))
+    (package
+      (name "sbcl-stumpwm-pamixer")
+      (version (git-version "0.1.1" revision commit))
+      (source (origin
+                (method git-fetch)
+                (uri (git-reference
+                      (url "https://github.com/Junker/stumpwm-pamixer")
+                      (commit commit)))
+                (file-name (git-file-name name version))
+                (sha256
+                 (base32
+                  "0djcrr16bx40l7b60d4j507vk5l42fdgmjpgrnk86z1ba8wlqim8"))))
+      (inputs (list `(,stumpwm "lib")
+                    pamixer))
+      (build-system asdf-build-system/sbcl)
+      (arguments
+       `(#:asd-systems '(:pamixer)
+         #:phases
+         ,#~(modify-phases %standard-phases
+             (add-after 'unpack 'patch-pamixer
+               (lambda _
+                 (substitute* "pamixer.lisp"
+                   (("\"pamixer \"")
+                    (string-append
+                     "\"" #$pamixer "/bin/pamixer \""))))))))
+      (home-page "https://github.com/Junker/stumpwm-pamixer")
+      (synopsis "StumpWM Pamixer Module")
+      (description "Minimalistic Pulseaudio volume and microphone control
+module for StumpWM.")
+      (license license:gpl3))))
+
 (define-public sbcl-stumpwm+slynk
   (deprecated-package "sbcl-stumpwm-with-slynk" stumpwm+slynk))