bug#66135: Unable to download Guile tar file

[Jean Abou Samra]

> Le 23 sept. 2023 à 06:38, ahmad khizir  a écrit :
> 
> 
> Not working for me, i can share the screenshot.

Please do.

bug#66057: (ice-9 match) allows invalid usages of ... or ..1

[Jean Abou Samra]

Le dimanche 17 septembre 2023 à 20:59 -0400, Maxim Cournoyer a écrit :
> It's mentioned in the Guile Reference manual; see info "(guile) Pattern
> Matching":
> > 
> > So your example is just binding the string "Printer" to the variable "..1":
> > since "..1" doesn't have any special meaning, it's just a pattern variable.
> 
> Unless I misread the doc, it should '..1' is a special case '...', which
> means "one or more" instead of "zero or more".


OK, my bad, I didn't know that. You're right that "..1" is mistreated here, it
should be compiled as "one or more repetitions" but instead gets compiled as a
pattern variable. That's a bug, indeed — I believe the expected behavior is that
"..1" behaves like "...", namely being allowed in the middle of a list.


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

bug#66057: (ice-9 match) allows invalid usages of ... or ..1

[Jean Abou Samra]

Le dimanche 17 septembre 2023 à 14:17 -0400, Maxim Cournoyer a écrit :
> Hi,
> 
> After attempting the following:
> 
> --8<---cut here---start->8---
> (match (string-split "./Bootloaders/Printer/Documentation/html" #\/)
>  (("." path ..1 "Documentation" "html")


For a start, where does that "..1" syntax come from? To my knowledge, no such
syntax is supported by Guile's pattern matcher, which AFAIK is the one described
in SRFI-204.

https://srfi.schemers.org/srfi-204/srfi-204.html


So your example is just binding the string "Printer" to the variable "..1":
since "..1" doesn't have any special meaning, it's just a pattern variable.


>   (pk 'path path)))
> 
> => ;;; (path "Bootloaders")
> 
> Expected (and works with '...'): 
> ;;; (path "Bootloaders" "Printer")
> --8<---cut here---end--->8---
> 
> and asking about it in #scheme or #guile, it seems the '..1' and '...'
> patterns *must* be used strictly to match at the end of lists,


??

This is not what SRFI 204 says, and it's not consistent with syntax-rules and
syntax-case patterns either.


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

bug#58066: pretty-print will make data modified by set-cdr! to random value

[Jean Abou Samra]

Closing this as a duplicate
of https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16060


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

bug#16060: Attempt to mutate a literal pair results in segfault (master)

[Jean Abou Samra]

This is still happening with Guile 3.0, but only at -O2, not at -O1.



$ cat x.scm 
(set-car! '(1 . 2) 3)

$ guild3.0 compile -O1 x.scm
wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.5/home/jean/tmp/x.scm.go'

$ guile3.0 x.scm
Backtrace:
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   5 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  4 (call-with-prompt ("prompt") # …)
In ice-9/eval.scm:
619:8  3 (_ #(#(#)))
In ice-9/boot-9.scm:
   2835:4  2 (save-module-excursion #)
  4380:12  1 (_)
In x.scm:
  1:0  0 (_)

x.scm:1:0: In procedure set-car!: Wrong type argument in position 1 (expecting
mutable pair): (1 . 2)

$ guild3.0 compile -O2 x.scm
wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.5/home/jean/tmp/x.scm.go'

$ guile3.0 x.scm
Segmentation fault (core dumped)



I found that module/language/cps/lower-primcalls.scm contains:

;; precondition: pair is mutable pair
(define-primcall-lowerer (set-car! cps k src #f (pair val))
  (with-cps cps
(build-term
  ($continue k src
($primcall 'scm-set!/immediate '(pair . 0) (pair val))


which bypasses the check that the scm_set_car_x and scm_set_cdr_x
functions do.

I wonder if instead of checking the pair beforehand, Guile could just
do the set-c(a|d)r! anyway. Could the problem with mmapped bytecode
just be solved by adding PROT_WRITE to the mmap flags? (Or are there
maybe thread-safety problems?)






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

bug#64508: Optimization of "-" function is incorrect in presence of GOOPS overloading

[Jean Abou Samra]

The following code demonstrates that when byte-compiling (but not when
interpreting), the call (- x) is transformed into (- 0 x). This results
in failure of custom - methods defined via GOOPS.

I think this says it all:


$ guile3.0
GNU Guile 3.0.7 [...]
scheme@(guile-user)> ,optimize (- x)
$1 = (- 0 x)


The longer version:


$ cat minus.scm 
(use-modules (oop goops))

(define-class  ()
  (bar #:init-keyword #:bar))

(define-method (- (x ))
  (make  #:bar (- (slot-ref x 'bar

(display (slot-ref (- (make  #:bar 5))
   'bar))
(newline)



$ guile3.0 --no-auto-compile minus.scm 
-5


$ guile3.0 minus.scm 
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/jean/tmp/minus.scm
;;; compiled /home/jean/.cache/guile/ccache/3.0-LE-8-
4.5/home/jean/tmp/minus.scm.go
Backtrace:
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   7 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  6 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  5 (_ #(#(#)))
In ice-9/boot-9.scm:
   2835:4  4 (save-module-excursion _)
  4380:12  3 (_)
In /home/jean/tmp/minus.scm:
 9:19  2 (_)
In oop/goops.scm:
  1567:11  1 (cache-miss 0 #< 7f56944e70b0>)
   1585:2  0 (_ _ _)

oop/goops.scm:1585:2: No applicable method for #< - (1)> in call (- 0
#< 7f56944e70b0>)



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

bug#62583: Guile 3.0.9 crashes when calling set-car! on the last node of '(...)

[Jean Abou Samra]

> Le 1 avr. 2023 à 08:22, Rui Zhang  a écrit :
> 
> Reproduction:
> 
>(let ((xs '(1)))
>  (set-car! xs 0))
> 
> or
> 
>(let ((xs '(1 2)))
>  (set-car! (cdr xs) 0))
> 
> Guile will segfault executing this code, and only when set-car! is called on 
> the last node.  I believe the expectation is that it does not segfault and xs 
> will be modified to (0) or (1 0) in these two examples.
> 
> If I use (list 1) instead of '(1), Guile does not seem to segfault.  Maybe 
> '(1) is constructed differently?
> 
> 
> $ guile --version
> guile (GNU Guile) 3.0.9
> Copyright (C) 2023 Free Software Foundation, Inc.
> 
> License LGPLv3+: GNU LGPL 3 or later .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> $ ./config.guess
> x86_64-pc-linux-gnu


A duplicate of https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16060

bug#61598: guile 3.0.9 missing module ice-9/readline.scm

[Jean Abou Samra]

> Le 18 févr. 2023 à 09:25, p...@posteo.net a écrit :
> 
> The Guile 3.0 manual mentions "(use-modules (ice-9 readline))", but the 
> module appears to be missing from the Guile 3.0.9 source code tarball. I 
> noticed the issue was brought up for version 3.0.9 RC1, but the bug was 
> closed. Has the module been intentionally removed for some reason? I found it 
> useful as it is included with the Guile in the Debian repositories.
> 
> 
> 

bug#61599: regarding "guile 3.0.9 missing module ice-9/readline.scm"

[Jean Abou Samra]

> Le 18 févr. 2023 à 09:25, p...@posteo.net a écrit :
> 
> Please disregard my previous bug report: "guile 3.0.9 missing module 
> ice-9/readline.scm". I realized what the problem was afterwards. The module 
> readline.scm is in a separate location in the source tarball and wasn't 
> included with the other ice-9 modules because I forgot to install the 
> readline dev libraries in my latest installation. Sorry about any hassle.
> 
> 
> 
> 

bug#60488: string-ref segfaults with n < 0 on Guile 3.0.8

[Jean Abou Samra]

> Le 2 janv. 2023 à 09:54, fester...@posteo.net a écrit :
> 
> On 02.01.2023 05:12, fester...@posteo.net wrote:
>> The following code results in a segmentation fault on Guile
>> 3.0.8-deb+3.0.8-2 (obtained from the Debian repositories):
>>(string-ref "my string" -3)
>> gdb's backtrace is the following:
>> #0  0x77f1bcc5 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #1  0x77f26c49 in scm_call_n ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #2  0x77e97b29 in scm_apply_0 ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #3  0x77f15966 in scm_throw ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #4  0x77f174e9 in scm_ithrow ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #5  0x77e94735 in scm_error_scm ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #6  0x77e94790 in scm_error ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #7  0x77ee19e7 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #8  0x77ee208b in scm_to_uint64 ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #9  0x77f1c5e4 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #10 0x77f26c49 in scm_call_n ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #11 0x77e93a97 in scm_primitive_eval ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #12 0x77e99a86 in scm_eval ()
>>   from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #13 0x77ef91c6 in scm_shell () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #14 0x77ea865c in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #15 0x77e91f6a in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #16 0x77f194e8 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #17 0x77f26c49 in scm_call_n () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #18 0x77e936ea in scm_call_2 () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #19 0x77f42292 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #20 0x77f0ff4f in scm_c_catch () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #21 0x77e942e6 in scm_c_with_continuation_barrier () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #22 0x77f14b89 in ?? () from /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #23 0x77c190e7 in GC_call_with_stack_base () from
>> /lib/x86_64-linux-gnu/libgc.so.1
>> #24 0x77f0fe68 in scm_with_guile () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #25 0x77eb1185 in scm_boot_guile () from
>> /lib/x86_64-linux-gnu/libguile-3.0.so.1
>> #26 0x510f in ?? ()
>> #27 0x77c9918a in __libc_start_call_main
>> (main=main@entry=0x50b0, argc=argc@entry=1,
>> argv=argv@entry=0x7fffe0b8) at
>> ../sysdeps/nptl/libc_start_call_main.h:58
>> #28 0x77c99245 in __libc_start_main_impl (main=0x50b0,
>> argc=1, argv=0x7fffe0b8, init=, fini=> out>, rtld_fini=, stack_end=0x7fffe0a8) at
>> ../csu/libc-start.c:381
>> #29 0x51aa in ?? ()
> 
> Sorry, didn't see #59874. This bug report is a duplicate of that bug. 
> Therefore this should be closed.
> 
> 
> 

bug#59874: Segfault from string-ref with negative 'k'

[Jean Abou Samra]

(Closing since this has been fixed.)



OpenPGP_signature
Description: OpenPGP digital signature

bug#59984: segfault in list-ref

[Jean Abou Samra]

Le 12/12/2022 à 05:10, Christopher Lam a écrit :


Hi guile dev team

Here's a glaring segfault in guile 3.0.8



This is a duplicate of 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59874, which is already 
fixed in master.


Best,
Jean


OpenPGP_signature
Description: OpenPGP digital signature

bug#49686: Confusing presence of #f in error message

[Jean Abou Samra]

This seems to have been fixed, probably in 
eb5ecf4944cd646341f7e47dda5396cf96a4b8a3.


OpenPGP_signature
Description: OpenPGP digital signature

bug#57507: Regular expression matching depends on locale encoding

[Jean Abou Samra]

Le 05/09/2022 à 21:24, Ludovic Courtès a écrit :

Yes, that’d be welcome.  I would not call it a constraint or limitation;
for example, that ‘w’ is not a letter in Swedish is the kind of thing
you’d generally want to take into account.  Now, it’d be nice if one
could easily specify the locale to operate under, with an API similar to
that of (ice-9 i18n) and its first-class locale objects.




Sorry that it took me forever to send this.



From c666ca4f72dc0a00d28b8d7ef1221ebfc9741551 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Thu, 17 Nov 2022 21:26:07 +0100
Subject: [PATCH] Doc: clarification on regexes and encodings

* doc/ref/api-regex.texi: make it more obviously clear that regexp
  matching supports only characters supported by the locale encoding.
---
 doc/ref/api-regex.texi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/doc/ref/api-regex.texi b/doc/ref/api-regex.texi
index b14c2b39c..bd1f4079d 100644
--- a/doc/ref/api-regex.texi
+++ b/doc/ref/api-regex.texi
@@ -57,7 +57,11 @@ locale's encoding, and then passed to the C library's 
regular expression

 routines (@pxref{Regular Expressions,,, libc, The GNU C Library
 Reference Manual}).  The returned match structures always point to
 characters in the strings, not to individual bytes, even in the case of
-multi-byte encodings.
+multi-byte encodings.  This ensures that the match structures are
+correct when performing matching with characters that have a multi-byte
+representation in the locale encoding.  Note, however, that using
+characters which cannot be represented in the locale encoding can lead
+to surprising results.

 @deffn {Scheme Procedure} string-match pattern str [start]
 Compile the string @var{pattern} into a regular expression and compare
--
2.38.1




OpenPGP_signature
Description: OpenPGP digital signature

bug#59221: (file-exists? #f) raises an exception

[Jean Abou Samra]

Le 13/11/2022 à 07:44, to...@tuxteam.de a écrit :

You both have a point. Checking for existing predicates with a
longer tradition, though:

   scheme@(guile-user)> (exact? "mumble")
   ice-9/boot-9.scm:1685:16: In procedure raise-exception:
   In procedure exact?: Wrong type argument in position 1: "mumble"

seems to support Jean Abu's position that it is more customary to
raise for an argument of the wrong type. Also `string


Yes. I am not sure where the people in the Guile IRC got the idea
that a predicate shouldn't raise an exception. Lots of predicates in
Guile do, and that is very helpful because it catches mistakes.



Naively, it just feel like it (file-exists? #f) should return #f.



Why?



Would there be an objection to changing the definition of file-exists to

(define (file-exists file)
 (and (string? file)
  (old-file-exists-code file)))




It would be inconsistent with the rest of Guile and I don't
see what it would help with.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

bug#59221: (file-exists? #f) raises an exception

[Jean Abou Samra]

> Le 12 nov. 2022 à 18:50, Joshua Branson via Bug reports for GUILE, GNU's 
> Ubiquitous Extension Language  a écrit :
> 
> 
> Hello you lovely guile people!
> 
> This bug is so simple the subject line says it all!
> 
> file-exists? is a predicate, but
> 
> #+BEGIN_SRC scheme
> (file-exists? #f)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure stat: Wrong type argument in position 1 (expecting open file 
> port): #f
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> #+END_SRC
> 
> I will shortly tag this as "easy".  Can you lovely maintainers give me
> about a week to try to fix this myself?
> 
> Thanks,
> 
> Joshua
> avid fantany reader


What’s the problem here?

It is normal for predicates to be defined only on certain types. You will find 
the same with positive?, string-null? and the like.

Regards,
Jean

bug#58646: [PATCH] doc: Fix eval-when example

[Jean Abou Samra]

From 0e35d0494b7c6f05819e3386d404776a64a2e5c9 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 19 Oct 2022 23:01:06 +0200
Subject: [PATCH] doc: Fix eval-when example

* doc/ref/api-macros.texi: make the macro expand to the literal
  date, not to a call to the date function.  The example previously
  did not actually need eval-when and did not show the intended
  effect.
---
 doc/ref/api-macros.texi | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/doc/ref/api-macros.texi b/doc/ref/api-macros.texi
index cdb33df31..ed7bbe763 100644
--- a/doc/ref/api-macros.texi
+++ b/doc/ref/api-macros.texi
@@ -1236,14 +1236,19 @@ But if a syntactic definition needs to call out 
to a normal procedure at
 expansion-time, it might well need need special declarations to 
indicate that

 the procedure should be made available at expansion-time.

-For example, the following code will work at a REPL, but not in a file:
+For example, the following code tries to embed a compilation timestamp
+in the compiled bytecode using a macro that expands to the date as
+string literal.  It will work at a REPL, but in a file, it cannot be
+byte-compiled.

 @example
-;; incorrect
 (use-modules (srfi srfi-19))
-(define (date) (date->string (current-date)))
-(define-syntax %date (identifier-syntax (date)))
-(define *compilation-date* %date)
+(define start-date (date->string (current-date)))
+(define-syntax *compilation-date*
+  (lambda (sintax)
+    start-date))
+(display *compilation-date*)
+(newline)
 @end example

 It works at a REPL because the expressions are evaluated one-by-one, 
in order,

@@ -1253,12 +1258,14 @@ evaluated until the compiled file is loaded.
 The fix is to use @code{eval-when}.

 @example
-;; correct: using eval-when
 (use-modules (srfi srfi-19))
 (eval-when (expand load eval)
-  (define (date) (date->string (current-date
-(define-syntax %date (identifier-syntax (date)))
-(define *compilation-date* %date)
+  (define start-date (date->string (current-date
+(define-syntax *compilation-date*
+  (lambda (sintax)
+    start-date))
+(display *compilation-date*)
+(newline)
 @end example

 @deffn {Syntax} eval-when conditions exp...
--
2.37.3

bug#58109: simple-format vs (ice-9 format) bug in 3.0.7?

[Jean Abou Samra]

Le 01/10/2022 à 15:40, Ludovic Courtès a écrit :

Hi,

Jean Abou Samra  skribis:


Uh, at the end of module/ice-9/format.scm, there is

;; Thanks to Shuji Narazaki
(module-set! the-root-module 'format format)

which dates back to

commit 14469b7c69feb0f2c5b8a093f19fe2a548b31c5b
Author: Greg J. Badros 
Date:   Thu Jan 20 20:58:30 2000 +

[...]


This probably predates #:replace and could be removed now, right?

Yes, it could be removed, but probably not before the 4.0 series.

The ‘-Wformat’ warning introduced sometime in the 2.0 or 2.2 series
prepared for that removal by warning about simple-format/format
mismatches, but there’s probably still code out there that assumes
‘format’ is the full-blown ‘format’, even when (ice-9 format) is not
explicitly imported.




OK, understood. How about adding comments and documentation?

diff --git a/doc/ref/misc-modules.texi b/doc/ref/misc-modules.texi
index 6c899a905..2c00ed859 100644
--- a/doc/ref/misc-modules.texi
+++ b/doc/ref/misc-modules.texi
@@ -1122,6 +1122,13 @@ you try to use one of them.  The reason for two 
versions is that the

 full @code{format} is fairly large and requires some time to load.
 @code{simple-format} is often adequate too.

+Beware that when @code{(ice-9 format)} is loaded, it replaces the
+binding for @code{format} on the toplevel.  If your module loads
+another module that loads @code{(ice-9 format)}, then your module
+will see the @code{format} function from @code{(ice-9 format)},
+even if it does not itself import @code{(ice-9 format)}.  This is
+legacy behavior and may be removed in a future Guile version.
+

 @node File Tree Walk
 @section File Tree Walk
diff --git a/module/ice-9/format.scm b/module/ice-9/format.scm
index ee7cba910..026fd9b54 100644
--- a/module/ice-9/format.scm
+++ b/module/ice-9/format.scm
@@ -32,6 +32,8 @@
 (define-module (ice-9 format)
   #:autoload (ice-9 pretty-print) (pretty-print truncated-print)
   #:autoload (ice-9 i18n) (%global-locale number->locale-string)
+  ;; Actually replaces the global format as soon as loaded; see the end
+  ;; of this file.
   #:replace (format))

 (define format:version "3.0")
@@ -83,7 +85,7 @@
   ;; format's user error handler

   (define (format-error . args)   ; never returns!
-    (with-throw-handler #t
+    (with-throw-handler #t
   (lambda ()
 (let ((port (current-error-port)))
   (unless (zero? %arg-pos)
@@ -1560,5 +1562,10 @@
   (close-port port)
   str)

-;; Thanks to Shuji Narazaki
+;; Set the format variable in the root module.  This is legacy and
+;; no longer necessary.  It means that as soon as (ice-9 format) is
+;; loaded somewhere by some module, the predefined binding for format
+;; becomes the extended format function, even in modules where (ice-9 
format)

+;; isn't imported.  Because of this, removing this line should be done
+;; when a backwards compatibility break is allowed.
 (module-set! the-root-module 'format format)




Best,
Jean

bug#58109: simple-format vs (ice-9 format) bug in 3.0.7?

[Jean Abou Samra]

Le 27/09/2022 à 12:35, Jean Abou Samra a écrit :



Le 27/09/2022 à 12:23, Christopher Lam a écrit :

Hi guilers, here's a short bash session.
Why would the first bash call to "guile s.scm" work, but not the 
second one?

guile-3.0.7 on ubuntu.




This is a duplicate of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50059




Uh, at the end of module/ice-9/format.scm, there is

;; Thanks to Shuji Narazaki
(module-set! the-root-module 'format format)

which dates back to

commit 14469b7c69feb0f2c5b8a093f19fe2a548b31c5b
Author: Greg J. Badros 
Date:   Thu Jan 20 20:58:30 2000 +

    * format.scm: Use (variable-set! (builtin-variable 'format)) to
    re-define format to be format:format (instead of just define,
    which interacts poorly with the module system).  Thanks to Shuji
    Narazaki for this change.

diff --git a/ice-9/format.scm b/ice-9/format.scm
index fce2737ce..40f20b3da 100644
--- a/ice-9/format.scm
+++ b/ice-9/format.scm
@@ -1670,7 +1670,9 @@

 (define format:abort (lambda () (error "error in format")))

-(define format format:format)
+;;(define format format:format)
+;; Thanks to Shuji Narazaki
+(variable-set! (builtin-variable 'format) format:format)

 ;; If this is not possible then a continuation is used to recover
 ;; properly from a format error. In this case format returns #f.



This probably predates #:replace and could be removed now, right?

bug#58109: simple-format vs (ice-9 format) bug in 3.0.7?

[Jean Abou Samra]

Le 27/09/2022 à 12:23, Christopher Lam a écrit :

Hi guilers, here's a short bash session.
Why would the first bash call to "guile s.scm" work, but not the 
second one?

guile-3.0.7 on ubuntu.




This is a duplicate of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50059

bug#58066: pretty-print will make data modified by set-cdr! to random value

[Jean Abou Samra]

Le 24/09/2022 à 12:01, slbtty a écrit :

GNU Guile 3.0.8

Using `guile3 < file.scm` to run the code below will makes the result
of tp unpredictable (pointing to very random things)

(use-modules (ice-9 pretty-print))
(define tl '(1 2))
(define tp (cdr tl))
(set-cdr! tp (cons 3 '()))
   (pretty-print tl)
   (pretty-print tp)
---

However, if i use plain old (display tp), the code will out put
expected valve (1 2 3) (3)
(define tl '(1 2))
(define tp (cdr tl))
(set-cdr! tp (cons 3 '()))
   (display tl) (newline)
   (display tp) (newline)

---

Context:

I am using guile3's repl and whenever i access a variable's by typing
its name after (set-cdr!), the result will goes wild.




Interesting. It looks like scm_is_mutable_pair is broken? It's
defined (in pairs.h) as

static inline int
scm_is_mutable_pair (SCM x)
{
  /* Guile embeds literal pairs into compiled object files.  It's not
 valid Scheme to mutate literal values.  Two practical reasons to
 enforce this restriction are to allow literals to share share
 structure (pairs) with other literals in the compilation unit, and
 to allow literals containing immediates to be allocated in the
 read-only, shareable section of the file.  Attempting to mutate a
 pair in the read-only section would cause a segmentation fault, so
 to avoid that, we really do need to enforce the restriction. */
  return scm_is_pair (x) && GC_is_heap_ptr (SCM2PTR (x));
}


I don't know why that breaks or how to fix it, though.

As you can read from the comment, this code is actually
invalid Scheme, since it mutates literal data. However,
it is true that Guile should raise an error for this,
not segfault (which is what it does for me) or start
printing random things.

If you define tl as (list 1 2 3) instead of '(1 2 3),
everything will be fine.

bug#57507: Regular expression matching depends on locale encoding

[Jean Abou Samra]

Le 05/09/2022 à 09:48, Ludovic Courtès a écrit :

Hi Jean,

Jean Abou Samra  skribis:


Regular expressions do funky things with Unicode if a non-Unicode-aware
locale is set. Yet, they're purely string operations, so I don't think
it's expected that they depend on the locale encoding.

This is the expected behavior: first because (ice-9 regex) is
implemented in terms of the libc regex functions, as Dale put (but that
could be thought as an implementation detail), and second because things
such as character classes are necessarily locale-dependent (this has
bitten us in the past, for instance with <https://bugs.gnu.org/35785>).

I hope that makes sense.




OK, thanks, but in this case, it should be clearly stated as a limitation
in the (ice-9 regex) documentation IMHO. If you don't know what constraints
there are on the implementation, there is no reason to expect this. Would it
help if I submitted a patch for that?

bug#57507: Regular expression matching depends on locale encoding

[Jean Abou Samra]

Regular expressions do funky things with Unicode if a non-Unicode-aware
locale is set. Yet, they're purely string operations, so I don't think
it's expected that they depend on the locale encoding.



$ LC_ALL=C guile3.0
GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (ice-9 regex))
scheme@(guile-user)> (match:substring (string-match "\u203f" "\u3091"))
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure make-regexp: Invalid preceding regular expression

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,q
scheme@(guile-user)> (match:substring (string-match "[\u203f]" "\u3091"))
$1 = "\u3091"
scheme@(guile-user)>

bug#50068: [PATCH] In curried definitions, move docstrings to outermost lambdas

[Jean Abou Samra]

Le 29/08/2022 à 18:10, lloda a écrit :

Applied in 61d8dab8eafd498306ce618582aab37497df77b4. Thank you!


Thanks, Iloda!

bug#50068: [PATCH] In curried definitions, move docstrings to outermost lambdas

[Jean Abou Samra]

Ping? Could this patch be considered please?

bug#57393: The Guile manuall has no entry for use-typelibs in the Procedures Index

[Jean Abou Samra]

Le 25/08/2022 à 00:10, Lee Thomas a écrit :
Hi. I am trying to run some examples for guile GUI toolkits, and they 
have use-typelibs in their code. It is failing for me, so I wanted to 
learn more about the procedure - but the Procedures Index has no entry 
for it. I would expect there would be an entry even if the procedure 
itself is deprecated.


If I can assist in resolving this issue, I'm happy to help.



There is no function called use-typelibs in Guile. It must come from 
somewhere else. Probably guile-gi, as far as I can see from 
https://spk121.github.io/guile-gi/Parsing-Typelibs-and-Creating-Bindings.html?

bug#57123: compile discards multiple values

[Jean Abou Samra]

Example:

scheme@(guile-user)> (eval '(values 1 2) (current-module))
$1 = 1
$2 = 2
scheme@(guile-user)> (use-modules (system base compile))
scheme@(guile-user)> (compile '(values 1 2) #:env (current-module))
$3 = 1
scheme@(guile-user)>


Tested with Guile 3.0.7.

A workaround can be found at
https://lists.gnu.org/archive/html/guile-user/2022-08/msg00043.html

bug#57119: Warning level 0 still yields warnings

[Jean Abou Samra]

For example:

$ cat cased.scm
(case 5
  ((5 5) 5))
$ guild3.0 compile -W0 cased.scm
cased.scm:2:3: warning: duplicate datum 5 in clause ((5 5) 5) of case 
expression (case 5 ((5 5) 5))

wrote `/[...]/cased.scm.go'


The documentation says that passing -W0 suppresses all warnings.
The above shows that this is not the case, at least not for
all warnings.

This is with Guile 3.0.7.

bug#56675: UTF16 encoding adds BOM before every single character

[Jean Abou Samra]

With this code:

(let ((p (open-output-file "x.txt")))
   (set-port-encoding! p "UTF16")
   (display "ABC" p)
   (close-port p))

the sequence of bytes in the output file x.txt is

['FF', 'FE', '41', '0', 'FF', 'FE', '42', '0', 'FF', 'FE', '43', '0']


As you can see, a BOM is being added before every
single character instead of just at the beginning.

Originally reported at
https://lists.gnu.org/archive/html/guile-user/2022-07/msg00041.html

bug#56493: Source locations are broken when byte-compiling

[Jean Abou Samra]

In Guile 3.0.8, compilation warnings when byte-compiling print 
.


$ ./libguile/guile test.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /.../test.scm
;;; : warning: possibly unbound variable 
`unbound-variable'

;;; compiled /home/jean/.cache/guile/ccache/3.0-LE-8-4.6/.../test.scm.go
Backtrace:
[snipped]


This was OK in 3.0.7.

This problem was originally reported at

https://lists.gnu.org/archive/html/guile-devel/2022-03/msg00017.html

bug#50068: [PATCH] In curried definitions, move docstrings to outermost lambda

[Jean Abou Samra]

Hi,

Please consider the following patch, fixing bug #50068.

Best regards,
Jean



From 79552d2974e9cbcfcf01960aab68cb6824c88972 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Tue, 29 Mar 2022 00:14:45 +0200
Subject: [PATCH] In curried definitions, move docstrings to outermost lambda

This makes the docstring attached to the curried function being defined
rather than the result of its application until a function that runs the
body is obtained, fixing
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50068
---
 module/ice-9/curried-definitions.scm  | 72 ---
 test-suite/tests/curried-definitions.test | 56 --
 2 files changed, 90 insertions(+), 38 deletions(-)

diff --git a/module/ice-9/curried-definitions.scm 
b/module/ice-9/curried-definitions.scm

index 7545338e3..7e758be5e 100644
--- a/module/ice-9/curried-definitions.scm
+++ b/module/ice-9/curried-definitions.scm
@@ -4,12 +4,12 @@
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 3 of the License, or (at your option) any later version.
-
+
  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.
-
+
  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
02110-1301 USA

@@ -20,38 +20,42 @@
  define-public
  define*-public))

-(define-syntax cdefine
-  (syntax-rules ()
-    ((_ (head . rest) body body* ...)
- (cdefine head
-   (lambda rest body body* ...)))
-    ((_ name val)
- (define name val
+(define-syntax make-currying-define
+  (syntax-rules ::: ()
+    ((_ currying-name lambda-name)
+ (define-syntax currying-name
+   (lambda (St-Ax)
+ (syntax-case St-Ax ()
+   ((_ ((head2 . rest2) . rest) docstring body body* ...)
+    (string? (syntax->datum #'docstring))
+    ;; Keep moving docstring to outermost lambda.
+    #'(currying-name (head2 . rest2)
+    docstring
+    (lambda-name rest body body* ...)))
+   ((_ (head . rest) body body* ...)
+    #'(currying-name head
+    (lambda-name rest body body* ...)))
+   ((_ name val)
+    #'(define name val

-(define-syntax cdefine*
-  (syntax-rules ()
-    ((_ (head . rest) body body* ...)
- (cdefine* head
-   (lambda* rest body body* ...)))
-    ((_ name val)
- (define* name val
+(make-currying-define cdefine lambda)
+(make-currying-define cdefine* lambda*)

-(define-syntax define-public
-  (syntax-rules ()
-    ((_ (head . rest) body body* ...)
- (define-public head
-   (lambda rest body body* ...)))
-    ((_ name val)
- (begin
-   (define name val)
-   (export name)
+(define-syntax make-currying-define-public
+  (syntax-rules ::: ()
+    ((_ public-name define-name)
+ (define-syntax public-name
+   (lambda (St-Ax)
+ (syntax-case St-Ax ()
+   ((_ binding body body* ...)
+    #`(begin
+    (define-name binding body body* ...)
+    (export #,(let find-name ((form #'binding))
+    (syntax-case form ()
+  ((head . tail)
+   (find-name #'head))
+  (name
+   #'name

-(define-syntax define*-public
-  (syntax-rules ()
-    ((_ (head . rest) body body* ...)
- (define*-public head
-   (lambda* rest body body* ...)))
-    ((_ name val)
- (begin
-   (define* name val)
-   (export name)
+(make-currying-define-public define-public cdefine)
+(make-currying-define-public define*-public cdefine*)
diff --git a/test-suite/tests/curried-definitions.test 
b/test-suite/tests/curried-definitions.test

index b4a1f6509..cd535b162 100644
--- a/test-suite/tests/curried-definitions.test
+++ b/test-suite/tests/curried-definitions.test
@@ -5,12 +5,12 @@
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 3 of the License, or (at your option) any later version.
-
+
  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.
-
+
  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to t

bug#52230: 'guild compile' and C(++) extensions (in the context of LilyPond)

[Jean Abou Samra]

Le 19/02/2022 à 22:25, Olivier Dion a écrit :

On Sat, 19 Feb 2022, Jean Abou Samra  wrote:

I had similar problem with Jami.  I added C++ primitives to Guile, but
these were not load using the foreign function interface.  Note, I'm
using Guile 3.0.8, but I think the same could be done for Guile 2.0.

Basically what I do is to add a `compile` command to my program so to
speak.

So usually the program does this:
 main -> install_scheme_primitives() -> Run the program

And for compilation
 main -> compile_in_guile() -> install_scheme_primitives() -> 
compile-file


To be clear here's what install_scheme_primitives() does:

void
install_scheme_primitives()
{
 /* Define modules here */
 auto load_module = [](auto name, auto init){
 scm_c_define_module(name, init, NULL);
 };

 load_module("jami account", install_account_primitives);
 load_module("jami call", install_call_primitives);
 load_module("jami conversation", install_conversation_primitives);
 load_module("jami logger bindings", install_logger_primitives);
 load_module("jami signal bindings", install_signal_primitives);
}


and here's what compile_in_guile() does:

void*
compile_in_guile(void* args_raw)
{
 // ...
 install_scheme_primitives();

 // This string is usually formatted
 scm_c_eval_string("(use-modules (system base compile))"
   "(compile-file \"foo.scm\" #:output-file \"foo.go\")")

// ..
}


so now I can correctly compile any file in the project.  I just add this
to Makefile.am:

MODULES  = foo.scm
GOBJECTS = $(MODULES:%=%.go)

%.go: %.scm | program
 @echo GUILD; ./program compile $< $@


Hope that can help.




Thank you Olivier, this is hugely helpful. So far we thought
we'd need to restructure our set of Scheme files in proper
modules to make separate byte-compilation happen. This works
in my experiments, and can compile several files that are
part of the same module as well, using the #:env argument
of compile-file. Thanks again, much appreciated.

Best regards,
Jean

bug#52230: 'guild compile' and C(++) extensions (in the context of LilyPond)

[Jean Abou Samra]

Hi,

(Cross-posted to guile-user, guile-devel and the debbugs
issue, I'm unsure where this should go.)

In LilyPond, we have now made a development release with
binaries using Guile 2.2. However, a major problem is that
we don't ship Guile bytecode yet. Notably, one problem
to get the bytecode in a build system is that we are
currently forced to use GUILE_AUTO_COMPILE=1 to generate
it -- which means we need to compile the entire suite of
regression tests in order to exercise all files. This
also means spurious test differences when Guile gets
noisy about byte-compilation 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16364).

In summary: it would mean a lot less headache to be
able to use 'guild compile'. Unfortunately, this does
not work. One issue is that our Scheme files are mostly
not Guile modules, but loaded directly with primitive-load-path.
This will be a lot of work to fix, but it is on our end.
However, I don't understand how to get around another
issue, which is how our Scheme code interfaces with C++.

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52230

Basically, if a Scheme file has something like

  (define-public point-stencil (ly:make-stencil "" '(0 . 0) '(0 . 0)))

where ly:make-stencil is a procedure defined in C++,
I can get this file to compile, but I can't get files
using it as a module to compile. Investigation shows
that Guile is apparently trying to load the module
when compiling.

$ cat print.scm
(define-module (print))

(display "Module running!")
$ guild compile print.scm
wrote 
`/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/lilypond/print.scm.go' 


$ cat import.scm
(use-modules (print))
$ guild compile -L . print.scm
wrote 
`/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/lilypond/print.scm.go' 


$ guild compile -L . import.scm
Module running!wrote 
`/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/lilypond/import.scm.go' 




For functions defined in C++, that does not work: they
are added by the entry point in the function that scm_boot_guile
calls, using scm_c_define_gsubr. They aren't defined until
the program is actually run.

So how is 'guild compile' supposed to work with C(++) code?

Thanks in advance,
Jean

bug#52230: Variable not visible to compiler causes compilation failure when importing module

[Jean Abou Samra]

In experiments with using guild for byte compilation
in LilyPond, I am hitting what seems like a bug. When
a variable is not defined declaratively in a way that
makes the compiler aware of it, the module it is
defined in can compile, but modules using it cannot.
Here is an example. fail.scm contains:

(define-module (fail))

variable-coming-from-somewhere-but-not-known-at-compile-time


import.scm is just:

(use-modules (fail))


Compiling fail.scm works:

$ guild compile fail.scm
fail.scm:3:0: warning: possibly unbound variable 
`variable-coming-from-somewhere-but-not-known-at-compile-time'

wrote `/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/.../fail.scm.go'

Compiling import.scm gives this traceback:

$ guild compile -L . import.scm
Backtrace:
In system/base/compile.scm:
   327:39 19 (read-and-compile # #:from _ #:to …)
   261:27 18 (_ _ _)
In ice-9/boot-9.scm:
   2835:4 17 (save-module-excursion #)
In language/scheme/compile-tree-il.scm:
    31:15 16 (_)
In ice-9/psyntax.scm:
  1230:36 15 (expand-top-sequence (#) …)
  1222:19 14 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
   259:10 13 (parse _ (("placeholder" placeholder)) (()) _ c&e (# #) #)
In ice-9/boot-9.scm:
  3927:20 12 (process-use-modules _)
   222:17 11 (map1 (((fail
  3928:31 10 (_ ((fail)))
  3326:17  9 (resolve-interface (fail) #:select _ #:hide _ #:prefix _ …)
In ice-9/threads.scm:
    390:8  8 (_ _)
In ice-9/boot-9.scm:
  3252:13  7 (_)
In ice-9/threads.scm:
    390:8  6 (_ _)
In ice-9/boot-9.scm:
  3536:20  5 (_)
   2835:4  4 (save-module-excursion #)
  3556:26  3 (_)
In unknown file:
   2 (primitive-load-path "fail" #)
In fail.scm:
  3:0  1 (_)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: 
variable-coming-from-somewhere-but-not-known-at-compile-time



I would appreciate any workarounds.

bug#52112: Compilation of macro returning record type fails

[Jean Abou Samra]

Thanks for your reply.

Le 26/11/2021 à 19:54, Taylan Kammer a écrit :

I don't think that's supposed to work.  I find it surprising that
record-type objects are self-evaluating, and in any case they can't
be turned into bytecode.

Your macro could return code that evaluates to a record definition.
Would that solve your use-case?



Yes, that is how I solved it in LilyPond
(https://gitlab.com/lilypond/lilypond/-/merge_requests/1026).

I was also somewhat surprised to see that
record types are self-evaluating. I don't
know where to check in R6RS what the expected
behavior would be. At any rate, it seems that
there is an inconsistency between the interpreter
and the compiler that would warrant resolving
either way.

bug#52112: Compilation of macro returning record type fails

[Jean Abou Samra]

Record types are self-evaluating:

scheme@(guile-user)> (eval (make-record-type 'my-record '()) 
(current-module))

$1 = #

Yet, when a macro returns a record type, Guile fails
to byte-compile the code, even though the execution
(via the evaluator) works fine. Here is a simple example:


(define-macro (my-macro)
  (make-record-type 'my-record-2 '()))

(display (my-macro))
(newline)


Execution log:


$ guile --no-auto-compile test.scm
#

$ guile test.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/jean/test.scm
;;; WARNING: compilation of /home/jean/test.scm failed:
;;; unhandled constant #
#

This is with Guile version 3.0.5.130-5a1e7.

bug#50068: Curried definitions lose docstrings

[Jean Abou Samra]

When a docstring is used in the body of a curried definition,
it ends up on the result of the application of the resulting
curried function, not on the function itself. Example:

(use-modules (ice-9 curried-definitions))

(define ((curried a) b)
  "Docstring of curried"
  'whatever)

(procedure-documentation curried)
=> #f

(procedure-documentation (curried 'whatnot))
=> "Docstring of curried"


This is apparently because Guile translates

(define ((curried a) b)
  ...)

to

(define (curried a)
  (lambda (b)
    ...))

which puts the docstring in the body
of lambda.

Tested with Guile 2.2 and 3.0.5.

bug#50060: The REPL does not honor --no-auto-compile

[Jean Abou Samra]

Even when guile is run with --no-auto-compile, the
REPL still seems to be compiling the source.

$ guile --no-auto-compile
GNU Guile 3.0.5.130-5a1e7
[Legalese…]
scheme@(guile-user)> unbound-variable
;;; :1:0: warning: possibly unbound variable `unbound-variable'
[Backtrace…]

This "possibly unbound variable" warning comes from
compilation (which can be seen by putting the same
code in a script and running with or without auto-compilation).

This is annoying, because in the REPL the code
is run immediately and we don't need the warning
about a "possibly unbound variable" just before
the actual error. In fact, it would seem desirable
to make "no auto-compilation" the default for the
REPL. Code run there is typically not
performance-sensitive.

(Originally reported at 
https://lists.gnu.org/archive/html/guile-user/2021-06/msg00065.html.)

bug#50059: (ice-9 format) undesirably loaded when compiling

[Jean Abou Samra]

Hello,

Please have a look at the following session:

$ cat bug.scm
(format #t "~f\n" 42)
$ guile --no-auto-compile bug.scm
Backtrace:
   1 (primitive-load "/home/jean/repos/guile/bug.scm")
   0 (simple-format #t "~f\n" 42)

ERROR: In procedure simple-format:
In procedure simple-format: FORMAT: Unsupported format option ~f - use 
(ice-9 format) instead

$ guile bug.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/jean/repos/guile/bug.scm
;;; compiled 
/home/jean/.cache/guile/ccache/3.0-LE-8-4.4/home/jean/repos/guile/bug.scm.go

42.0
$ guile bug.scm
Backtrace:
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   5 (apply-smob/0 #)
In ice-9/boot-9.scm:
    724:2  4 (call-with-prompt ("prompt") # …)
In ice-9/eval.scm:
    619:8  3 (_ #(#(#)))
In ice-9/boot-9.scm:
   2835:4  2 (save-module-excursion #)
  4380:12  1 (_)
In unknown file:
   0 (simple-format #t "~f\n" 42)

ERROR: In procedure simple-format:
In procedure simple-format: FORMAT: Unsupported format option ~f - use 
(ice-9 format) instead



As you can see, during the run where compilation
is performed, (ice-9 format) is loaded in the
main environment without being asked for, making
the program execution different, which is somewhat
confusing and error-prone as a program that has been
tested once will no longer work the next time
(thus possibly escaping an automated testing
system).

This is with Guile 3.0.5.130-5a1e7.

Thanks for your attention,
Jean Abou Samra

bug#49686: Confusing presence of #f in error message

[Jean Abou Samra]

Note that this does not happens with Guile 2.2

bug#49686: Confusing presence of #f in error message

[Jean Abou Samra]

Hello,

At the Guile prompt:

scheme@(guile-user)> (if #t (begin (define var 5) (display var))
While compiling expression:
Syntax error:
unknown file:#f:#f: definition in expression context, where definitions 
are not allowed, in form (define var 5)


The "#f:#f:" part in the error message does not look
expected. This is Guile 3.0.5.130-5a1e7.

Best regards,
Jean Abou Samra

bug#49111: (ice-9 session) is undocumented

[Jean Abou Samra]

Hello,

As the title says: the functions found in (ice-9 session) are not 
described anywhere in the Guile documentation, except in the Changelog. 
Some of them are very useful, like procedure-arguments.


Thanks,
Jean Abou Samra