Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

[Development of GNU Guix and the GNU System distribution.]

2021 m. sausio 6 d., trečiadienis 11:32:48 GMT Ludovic Courtès rašė:
> Hi!
> 
> Jan Nieuwenhuizen  skribis:
> 
> > I have reset Guix' wip-full-source-bootstrap branch with a first working
> > implementation of the, well, "Full Source Bootstrap" for x86-linux (and
> > x86_64-linux).  This bootstrap is rooted in the 357-byte hex0-seed from
> > the Stage0 project (https://savannah.gnu.org/projects/stage0):
> >
> > $ ./pre-inst-env guix build hello --verbosity=1
> > [..]
> > /gnu/store/w61gf93yn2bxwyc6d1xp4y9lavvw1l3d-hello-2.10
> > 17:58:54 janneke@dundal:~/src/guix/wip-fsb [env]
> 
> This is amazing!  Incredible.  Thumbs up!
> 
> (BTW, you recently worked on the secret service¹, and now the
> FSB—coincidence?)
> 
> ¹ 
> https://git.savannah.gnu.org/cgit/guix.git/commit?id=ec32d4f291b3cc039a99f8090b6c2b2444be5a83
> 
> > When you look at the bottom of the graph (see attached), you will notice
> > "%bootstrap-guile": the driver that we use for the Guix build and also
> > for "bootar", "gash", and "gash-utils".  This "%bootstrap-guile" is not
> > used as a seed in anything that is built, "%bootstrap-guile", "bootar",
> > "gash", and "gash-utils" could be replaced with any other driver.
> 
> Longer-term, could bootar, Gash, etc. run on Mes?  Would that help?

I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2 
branch)
is trying to achieve.

Outside of Guix we are working on bootstrap that does not depend on guile driver
and is driven only by hex-0 seed (357 bytes) kaem-optional-seed (737 bytes) and 
any POSIX
kernel.

At the moment it goes all the way up to Mes (tcc is now in progress).

Andrius

[1] https://github.com/oriansj/mes-m2

> 
> > Two new packages are added: "bootstrap-seeds", which contains the
> > hex0-seed binary
> > (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0-seed)
> > with ASCII-equivalent
> > (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0),
> > and "m2-planet-boot" which, starting from hex0, via hex1, M0, hex2 and
> > M1, bootstraps the M2-Planet transpiler.  M2 is a language that closely
> > resembles a subset of C.
> >
> > The breakthrough is that this M2-Planet can now compile a version of GNU
> > Mes, as yet unreleased: the wip-m2 branch.  This removes the remaining
> > binary seeds: %bootstrap-mescc-tools and %bootstrap-mes, together with
> > the "%bootstrap-mes-rewired" hack.
> 
> Woow.  I’m willing to take a closer look at all this, this is
> impressive!
> 
> > Apart from a review there is still some work before it can be
> > integrated, in short (from the top commit message):
> >
> > XXX TODO:
> >* wip-full-source-bootstrap
> >  - release mes-0.24, update
> >  - possibly release m2-planet-1.8.0, update
> >  - rebase wip-full-source-bootstrap onto core-updates
> >  - integrate
> 
> All this should be piece of cake compared to what you’ve gone through.
> ;-)  But it does mean long rebuild cycles, which I guess can be tiring.
> 
> >* wip-arm-bootstrap
> >  - finish; currently stuck on gawk-mesboot0
> >  - release mes-0.23
> >  - devise strategy for integrating wip-full-source-bootstrap and
> >wip-arm-bootstrap
> 
> Ah, that’s the second big challenge!
> 
> Congratulations to you and everyone involved for going this far!
> You made it!
> 
> Ludo’.
> 
> 

signature.asc
Description: This is a digitally signed message part.

Re: [bootstrappable] wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

[Paul Sherwood]

On 2021-01-04 17:01, Jan Nieuwenhuizen wrote:
I have reset Guix' wip-full-source-bootstrap branch with a first 
working

implementation of the, well, "Full Source Bootstrap" for x86-linux (and
x86_64-linux).  This bootstrap is rooted in the 357-byte hex0-seed from
the Stage0 project (https://savannah.gnu.org/projects/stage0):


This is really exciting, great job Jan! Do you need any help, e.g. on 
the ARM side, or with optimising the integration?

Re: Staging branch [aarch64 failures]

[Leo Famulari]

On Wed, Jan 06, 2021 at 11:38:17AM +0100, Stefan wrote:
> Hi Leo!
> 
> > "while setting up the build environment: executing 
> > `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No 
> > such 
> > file or directory"
> > 
> > Does anybody have advice?
> 
> I have the same problem. See  for a 
> workaround.

Thanks for pointing this out. It does seem to be a similar issue.

Re: 02/05: gnu: libmad: Install pkg-config file.

[Kei Kebreau]

Ludovic Courtès  writes:

> Hi Kei,
>
> Perhaps we can keep the .pc file for libmad, adding a comment mentioning
> what you wrote above, but remove it in those cases where it’s not needed
> (as in: not required by Audacity & co., and not done in other distros)?
>
> Thanks,
> Ludo’.

This sounds good to me.  I take this message as permission to push some
changes with those comments?


signature.asc
Description: PGP signature

Re: [RFC] Improve Python package quality

[Hartmut Goebel]

Am 05.01.21 um 11:48 schrieb Vincent Legoll:
> That is better, but the separate file would allow to have proper
> syntax highlighting, allow linting/pep8'ing, etc.

Probably not worth the effort for trying to put this into a separate file.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: ZFS on Guix

[raid5atemyhomework]

Latest patchset: https://issues.guix.gnu.org/45692

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
> Hi Tanguy,
> 
>> So, I've tried packaging `python-keyring` with those two…
>> 
>> `pep517` keeps on trying to download dependencies, which won't work.
>> 
>> `build` crashes with "ZIP does not support timestamps before 1980",
>> which, I guess is related to the fact that everything in the store is
>> timestamped to January 1st 1970.
> have you been looking into a python-build-system using `build`[1]? I’ve
> had the same issue with egg versions set to 0.0.0 and think in the long
> run moving to a PEP 517-style build is the way forward.

Actually —and I almost forgot!—, Sébastien found a solution to our "0.0.0" 
problem:
https://github.com/jaraco/keyring/issues/469#issuecomment-735695476

-- 
Tanguy

Re: Questions regarding Python packaging

[Tanguy LE CARROUR]

Hi Lars,


Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
> Hi Tanguy,
> 
>> So, I've tried packaging `python-keyring` with those two…
>> 
>> `pep517` keeps on trying to download dependencies, which won't work.
>> 
>> `build` crashes with "ZIP does not support timestamps before 1980",
>> which, I guess is related to the fact that everything in the store is
>> timestamped to January 1st 1970.
> have you been looking into a python-build-system using `build`[1]? I’ve
> had the same issue with egg versions set to 0.0.0 and think in the long
> run moving to a PEP 517-style build is the way forward.

I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(

I'll revive the thread as soon as I've made progress…

Regards!

-- 
Tanguy

RE: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

[Orians, Jeremiah (DTMB)]

> I think that's what mes-m2 rewrite [1] (not to be confused with mes wip-m2 
> branch) is trying to achieve.
My fault for that confusion. Wish I was faster at implementing syntax-case in C 
-_-

> Outside of Guix we are working on bootstrap that does not depend on guile 
> driver and is driven only by hex-0 seed (357 bytes) kaem-optional-seed (737 
> bytes) and any POSIX kernel.
We love it ^_^

> At the moment it goes all the way up to Mes (tcc is now in progress).
Eternal progress

Oh and we are currently joking about replacing mes.c with a scheme written in 
Haskell because we bootstrapped a minimal Haskell too.
https://github.com/oriansj/blynn-compiler/

Then the loop would be:
a scheme interpreter written in Haskell 
running 
a C compiler written in scheme 
that can build 
the Haskell compiler able to build the original scheme interpreter.

If we get it to enough guile compatibility; then it becomes:
once you have Gnu Mes, you are already bootstrapped. 

^_^

- Jeremiah

Re: [bootstrappable] wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> I have reset Guix' wip-full-source-bootstrap branch with a first working
> implementation of the, well, "Full Source Bootstrap" for x86-linux (and
> x86_64-linux).  This bootstrap is rooted in the 357-byte hex0-seed from
> the Stage0 project (https://savannah.gnu.org/projects/stage0):
>
> $ ./pre-inst-env guix build hello --verbosity=1
> [..]
> /gnu/store/w61gf93yn2bxwyc6d1xp4y9lavvw1l3d-hello-2.10
> 17:58:54 janneke@dundal:~/src/guix/wip-fsb [env]

This is amazing!  Incredible.  Thumbs up!

(BTW, you recently worked on the secret service¹, and now the
FSB—coincidence?)

¹ 
https://git.savannah.gnu.org/cgit/guix.git/commit?id=ec32d4f291b3cc039a99f8090b6c2b2444be5a83

> When you look at the bottom of the graph (see attached), you will notice
> "%bootstrap-guile": the driver that we use for the Guix build and also
> for "bootar", "gash", and "gash-utils".  This "%bootstrap-guile" is not
> used as a seed in anything that is built, "%bootstrap-guile", "bootar",
> "gash", and "gash-utils" could be replaced with any other driver.

Longer-term, could bootar, Gash, etc. run on Mes?  Would that help?

> Two new packages are added: "bootstrap-seeds", which contains the
> hex0-seed binary
> (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0-seed)
> with ASCII-equivalent
> (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0),
> and "m2-planet-boot" which, starting from hex0, via hex1, M0, hex2 and
> M1, bootstraps the M2-Planet transpiler.  M2 is a language that closely
> resembles a subset of C.
>
> The breakthrough is that this M2-Planet can now compile a version of GNU
> Mes, as yet unreleased: the wip-m2 branch.  This removes the remaining
> binary seeds: %bootstrap-mescc-tools and %bootstrap-mes, together with
> the "%bootstrap-mes-rewired" hack.

Woow.  I’m willing to take a closer look at all this, this is
impressive!

> Apart from a review there is still some work before it can be
> integrated, in short (from the top commit message):
>
> XXX TODO:
>* wip-full-source-bootstrap
>  - release mes-0.24, update
>  - possibly release m2-planet-1.8.0, update
>  - rebase wip-full-source-bootstrap onto core-updates
>  - integrate

All this should be piece of cake compared to what you’ve gone through.
;-)  But it does mean long rebuild cycles, which I guess can be tiring.

>* wip-arm-bootstrap
>  - finish; currently stuck on gawk-mesboot0
>  - release mes-0.23
>  - devise strategy for integrating wip-full-source-bootstrap and
>wip-arm-bootstrap

Ah, that’s the second big challenge!

Congratulations to you and everyone involved for going this far!
You made it!

Ludo’.

Re: 02/05: gnu: libmad: Install pkg-config file.

[Ludovic Courtès]

Hi Kei,

Kei  skribis:

>> It seems to me that we shouldn’t provide .pc files if upstream doesn’t
>> do it.  The main reason is that developers who use Guix will come to
>> rely on it and unknowingly write code that doesn’t work on other
>> distros.  (I remember pestering in the past as I stumbled upon packages
>> who depended on some library as packaged by a specific distro.  :-))
>> 
>> WDYT?
>> 
>> Apologies if I missed an earlier discussion!
>
> No apologies needed, the discussion was minimal at best.  This patch is the
> result of my yielding to the forces of incompatibility you mention.  Major
> distributions like Debian, Arch Linux [1], and Fedora [2] have all added pkg-
> config files for (at least) libmad.  Audacity expects to find pkg-config files
> for the system libraries it uses, so I supplied those to follow the path of
> least resistance.

Ah, that makes sense; it’s a case where I think it’s OK to follow the
majority.

Perhaps we can keep the .pc file for libmad, adding a comment mentioning
what you wrote above, but remove it in those cases where it’s not needed
(as in: not required by Audacity & co., and not done in other distros)?

Thanks,
Ludo’.

Re: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[raingloom]

On Mon, 07 Dec 2020 05:51:05 +0900
yasu  wrote:

> Hi Zimoun,
> 
> I tried as you suggested but it didn't work...
> 
> 
>root@guix ~# echo "kernel.unprivileged_userns_clone = 1" >
>/etc/sysctl.d/local.conf
>-bash: /etc/sysctl.d/local.conf: No such file or directory

This could mean you have to create the sysctl.d directory.
Try running this:
```
# mkdir -p /etc/sysctl.d/
# echo "kernel.unprivileged_userns_clone = 1" > /etc/sysctl.d/local.conf
```

Re: Guile 2.0 in make-bootstrap.scm

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello Ludo!
>
> While uploading the powerpc64le-linux tarballs, I noticed they use Guile
> 2.0, which reminded me of eef44fea17a735d2f4048a747d16af478d4b9dbc:
>
> Revert "gnu: guile-static-stripped: Update to 2.2."
> 
> As discussed on IRC, keeping bootstrap Guile on 2.0 simplifies adding new
> architectures and removes the need for parameterizing
> gnu/packages/bootstrap.scm.
> 
> This reverts commit 2acfe022a740f79b593348cc6362cc4ee8f33bb4.
> 
> * gnu/packages/make-bootstrap.scm (%guile-static): Revert to guile-2.0.  
> Retain
> build recipe.
> * gnu/packages/patches/guile-relocatable.patch: Update for Guile 2.0.14.
>
> Do you remember the reason for this change?

I remember we hesitated gratuitously updating the %bootstrap-guile seed
(to 2.2) and decided to try to "make it work without updating the guile
seed".

I am not 100% sure, we'd have to look up the IRC discussions.

> What’s surprising is that
>  does use
> 2.2.

Oh, that's weird.  Well, we used gule-2.2 until almost the very last
moment, I remember.  I am cc'ing Timothy, as he helped make the
guile-2.0 bootstrap possible (gash compatibility and such).

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Staging branch [aarch64 failures]

[Stefan]

Hi Leo!

> "while setting up the build environment: executing 
> `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such 
> file or directory"
> 
> Does anybody have advice?


I have the same problem. See  for a 
workaround.


Bye

Stefan

Re: Specify substitute url in GUI installer

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> However, it's sad that there's no option for user to specify substitute
>> url in GUI installer of Guix ISO. It means that people new to Guix still
>> have to tolerate the slow connection during the installation.
>>
>> Can we add such option for GUI installer?
>
> Adding such an option shouldn't be too hard, as there's already the
> possibility to add an HTTP mirror from the parameters menu.
>
> The problem is to authorize the substitute server. I don't think it's
> reasonable to ask the user to enter the server public key manually. An
> option would be to fetch the public key from
> "https://the-substitute-sever/signing-key.pub;, display it, and propose
> the user to authorize or not this server.

That looks reasonable to me.

We should make sure most common use cases don’t end up going through too
many extra dialog boxes though.

Thanks,
Ludo’.

Re: Identical files across subsequent package revisions

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> It could go along these lines:
>
>   1. GET /digest/xyz-emacs; the digest contains a list of file/hash
>  pairs essentially;
>
>   2. traverse digest and hardlink the files already in /gnu/store/.links
>  to the target directory;
>
>   3. pipeline-GET the remaining files and install them.
>
> Like you write, since we already have deduplication, part of it comes
> for free.

I prototyped that during the holidays and pushed the result as
‘wip-digests’ (rough on the edges!).

It works essentially as written above.  ‘guix substitute’ fetches
digests at the same time as it fetches narinfos so it can keep them in
cache, which in turn means that when you install things it already has
info locally to determine which files it already has and which ones it
needs to fetch (in the best case, the substitute phase simply hard-links
files locally without connecting to the server!).

One of the open issues is compression.  ‘guix publish’ now serves
individual files, but obviously they should be compressed somehow.
For nars, we have /lzip, /gzip, etc. URLs, which gives clients more
freedom on the choice of compression but is also quite heavyweight.  For
individual files, I’m thinking we could use ‘Accept-Encoding’ to let the
client declare which compression formats it supports and then let ‘guix
publish’ choose the one it prefers.

In the worst case, when none of the files are available locally, we’d be
downloading all the individual files, which is probably more data than a
single compressed nar.  I guess ‘guix substitute’ could fall back to nar
download when too little is available locally.

The downside compared to using ERIS or IPFS is that it’s really a hack.
The upside is that it’s little work and it’s efficient since we already
have that content-addressed file store in /gnu/store/.links.

Thoughts?

Ludo’.

Re: Identical files across subsequent package revisions

[Ludovic Courtès]

Hi!

pukkamustard  skribis:

> Your research inspired me to do conduct some experiments towards
> de-duplication.
>
> For two similar packages (emacs-27.1 and emacs-26.3) I was able to
> de-duplicate ~12% using EROFS and ERIS. Still far from the ~85%
> similarity, but an attempt I'd like to share.
>
> The two main ingredients:
>
> - EROFS (Enhanced Read-Only File-System) is a read-only,   compressed
>  file-system comparable to SquashFS. It has some properties that
>  make
>  it more suitable than SquashFS (it aligns content to fixed block
>  size). EROFS is in mainline Linux Kernel since v5.4.
>
> - ERIS (Encoding for Robust Immutable Storage) is an encoding of
>   content
>  into uniformly sized blocks that I've been working on. It
>  de-couples
>  encoding of content from storage and transport layer. Transport
>  layers
>  can be things like IPFS, GNUNet, Named Data Network or just a   plain
>  old HTTP service.
>
> I make EROFS images of the packages and encode them with ERIS, which
> de-duplicates blocks as part of the encoding process.
>
> With this I manage to de-duplicate between 12-17% (depending on some
> parameters).

Very nice!  I wonder what the file-level similarity is compared to the
block-level similarity.

> This could allow:
>
> - Directly mounting packages instead of unarchiving (a la distri)

Yeah, I’m not sure about this part.  It would be a radical change for
Guix in terms of code, and I also wonder about the efficiency: sure
mounting the package would be instantaneous, but subsequent reads would
be slowed down compared to the current approach.  Maybe the slowdown is
only on the first hit though, and maybe it’s hardly measurable, dunno.

> - Peer-to-peer distribution of packages (that's what ERIS is for)

Yup, looking forward to that.

> - De-duplicating common content in packages to a certain extent
>   (topic
>  of this thread)
>
> A more in-depth write-up:
> https://gitlab.com/openengiadina/eris/-/tree/main/examples/dedup-fs

Great writeup and nice tooling that you have here!

Thanks,
Ludo’.

Re: Guile 2.0 in make-bootstrap.scm

[Efraim Flashner]

On Wed, Jan 06, 2021 at 10:01:15AM +0100, Ludovic Courtès wrote:
> Hi Janneke!
> 
> While uploading the powerpc64le-linux tarballs, I noticed they use Guile
> 2.0, which reminded me of eef44fea17a735d2f4048a747d16af478d4b9dbc:
> 
> Revert "gnu: guile-static-stripped: Update to 2.2."
> 
> As discussed on IRC, keeping bootstrap Guile on 2.0 simplifies adding new
> architectures and removes the need for parameterizing
> gnu/packages/bootstrap.scm.
> 
> This reverts commit 2acfe022a740f79b593348cc6362cc4ee8f33bb4.
> 
> * gnu/packages/make-bootstrap.scm (%guile-static): Revert to guile-2.0.  
> Retain
> build recipe.
> * gnu/packages/patches/guile-relocatable.patch: Update for Guile 2.0.14.
> 
> Do you remember the reason for this change?
> 
> What’s surprising is that
>  does use
> 2.2.
> 

That wasn't me? (I apparently touch everything) I remember guile-2.2 for
the bootstrap had (likely) endianness ordering issues with PPC32, and it
was far simpler to revert back to guile-2.0 than to try to fix it.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Guile 2.0 in make-bootstrap.scm

[Ludovic Courtès]

Hi Janneke!

While uploading the powerpc64le-linux tarballs, I noticed they use Guile
2.0, which reminded me of eef44fea17a735d2f4048a747d16af478d4b9dbc:

Revert "gnu: guile-static-stripped: Update to 2.2."

As discussed on IRC, keeping bootstrap Guile on 2.0 simplifies adding new
architectures and removes the need for parameterizing
gnu/packages/bootstrap.scm.

This reverts commit 2acfe022a740f79b593348cc6362cc4ee8f33bb4.

* gnu/packages/make-bootstrap.scm (%guile-static): Revert to guile-2.0.  
Retain
build recipe.
* gnu/packages/patches/guile-relocatable.patch: Update for Guile 2.0.14.

Do you remember the reason for this change?

What’s surprising is that
 does use
2.2.

Thanks,
Ludo’.

[Outreachy] Strategy to implement guix git log --pretty=

[Leo Prikler]

Hello Magali,

have you looked into (ice-9 peg)?  An easy pretty grammar, that would
catch your example would be the following:

--8<---cut here---start->8---
(use-modules (ice-9 peg))

(define-peg-pattern commit-hash all (ignore "%h"))
(define-peg-pattern subject all (ignore "%s"))

(define-peg-pattern pretty body
  (* (or commit-hash
 subject
 (* (and (not-followed-by "%") peg-any)

(peg:tree (match-pattern pretty "%h %s")) ;; => (commit-hash " "
subject)
--8<---cut here---end--->8---

Of course you have to extend it with all the other percent escapes.
Then you simply map a match-lambda over the "tree", which if given a
symbol returns a string containng the actual value and if given a
string returns the string unchanged.  Finally you string-concatenate
them.  Naturally, you have to check whether the string was valid as
well -- a lone "%" should not match, for instance.

Cheers,
Leo

Re: [Outreachy] Strategy to implement guix git log --pretty=

[Gábor Boskovits]

Hello,

Magali  ezt írta (időpont: 2021. jan. 6., Sze, 5:35):
>
> Hello Guix,
>
> As you might know, as part of my Outreachy internship I'm currently
> working on implementing the subcommand 'guix git log', for browsing the
> history of all packages. So far, it works with '--oneline' and
> '--format=', and FORMAT can be 'oneline', 'medium' or 'full'. If
> you want to see it, the code can be found at
> https://gitlab.com/magalilemes/guix
>
> On the road to adding another option to the subcommand,
> '--pretty=' arose as an idea. With git log, you can do something
> like
> git log pretty=
> And this string can have placeholders, such as %h for showing the short
> hash of a commit, and %s for showing the commit subject. For instance,
> you could have git log --pretty="%h %s" and this would display the
> commit history log with the short hash and subject of commits.
>
> So, in order to implement 'guix git log --pretty=', I'd like
> help with a strategy to parse the string. Any examples, ideas and tips
> would be really appreciated.
>

>From the top of my head two things come to mind, you could either
tokenize the string and handle it as a list,
or you could do a regex matching. I don't think anything more
complicated is needed to handle this.

You can find the relevant docs here:
https://www.gnu.org/software/guile/manual/html_node/Strings.html
https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html




> Cheers,
>
> Magali
>
>

Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21