Re: GNU Guix maintainer rotation
Welcome Efraim ! Best wishes for the duty. Thank you Ludo' and Marius ! Enjoy the free time Really hope I will still be able to trade a 'hi' in the IRC on my rare connections. haha Jérémy OpenPGP_0x700F5E0CCBB2E2D1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
GNU Guix maintainer rotation
Hello Guix! I'd like to bring your attention to a change to the current Guix maintainers collective; in a nutshell, Ludovic and Marius are stepping down from maintainer-ship while Efraim is joining. I won't write more as you can find all the details in this blog post: https://guix.gnu.org/en/blog/2022/gnu-guix-maintainer-rotation/. Many thanks to Ludovic and Marius for their past roles as Guix co-maintainers, and a warm welcome to Efraim! Happy hacking! Maxim
Re: What happened to gfortran-toolchain?
> Could this hidden-package form be the culprit here? Was hiding gfortran > an intentional change to Guix System, or was this an accident? If the > former, what is the current recommended approach for Fortran programming > on Guix? Just came across this commit which was made about an hour before your message: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=af1b5de6d8a54439ef3f7e1f5fe9a8e7d109972d Does that fix the problem for you? Cheers, Remco
emacs-shroud package appears to be out of date
Hi Guix, During my recent `guix pull` + `guix package -u` adventure, the emacs-shroud package barfed due to what looks like a hard-coded reference to an older version of gnupg. I uninstalled it in order to complete my upgrade. Of course, when I try to reinstall it now, I continue to get the same version conflict error due to gnupg. ``` gjohnson@euclid ~ $ guix package -i emacs-shroud The following package will be installed: emacs-shroud 1.105 guix package: error: profile contains conflicting entries for gnupg guix package: error: first entry: gnupg@2.2.30 /gnu/store/0snfzd41n430ddpq316j9v2z5fn2y62m-gnupg-2.2.30 guix package: error:... propagated from emacs-shroud@1.105 guix package: error: second entry: gnupg@2.2.32 /gnu/store/75122spwjdkxxgd32gkkil3n7ifax8i5-gnupg-2.2.32 guix package: error:... propagated from emacs-pinentry@0.1-1.dcc9ba0 hint: Try upgrading both `emacs-shroud' and `emacs-pinentry', or remove one of them from the profile. ``` Note, that while the above error message is complaining about emacs-pinentry, it still barfs even if I remove emacs-pinentry and just install gnupg directly since the current gnupg is 2.2.32. Can whoever is maintaining the emacs-shroud package please update it to gnupg@2.2.32, so it can be installed again? Thanks, Gary -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org === () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Why is HTML email a security nightmare? See https://useplaintext.email/ Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
What happened to gfortran-toolchain?
Hi Guix,
I finally got around to running `guix pull` and `guix package -u` on my
system now that the holidays are over, and I got a notification that
the gfortran-toolchain package had been removed. Sure enough, running
`guix package -s gfortran-toolchain` and even `guix package -s gfortran`
return no results at all.
After a bit of digging, I managed to track down the gfortran-toolchain
package definition to gnu/packages/commencement.scm, where it looks
perfectly normal to me.
```
(define-public gfortran-toolchain
(package (inherit (make-gcc-toolchain gfortran))
(synopsis "Complete GCC tool chain for Fortran development")
(description "This package provides a complete GCC tool chain for
Fortran development to be installed in user profiles. This includes
gfortran, as well as libc (headers and binaries, plus debugging symbols
in the @code{debug} output), and binutils.")))
```
However, when I follow its reference to the
gfortran package over to gnu/packages/gcc.scm, I see this:
```
(define-public gfortran
(hidden-package
(custom-gcc gcc
"gfortran" '("fortran")
%generic-search-paths)))
```
Could this hidden-package form be the culprit here? Was hiding gfortran
an intentional change to Guix System, or was this an accident? If the
former, what is the current recommended approach for Fortran programming
on Guix?
Thanks,
Gary
--
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
===
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Why is HTML email a security nightmare? See https://useplaintext.email/
Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Re: Help needed with substitute* command
Thanks for the detailed explanation Tobias. Guess I need to brush up on
regular expressions.
Mortimer
On Thu, Jan 6, 2022 at 9:43 AM Tobias Geerinckx-Rice wrote:
> Hullo Mortimer,
>
> I hope this answer isn't too basic for you. This input:
>
> Mortimer Cladwell 写道：
> > ---input.txt(2)---
> > foo(abc)bar(def)
>
> does not match the extended regular expression:
>
> > "foo([a-z]+)bar(.*)$"
>
> This would:
>
> ---input.txt(3)---
> foolishbarista
>
> result: bazlishista
>
> I'm not the one to either write or recommend a tutorial on
> extended regular expressions, but you'll find plenty on the 'net.
> There's also ‘info (grep)Regular Expressions’ which might be good.
> These things aren't specific to Guile, although a few dialects
> exist, and I think Guile uses the POSIX one. The differences are
> quite small.
>
> In this specific example
>
> > ("foo([a-z]+)bar(.*)$" all letters end)
>
> the first string is an extended regular expression.
>
> It will match a literal ‘foo’ anywhere on a line, followed by 1 or
> more lowercase letters, followed by a literal ‘bar’, followed by
> anything until the end of the line.
>
> It will NOT match anything with ‘()’ brackets in it, like your
> original input.txt(2). The brackets are regexp syntax used for
> grouping and capturing.
>
> If an optional variable name follows the regexp, it will be set to
> the complete match. Here, that is ‘all’, which in our example
> will contain "foolishbarista". It's not used here.
>
> In practice, this variable would be named ‘_’ to indicate that
> it's unimportant:
>
> (("foo([a-z]+)bar(.*)$" _ letters end)
>(string-append "baz" letters end))
>
> but the author of the manual example thought that ‘all’ would be
> more clear.
>
> Each subsequent optional variable will be set to the content
> matched by () groups. Here, ‘letters’ will be set to whatever
> matched ‘[a-z]+’, and ‘end’ to whatever matched ‘.*’.
>
> In our example ‘letters’ is "lish" and ‘end’ is "ista".
>
> This is powerful, because we can construct arbitrary strings at
> run time based that can differ significantly for each line that
> matches the same regexp:
>
> > (string-append "baz" letter end)
>
> is just Scheme code that uses the captured variables above,
> without hard-coding assumptions about what was matched.
>
> footbarnacles → baztnacles
> foodiebarmaid → bazdiemaid
> …
>
> Minutes of fun.
>
> This special meaning of ‘()’ in extended rexeps means that if you
> would want to match:
>
> ---input.txt(4)---
> fo(bizzle)
>
> you'd write:
>
> "fo\\(bizzle\\)"
>
> Because "\" in a string *also* has special meaning to Guile
> itself, we have to write "\\(" if we want the regexp engine to see
> "\(".
>
> > Is the letters/letter in the manual a typo? If I use letter I
> > get
> > "...unbound variable..."
>
> Yes, that was a typo, both names should match. I've fixed it.
> Thanks for apparently being the first to test this snippet!
>
> Kind regards,
>
> T G-R
>
Re: Help needed with substitute* command
Hullo Mortimer,
I hope this answer isn't too basic for you. This input:
Mortimer Cladwell 写道：
---input.txt(2)---
foo(abc)bar(def)
does not match the extended regular expression:
"foo([a-z]+)bar(.*)$"
This would:
---input.txt(3)---
foolishbarista
result: bazlishista
I'm not the one to either write or recommend a tutorial on
extended regular expressions, but you'll find plenty on the 'net.
There's also ‘info (grep)Regular Expressions’ which might be good.
These things aren't specific to Guile, although a few dialects
exist, and I think Guile uses the POSIX one. The differences are
quite small.
In this specific example
("foo([a-z]+)bar(.*)$" all letters end)
the first string is an extended regular expression.
It will match a literal ‘foo’ anywhere on a line, followed by 1 or
more lowercase letters, followed by a literal ‘bar’, followed by
anything until the end of the line.
It will NOT match anything with ‘()’ brackets in it, like your
original input.txt(2). The brackets are regexp syntax used for
grouping and capturing.
If an optional variable name follows the regexp, it will be set to
the complete match. Here, that is ‘all’, which in our example
will contain "foolishbarista". It's not used here.
In practice, this variable would be named ‘_’ to indicate that
it's unimportant:
(("foo([a-z]+)bar(.*)$" _ letters end)
(string-append "baz" letters end))
but the author of the manual example thought that ‘all’ would be
more clear.
Each subsequent optional variable will be set to the content
matched by () groups. Here, ‘letters’ will be set to whatever
matched ‘[a-z]+’, and ‘end’ to whatever matched ‘.*’.
In our example ‘letters’ is "lish" and ‘end’ is "ista".
This is powerful, because we can construct arbitrary strings at
run time based that can differ significantly for each line that
matches the same regexp:
(string-append "baz" letter end)
is just Scheme code that uses the captured variables above,
without hard-coding assumptions about what was matched.
footbarnacles → baztnacles
foodiebarmaid → bazdiemaid
…
Minutes of fun.
This special meaning of ‘()’ in extended rexeps means that if you
would want to match:
---input.txt(4)---
fo(bizzle)
you'd write:
"fo\\(bizzle\\)"
Because "\" in a string *also* has special meaning to Guile
itself, we have to write "\\(" if we want the regexp engine to see
"\(".
Is the letters/letter in the manual a typo? If I use letter I
get
"...unbound variable..."
Yes, that was a typo, both names should match. I've fixed it.
Thanks for apparently being the first to test this snippet!
Kind regards,
T G-R
signature.asc
Description: PGP signature
Help needed with substitute* command
Hi,
I do not understand the second substitute* example in the Guix Manual.
I have the executable mysubs.scm:
--mysubs.scm-
(add-to-load-path
"/gnu/store/rjzj1z89jqcb60nhg5gknkibcl84b3jb-guix-29745d23b-modules/share/guile/site/3.0")
(add-to-load-path ".")
(use-modules
(guix build utils)
(ice-9 rdelim)
(ice-9 popen)
(ice-9 regex) ;;list-matches
(ice-9 pretty-print))
(define (main args)
(begin
(substitute* "./input.txt"
(("hello")
"good morning\n")
(("foo([a-z]+)bar(.*)$" all letters end)
(string-append "baz" letters end
(pretty-print "done"))
-end
I run this on 2 different inputs representing the two examples in the
manual:
---input.txt(1)--
hello
-
result: good morning
---input.txt(2)---
foo(abc)bar(def)
---
result: foo(abc)bar(def)
Why no substitution with the second example?
Is the letters/letter in the manual a typo? If I use letter I get
"...unbound variable..."
Thanks
Mortimer
