"Dr. Arne Babenhauserheide" writes:
> Felix Lechner writes:
>> If I were truly worried that the FSF was offended by my use of the GNU
>> trademark, I would check with them.
>> …
>> For example, I would avoid the impression that the owner endorsed my
>>
Hi Felix,
thank you very much for your answer!
Felix Lechner writes:
> If I were truly worried that the FSF was offended by my use of the GNU
> trademark, I would check with them. If that didn't yield any results, I
> would ask an attorney.
I’m not worried that they would be offended, but I di
Hi,
I have push access to savannah to be able to merge patches needed for
Lilypond. On codeberg I currently don’t have push/write/merge access.
https://codeberg.org/guile/guile
Can I get push, write, or merge access to codeberg for Lilypond patches,
too?
My user: https://codeberg.org/ArneBab
Sav
Damien Mattei writes:
> ah i understand it is not code? but edition macros?
> if i understand well...🤔
Yes :-)
I replaced it by just creating the variables in the snippet again, so I
don’t have to explain literate programming with org-mode noweb in the
book.
https://www.draketo.de/software/pro
Hi Damien,
I’m glad you like it!
> but i do not understand why so much {{{ }}} at page 23:
> {{{known-heights}}}
It seems then that I have to explain that in the book. And maybe revert
back to the default <>. Or do without it.
Those are org-mode noweb-references: it inserts the known-heights bl
Hi,
Naming and Logic -- programming essentials with Scheme
is a small 64-page booklet I’ve been writing for the past year:
https://www.draketo.de/software/programming-scheme.html
https://www.draketo.de/software/programming-scheme.pdf
To be printed on DinA6-paper (DinA5 for a large-font version).
Mike Gran writes:
> So I'm still plugging away at this Guile on Windows stuff.
Thank you for keeping us up to date!
> Guile's use of BDW GC is complicated. It is not the
> "just replace malloc with GC_MALLOC" described
> in the BDW GC docs.
Are you aware of the work done on whippet to replace
"Dr. Arne Babenhauserheide" writes:
> Mike Gran writes:
>> bootstrapped with the bitrotten guts of what we had before to get back
>> to a working `make check`. From here, it might be simple to extract
>> the old 64-bit patch and incorporate the Lilypond patch
Mike Gran writes:
> bootstrapped with the bitrotten guts of what we had before to get back
> to a working `make check`. From here, it might be simple to extract
> the old 64-bit patch and incorporate the Lilypond patch set in whole or
> in part. I don't know yet. I haven't tried it.
…
> - rlb ex
shell mumi -- mumi search submitter:arne is:open
72208 [PATCH] doc: tour: note the top-level modules ice-9, scheme, and srfi
opened 9 months ago by Dr. Arne Babenhauserheide, last updated 5 months ago
…
^ works now.
> 1. Applying a patch series locally
$ mumi current 72208
72208 [PATCH] doc: to
Arun Isaac writes:
> But, perhaps your question is more about the mumi CLI? The mumi CLI is
> documented in the Guix manual at
> https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html#index-mumi-command_002dline-interface
> But first, this patch adding mumi CLI configuration
Hi Arun,
Arun Isaac writes:
> Recently, the mumi instance run by the Guix project also started
> indexing Guile issues. Please try out mumi for guile at
> https://issues.guix.gnu.org/guile . I hope the Guile project can benefit
This looks neat — thank you!
In general for mumi I tried to use it,
Mike Gran writes:
> Mike Gran writes:
> I've created a new branch in the main Guile repo on savannah called
> wip-guile-2025, pulling in enough of various patchsets to get `make` and
…
> There are no actions required by anyone at this point, but, I'll need
> some review once I have a tree I'm ha
Mike Gran writes:
>> Did you manage to move forward with the patches?
> Things are in progress, but since I've been out of the free software
> scene for a while, it took me a bit to pull things together: linux box
> figure out emacs mail again, IMAP, SMTP, debbugs, git am, etc. Patches
> are tough
Hi Jonas, Hi Mike,
Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library"
writes:
>> If someone wants to point me to a complete source tarball
>> to diff with main or some other additional source of information,
>> I can continue my evaluation. Else, I can use these pa
Jonas Hahnfeld writes:
> If I'm honest, it would help more to get reviews from people actually
> looking at the code...
For some context: we are struggling to find people with experience in
Windows and rlb went as deep as was possible in their limited time.
I asked rlb to provide the feedback th
Hi Felix,
Felix Lechner via "Developers list for Guile, the GNU extensibility library"
writes:
> On Tue, Feb 04 2025, Tomas Volf wrote:
>> automatically decoding now would lead to double decoding.
>
> Will a second decoding step for HTML entities, which is the most likely
> workaround, mess up s
Tomas Volf <~@wolfsden.cz> writes:
> I think I found a bug in the htmlprag module in guile-lib. When parsing
> attributes, the values are not properly decoded:
Thank you for the report!
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use (htmlprag)
> s
Hi Jonas,
Thank you for the rebased patches!
Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library"
writes:
> Another ping on this thread. Just to remind, this is important for
> LilyPond, which is a fellow GNU project.
>
> I'm attaching the first five patches required to
tests in the background, and it
does not aim to be a full replacement of all tests, but to reduce the
overhead for unit tests and to keep them close to the implementation.
Best wishes,
Arne
From 670c9df1ec1dd07d06c2041afb98c19d94915fe8 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Sun
Skyler Ferris via "Developers list for Guile, the GNU extensibility library"
writes:
> I have 2 concerns that I want to address. The first concern is the bad
> user experience created by calling a procedure which is advertised in
> the manual only to be told that it does not exist. I consider th
far as I can tell.
Best wishes,
Arne
"Dr. Arne Babenhauserheide" writes:
> Hi,
>
> did this question drown in other messages? Should this go
>
> - to guile-lib
> - to guile
> - elsewhere?
>
> My preference would be guile, because then it would be available
Hi,
did this question drown in other messages? Should this go
- to guile-lib
- to guile
- elsewhere?
My preference would be guile, because then it would be available for
everyone learning Guile Scheme and I could more easily use it in
tutorials
Best wishes,
Arne.
"Dr. Arne Babenhauser
Hi,
when merging the patches by Matthew, I missed that the commit messages
were merged into a single line.
I’m sorry about that (but don’t think force-pushing would be proper).
I’ll take more care to check imported patches in the future.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch se
Hi,
the attached patch just adds a note about the switch `guile -I` in the
NEWS file so it does not have to be done during release.
From e226ddb13fcd01f92d124f583d83d2cd4d1df08b Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Sat, 12 Oct 2024 14:29:03 +0200
Subject: [PATCH] note
writes:
> On Sun, Oct 06, 2024 at 07:13:02AM -0700, Matt Wette wrote:
>> 1) Leave welcome message as is, going to stdout.
>> 2) Find a way to make 00-repl-server.test work.
>> 3) Initialize current-info-port to stdout (ugly)
>> 4) Add some other hook in system/repl/common.scm(repl-welcome) to dea
Hi Matt,
Matt Wette writes:
> I got it working. I made two changes:
Nice!
> 1) I updated the change to ice-9/command-line.scm. The `patch'
> command rejected the location of the `-I' option placement.
> 2) I reverted the change to system/repl/common.scm which had changed
> the output of the
Hi Matt,
I just ran the testsuite after applying your changes, and it stalls at
$ make check -j16
...
;;; SSAX warning: DOCTYPE DECL T system1 found and skipped
UNRESOLVED: time.test: strftime: C99 %z format: strftime fr_FR.iso88591
UNRESOLVED: time.test: strptime: GNU %s format: strftime fr_FR.i
Matt Wette writes:
> On 10/2/24 6:48 AM, Dr. Arne Babenhauserheide wrote:
>>> https://github.com/mwette/guile-contrib/blob/main/patch/3.0.9/info-port.patch
> If you compare to the input-port and error-port analogs you may come
> to the conclusion I did.
Ah, I see — thank you
Matt Wette writes:
> On 3/11/24 6:50 AM, Matt Wette wrote:
>> On 3/10/24 6:01 PM, Dr. Arne Babenhauserheide wrote:
>>> Hi,
>>>
>>> It’s been two months now, did anyone get to review this patch?
>>>
>>> It’s small and it gives an instant i
Hi,
In the past year I often had to make code work on different versions on
Guile. Either because my laptop has a different distribution than my
Desktop (Trisquel vs. Guix) or because my server has yet another
distribution and may be on Debian stable (or oldstable).
The main problem for me was #:
Maxime Devos writes:
>> (xml->sxml "http://example.org/ns1\";>text")
> If you remove a single namespace, apparently that’s true, but what if
> multiple namespaces are removed? Does it still work then?
Yes, it still works:
(import (sxml simple))
(define xml-string "http://foobar\";>http://www.w
Richard Sent writes:
> This documents behavior discussed in
> https://lists.gnu.org/archive/html/guile-user/2024-07/msg00013.html.
>
> * doc/ref/sxml.texi (Reading and Writing XML): Document behavior of #f
> namespace prefix.
> ---
> doc/ref/sxml.texi | 3 ++-
> 1 file changed, 2 insertions(+),
Maxime Devos writes:
> * hence, you can define a module from within another module (might be
> situationally useful, but comes with new difficulties for module
> lookup)
I actually tried something in that direction in enter three witches —
and failed.
I wanted to add a macro that maps
SCENE I
Attila Lendvai writes:
>> Do you know that the Broken Window theory has been debunked?
>> https://cssh.northeastern.edu/sccj/2019/05/21/researchers-debunk-broken-windows-theory-after-35-years/
>
> there's no need for scientific papers about something i can observe myself.
> both inside me, in my
MSavoritias writes:
> Dr. Arne Babenhauserheide kirjoitti 20.7.2024 klo 17.52:
>> Lassi Kortela writes:
>>>> It would be easy to state in more places "the standard library of guile
>>>> is called ice-9 (see [history])".
>>> With no disrespect
Lassi Kortela writes:
>>> That said, I think that in Scheme, standard is quite different from
>>> portable – if something standard is implemented, it will be (mostly)
>>> according
>>> to the standard, so in this way it is ‘portable’, but that’s a big ‘if’.
>>> For large Schemes (and small Sch
Lassi Kortela writes:
>> Would it be possible to start into that by creating prefixes for the
>> different package repositories?
>> (akkuscm ...) and (snow-fort ...)
>
> I advise against doing that, as the same package can be published to
> multiple repositories.
Would that be a problem? All it
Maxime Devos writes:
> That said, I think that in Scheme, standard is quite different from portable
> – if something standard is implemented, it will be (mostly) according
> to the standard, so in this way it is ‘portable’, but that’s a big ‘if’. For
> large Schemes (and small Schemes for which
Lassi Kortela writes:
>> Is anything except for (srfi ...) and (rnrs ...) expected to be
>> portable? I thought till now that if I want my code portable, an easy
>> way would be to restrict my imports to these.
>
> The R6RS and R7RS library definition framework (which is broadly
> compatible acro
Lassi Kortela writes:
>> But on the topic of (guile ...) as name: I’m not sure whether (guile
>> ...) is better. Because what then is (language ...)? What are (oop ...)
>> (sxml ...) and (web ...)?
>> Should all of these move into (guile ...)?
>
> IMHO they should move under (guile ...). Other Sc
Hi,
Following my answer in the discussion (after checking the non-ice-9
prefixes), this may be a better representation of the modules Guile
provides:
From 6838e4da9712425e7e45805a73731bb399d90a86 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Sat, 20 Jul 2024 15:03:15 +0200
Subject
Lassi Kortela writes:
>> It would be easy to state in more places "the standard library of guile
>> is called ice-9 (see [history])".
>
> With no disrespect intended -- I understand it's a joke that was funny
> at one time -- "the standard library of Guile is called ice-9" sounds
> like "the unit
1
From: Arne Babenhauserheide
Date: Sat, 11 Dec 2021 16:12:17 +0100
Subject: [PATCH] Add instructions for sending patches
---
website/apps/base/contribute-page.scm | 16
1 file changed, 16 insertions(+)
diff --git a/website/apps/base/contribute-page.scm b/website/apps/base/cont
8fde348e21 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Sat, 20 Jul 2024 15:03:15 +0200
Subject: [PATCH] doc: reference ice-9, scheme, and srfi
* doc/ref/tour.texi (Using Modules): reference ice-9, scheme, and srfi.
---
doc/ref/tour.texi | 9 +
1 file changed, 9 insertions(+)
Attila Lendvai writes:
>> >If there were more concern about compatibility -- all 2.0 programs will
>> >compile an work with 3.0 -- then we would not need to keep the old
>> >versions.
>>
>> One of these changes is how #:autoload works. One of the options to
>> preserve compatibility yet introduc
Attila Lendvai writes:
>> > IOW, if you don't want changes in your dependencies, then just don't
>> update them.
>>
>> This does not work.
>>
>> You often have to update dependencies for security reasons. Got a new
>> gnutls or openssl or openssh with new cyphers you need to have a worki
MSavoritias writes:
> There will be some time before it is actually removed.
So it will just take a bit longer until my setup gets broken.
> Given a long timeline i doubt older programs would be advised to be
> used or even work with recent guile. Given the rest of the cleaning
> discussion and
Attila Lendvai writes:
> IOW, if you don't want changes in your dependencies, then just don't update
> them.
This does not work.
You often have to update dependencies for security reasons. Got a new
gnutls or openssl or openssh with new cyphers you need to have a working
program — will Guile 3
Olivier Dion writes:
> On Sat, 29 Jun 2024, Mikael Djurfeldt wrote:
>
> [...]
>
>> As has been spoken about here previously, I suggest that we
>> design a new module hierarchy, introduce aliases for module bindings, and
>> still supply the old module hierarchy during a few years for backward
>>
Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library"
writes:
> On Wed, 2024-03-20 at 21:28 +0100, Jonas Hahnfeld wrote:
>> I'm also explicitly CC'ing Andy and Ludo - we really need a statement
>> by a maintainer whether this can land. From my point of view, it's a
>> cle
Maxime Devos writes:
>> But when the culture shifts so people say “hey, we have versioned APIs
>> now, let’s change everything around to fit this new style; it won’t
>> break existing clients (until we remove the old version)” (can you say
>> that you never saw people do that? I did see it), then
Hi,
"Dr. Arne Babenhauserheide" writes:
> === Guile--V3.0.10 Geometric Mean slowdown (successful tests / total tests)
> ===
>
> 1.0241580763853801 (55 / 57)
> --
> === Guile--V3.0.9 Geometric Mean slowdown (successful tests / total tests) ===
>
> 1.060174741
Maxime Devos writes:
> No it doesn’t, because of _the version number_. If you put (6) next to
> the module name, that’s the _exact_ version number, it’s not ‘6 or
> later’ or ‘maybe 6 whatever’, it’s ‘exactly 6’. You could load
> multiple versions of a module at the same time! (Not actually
> impl
Hi,
I ran and evaluated ecraven’s r7rs-benchmarks for Guile 3.0.8 to 3.0.10
and found 3.0.10 to be around 3% faster than 3.0.8 and 3.0.9.
I’m actually calculating the geometric mean of the slowdown of different
tests compared to the fastest:
=== Guile--V3.0.10 Geometric Mean slowdown (successf
"Thompson, David" writes:
> wrote:
>> I will suggest that if a consensus is reached on what new code must
>> adhere to (e.g. no (guile) namespace pollution, no new procedures
>> written in C), it should be documented in the reference manual.
>
> Right, there is no consensus about this right now.
Maxime Devos writes:
> ```
> #!r6rs
> (library (foo)
>(export foo)
>(import (rnrs base))
>(define foo
> (cons 'a 1)))
> ```
> Here you are demonstrating how R6RS libraries have the _same_ problem. You
> should at least have included a version number next to (rnrs
> base). Who kno
Maxime Devos writes:
>> I suggest that we design a new module hierarchy, introduce aliases for
>> module bindings, and still supply the old module hierarchy during a few
>> years for backward compatibility.
> Also, on deprecation and removal: just because you deprecate something,
> doesn’t mean
Damien Mattei writes:
> About breaking backward compatibility , i understand it could be a
> disaster... but if Python made this choice
The experience of Python should not be encouragement. It was a disaster.
Many tools are *still* broken, especially specialist tools. More than
one and a half d
Mikael Djurfeldt writes:
> design a new module hierarchy, introduce aliases for module bindings,
> and still supply the old module hierarchy during a few years for
> backward compatibility.
Please do not do this. It is a recipe for disaster.
Do you remember when Lilypond broke with Guile 2.0?
H
Hi,
I realized that I did not actually send the reply to the list.
Damien Mattei writes:
> where is the doc of Wisp? i did not yet install it, as i understand it will
> be included in next release of Guile?
The documentation is either in the SRFI or on the wisp website:
- https://srfi.scheme
Felix Lechner via "Developers list for Guile, the GNU extensibility library"
writes:
> I would like to release some code under the GPL. libguile.so calls it
> from C. The setup is similar to the code in the Tortoise tutorial. [1]
>
> Guile is licensed under the LGPL, so it is possible for propr
Hi Ludo’,
Ludovic Courtès writes:
> I have the pleasure to inform you that I have finally pushed this! :-)
>
> Apologies for taking so long, and thank you for being patient.
Thank you for reviewing and pushing it!
> Some of the suggestions I made earlier¹ were still not implemented
> though:
>
"Dr. Arne Babenhauserheide" writes:
> Zelphir Kaltstahl writes:
>> https://codeberg.org/ZelphirKaltstahl/guile-examples/src/commit/0e231c289596cb4c445efb30168105914a8539a5/macros/contracts
> And the *-versions are ominous: optional and keyword arguments may be
> the n
Hi,
I’ve been using my doctests implementation for years now, and it works
beautifully for me, so I would like to contribute it — either to
guile-lib as (tests doctest) or to guile (maybe (ice-9 doctest)?).
Working code is here:
https://hg.sr.ht/~arnebab/wisp/browse/examples/doctests.scm?rev=tip
Ryan Raymond writes:
> For example, I modified "parse-http-method" and completely removed all error
> throwing capabilities but I am still getting an error thrown from
> within that function.
> (bad-request "Invalid method: ~a" (substring str start end))
>
> I am assuming that the modules are n
"Dr. Arne Babenhauserheide" writes:
> this gets rid of a warning in our testsuite (guile-test): it uses load
> but is not marked as non-declarative.
Reviewed by Andy Wingo on IRC ⇒ merged and pushed. Thank you!
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
o
Hi Matt,
Matt Wette writes:
> On 3/10/24 6:01 PM, Dr. Arne Babenhauserheide wrote:
> It’s small and it gives an instant improvement when using Guile in Emacs
> orgmode babel sourceblocks that get evaluated on export.
>
> I did look at it. Another solution, I prefer, is ge
644
index 0..dae9642ae
--- /dev/null
+++ b/module/language/wisp.scm
@@ -0,0 +1,776 @@
+;;; Wisp
+
+;; Copyright (C) 2013, 2017, 2018, 2020 Free Software Foundation, Inc.
+;; Copyright (C) 2014--2023 Arne Babenhauserheide.
+;; Copyright (C) 2023 Maxime Devos
+
+ This library is free softwar
Hi,
the following patch just adds the note to test-suite/guile-test how to
run it.
This file is referenced in test files, so the instructions it gives
should lead to the right way to run it.
From 097c5e869ebee05d20d8298fdf2a8aa58f2acca0 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date
Hi,
this gets rid of a warning in our testsuite (guile-test): it uses load
but is not marked as non-declarative.
The patch:
From 6b7dcf5e77aebe5ad9e22d7cd7c568bc5ed5fccd Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Mon, 11 Mar 2024 01:50:29 +0100
Subject: [PATCH] guile-test
Hi,
It’s been two months now, did anyone get to review this patch?
It’s small and it gives an instant improvement when using Guile in Emacs
orgmode babel sourceblocks that get evaluated on export.
Best wishes,
Arne
"Dr. Arne Babenhauserheide" writes:
> Hello,
>
> the fo
Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library"
writes:
> On Tue, 2023-11-28 at 22:04 +0100, Jonas Hahnfeld wrote:
>> On Sun, 2023-10-29 at 22:34 +0100, Jonas Hahnfeld wrote:
>> > I would like to propose a different approach: It turns out to be
>> > possible to just
Hi,
do you know a nice minimal example that shows how to extend Guile with
Rust to get maximum performance for some tasks?
I’m not looking for hints how to speed up Scheme code, or how to do
less. Instead I want to learn how to do those cases where I actually
need some specific algorithm at maxim
Damien Mattei writes:
> On Sat, Jan 20, 2024 at 9:07 PM Dr. Arne Babenhauserheide
> wrote:
> Damien Mattei writes:
> > by keeping the same
> > number of parenthesis, but they are just differents : ( ), { }, [ ]
> > and it allow the use of infix expressions.
>
Damien Mattei writes:
> i just add a #; support in Scheme+ :
> https://github.com/damien-mattei/Scheme-PLUS-for-Guile
> Scheme+ is an extension syntax to Scheme. It goes in the opposite direction
> of Wisp or Rhombus (based on Racket)
Note that Wisp and Rhombus differ: Wisp is just Scheme t
Christina O'Donnell writes:
> On 09/01/2024 07:05, Dr. Arne Babenhauserheide wrote:
>> It’s a new year — any chance for one more look whether adding SRFI-119
>> in Guile is ok to merge?
>
> As a disclaimer, I'm a Scheme newbie, but I think my opinion may have
Hi,
I just got the most beautiful feedback on Wisp as a Scheme primer, so I
would like to nag about inclusion of SRFI-119 into Guile again:
»I tend to use [Wisp] as a Scheme primer for colleagues that are used
to Python but want to explore the realms of functional programming
without … hav
:00 2001
From: Arne Babenhauserheide
Date: Tue, 9 Jan 2024 14:40:30 +0100
Subject: [PATCH] GUILE_QUIET: suppress repl-welcome when GUILE_QUIET env is
set
* module/system/repl/repl.scm (run-repl*): print welcome *unless* GUILE_QUIET
is set
* doc/ref/guile-invoke.texi (Environment Variables
ename=0001-GUILE_QUIET-suppress-repl-welcome-when-GUILE_QUIET-e.patch
Content-Transfer-Encoding: quoted-printable
From=205af642cb967942c7cb46b773431a44ceae1e7cbe Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 9 Jan 2024 14:40:30 +0100
Subject: [PATCH] GUILE_QUIET: suppress repl-we
"Dr. Arne Babenhauserheide" writes:
> Is adding SRFI-119 to Guile good to go?
It’s a new year — any chance for one more look whether adding SRFI-119
in Guile is ok to merge?
Best wishes,
Arne
signature.asc
Description: PGP signature
Hafeez Bana writes:
> The kind of advice you would be giving is:
…
> Alternatively, if there are sysadmin shops that are interested in doing
> this work - please contact me.
>
> 🩷 Guix.
Out of interest: Did you already receive applications for this?
If not: ping to all who may have missed your
Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library"
writes:
>> What do you and others think of this approach, would this be "more"
>> acceptable to land in main?
>
> Ping, any comments on this approach? I built binaries for LilyPond
> 2.25.10 using these patches applied
ArneBab writes:
> ArneBab writes:
>> I now assigned my copyright in GNU Guile to FSF
> Is the patch now good to go?
Clarification: I don’t actually need someone to push this (I can push).
I just need the go to actually do it (rebase the branch then merge it),
because I don’t want to push my own
"Dr. Arne Babenhauserheide" writes:
> "Dr. Arne Babenhauserheide" writes:
>
>> "Dr. Arne Babenhauserheide" writes:
>>>> OK. I assumed you already emailed ass...@gnu.org the relevant form,
>>>> right? Let us know how it
"Dr. Arne Babenhauserheide" writes:
> "Dr. Arne Babenhauserheide" writes:
>>> OK. I assumed you already emailed ass...@gnu.org the relevant form,
>>> right? Let us know how it goes.
> I now sent a request to be sent the papers to sign to ass...@gnu
Linus Björnstam writes:
> are bound in letrec*. This should also be the case in chez, but chez
> displays an error. Given I have found the chez is never wrong with
> regards to R6RS we can say that guiles behaviour is not conformant
> with r6rs.
…
> What I am saying is: congrats, you found a bug
Hi,
Linus Björnstam writes:
> When you are not referencing x before defining y everything works as
> you want. There is no, so to say, temporal dependency on how the
> things are bound. When you introduce (display x) before actually
> defining y you force letrec* to bind x to the unspecified val
Hi,
while writing a comment to SRFI-245 I think I found an inconsistency in
the Implementation in Guile.
This works:
(define (using-later-variable)
(define x y)
(define y #t)
x)
(using-later-variable)
;; => #t
This still works:
(define (using-later-variable)
(define x y)
(newline)
"Dr. Arne Babenhauserheide" writes:
>> OK. I assumed you already emailed ass...@gnu.org the relevant form,
>> right? Let us know how it goes.
>
> If I read it right, the docs
> https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
> say that I nee
"Dr. Arne Babenhauserheide" writes:
> I’m attaching the new squashed patch again here and will add the patches
> for the review changes to a second email.
Attached are the promised patches of the additional review changes.
Thank you for yo
et that sorted out, that would be the moment I’d switch to
records (then they would need no added special casing), but I would
prefer to take your offer to do that change in a followup patch.
> Some comments:
>
>> From 5857f8b961562d1ad2ae201401d5343233422eff Mon Sep 17 00:00:00 200
"Dr. Arne Babenhauserheide" writes:
> diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
> index 0cdf56923..5b82f8070 100644
> --- a/doc/ref/srfi-modules.texi
> +++ b/doc/ref/srfi-modules.texi
> +To execute a file with wisp code, select the language
"Dr. Arne Babenhauserheide" writes:
> Attached is a new squashed patch. I’ll send another email with only the
> commits for the individual changes on top of the original squashed patch
> to avoid tripping up tools that extract diffs.
This is the promised email with just the
88f241d45d1fd52fa2f58ce772 Mon Sep 17 00:00:00 2001
>> From: Arne Babenhauserheide
>> Date: Fri, 3 Feb 2023 22:20:04 +0100
>> Subject: [PATCH] Add language/wisp, wisp tests, and srfi-119 documentation
>>
>> * doc/ref/srfi-modules.texi (srfi-119): add node
>> * modu
Maxime Devos writes:
>> [...]
>> Can you make it LGPLv3+? It’s a small file anyway.
>
> Only if David A. Wheeler, Alan Manuel K. Gloria and Maxime Devos
> agrees. Otherwise, you still need to include the license text:
I just asked David and Alan, and when I checked the sources I realized
that
Ludovic Courtès writes:
> pukkamustard skribis:
>
>> I've been using SRFI-146
>> (https://srfi.schemers.org/srfi-146/srfi-146.html) for functional
>> mappings. There's a Guile port:
>> https://inqlab.net/git/guile-srfi-146.git/ (also in Guix -
>> guile-srfi-146).
>
> I’m late to the party, but
Josselin Poiret writes:
> Reciprocally, I don't think a simple pull request provides much over
> git-am, except that with `format-patch`, everything is simply text, that
> once sent over email (in a decentralized fashion) can be simply
> responded to and read without relying on complicated javas
writes:
> You seem to be somewhat upset, but I don't quite understand what
> your gripe is.
If I understood it correctly, they interpret the 'wtf? as expressing
"this is a problem that should be changed" and wanted to say
(equal? '(. a) 'a) should stay #true in Guile and consequently
(call-with
Dmitry Alexandrov writes:
> but explicitly documented in (info "(elisp) Dotted Pair Notation") as well:
>
> #+begin_quote
>As a somewhat peculiar side effect of ‘(a b . c)’ and ‘(a . (b . c))’
> being equivalent, for consistency this means that if you replace ‘b’
> here with the empty sequen
1 - 100 of 237 matches
Mail list logo