rfc: next guile 1.8.x release

rfc: next guile 1.8.x release

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]


I would like to work (on the weekends, so as not to intefere w/
<day-job>) on preparation and release of Guile 1.8.9, targeted
for the ides of April (more or less).

Guile 1.8.x users: What changes do you want to see in 1.8.9?

Guile maintainers: Any tips (process, content, interop, etc)
most welcome!

Please forward this RFC widely.  (I don't want to spam lists
that i don't subscribe to, personally, but those who straddle
feel free. :-D)

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)               ; (2021) Software Libero
   (pcase (context query)               ;       = Dissenso Etico
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 219 bytes --]

Re: rfc: next guile 1.8.x release

[Mike Gran]

On Sun, Jan 10, 2021 at 04:54:38PM -0500, Thien-Thi Nguyen wrote:
> 
> I would like to work (on the weekends, so as not to intefere w/
> <day-job>) on preparation and release of Guile 1.8.9, targeted
> for the ides of April (more or less).
> 
> Guile 1.8.x users: What changes do you want to see in 1.8.9?

Hello ttn-
Guile 1.8.x was rather portable. So my only suggestion is to
keep it portable.
-Mike Gran

Re: rfc: next guile 1.8.x release

[Massimiliano Gubinelli]

Hi,

I was not aware that Guile 1.8 was still "officially" maintained. What is the current status/policy about it?

 I'm not sure is appropriate to ask  but it would be nice if MinGW (both 32 and 64 bit) could be supported and to have it parallel installable with Guile 2 (and Guile 3).

Best regards,
Max


> On 11. Jan 2021, at 15:51, Mike Gran <spk121@yahoo.com> wrote:
> 
> On Sun, Jan 10, 2021 at 04:54:38PM -0500, Thien-Thi Nguyen wrote:
>> 
>> I would like to work (on the weekends, so as not to intefere w/
>> <day-job>) on preparation and release of Guile 1.8.9, targeted
>> for the ides of April (more or less).
>> 
>> Guile 1.8.x users: What changes do you want to see in 1.8.9?
> 
> Hello ttn-
> Guile 1.8.x was rather portable. So my only suggestion is to
> keep it portable.
> -Mike Gran
> 

Re: rfc: next guile 1.8.x release

[Thien-Thi Nguyen]

() Mike Gran <spk121@yahoo.com>
() Mon, 11 Jan 2021 06:51:35 -0800

   Guile 1.8.x was rather portable. So my only suggestion is to
   keep it portable.

Good idea.  Are there any specific platforms you're interested
in?  Are there any specific regressions in portability you're
interested in avoiding?

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)               ; (2021) Software Libero
   (pcase (context query)               ;       = Dissenso Etico
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502

Re: rfc: next guile 1.8.x release

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]


() Massimiliano Gubinelli <m.gubinelli@gmail.com>
() Tue, 12 Jan 2021 11:55:37 +0100

   I was not aware that Guile 1.8 was still "officially"
   maintained. What is the current status/policy about it?

I believe the maintainers have stopped supporting Guile 1.8.x
for a while now.  I'm not an official maintainer, just someone
who has write privs for the repo.  I suppose it would be good to
hear from the official maintainers before proceeding, so as to
avoid any surprises, but my gut feel is that they're pretty
relaxed about anything that does not interfere w/ the cutting
edge stuff they do.

   I'm not sure is appropriate to ask but it would be nice if
   MinGW (both 32 and 64 bit) could be supported and to have it
   parallel installable with Guile 2 (and Guile 3).

I think it's always appropriate to express "it would be nice"
thoughts.  What can it hurt?

That said, i'm not familiar w/ MinGW, so i will rely on
community feedback to guide me.  As long as MinGW support does
not impede GNU/Linux functionality, i think we'll be fine...

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)               ; (2021) Software Libero
   (pcase (context query)               ;       = Dissenso Etico
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 219 bytes --]

Re: rfc: next guile 1.8.x release

[Ludovic Courtès]

Hi!

Thien-Thi Nguyen <ttn@gnuvola.org> skribis:

> I would like to work (on the weekends, so as not to intefere w/
> <day-job>) on preparation and release of Guile 1.8.9, targeted
> for the ides of April (more or less).
>
> Guile 1.8.x users: What changes do you want to see in 1.8.9?
>
> Guile maintainers: Any tips (process, content, interop, etc)
> most welcome!

Guile 1.8 has been unmaintained for years and I wonder about the message
we’d be sending by publishing a bug-fix release 11 years and 3 major
versions later.

I know it still has two important users (LilyPond and TeXmacs), but it
doesn’t seem viable to me to go this route.

Ludo’.

Re: rfc: next guile 1.8.x release

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> Thien-Thi Nguyen <ttn@gnuvola.org> skribis:
>> I would like to work (on the weekends, so as not to intefere w/
>> <day-job>) on preparation and release of Guile 1.8.9, targeted
>> for the ides of April (more or less).
>>
>> Guile 1.8.x users: What changes do you want to see in 1.8.9?

I am not a Guile 1.8.x user, but changes I would like to see is anything
that could ease incremental porting to Guile 3.x. If there’s a way to
backport incompatible interfaces from 3.x so people can replace the
1.8.x-specific interfaces one by one, that could make it more viable to
move upwards.

>> Guile maintainers: Any tips (process, content, interop, etc)
>> most welcome!
>
> Guile 1.8 has been unmaintained for years and I wonder about the message
> we’d be sending by publishing a bug-fix release 11 years and 3 major
> versions later.

The message we’re sending is that we don’t leave anyone out in the cold
who committed to using Guile.

> I know it still has two important users (LilyPond and TeXmacs), but it
> doesn’t seem viable to me to go this route.

If Thien-Thi Nguyen wants to do it, I see no reason to stand in the way.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: rfc: next guile 1.8.x release

[Ricardo Wurmus]

Dr. Arne Babenhauserheide <arne_bab@web.de> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Thien-Thi Nguyen <ttn@gnuvola.org> skribis:
>>> I would like to work (on the weekends, so as not to intefere w/
>>> <day-job>) on preparation and release of Guile 1.8.9, targeted
>>> for the ides of April (more or less).
>>>
>>> Guile 1.8.x users: What changes do you want to see in 1.8.9?
>
> I am not a Guile 1.8.x user, but changes I would like to see is anything
> that could ease incremental porting to Guile 3.x. If there’s a way to
> backport incompatible interfaces from 3.x so people can replace the
> 1.8.x-specific interfaces one by one, that could make it more viable to
> move upwards.

Guile 2 was already very different from 1.8.

>>> Guile maintainers: Any tips (process, content, interop, etc)
>>> most welcome!
>>
>> Guile 1.8 has been unmaintained for years and I wonder about the message
>> we’d be sending by publishing a bug-fix release 11 years and 3 major
>> versions later.
>
> The message we’re sending is that we don’t leave anyone out in the cold
> who committed to using Guile.

The mailing lists are evidence enough that users of Guile 1.8 can get
help in migrating to version 2+.

But suggesting that Guile 1.8 is still maintained when it emphatically
is not — that is a step too far, in my opinion.

-- 
Ricardo

Re: rfc: next guile 1.8.x release

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

>> Ludovic Courtès <ludo@gnu.org> writes:
>>> Thien-Thi Nguyen <ttn@gnuvola.org> skribis:
>> The message we’re sending is that we don’t leave anyone out in the cold
>> who committed to using Guile.
>
> The mailing lists are evidence enough that users of Guile 1.8 can get
> help in migrating to version 2+.
>
> But suggesting that Guile 1.8 is still maintained when it emphatically
> is not — that is a step too far, in my opinion.

Receiving security fixes.

I think that is important, because it shows people whether they can
expect their tools written for 3.x to still work in 10 years.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: rfc: next guile 1.8.x release

[Massimiliano Gubinelli]

> On 30. Jan 2021, at 13:31, Ricardo Wurmus <rekado@elephly.net> wrote:
> 
> 
> Dr. Arne Babenhauserheide <arne_bab@web.de <mailto:arne_bab@web.de>> writes:
> 
>> Ludovic Courtès <ludo@gnu.org> writes:
>> 
>>> Thien-Thi Nguyen <ttn@gnuvola.org> skribis:
>>>> I would like to work (on the weekends, so as not to intefere w/
>>>> <day-job>) on preparation and release of Guile 1.8.9, targeted
>>>> for the ides of April (more or less).
>>>> 
>>>> Guile 1.8.x users: What changes do you want to see in 1.8.9?
>> 
>> I am not a Guile 1.8.x user, but changes I would like to see is anything
>> that could ease incremental porting to Guile 3.x. If there’s a way to
>> backport incompatible interfaces from 3.x so people can replace the
>> 1.8.x-specific interfaces one by one, that could make it more viable to
>> move upwards.
> 
> Guile 2 was already very different from 1.8.
> 
>>>> Guile maintainers: Any tips (process, content, interop, etc)
>>>> most welcome!
>>> 
>>> Guile 1.8 has been unmaintained for years and I wonder about the message
>>> we’d be sending by publishing a bug-fix release 11 years and 3 major
>>> versions later.
>> 
>> The message we’re sending is that we don’t leave anyone out in the cold
>> who committed to using Guile.
> 
> The mailing lists are evidence enough that users of Guile 1.8 can get
> help in migrating to version 2+.
> 
> But suggesting that Guile 1.8 is still maintained when it emphatically
> is not — that is a step too far, in my opinion.
> 

I spent the last few months of my allowed "hacking time" in trying to understand the situation and the possible strategies TeXmacs has wrt. extension language. Since the beginning TeXmacs used Guile (I think it was the natural choice for a GNU project). In TeXmacs Guile is an "extension language" and this means various things.

1) most of the codebase is in C++ and depends on other large libraries like Qt for cross-platform compatibility and defines its own interface to the OS
2) internally we do not use Unicode for strings
3) our code is written for a fast interpreted and dynamical scheme (like Guile 1.8)

all these three features point to weakness of various possible solutions

1) we do not need a Scheme with a lot of OS interfaces, this duplicate functionalities in QT and in our own code. For example all the OS interaction is dealt with internal functions (also because TeXmacs has its own virtual filesystem). We do not need threads, GMP, etc... all these additional parts add bloat without providing real useful functionalities.
2) it is better for us to have a Scheme which is not picky wrt. encodings. 
3) compiled schemes or schemes without first-class modules are more difficult to adapt to our own flavour of scheme coding.

Currently I'm trying three different routes:

- embed S7 (which is fast, dynamic and minimal and works everywhere)
- go for Guile 3 (I've still problems with phasing of macro expansion and bootstrap of our codebase. Will it work on Windows? Do we really need to carry on all the code we do not use?)
- go for Chez Scheme (like for Guile 3 problems with compilation phases and bootstrap of our codebase. I'm more confident it will work on Windows and on new architecture, it is more compact than Guile, essentially only the compiler, I've still problems with the garbage collector at the level of C++ interface).

My feeling is that Scheme developers are focused on compiled static programs and not so much on providing a reliable extension language for other programs. Ideally I would agree with the idea of writing everything in a fast scheme, but reality is different: cross-platform GUI are written in C++, TeXmacs' typesetting code is in C++: nobody has the time to rewrite everything. What Scheme provide to TeXmacs (and I think to a project like Lilypond, which however I do not know well) is a way to create our own extension language where to specify custom behaviour: we have macros to describe the GUI, the keybindings, the conversion algorithms, etc... all this is a quite large codebase which does not fit very much in the "statically compiled module" idea.  Still it is a very complex layer (TeXmacs has 100.000 lines of Scheme code).

Guile 1.8 works very well for us, that is the irony... We like it a lot, it is fast (and we need fast because interpreted code is called at every keypress....) It is so good that it is not easy to find a replacement: Chibi is too slow, S7 is very good but I needed to patch it otherwise it had some problem and was much slower than Guile 1.8. 

So Guile 1.8 today remains a very good piece of software, that is the reason we keep it. Maybe Lilypond has similar reasons. Our problems come from the fact that major Linux distributions do not package it anymore, so packaging TeXmacs has become a pain. We are even thinking to just include the code in our codebase... or even include Guile 1.6 which is also good enough for us and does not force us to link GMP.

In my mind Guile 1.8 is a very different language than Guile 2/3 and I do not see reason to make difficult for people to install them in parallel as it is possible for Guile 2 and Guile 3. Guile 2 cannot replace Guile 1.8, in this respect S7 is a better replacement, actively maintained. 

What would be ideal for large programs like ours is to have an extension language with the following characteristics:

1) it exposes as little surface as possible to the OS (so that it is easily portable and adaptable),
2) allow to use other string representations, so that one can just use the strings which come with the application without marshalling them thru the FFI,
3)  is fast enough even with interpreted code so that interactive applications can rely on it.
4)  it has some consideration of interactive applications where the separations of code in libraries is not very appropriate: one cannot ask the user to import 10-20 modules before being able to write some code. In TeXmacs we have a system where every module create procedures in a global environment. This is easy to do with Guile first-class modules but it is quite difficult to do in other schemes which are more picky about symbol lookup. 

I would be interested in hearing from other "large" adopters of Guile about their experience on the topics I mentioned above. 

Also I would be interested in pointers into current uses of Guile in other large programs so that I can learn patterns/techniques which maybe I've missed (how to structure the codebase, how to do cross-platform development, interaction with the OS, etc...)

Let me just finish by saying that at the moment we do not have clear plans on the future of Guile in TeXmacs, and it is probable that we will stick with Guile 1.8 for a while longer, so if there are patch around (e.g. to compile in Windows, etc...) it would be very useful to have a way to centralize them, and maybe to have Guile 1.8 parallel installable with Guile 2/3. 

Best,
Massimiliano

ps: some time ago I noted down some remarks about the problem of which Scheme to use in TeXmacs here : https://texmacs.github.io/notes/docs/scheming.html <https://texmacs.github.io/notes/docs/scheming.html>
comments are welcome.


> -- 
> Ricardo

Re: rfc: next guile 1.8.x release

[Ludovic Courtès]

Hi Massimiliano,

Thanks for the needs of TeXmacs this clearly.  A few comments below…

Massimiliano Gubinelli <m.gubinelli@gmail.com> skribis:

> all these three features point to weakness of various possible solutions
>
> 1) we do not need a Scheme with a lot of OS interfaces, this duplicate functionalities in QT and in our own code. For example all the OS interaction is dealt with internal functions (also because TeXmacs has its own virtual filesystem). We do not need threads, GMP, etc... all these additional parts add bloat without providing real useful functionalities.

Threads and bignums (GMP) were already in 1.8 though, and overall
libguile exposes about as much functionality today than in 1.8.  But I
can see that Qt and Guile are “competing” feature-wise.

> 2) it is better for us to have a Scheme which is not picky wrt. encodings. 

You can use binary output for when you just want to write bytes (info
"(guile) Binary I/O").

> 3) compiled schemes or schemes without first-class modules are more difficult to adapt to our own flavour of scheme coding.

I don’t think this is necessarily the case.  Probably you’ll want a
.scm -> .go rule in your makefiles, but that’s about it.

> Currently I'm trying three different routes:
>
> - embed S7 (which is fast, dynamic and minimal and works everywhere)
> - go for Guile 3 (I've still problems with phasing of macro expansion and bootstrap of our codebase. Will it work on Windows? Do we really need to carry on all the code we do not use?)
> - go for Chez Scheme (like for Guile 3 problems with compilation phases and bootstrap of our codebase. I'm more confident it will work on Windows and on new architecture, it is more compact than Guile, essentially only the compiler, I've still problems with the garbage collector at the level of C++ interface).

It’s much easier to port from Guile to Guile than from Guile to
something else.  :-)

The extra “code you don’t use” in Guile can be seen as a weight, but
longer-term, it could also change the way you approach problems in
TeXmacs and the way you structure it.

Guile 3 can be embedded just like Guile 1, but it supports a much
broader range of applications by being faster and providing more tools.

Ludo’.

Re: rfc: next guile 1.8.x release

[John Cowan]

On Sun, Jan 31, 2021 at 12:36 PM Massimiliano Gubinelli <
m.gubinelli@gmail.com> wrote:


> Chibi is too slow


I'll just mention here that Chibi's file include/chibi/features.h has many
feature macros (at the C level) that can be changed to make Chibi
smaller/faster: for example, you could disable Unicode support, R7RS module
support, etc.  If you do that, rebuild, and re-benchmark, the results might
be more pleasant.  There would still be the issue of making whatever
changes are required to adapt the existing code to Chibi, of course.

> So Guile 1.8 today remains a very good piece of software,


I propose (and I think this would make the Guile team happier) that you
fork Guile 1.8.x into a new project with a new name (Canny Scheme, Foxy
Scheme, or Sneaky Scheme, perhaps?).  That way you can maintain it for
your own use, it will be easier for packagers to work with since it will
have its own version number sequence, and it will be available to others
who want small, fast, somewhat Guile-compatible code.

Whether this would be a GNU project or not would need to be resolved by the
powers that GNU, of course.

In my mind Guile 1.8 is a very different language than Guile 2/3


Agreed: a different dialect of Scheme should have its own name.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant
le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux,
de rapport nyait pas.               --Jacques Lacan, "L'Etourdit"

Re: rfc: next guile 1.8.x release

[Andy Wingo]

Hi :)

On Sun 10 Jan 2021 22:54, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> I would like to work (on the weekends, so as not to intefere w/
> <day-job>) on preparation and release of Guile 1.8.9, targeted
> for the ides of April (more or less).

Humm!  I see you have started work here and are pushing to the main
release branch.  While I wish you well & much joy in the 1.8 hacking
endeavor I don't think a new 1.8 release is in the plans for the GNU
Guile project.  Currently the branch_release-1-8 git branch is for
hotfixes leading up to a planned release, and after discussing with
Ludovic, we as maintainers do not currently plan a release and must
therefore kindly request that we leave these branches to rest in peace
:)

Of course, I understand you are interested in 1.8 development and that's
great -- just that I don't think we want it to be an official GNU Guile
endeavor.  But if there are users interested in such a release, more
power to them; perhaps there is room for an unofficial Guile development
branch.  Just that again -- and I really hate to be negative here -- I
don't think it's something that should happen in the context of the GNU
Guile project, or in its repository.  The 1.8 development branch is
certainly not open right now in the main repository.

Kind regards, & happy hacking,

Andy

Re: rfc: next guile 1.8.x release

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]


Andy Wingo <wingo@pobox.com> writes:

> power to them; perhaps there is room for an unofficial Guile development
> branch.  Just that again -- and I really hate to be negative here -- I

How about taking this at literal value and creating an ugg8-repository:
Unofficial GNU Guile 1.8? That carries with it the connotations of
keeping to plain, strong values without fundamental changes, and picking
up from the 8, so it isn’t limited to the minor number behind 1.8.x
(with x > 8).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: rfc: next guile 1.8.x release

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]


() "Dr. Arne Babenhauserheide" <arne_bab@web.de>
() Tue, 09 Mar 2021 08:14:07 +0100

   How about taking this at literal value and creating an
   ugg8-repository: Unofficial GNU Guile 1.8? That carries with
   it the connotations of keeping to plain, strong values
   without fundamental changes, and picking up from the 8, so it
   isn’t limited to the minor number behind 1.8.x (with x > 8).

Please see: <https://gitlab.com/restio-al-restio/huge>.  I think
sooner or later the Official Guile maintainers will come around
to see that such a repo (whether on Savannah or Gitlab or ...)
represents a good incubation ground for future hackers, where
the old curmudgeons (i.e., Yours Truly) can mix w/ the new blood
and in the process hone their chops to be official maintainers
in their own right.

If, OTOH, this never happens, well, let that be a lesson for the
idealists and their efforts at pulling down The Wall.  :-D

Since HUGE hopes for re-merge Some Day, i will manage it wearing
my GNU maintainer hat, w/ additional TTN-specific requirements:

- Use TTN-style commit log entries (see, e.g., GNU RCS).
  (However, no need to actually maintain ChangeLog files.)

- "Don't break userland."

- Focus on documentation / bug fixes / implementation quality.

Who knows, maybe Good Things can be forward- and backward- and
sideways-ported to/from HUGE in the years to come.  May all of
Guile-dom benefit from the participation of HUGE hackers!

In order to not corrupt the precious bittily fluids of the HUGE
repo itself (which, as said earlier, is hoped to be a candidate
for re-merge Some Day by more enlightened Guile maintainers),
i'll probably create another repo "HUGE-META" which will have
HUGE as a submodule, where non-GNU-ish stuff can happen.  Like
everything, depends on interest and available energy, i suppose.
(Or maybe someone else can do that.)

Lastly, i get the vibe that Source Hut is all the rage, but my
Day Job doesn't have health insurance, so i'm scrimping by on
the gratis substrates for now.  Let's see how that goes...

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)               ; (2022) Software Libero
   (pcase (context query)               ;       = Dissenso Etico
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 219 bytes --]

Re: rfc: next guile 1.8.x release

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]


() Thien-Thi Nguyen <ttn@gnuvola.org>
() Wed, 02 Mar 2022 19:11:35 -0500

   Please see: <https://gitlab.com/restio-al-restio/huge> [...]

Just a quick followup: The ‘p’ branch passes "make check" now:

 https://gitlab.com/restio-al-restio/huge/-/milestones/2#tab-issues

This means if you have any long-standing issues w/ Guile 1.8.x
(or w/ Guile in general that manifest also in 1.8.x), you are
hereby invited to let your inner child put finger to keyboard
and submit issues / tests / bug reports / bug fixes.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)               ; (2022) Software Libero
   (pcase (context query)               ;       = Dissenso Etico
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 219 bytes --]