unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* rfc: next guile 1.8.x release
@ 2021-01-10 21:54 Thien-Thi Nguyen
  2021-01-11 14:51 ` Mike Gran
  2021-01-29 21:35 ` Ludovic Courtès
  0 siblings, 2 replies; 12+ messages in thread
From: Thien-Thi Nguyen @ 2021-01-10 21:54 UTC (permalink / raw)
  To: guile-user

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-10 21:54 rfc: next guile 1.8.x release Thien-Thi Nguyen
@ 2021-01-11 14:51 ` Mike Gran
  2021-01-12 10:55   ` Massimiliano Gubinelli
  2021-01-16 22:48   ` Thien-Thi Nguyen
  2021-01-29 21:35 ` Ludovic Courtès
  1 sibling, 2 replies; 12+ messages in thread
From: Mike Gran @ 2021-01-11 14:51 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: guile-user

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-11 14:51 ` Mike Gran
@ 2021-01-12 10:55   ` Massimiliano Gubinelli
  2021-01-16 22:55     ` Thien-Thi Nguyen
  2021-01-16 22:48   ` Thien-Thi Nguyen
  1 sibling, 1 reply; 12+ messages in thread
From: Massimiliano Gubinelli @ 2021-01-12 10:55 UTC (permalink / raw)
  To: Mike Gran; +Cc: guile-user, Thien-Thi Nguyen

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
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-11 14:51 ` Mike Gran
  2021-01-12 10:55   ` Massimiliano Gubinelli
@ 2021-01-16 22:48   ` Thien-Thi Nguyen
  1 sibling, 0 replies; 12+ messages in thread
From: Thien-Thi Nguyen @ 2021-01-16 22:48 UTC (permalink / raw)
  To: Mike Gran; +Cc: guile-user

() 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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-12 10:55   ` Massimiliano Gubinelli
@ 2021-01-16 22:55     ` Thien-Thi Nguyen
  0 siblings, 0 replies; 12+ messages in thread
From: Thien-Thi Nguyen @ 2021-01-16 22:55 UTC (permalink / raw)
  To: Massimiliano Gubinelli; +Cc: guile-user

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-10 21:54 rfc: next guile 1.8.x release Thien-Thi Nguyen
  2021-01-11 14:51 ` Mike Gran
@ 2021-01-29 21:35 ` Ludovic Courtès
  2021-01-29 23:46   ` Dr. Arne Babenhauserheide
  1 sibling, 1 reply; 12+ messages in thread
From: Ludovic Courtès @ 2021-01-29 21:35 UTC (permalink / raw)
  To: guile-user

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’.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-29 21:35 ` Ludovic Courtès
@ 2021-01-29 23:46   ` Dr. Arne Babenhauserheide
  2021-01-30 12:31     ` Ricardo Wurmus
  0 siblings, 1 reply; 12+ messages in thread
From: Dr. Arne Babenhauserheide @ 2021-01-29 23:46 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guile-user

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-29 23:46   ` Dr. Arne Babenhauserheide
@ 2021-01-30 12:31     ` Ricardo Wurmus
  2021-01-30 14:49       ` Dr. Arne Babenhauserheide
  2021-01-31 17:35       ` Massimiliano Gubinelli
  0 siblings, 2 replies; 12+ messages in thread
From: Ricardo Wurmus @ 2021-01-30 12:31 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: Ludovic Courtès, guile-user


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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-30 12:31     ` Ricardo Wurmus
@ 2021-01-30 14:49       ` Dr. Arne Babenhauserheide
  2021-01-31 17:35       ` Massimiliano Gubinelli
  1 sibling, 0 replies; 12+ messages in thread
From: Dr. Arne Babenhauserheide @ 2021-01-30 14:49 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Ludovic Courtès, guile-user

[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-30 12:31     ` Ricardo Wurmus
  2021-01-30 14:49       ` Dr. Arne Babenhauserheide
@ 2021-01-31 17:35       ` Massimiliano Gubinelli
  2021-02-01 21:49         ` Ludovic Courtès
  2021-02-07  6:59         ` John Cowan
  1 sibling, 2 replies; 12+ messages in thread
From: Massimiliano Gubinelli @ 2021-01-31 17:35 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guile-user, Ludovic Courtès



> 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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-31 17:35       ` Massimiliano Gubinelli
@ 2021-02-01 21:49         ` Ludovic Courtès
  2021-02-07  6:59         ` John Cowan
  1 sibling, 0 replies; 12+ messages in thread
From: Ludovic Courtès @ 2021-02-01 21:49 UTC (permalink / raw)
  To: Massimiliano Gubinelli; +Cc: guile-user

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’.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: rfc: next guile 1.8.x release
  2021-01-31 17:35       ` Massimiliano Gubinelli
  2021-02-01 21:49         ` Ludovic Courtès
@ 2021-02-07  6:59         ` John Cowan
  1 sibling, 0 replies; 12+ messages in thread
From: John Cowan @ 2021-02-07  6:59 UTC (permalink / raw)
  To: Massimiliano Gubinelli; +Cc: guile-user, Ludovic Courtès

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"


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-02-07  6:59 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-10 21:54 rfc: next guile 1.8.x release Thien-Thi Nguyen
2021-01-11 14:51 ` Mike Gran
2021-01-12 10:55   ` Massimiliano Gubinelli
2021-01-16 22:55     ` Thien-Thi Nguyen
2021-01-16 22:48   ` Thien-Thi Nguyen
2021-01-29 21:35 ` Ludovic Courtès
2021-01-29 23:46   ` Dr. Arne Babenhauserheide
2021-01-30 12:31     ` Ricardo Wurmus
2021-01-30 14:49       ` Dr. Arne Babenhauserheide
2021-01-31 17:35       ` Massimiliano Gubinelli
2021-02-01 21:49         ` Ludovic Courtès
2021-02-07  6:59         ` John Cowan

unofficial mirror of guile-user@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-user/0 guile-user/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-user guile-user/ https://yhetil.org/guile-user \
		guile-user@gnu.org
	public-inbox-index guile-user

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.user
	nntp://news.gmane.io/gmane.lisp.guile.user


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git