bug#72154: test-error does not work

[Tomas Volf]

Hi,

currently the test-error does not seem to work:

(test-error "should throw" 'foo
  (throw 'bar))

results in

test-name: should throw
location: test.scm:191
source:
+ (test-error "should throw" 'foo (throw 'bar))
expected-error:
+ foo
actual-error:
+ (bar)
result: PASS

According to feedback from mastodon it is not really implemented.  That does not
seem to be documented.  Maybe it would be better to just not export it?  Or it
should throw 'not-implemented instead of just passing?

Have a nice day,
Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#72153: Test name is evaluated twice

[Tomas Volf]

Hello,

given a test of

(test-assert (pk "foo")
  #t)

the test name is evaluated twice:

;;; ("foo")

;;; ("foo")
test-name: foo
location: test.scm:194
source:
+ (test-assert (pk "foo") #t)
actual-value: #t
result: PASS

That does not seem to be allowed by SRFI-64.  I do not believe this is limited
to test-assert, I managed to reproduce with test-equal as well.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#71980: [3.0.10] posix.test uses depcrecated tmpnam

[Tomas Volf]

On 2024-07-07 09:27:14 -0700, Matt Wette wrote:
> With `--disable-tmpnam'  argument to configure, posix.test fails: missing
> `tmpnam`.
>
> patch attached

There also is #71796 as a possible patch (since June 27th), which is arguably
bit smaller (albeit I am biased since I am the author over there ^_^ ).

>
> --- test-suite/tests/posix.test-orig    2024-07-03 15:45:16.352132881 -0700
> +++ test-suite/tests/posix.test    2024-07-07 09:21:53.342855356 -0700
> @@ -361,20 +361,21 @@
>    (status:exit-val (system* "something-that-does-not-exist"
>
>    (pass-if-equal "https://bugs.gnu.org/52835;
> -  "bong\n"
> -    (let ((file (tmpnam)))
> +    "bong\n"
> +    (let ((port (mkstemp "T-XX")))
>    ;; Redirect stdout and stderr to FILE.
>    (define status
> -    (call-with-output-file file
> -  (lambda (port)
> -    (with-output-to-port port
> +    (with-output-to-port port
> +  (lambda ()
> +    (with-error-to-port port
>    (lambda ()
> -    (with-error-to-port port
> -  (lambda ()
> -    (system* "sh" "-c" "echo bong >&2"
> +    (system* "sh" "-c" "echo bong >&2"))
>
>    (and (zero? (status:exit-val status))
> -   (call-with-input-file file get-string-all
> +   (zero? (seek port 0 SEEK_SET))
> +   (let ((contents (get-string-all port)))
> + (close-port port)
> + contents

Interesting.  Does this clean up the temporary file somehow or will it stay
around?

>
>    (pass-if-equal "https://bugs.gnu.org/63024;
>    0

> --- test-suite/tests/posix.test-orig  2024-07-03 15:45:16.352132881 -0700
> +++ test-suite/tests/posix.test   2024-07-07 09:21:53.342855356 -0700
> @@ -361,20 +361,21 @@
>(status:exit-val (system* "something-that-does-not-exist"
>
>(pass-if-equal "https://bugs.gnu.org/52835;
> -  "bong\n"
> -(let ((file (tmpnam)))
> +"bong\n"
> +(let ((port (mkstemp "T-XX")))
>;; Redirect stdout and stderr to FILE.
>(define status
> -(call-with-output-file file
> -  (lambda (port)
> -(with-output-to-port port
> +(with-output-to-port port
> +  (lambda ()
> +(with-error-to-port port
>(lambda ()
> -(with-error-to-port port
> -  (lambda ()
> -(system* "sh" "-c" "echo bong >&2"
> +(system* "sh" "-c" "echo bong >&2"))
>
>(and (zero? (status:exit-val status))
> -   (call-with-input-file file get-string-all
> +   (zero? (seek port 0 SEEK_SET))
> +   (let ((contents (get-string-all port)))
> + (close-port port)
> + contents
>
>(pass-if-equal "https://bugs.gnu.org/63024;
>0

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#71800: [PATCH 1/2] doc: Document #:hide.

[Tomas Volf]

* doc/ref/api-modules.texi (Using Guile Modules): Document #:hide.
---
 doc/ref/api-modules.texi | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index 9f2bba02d..efe739a25 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -196,25 +196,32 @@ whose public interface is found and used.
 @cindex binding renamer
 @lisp
  (MODULE-NAME [#:select SELECTION]
+  [#:hide HIDE]
   [#:prefix PREFIX]
   [#:renamer RENAMER])
 @end lisp
 
 in which case a custom interface is newly created and used.
 @var{module-name} is a list of symbols, as above; @var{selection} is a
-list of selection-specs; @var{prefix} is a symbol that is prepended to
-imported names; and @var{renamer} is a procedure that takes a symbol and
-returns its new name.  A selection-spec is either a symbol or a pair of
-symbols @code{(ORIG . SEEN)}, where @var{orig} is the name in the used
-module and @var{seen} is the name in the using module.  Note that
-@var{seen} is also modified by @var{prefix} and @var{renamer}.
+list of selection-specs; @var{hide} is a list of bindings which should
+not be imported; @var{prefix} is a symbol that is prepended to imported
+names; and @var{renamer} is a procedure that takes a symbol and returns
+its new name.  A selection-spec is either a symbol or a pair of symbols
+@code{(ORIG . SEEN)}, where @var{orig} is the name in the used module
+and @var{seen} is the name in the using module.  Note that @var{seen} is
+also modified by @var{prefix} and @var{renamer}.
 
-The @code{#:select}, @code{#:prefix}, and @code{#:renamer} clauses are
-optional.  If all are omitted, the returned interface has no bindings.
-If the @code{#:select} clause is omitted, @var{prefix} and @var{renamer}
-operate on the used module's public interface.
+The @code{#:select}, @code{#:hide}, @code{#:prefix}, and
+@code{#:renamer} clauses are optional.  If all are omitted, the returned
+interface has no bindings.  If the @code{#:select} clause is omitted,
+@var{prefix} and @var{renamer} operate on the used module's public
+interface.
 
-In addition to the above, @var{spec} can also include a @code{#:version} 
+The @code{#:hide} operates on list of bindings in the module being
+imported, before any renaming is performed.  If both @code{#:select} and
+@code{#:hide} contain a binding, the @code{#:hide} wins.
+
+In addition to the above, @var{spec} can also include a @code{#:version}
 clause, of the form:
 
 @lisp
-- 
2.45.1

bug#71800: [PATCH 2/2] doc: Fix implication of omitting optional arguments.

[Tomas Volf]

According to the previous wording, omitting all optional arguments led
to empty interface.  That however was not the case and was only a
documentation bug (as confirmed by wingo on IRC).  So let us fix that.

* doc/ref/api-modules.texi (Using Guile Modules): Fix implication of
omitting optional arguments.
---
 doc/ref/api-modules.texi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index efe739a25..115ebbac2 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -212,10 +212,10 @@ and @var{seen} is the name in the using module.  Note 
that @var{seen} is
 also modified by @var{prefix} and @var{renamer}.
 
 The @code{#:select}, @code{#:hide}, @code{#:prefix}, and
-@code{#:renamer} clauses are optional.  If all are omitted, the returned
-interface has no bindings.  If the @code{#:select} clause is omitted,
-@var{prefix} and @var{renamer} operate on the used module's public
-interface.
+@code{#:renamer} clauses are optional.  If all are omitted, this form
+behaves identically to the previous one.  If the @code{#:select} clause
+is omitted, @var{prefix} and @var{renamer} operate on the used module's
+public interface.
 
 The @code{#:hide} operates on list of bindings in the module being
 imported, before any renaming is performed.  If both @code{#:select} and
-- 
2.45.1

bug#71800: [PATCH 0/2] Improve documentation about using modules.

[Tomas Volf]

Document the #:hide argument.  Correct text for implication of leaving
all optional arguments out.

Tomas Volf (2):
  doc: Document #:hide.
  doc: Fix implication of omitting optional arguments.

 doc/ref/api-modules.texi | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

--
2.45.1

bug#71798: [PATCH 1/2] doc: Document #:hide.

[Tomas Volf]

* doc/ref/api-modules.texi (Using Guile Modules): Document #:hide.
---
 doc/ref/api-modules.texi | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index 9f2bba02d..efe739a25 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -196,25 +196,32 @@ whose public interface is found and used.
 @cindex binding renamer
 @lisp
  (MODULE-NAME [#:select SELECTION]
+  [#:hide HIDE]
   [#:prefix PREFIX]
   [#:renamer RENAMER])
 @end lisp
 
 in which case a custom interface is newly created and used.
 @var{module-name} is a list of symbols, as above; @var{selection} is a
-list of selection-specs; @var{prefix} is a symbol that is prepended to
-imported names; and @var{renamer} is a procedure that takes a symbol and
-returns its new name.  A selection-spec is either a symbol or a pair of
-symbols @code{(ORIG . SEEN)}, where @var{orig} is the name in the used
-module and @var{seen} is the name in the using module.  Note that
-@var{seen} is also modified by @var{prefix} and @var{renamer}.
+list of selection-specs; @var{hide} is a list of bindings which should
+not be imported; @var{prefix} is a symbol that is prepended to imported
+names; and @var{renamer} is a procedure that takes a symbol and returns
+its new name.  A selection-spec is either a symbol or a pair of symbols
+@code{(ORIG . SEEN)}, where @var{orig} is the name in the used module
+and @var{seen} is the name in the using module.  Note that @var{seen} is
+also modified by @var{prefix} and @var{renamer}.
 
-The @code{#:select}, @code{#:prefix}, and @code{#:renamer} clauses are
-optional.  If all are omitted, the returned interface has no bindings.
-If the @code{#:select} clause is omitted, @var{prefix} and @var{renamer}
-operate on the used module's public interface.
+The @code{#:select}, @code{#:hide}, @code{#:prefix}, and
+@code{#:renamer} clauses are optional.  If all are omitted, the returned
+interface has no bindings.  If the @code{#:select} clause is omitted,
+@var{prefix} and @var{renamer} operate on the used module's public
+interface.
 
-In addition to the above, @var{spec} can also include a @code{#:version} 
+The @code{#:hide} operates on list of bindings in the module being
+imported, before any renaming is performed.  If both @code{#:select} and
+@code{#:hide} contain a binding, the @code{#:hide} wins.
+
+In addition to the above, @var{spec} can also include a @code{#:version}
 clause, of the form:
 
 @lisp
-- 
2.45.1

bug#71799: [PATCH 2/2] doc: Fix implication of omitting optional arguments.

[Tomas Volf]

According to the previous wording, omitting all optional arguments led
to empty interface.  That however was not the case and was only a
documentation bug (as confirmed by wingo on IRC).  So let us fix that.

* doc/ref/api-modules.texi (Using Guile Modules): Fix implication of
omitting optional arguments.
---
 doc/ref/api-modules.texi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index efe739a25..115ebbac2 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -212,10 +212,10 @@ and @var{seen} is the name in the using module.  Note 
that @var{seen} is
 also modified by @var{prefix} and @var{renamer}.
 
 The @code{#:select}, @code{#:hide}, @code{#:prefix}, and
-@code{#:renamer} clauses are optional.  If all are omitted, the returned
-interface has no bindings.  If the @code{#:select} clause is omitted,
-@var{prefix} and @var{renamer} operate on the used module's public
-interface.
+@code{#:renamer} clauses are optional.  If all are omitted, this form
+behaves identically to the previous one.  If the @code{#:select} clause
+is omitted, @var{prefix} and @var{renamer} operate on the used module's
+public interface.
 
 The @code{#:hide} operates on list of bindings in the module being
 imported, before any renaming is performed.  If both @code{#:select} and
-- 
2.45.1

bug#71796: [PATCH] Do not depend on tmpnam in posix.test.

[Tomas Volf]

`tmpnam' is a deprecated procedure that can be excluded during a
configure (`--disable-tmpnam').  There currently was a single test
relying on it, and therefore failing is such configuration.  This commit
switches to mkstemp instead.

* test-suite/tests/posix.test ("system*"): Use mkstemp instead of
tmpnam.
---
 test-suite/tests/posix.test | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/test-suite/tests/posix.test b/test-suite/tests/posix.test
index 18dad8902..0d75eb145 100644
--- a/test-suite/tests/posix.test
+++ b/test-suite/tests/posix.test
@@ -362,7 +362,8 @@
 
   (pass-if-equal "https://bugs.gnu.org/52835;
   "bong\n"
-(let ((file (tmpnam)))
+(let* ((port (mkstemp "T-XX"))
+   (file (port-filename port)))
   ;; Redirect stdout and stderr to FILE.
   (define status
 (call-with-output-file file
@@ -373,8 +374,9 @@
   (lambda ()
 (system* "sh" "-c" "echo bong >&2"
 
+  (delete-file file)
   (and (zero? (status:exit-val status))
-   (call-with-input-file file get-string-all
+   (get-string-all port
 
   (pass-if-equal "https://bugs.gnu.org/63024;
   0
-- 
2.45.1

bug#71262: [PATCH] Try to install C.UTF-8 locale before falling back to C.

[Tomas Volf]

If user does not have LANG or LC_ALL set (as does often happen in
various sandboxes) glibc will just install C locale.  That is fine (and
permissible by POSIX), however in Guile's context it is of a mixed
usefulness due to the absence of UTF-8 support.

This commit changes the locale auto-installation logic to attempt
C.UTF-8 locale first (if user did not request another one).

User can still get C locale by either GUILE_INSTALL_LOCALE=0 or LANG=C.
This default should be more useful in this day and age, at least for
Guile users.

* libguile/guile.c (should_install_default_locale): New function.
(main)[should_install_locale ()]: Try to install C.UTF-8 before falling
back to C.
* doc/ref/guile-invoke.texi (Environment Variables): Document the
change.
---
 doc/ref/guile-invoke.texi |  6 --
 libguile/guile.c  | 19 +--
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/doc/ref/guile-invoke.texi b/doc/ref/guile-invoke.texi
index 856bce7b8..e08d78200 100644
--- a/doc/ref/guile-invoke.texi
+++ b/doc/ref/guile-invoke.texi
@@ -344,8 +344,10 @@ variable.  By default, the history file is 
@file{$HOME/.guile_history}.
 This is a flag that can be used to tell Guile whether or not to install
 the current locale at startup, via a call to @code{(setlocale LC_ALL
 "")}@footnote{The @code{GUILE_INSTALL_LOCALE} environment variable was
-ignored in Guile versions prior to 2.0.9.}.  @xref{Locales}, for more
-information on locales.
+ignored in Guile versions prior to 2.0.9.}.  If no explicit locale is
+set by the user (via @code{LC_ALL} or @code{LANG} environment
+variables), @samp{C.UTF-8} is tried before falling back to @samp{C}.
+@xref{Locales}, for more information on locales.
 
 You may explicitly indicate that you do not want to install
 the locale by setting @env{GUILE_INSTALL_LOCALE} to @code{0}, or
diff --git a/libguile/guile.c b/libguile/guile.c
index 8283ef6fa..a4ad10400 100644
--- a/libguile/guile.c
+++ b/libguile/guile.c
@@ -80,6 +80,16 @@ should_install_locale (void)
   return get_integer_from_environment ("GUILE_INSTALL_LOCALE", 1);
 }
 
+static int
+should_install_default_locale (void)
+{
+  /* This logic is derived from a precedence order described in section
+ 8.2 of The Open Group Base Specifications Issue 7, 2018 edition. */
+  const char *lang   = getenv ("LANG");
+  const char *lc_all = getenv ("LC_ALL");
+  return (!lc_all || *lc_all == 0) && (!lang || *lang == 0);
+}
+
 int
 main (int argc, char **argv)
 {
@@ -88,8 +98,13 @@ main (int argc, char **argv)
  error messages, use the right locale.  See
  
  for the rationale.  */
-  if (should_install_locale () && setlocale (LC_ALL, "") == NULL)
-fprintf (stderr, "guile: warning: failed to install locale\n");
+  if (should_install_locale ()) {
+if (should_install_default_locale ()
+&& setlocale(LC_ALL, "C.UTF-8") != NULL)
+  ;
+else if (setlocale (LC_ALL, "") == NULL)
+  fprintf (stderr, "guile: warning: failed to install locale\n");
+  }
 
   scm_boot_guile (argc, argv, inner_main, 0);
   return 0; /* never reached */
-- 
2.41.0

bug#71047: [PATCH] doc: Recommend alist-copy instead of list-copy.

[Tomas Volf]

The current recommendation of `list-copy' is not right and does not lead
to preserving the original list:

scheme@(guile-user)> (define x (list (cons 'a 1) (cons 'b 2)))
scheme@(guile-user)> (define y (list-copy x))
scheme@(guile-user)> (assq-set! y 'b 3)
$1 = ((a . 1) (b . 3))
scheme@(guile-user)> x
$2 = ((a . 1) (b . 3))

Correct approach seems to be use `alist-copy' from SRFI-1 leading to the
expected behavior of:

scheme@(guile-user)> ,use (srfi srfi-1)
scheme@(guile-user)> (define x (list (cons 'a 1) (cons 'b 2)))
scheme@(guile-user)> (define y (alist-copy x))
scheme@(guile-user)> (assq-set! y 'b 3)
$1 = ((a . 1) (b . 3))
scheme@(guile-user)> x
$2 = ((a . 1) (b . 2))

* doc/ref/api-data.texi (Adding or Setting Alist Entries): Recommend
`alist-copy'.
---
 doc/ref/api-data.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/ref/api-data.texi b/doc/ref/api-data.texi
index 3b9933d97..81552dec3 100644
--- a/doc/ref/api-data.texi
+++ b/doc/ref/api-data.texi
@@ -9509,7 +9509,7 @@ difference to you.
 If you need to keep the old value of an association list in a form
 independent from the list that results from modification by
 @code{acons}, @code{assq-set!}, @code{assv-set!} or @code{assoc-set!},
-use @code{list-copy} to copy the old association list before modifying
+use @code{alist-copy} to copy the old association list before modifying
 it.
 
 @deffn {Scheme Procedure} acons key value alist
-- 
2.41.0

bug#68504: [PATCH v3] Add copy-on-write support to scm_copy_file.

[Tomas Volf]

On 2024-03-12 14:06:34 +0100, Ludovic Courtès wrote:
>
> Finally pushed as e1690f3fd251d69b3687ec12c6f4b41034047f0f.  Note that I
> added copyright lines for you, let me know if I got it wrong.

Thank you for merging it, and thanks for the copyright, looks correct :)

> As a followup, we should add support for ‘copy_file_range’ when FICLONE
> cannot be used; glibc supports it on all platforms but it returns ENOSYS
> on GNU/Hurd currently.
>
> WDYT?

Sure, I am willing to do my part.  I managed to find this blog post[0], so after
some minor troubles I did manage to get a VM with GNU/Hurd running.  Next I will
read up on copy_file_range and try to put together a patch.

Just to make sure, your idea here is exactly what?  Always try to use
copy_file_range before the regular copy?  So the flow would be

For 'always case:

CoW  ---fail-->  FAIL

For 'auto case:

CoW  ---fail-->  copy_file_range  ---fail-->  current copy  ---fail-->  FAIL

For 'never case:

copy_file_range  ---fail-->  current copy  ---fail-->  FAIL

Is that an accurate summary?  Or did you mean only as a fallback for the CoW, so
only for 'auto, but not for the 'never?

Tomas

0: 
https://guix.gnu.org/en/blog/2020/a-hello-world-virtual-machine-running-the-hurd/

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#69730: Segfault in (spawn) when passed wrong port

[Tomas Volf]

Greetings,

When I pass #f to spawn as a port, it just segfaults:

$ guile -c '(spawn "true" (list "") #:error #f)'
Segmentation fault

Ignoring the fact whether #f should be an accepted value (I think it would be
more elegant and portable then (open-output-file "/dev/null")), I would not
expect invalid value in an interpreted language to cause a segfault.  If the
value is indeed invalid, it should throw an error.

Original report: https://emacs.ch/@kakafarm/112075808549752692

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#69438: basename faulty with nul and suffix

[tomas]

On Tue, Feb 27, 2024 at 08:14:58PM +, Zefram via Bug reports for GUILE, 
GNU's Ubiquitous Extension Language wrote:
> Trying out the basename function in Guile 3.0.9:
> 
> scheme@(guile-user)> (basename "foo/bar")
> $1 = "bar"
> scheme@(guile-user)> (basename "foo/bar" "r")
> $2 = "ba"
> scheme@(guile-user)> (basename "foo/bar" "x")
> $3 = "bar"
> scheme@(guile-user)> (basename "foo/bar\0baz/quux")
> $4 = "bar"
> scheme@(guile-user)> (basename "foo/bar\0baz/quux" "r")
> $5 = "bar"
> scheme@(guile-user)> (basename "foo/bar\0baz/quux" "x")
> $6 = "ba"
> 
> The first three cases here show the function operating correctly on a
> mundane pathname string.

Hm. The functions are clearly designated as POSIX. In POSIX, \0 is
explicitly excluded as a legal character in paths [1] [2]. I guess
the implementation is just passing the buck to the OS's basename(3).

Arguably, it'd be friendlier for the function to throw an error,
but then, it'd be inconsistent with the OS. You can't win :-)

Perhaps, a note in the docs wouldn't harm, though.

Cheers

[1] 
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266
[2] 
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_169
-- 
t


signature.asc
Description: PGP signature

bug#68504: [PATCH] Add copy-on-write support to scm_copy_file.

[Tomas Volf]

On 2024-01-24 11:26:56 +0100, Ludovic Courtès wrote:
>
> The patch looks great (and very useful) to me, modulo one issue:
>
> > -SCM_API SCM scm_copy_file (SCM oldfile, SCM newfile);
> > +SCM_API SCM scm_copy_file (SCM oldfile, SCM newfile, SCM rest);
>
> Since this is a public interface, we cannot change this function’s
> signature during the 3.0 stable series.
>
> Thus, I would suggest keeping the public ‘scm_copy_file’ unchanged and
> internally having a three-argument variant.  The Scheme-level
> ‘copy-file’ would map to that three-argument variant.  (See how
> ‘scm_pipe’ and ‘scm accept’ as examples.)

That is a very good point, which I did not realize at all.  Thanks to the
examples you provided, it was not that hard to do (well, assuming I did it
right).

> Could you send an updated patch?

Done.  However now that I read it after myself, I overlooked this occurrence of
scm_copy_file in the commit message:

This commit adds support for this feature into our
copy-file (scm_copy_file) procedure.  Same as `cp', it defaults to

So I just sent v3 right after v2, sorry for the noise, should have been more
careful.

>
> BTW, copyright assignment to the FSF is now optional but encouraged.
> Please see
> <https://lists.gnu.org/archive/html/guile-devel/2022-10/msg8.html>.

Since it is optional, I will currently opt into not doing the assignment, I do
not like the concept that much.  I will try to find time to actually form an
opinion based on facts.

Have a nice day,
Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#68504: [PATCH v3] Add copy-on-write support to scm_copy_file.

[Tomas Volf]

On modern file-systems (BTRFS, ZFS) it is possible to copy a file using
copy-on-write method.  For large files it has the advantage of being
much faster and saving disk space (since identical extents are not
duplicated).  This feature is stable and for example coreutils' `cp'
does use it automatically (see --reflink).

This commit adds support for this feature into our copy-file procedure.
Same as `cp', it defaults to 'auto, meaning the copy-on-write is
attempted, and in case of failure the regular copy is performed.

No tests are provided, because the behavior depends on the system,
underlying file-system and its configuration.  That makes it challenging
to write a test for it.  Manual testing was performed instead:

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB36.00KiB   0.00B  /tmp/cow

$ cat cow-test.scm
(copy-file "/tmp/cow" "/tmp/cow-unspecified")
(copy-file "/tmp/cow" "/tmp/cow-always" #:copy-on-write 'always)
(copy-file "/tmp/cow" "/tmp/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/tmp/cow-never" #:copy-on-write 'never)
(copy-file "/tmp/cow" "/dev/shm/cow-unspecified")
(copy-file "/tmp/cow" "/dev/shm/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/dev/shm/cow-never" #:copy-on-write 'never)
$ ./meta/guile -s cow-test.scm

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB   0.00B36.00KiB  /tmp/cow
  36.00KiB   0.00B36.00KiB  /tmp/cow-always
  36.00KiB   0.00B36.00KiB  /tmp/cow-auto
  36.00KiB36.00KiB   0.00B  /tmp/cow-never
  36.00KiB   0.00B36.00KiB  /tmp/cow-unspecified

$ sha1sum /tmp/cow* /dev/shm/cow*
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-always
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-unspecified
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-unspecified

This commit also adds to new failure modes for (copy-file).

Failure to copy-on-write when 'always was passed in:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'always)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: copy-on-write failed: Invalid cross-device link

Passing in invalid value for the #:copy-on-write keyword argument:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'nevr)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: invalid value for #:copy-on-write: nevr

* NEWS: Add note for copy-file supporting copy-on-write.
* configure.ac: Check for linux/fs.h.
* doc/ref/posix.texi (File System)[copy-file]: Document the new
signature.
* libguile/filesys.c (clone_file): New function cloning a file using
FICLONE, if supported.
(k_copy_on_write): New keyword.
(sym_always, sym_auto, sym_never): New symbols.
(scm_copy_file2): Renamed from scm_copy_file.  New #:copy-on-write
keyword argument.  Attempt copy-on-write copy by default.
(scm_copy_file): Call scm_copy_file2.
* libguile/filesys.h: Add scm_copy_file2 as SCM_INTERNAL.
---
v2: Introduce scm_copy_file2 in order to preserve backwards compatibility.

v3: Remove mention of scm_copy_file from the commit message.

 NEWS   |  9 +
 configure.ac   |  1 +
 doc/ref/posix.texi |  9 -
 libguile/filesys.c | 82 +++---
 libguile/filesys.h |  1 +
 5 files changed, 89 insertions(+), 13 deletions(-)

diff --git a/NEWS b/NEWS
index b319404d7..9147098c9 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,15 @@ definitely unused---this is notably the case for modules 
that are only
 used at macro-expansion time, such as (srfi srfi-26).  In those cases,
 the compiler reports it as "possibly unused".

+** copy-file now supports copy-on-write
+
+The copy-file procedure now takes an additional keyword argument,
+#:copy-on-write, specifying whether copy-on-write should be done, if the
+underlying file-system supports it.  Possible values are 'always, 'auto
+and 'never, with 'auto being the default.
+
+This speeds up copying large files a lot while saving the disk space.
+
 * Bug fixes

 ** (ice-9 suspendable-ports) incorrect UTF-8 decoding
diff --git a/configure.ac b/configure.ac
index d0a2dc79b..c46586e9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -418,6 +418,7 @@ AC_SUBST([SCM_I_GSC_HAVE_STRUCT_DIRENT64])
 #   sys/sendfile.h - non-POSIX, found in glibc
 #
 AC_CHECK_HEADERS([complex.h fenv.h io.h memory.h process.h \
+linux/fs.h \
 sys/dir.h sys/ioctl.h sys/select.h \
 sys/time.h sys/timeb.h sys/times.h sys/stdtypes.h sys/types.h \
 sys/utime.h 

bug#68504: [PATCH v2] Add copy-on-write support to scm_copy_file.

[Tomas Volf]

On modern file-systems (BTRFS, ZFS) it is possible to copy a file using
copy-on-write method.  For large files it has the advantage of being
much faster and saving disk space (since identical extents are not
duplicated).  This feature is stable and for example coreutils' `cp'
does use it automatically (see --reflink).

This commit adds support for this feature into our
copy-file (scm_copy_file) procedure.  Same as `cp', it defaults to
'auto, meaning the copy-on-write is attempted, and in case of failure
the regular copy is performed.

No tests are provided, because the behavior depends on the system,
underlying file-system and its configuration.  That makes it challenging
to write a test for it.  Manual testing was performed instead:

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB36.00KiB   0.00B  /tmp/cow

$ cat cow-test.scm
(copy-file "/tmp/cow" "/tmp/cow-unspecified")
(copy-file "/tmp/cow" "/tmp/cow-always" #:copy-on-write 'always)
(copy-file "/tmp/cow" "/tmp/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/tmp/cow-never" #:copy-on-write 'never)
(copy-file "/tmp/cow" "/dev/shm/cow-unspecified")
(copy-file "/tmp/cow" "/dev/shm/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/dev/shm/cow-never" #:copy-on-write 'never)
$ ./meta/guile -s cow-test.scm

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB   0.00B36.00KiB  /tmp/cow
  36.00KiB   0.00B36.00KiB  /tmp/cow-always
  36.00KiB   0.00B36.00KiB  /tmp/cow-auto
  36.00KiB36.00KiB   0.00B  /tmp/cow-never
  36.00KiB   0.00B36.00KiB  /tmp/cow-unspecified

$ sha1sum /tmp/cow* /dev/shm/cow*
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-always
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-unspecified
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-unspecified

This commit also adds to new failure modes for (copy-file).

Failure to copy-on-write when 'always was passed in:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'always)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: copy-on-write failed: Invalid cross-device link

Passing in invalid value for the #:copy-on-write keyword argument:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'nevr)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: invalid value for #:copy-on-write: nevr

* NEWS: Add note for copy-file supporting copy-on-write.
* configure.ac: Check for linux/fs.h.
* doc/ref/posix.texi (File System)[copy-file]: Document the new
signature.
* libguile/filesys.c (clone_file): New function cloning a file using
FICLONE, if supported.
(k_copy_on_write): New keyword.
(sym_always, sym_auto, sym_never): New symbols.
(scm_copy_file2): Renamed from scm_copy_file.  New #:copy-on-write
keyword argument.  Attempt copy-on-write copy by default.
(scm_copy_file): Call scm_copy_file2.
* libguile/filesys.h: Add scm_copy_file2 as SCM_INTERNAL.
---
v2: Introduce scm_copy_file2 in order to preserve backwards compatibility.

 NEWS   |  9 +
 configure.ac   |  1 +
 doc/ref/posix.texi |  9 -
 libguile/filesys.c | 82 +++---
 libguile/filesys.h |  1 +
 5 files changed, 89 insertions(+), 13 deletions(-)

diff --git a/NEWS b/NEWS
index b319404d7..9147098c9 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,15 @@ definitely unused---this is notably the case for modules 
that are only
 used at macro-expansion time, such as (srfi srfi-26).  In those cases,
 the compiler reports it as "possibly unused".

+** copy-file now supports copy-on-write
+
+The copy-file procedure now takes an additional keyword argument,
+#:copy-on-write, specifying whether copy-on-write should be done, if the
+underlying file-system supports it.  Possible values are 'always, 'auto
+and 'never, with 'auto being the default.
+
+This speeds up copying large files a lot while saving the disk space.
+
 * Bug fixes

 ** (ice-9 suspendable-ports) incorrect UTF-8 decoding
diff --git a/configure.ac b/configure.ac
index d0a2dc79b..c46586e9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -418,6 +418,7 @@ AC_SUBST([SCM_I_GSC_HAVE_STRUCT_DIRENT64])
 #   sys/sendfile.h - non-POSIX, found in glibc
 #
 AC_CHECK_HEADERS([complex.h fenv.h io.h memory.h process.h \
+linux/fs.h \
 sys/dir.h sys/ioctl.h sys/select.h \
 sys/time.h sys/timeb.h sys/times.h sys/stdtypes.h sys/types.h \
 sys/utime.h unistd.h utime.h pwd.h grp.h sys/utsname.h \

bug#68505: [PATCH v2] Add more detailed instructions into the HACKING file.

[Tomas Volf]

Thank you for the review.

On 2024-01-24 11:18:27 +0100, Ludovic Courtès wrote:
> > +You can spawn a shell with all the required dependencies using GNU Guix
> > +by running the following command:
> > +
> > +guix shell -D -f guix.scm --pure
>
> I would suggest running:
>
>   guix shell -CP
>
> (Currently ‘README’ suggests ‘guix shell’.)
>
> The rationale is: it’s shorter, using a container avoids interference,
> and ‘-P’ works well with ‘config.cache’ & co. (because the cached file
> names then are $HOME/.guix-profile/…).
>
> WDYT?

Modified as agreed on irc.  I am not convinced on the -P, but I defer to your
judgment on this.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#68505: [PATCH v3] Add more detailed instructions into the HACKING file.

[Tomas Volf]

Until now, the ./meta/guile was not mentioned anywhere, and therefore it
was not obvious how to run the locally compiled Guile without installing
it.

While modifying the file, I took the liberty to also mention a bit about
compiling Guile using Guix.

Finally, the header lines where cleaned up, ensuring all of them end at
70 and have a leading space.

* HACKING (Hacking It Yourself): Add Guix instructions.  Add a note
about meta/guile script.
(Sample GDB Initialization File),
(Naming conventions): Clean up the header line.
---
v2:
Add note regarding JIT and GNU Hurd.  Add note regarding -fexcess-precision.
Add --disable-static and explain it.

v3:
Use -CP instead of --pure.

 HACKING | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/HACKING b/HACKING
index 387643bf7..94fba199c 100644
--- a/HACKING
+++ b/HACKING
@@ -26,6 +26,40 @@ http://www.gnu.org/software/guile/mail/mail.html for more 
info.

 Hacking It Yourself ==

+You can spawn a shell with all the required dependencies using GNU Guix
+by running the following command:
+
+guix shell -D -f guix.scm --pure
+
+In this way, you can effortlessly compile Guile from the Git checkout
+with just these three lines:
+
+guix shell -CP -D -f guix.scm -- ./autogen.sh
+guix shell -CP -D -f guix.scm -- ./configure \
+--enable-mini-gmp --disable-static
+guix shell -CP -D -f guix.scm -- make
+
+Disabling of the static libraries is optional, but it does speed up the
+builds, and you are unlikely to need them for local development.
+
+  Note: Currently JIT causes Guile to crash in obscure ways on GNU Hurd,
+so on that platform you want to also pass the --disable-jit flag
+to the configure script.
+
+  Note: On any i*86 architecture, you also need to pass in the compiler
+flag -fexcess-precision=standard in order to get the test suite
+to pass.  That can be done by passing an additional argument to
+the configure script:
+ CFLAGS='-g -O2 -fexcess-precision=standard'
+
+Once that finishes, you can execute your newly compiled Guile using the
+./meta/guile script:
+
+$ guix shell -CP -D -f guix.scm -- ./meta/guile -v | head -n1
+guile (GNU Guile) 3.0.9.139-d7cf5-dirty
+
+For more manual approach, read on.
+
 When Guile is obtained from Git, a few extra steps must be taken
 before the usual configure, make, make install.  You will need to have
 up-to-date versions of the tools as listed below, correctly installed.
@@ -73,7 +107,7 @@ Here is the authoritative list of tool/version/platform 
tuples that
 have been known to cause problems, and a short description of the problem.


-Sample GDB Initialization File=
+Sample GDB Initialization File ===

 In GDB, you probably want to load the gdbinit file included with Guile,
 which defines a number of GDB helpers to inspect Scheme values.
@@ -215,7 +249,7 @@ The goal is to reduce (and over time, eliminate) spurious 
diffs.
 For Emacs users:
   (add-hook 'before-save-hook 'delete-trailing-whitespace)

-Naming conventions =
+Naming conventions ===

 We use certain naming conventions to structure the considerable number
 of global identifiers.  All identifiers should be either all lower
--
2.41.0

bug#68507: [PATCH] doc: Fix example in list-transduce example.

[Tomas Volf]

While the `.' might be correct from a grammatical point of view (I do
not know), it turns the example into invalid scheme code, which is not
ideal.  New users (like me) might try to copy the whole line and wonder
why it does not work (like I did).  So delete it.

* doc/ref/srfi-modules.texi (SRFI-171 General Discussion): Delete the
trailing . from the example.
---
 doc/ref/srfi-modules.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 0cdf56923..09b591e89 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -5748,7 +5748,7 @@ reducer with result-so-far and the maybe-transformed 
input.
 A simple example is as following:
 
 @example
-(list-transduce (tfilter odd?) + '(1 2 3 4 5)).
+(list-transduce (tfilter odd?) + '(1 2 3 4 5))
 @end example
 
 This first returns a transducer filtering all odd
-- 
2.41.0

bug#68506: [PATCH v3] doc: Extend documentation for (ice-9 match)

[Tomas Volf]

Extend the documentation for (ice-9 match) module with explanations of
some of the patterns and also provide more examples for them.  That
should make it more useful for people trying to use the module for the
first time just based on the documentation.

* doc/ref/match.texi (Pattern Matching): Explain some patterns and
provide more examples.
---
v2:
* drop myself from THANKS file, someone else can thank me if they want to
* remove most of unnecessary lets
* spelling and wording fixes
* add new paragraph describing (and ...)

v3:
Attempt to resolve feedback regarding the let usage:

> Whether you choose to to inline it or not, please do it consistently.

I removed all of them except two.  The very first one, since in this case I
believe it leads to the comments being more readable:

(let ((l '(hello (world
  (match l   ;; <- the input object
(('hello (who))  ;; <- the pattern
 who)))  ;; <- the expression evaluated upon matching

It also creates a nice contrast with the second example, which now also
demonstrates that you do not have to use the let, and the object can be inline.

Second case is the "more complex example", where I believe the let again leads
to significantly more readable code (keeping alice and bob together) to outweigh
the perceived inconsistency.

If requested, I can of course nuke these two usages as well.

Previous discussion happened on the mailing list.

 doc/ref/match.texi | 90 +++---
 1 file changed, 86 insertions(+), 4 deletions(-)

diff --git a/doc/ref/match.texi b/doc/ref/match.texi
index f5ea43118..774fc856e 100644
--- a/doc/ref/match.texi
+++ b/doc/ref/match.texi
@@ -50,10 +50,9 @@ list---i.e., the symbol @code{world}.  An error would be 
raised if
 The same object can be matched against a simpler pattern:
 
 @example
-(let ((l '(hello (world
-  (match l
-((x y)
- (values x y
+(match '(hello (world))
+  ((x y)
+   (values x y)))
 @result{} hello
 @result{} (world)
 @end example
@@ -181,6 +180,89 @@ The names @code{quote}, @code{quasiquote}, @code{unquote},
 @code{or}, @code{not}, @code{set!}, @code{get!}, @code{...}, and
 @code{___} cannot be used as pattern variables.
 
+@code{string}, @code{number}, and others refer to literal strings,
+numbers, and others.  Therefore, the pattern @code{string} binds the
+value to the identifier @code{string} and the pattern @code{"string"}
+matches if the value is @code{"string"}.  An example demonstrating this
+(by using very bad naming):
+
+@example
+(match "foo"
+  (number number))
+@result{} "foo"
+@end example
+
+The field operator (@code{(= field pat)}) has no relation to the fields
+of records.  The @code{field} should be an expression evaluating to a
+procedure taking a single argument, and @code{pat} is matched against
+the return value.  Simple example:
+
+@example
+(match '(1 2)
+  ((= cadr x)
+   x))
+@result{} 2
+@end example
+
+The record operator(@code{($ record-name pat_1 ... pat_n)}) can be used
+for matching records.  Patterns are matched against the slots in order,
+not all have to be present, and there is no way to skip a slot.  An
+example demonstrating the usage:
+
+@example
+(define-record-type 
+  (make-foo bar baz zab)
+  foo?
+  (bar foo-bar)
+  (baz foo-baz)
+  (zab foo-zab))
+
+(match (make-foo 1 '2 "three")
+  ;; Make sure obj is a  instance, with bar slot being a number
+  ;; and zab slot being a string.  We do not care about baz slot,
+  ;; therefore we use _ to match anything.
+  (($  (? number?) _ (? string?))
+   "ok"))
+@result{} "ok"
+@end example
+
+If you need to ensure that a value is of a specific record type and at
+the same time bind it to a variable, the record operator will not be
+enough by itself, since you can only capture the fields.  You would need
+to combine it with other patterns, for example @code{(? foo? obj)}.
+
+When you need to apply multiple patterns, or a check and a pattern, you
+can use (@code{(? predicate pat_1 ... pat_n)}) for that.  The patterns
+are evaluated as if in the @code{(and ...)}.  If, for example, you want
+to check whether something is a symbol and at the same time bind the
+value to a variable, it could look like this:
+
+@example
+(match '(delete . some-id)
+  (('delete . (? symbol? id))
+   ;; We now could, for example, use the id to delete from some alist.
+   id))
+@result{} some-id
+@end example
+
+The @code{(and ...)} is of course useful as well, especially if no
+predicate is required.  While you could use @code{(const #t)} as the
+predicate, using @code{(and ...)} is better.  For example, capturing an
+object iff it is a list of at least two items can be done like this:
+
+@example
+(match '(foo baz bar)
+  ((and (a b ...) lst)
+   lst))
+@result{} (foo baz bar)
+@end example
+
+@c FIXME: Remove this remark once everything is clearly described and
+@c consulting the comment is no longer necessary.
+If you are unclear about how something works, you can try consulting the

bug#68505: [PATCH v2] Add more detailed instructions into the HACKING file.

[Tomas Volf]

Until now, the ./meta/guile was not mentioned anywhere, and therefore it
was not obvious how to run the locally compiled Guile without installing
it.

While modifying the file, I took the liberty to also mention a bit about
compiling Guile using Guix.

Finally, the header lines where cleaned up, ensuring all of them end at
70 and have a leading space.

* HACKING (Hacking It Yourself): Add Guix instructions.  Add a note
about meta/guile script.
(Sample GDB Initialization File),
(Naming conventions): Clean up the header line.
---
v2:
Add note regarding JIT and GNU Hurd.  Add note regarding -fexcess-precision.
Add --disable-static and explain it.

Previous discussion happened on the mailing list.

 HACKING | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/HACKING b/HACKING
index 387643bf7..5926fb275 100644
--- a/HACKING
+++ b/HACKING
@@ -26,6 +26,40 @@ http://www.gnu.org/software/guile/mail/mail.html for more 
info.
 
 Hacking It Yourself ==
 
+You can spawn a shell with all the required dependencies using GNU Guix
+by running the following command:
+
+guix shell -D -f guix.scm --pure
+
+In this way, you can effortlessly compile Guile from the Git checkout
+with just these three lines:
+
+guix shell -D -f guix.scm --pure -- ./autogen.sh
+guix shell -D -f guix.scm --pure -- ./configure \
+--enable-mini-gmp --disable-static
+guix shell -D -f guix.scm --pure -- make
+
+Disabling of the static libraries is optional, but it does speed up the
+builds, and you are unlikely to need them for local development.
+
+  Note: Currently JIT causes Guile to crash in obscure ways on GNU Hurd,
+so on that platform you want to also pass the --disable-jit flag
+to the configure script.
+
+  Note: On any i*86 architecture, you also need to pass in the compiler
+flag -fexcess-precision=standard in order to get the test suite
+to pass.  That can be done by passing an additional argument to
+the configure script:
+ CFLAGS='-g -O2 -fexcess-precision=standard'
+
+Once that finishes, you can execute your newly compiled Guile using the
+./meta/guile script:
+
+$ ./meta/guile -v | head -n1
+guile (GNU Guile) 3.0.9.139-d7cf5-dirty
+
+For more manual approach, read on.
+
 When Guile is obtained from Git, a few extra steps must be taken
 before the usual configure, make, make install.  You will need to have
 up-to-date versions of the tools as listed below, correctly installed.
@@ -73,7 +107,7 @@ Here is the authoritative list of tool/version/platform 
tuples that
 have been known to cause problems, and a short description of the problem.
 
 
-Sample GDB Initialization File=
+Sample GDB Initialization File ===
 
 In GDB, you probably want to load the gdbinit file included with Guile,
 which defines a number of GDB helpers to inspect Scheme values.
@@ -215,7 +249,7 @@ The goal is to reduce (and over time, eliminate) spurious 
diffs.
 For Emacs users:
   (add-hook 'before-save-hook 'delete-trailing-whitespace)
 
-Naming conventions =
+Naming conventions ===
 
 We use certain naming conventions to structure the considerable number
 of global identifiers.  All identifiers should be either all lower
-- 
2.41.0

bug#68504: [PATCH] Add copy-on-write support to scm_copy_file.

[Tomas Volf]

On modern file-systems (BTRFS, ZFS) it is possible to copy a file using
copy-on-write method.  For large files it has the advantage of being
much faster and saving disk space (since identical extents are not
duplicated).  This feature is stable and for example coreutils' `cp'
does use it automatically (see --reflink).

This commit adds support for this feature into our
copy-file (scm_copy_file) procedure.  Same as `cp', it defaults to
'auto, meaning the copy-on-write is attempted, and in case of failure
the regular copy is performed.

No tests are provided, because the behavior depends on the system,
underlying file-system and its configuration.  That makes it challenging
to write a test for it.  Manual testing was performed instead:

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB36.00KiB   0.00B  /tmp/cow

$ cat cow-test.scm
(copy-file "/tmp/cow" "/tmp/cow-unspecified")
(copy-file "/tmp/cow" "/tmp/cow-always" #:copy-on-write 'always)
(copy-file "/tmp/cow" "/tmp/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/tmp/cow-never" #:copy-on-write 'never)
(copy-file "/tmp/cow" "/dev/shm/cow-unspecified")
(copy-file "/tmp/cow" "/dev/shm/cow-auto" #:copy-on-write 'auto)
(copy-file "/tmp/cow" "/dev/shm/cow-never" #:copy-on-write 'never)
$ ./meta/guile -s cow-test.scm

$ btrfs filesystem du /tmp/cow*
 Total   Exclusive  Set shared  Filename
  36.00KiB   0.00B36.00KiB  /tmp/cow
  36.00KiB   0.00B36.00KiB  /tmp/cow-always
  36.00KiB   0.00B36.00KiB  /tmp/cow-auto
  36.00KiB36.00KiB   0.00B  /tmp/cow-never
  36.00KiB   0.00B36.00KiB  /tmp/cow-unspecified

$ sha1sum /tmp/cow* /dev/shm/cow*
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-always
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /tmp/cow-unspecified
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-auto
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-never
4c665f87b5dc2e7d26279c4b48968d085e1ace32  /dev/shm/cow-unspecified

This commit also adds to new failure modes for (copy-file).

Failure to copy-on-write when 'always was passed in:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'always)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: copy-on-write failed: Invalid cross-device link

Passing in invalid value for the #:copy-on-write keyword argument:

scheme@(guile-user)> (copy-file "/tmp/cow" "/dev/shm/cow" #:copy-on-write 
'nevr)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure copy-file: invalid value for #:copy-on-write: nevr

* NEWS: Add note for copy-file supporting copy-on-write.
* configure.ac: Check for linux/fs.h.
* doc/ref/posix.texi (File System)[copy-file]: Document the new
signature.
* libguile/filesys.c (clone_file): New function cloning a file using
FICLONE, if supported.
(k_copy_on_write): New keyword.
(sym_always, sym_auto, sym_never): New symbols.
(scm_copy_file): New #:copy-on-write keyword argument.  Attempt
copy-on-write copy by default.
* libguile/filesys.h: Update signature for scm_copy_file.
---
 NEWS   |  9 ++
 configure.ac   |  1 +
 doc/ref/posix.texi |  9 +-
 libguile/filesys.c | 74 +++---
 libguile/filesys.h |  2 +-
 5 files changed, 82 insertions(+), 13 deletions(-)

diff --git a/NEWS b/NEWS
index b319404d7..9147098c9 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,15 @@ definitely unused---this is notably the case for modules 
that are only
 used at macro-expansion time, such as (srfi srfi-26).  In those cases,
 the compiler reports it as "possibly unused".
 
+** copy-file now supports copy-on-write
+
+The copy-file procedure now takes an additional keyword argument,
+#:copy-on-write, specifying whether copy-on-write should be done, if the
+underlying file-system supports it.  Possible values are 'always, 'auto
+and 'never, with 'auto being the default.
+
+This speeds up copying large files a lot while saving the disk space.
+
 * Bug fixes
 
 ** (ice-9 suspendable-ports) incorrect UTF-8 decoding
diff --git a/configure.ac b/configure.ac
index d0a2dc79b..c46586e9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -418,6 +418,7 @@ AC_SUBST([SCM_I_GSC_HAVE_STRUCT_DIRENT64])
 #   sys/sendfile.h - non-POSIX, found in glibc
 #
 AC_CHECK_HEADERS([complex.h fenv.h io.h memory.h process.h \
+linux/fs.h \
 sys/dir.h sys/ioctl.h sys/select.h \
 sys/time.h sys/timeb.h sys/times.h sys/stdtypes.h sys/types.h \
 sys/utime.h unistd.h utime.h pwd.h grp.h sys/utsname.h \
diff --git a/doc/ref/posix.texi b/doc/ref/posix.texi
index fec42d061..d26808d91 100644
--- a/doc/ref/posix.texi
+++ b/doc/ref/posix.texi
@@ 

bug#66531: [PATCH] ftw: Fix getuid-or-false, getgid-or-false macros., bug#66531: [PATCH] ftw: Fix getuid-or-false, getgid-or-false macros., control message for bug #66531

[Tomas Volf]

Mike Gran  writes:

Hello,

> I haven't forgotten about this. My linux devel box died.
>
> Maybe someone else can make the push, otherwise, I'll be back in business in 
> a couple weeks.

Just a polite ping regarding this patch.

Thank you and have a nice day,
Tomas Volf

bug#68350: Segmentation fault using list-head with negative k

[Tomas Nordin]

lloda  writes:

> I think this is another dupe of https://debbugs.gnu.org/58154.

Highly possible. Like Ricardo I cannot reproduce this with a local build
I made from the tip of the repo. (I saw the same segfault using list-ref
with the debian 3.0.8 version FWIW.)

--
Tomas

bug#68350: Segmentation fault using list-head with negative k

[Tomas Nordin]

Hello List

If this has been reported before I didn't find it. Here's the recipe:

$ guile -q
GNU Guile 3.0.8
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)> (list-head '(1 2 3) -1)
Segmentation fault

Argument -1 is an improper argument and an error is expected, but not a
segmentation fault.

With positive integers out of bounds I see an exception, not segfault.

This is an apt-installed guile on Debian

$ dpkg -l | grep guile
ii  guile-3.0   3.0.8-2 
 amd64GNU extension language and Scheme interpreter
ii  guile-3.0-doc   3.0.8-2 
 all  Documentation for Guile 3.0
ii  guile-3.0-libs:amd643.0.8-2 
 amd64Core Guile libraries

Thanks for all the work

--
Tomas

bug#66531: [PATCH] ftw: Fix getuid-or-false, getgid-or-false macros.

[Tomas Volf]

Hi,

On 2023-10-25 14:01:43 +, Mike Gran wrote:
> I haven't forgotten about this. My linux devel box died.

My deepest sympathies.

>
> Maybe someone else can make the push, otherwise, I'll be back in business in 
> a couple weeks.

Polite ping, just making sure this is still on the radar.

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#66531: [PATCH] ftw: Fix getuid-or-false, getgid-or-false macros.

[Tomas Volf]

On 2023-10-13 17:30:06 +, Mike Gran wrote:
> > Both macros were missing a quote for the procedure call, causing the
> > actual return value to be compiled into the ftw.go, instead of the
> >procedure call.  Snippet from disassembly of ftw.go does confirm that:
> 
> Looks good to me.
> 
> If you don't have commit approval, I can take the action to commit it,
> and write a test case, since I was the one who broke it back in 2021.

I do not have commit access, nor I am sure how the tests should look
like, so if you would be so kind to take it over from here, that would
be great. :)

> 
> Mike Gran

Tomas Volf

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#66531: [PATCH] ftw: Fix getuid-or-false, getgid-or-false macros.

[Tomas Volf]

Both macros were missing a quote for the procedure call, causing the
actual return value to be compiled into the ftw.go, instead of the
procedure call.  Snippet from disassembly of ftw.go does confirm that:

  55(make-immediate 2 3990) ;; 997at 
ice-9/ftw.scm:319:46
  56(make-long-immediate 1 120002)  ;; 3  at 
ice-9/ftw.scm:320:46

That effectively prevented ftw from entering directories without access
for others.  Simple reproduction:

scheme@(guile-user)> ,use (ice-9 ftw)
scheme@(guile-user)> (mkdir "/tmp/")
scheme@(guile-user)> (chmod "/tmp/" #o0700)
scheme@(guile-user)> (ftw "/tmp/" (lambda (_ __ f) (pk f) #t))

;;; (directory-not-readable)
$1 = #t
scheme@(guile-user)> (system "ls -al /tmp/")
total 0
drwx-- 1 wolf wolf   0 Oct 11 22:54 .
drwxrwxrwt 1 root root 888 Oct 11 22:54 ..
$2 = 0

The fix is to quote the procedure call, leading to the intended
behavior.

This fixes bug 55344.

* module/ice-9/ftw.scm (getuid-or-false): Quote the (getuid).
(getgid-or-false): Quote the (getgid).
---
 module/ice-9/ftw.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/module/ice-9/ftw.scm b/module/ice-9/ftw.scm
index ac6aa6316..8496086a1 100644
--- a/module/ice-9/ftw.scm
+++ b/module/ice-9/ftw.scm
@@ -201,12 +201,12 @@
 
 (define-macro (getuid-or-false)
   (if (defined? 'getuid)
-  (getuid)
+  '(getuid)
   #f))
 
 (define-macro (getgid-or-false)
   (if (defined? 'getgid)
-  (getgid)
+  '(getgid)
   #f))
 
 (define (directory-files dir)
-- 
2.41.0

bug#66135: Unable to download Guile tar file

[tomas]

On Sat, Sep 23, 2023 at 02:18:24PM +0530, ahmad khizir wrote:

Hi, Ahmad

> Operate system is redhat 7.4
> I tried to download via wget command
> I am using institute network.
> I am ok with this point that you mentioned regarding, let me check with my
> personal network and let you know.

Thank you for the details!

You may try the "-S" options to wget: this will print the HTTP
headers, which might help in identifying the problem.

If I do that, this is what I see:

 | tomas@trotzki:/tmp$ wget -S https://ftp.gnu.org/gnu/guile/guile-3.0.9.tar.gz
 | --2023-09-24 11:07:42--  https://ftp.gnu.org/gnu/guile/guile-3.0.9.tar.gz
 | Resolving ftp.gnu.org (ftp.gnu.org)... 2001:470:142:3::b, 209.51.188.20
 | Connecting to ftp.gnu.org (ftp.gnu.org)|2001:470:142:3::b|:443... connected.
 | HTTP request sent, awaiting response... 
 |   HTTP/1.1 200 OK
 |   Date: Sun, 24 Sep 2023 09:07:44 GMT
 |   Server: Apache/2.4.29 (Trisquel_GNU/Linux)
 |   Strict-Transport-Security: max-age=63072000
 |   Last-Modified: Wed, 25 Jan 2023 13:51:41 GMT
 |   ETag: "948a4f-5f316eea157b8"
 |   Accept-Ranges: bytes
 |   Content-Length: 9734735
 |   Content-Security-Policy: default-src 'self'; img-src 'self' 
https://static.fsf.org https://static.gnu.org https://gnu.org 
http://static.fsf.org http://static.gnu.org http://gnu.org; object-src 'none'; 
frame-ancestors 'none'
 |   X-Frame-Options: DENY
 |   X-Content-Type-Options: nosniff
 |   Keep-Alive: timeout=5, max=100
 |   Connection: Keep-Alive
 |   Content-Type: application/x-gzip
 | Length: 9734735 (9.3M) [application/x-gzip]
 | Saving to: ‘guile-3.0.9.tar.gz’

[then it proceeds to download the file]

I could imagine that your institution has a HTTP proxy between you and the
internet, and that this just refuses to forward HTTPS.

Alas, trying the "http://; URL, the server insists (HSTS policy) in upgrading
that to the "https://; one, so if my guess is right above, we'd need a "Plan B".

This would be one of the cases where blindly applying something perceived to
be secure in spite of the users leads to bad results. Sigh.

Cheers
-- 
t


signature.asc
Description: PGP signature

bug#66135: Unable to download Guile tar file

[tomas]

It worked for me too.

On Sat, Sep 23, 2023 at 09:19:54AM +0530, ahmad khizir wrote:
> Not working for me, i can share the screenshot.

Perhaps better if you describe what you are trying (how are
you downloading, perhaps whether you are in a company or
country which might enforce network restrictions) and what
the error message is.

What is your operating system? Are you comfortable with the
command line? (this might help debug the problm ).

Much more helpful than a screen dump which some of us won't
look at (I, for example have a text-only mail program and
currently so little bandwidth that I won't look at it for
sure :-)

Cheers
-- 
tomás


signature.asc
Description: PGP signature

bug#63196: Further on this error message

[tomas]

On Mon, May 01, 2023 at 10:44:18AM +0800, Christopher Lam wrote:
> The source seems to be sxpath.scm -- see "yikes" error which triggers when
> n is -2 -4 -6 etc. I don't know how to build guile from sources and cannot
> debug further.
> 
> 
> (define (node-pos n)
>   (lambda (nodeset)
> (cond
>  ((not (nodeset? nodeset)) '())
>  ((null? nodeset) nodeset)
>  ((eqv? n 1) (list (car nodeset)))
>  ((negative? n) ((node-pos (+ n 1 (length nodeset))) nodeset))
>  (else
>   (or (positive? n) (error "yikes!"))
>   ((node-pos (1- n)) (cdr nodeset))

Hm. It seems that calling `node-pos' with n == 0 runs straight into the
"yikes" case (unless `nodeset' is #f or null, that is).

And we would get this when n ==-2 and (length nodeset) equals 1 on the
next recursive call. Or when n == -3 and (length nodeset) == 2, and so
on -- i.e. when n == -1 - (length nodeset).

We reach such a point again when n == 2*(-1 - (length nodeset)): it runs
into the case (negative? n), retries with n' = (+ n 1 (length nodeset))
which is still negative, next try is 0 => yikes.

So in your case I guess your (length nodeset) is 1, because you have
a cycle length of two :-)

Reading between the lines in the code above for the positive case, I
gather that the intention is to return an empty nodeset (i.e. '())
when n runs off the nodeset. So I'd extend the ((negative? n) ...)
case like so:

  ((negative? n)
(let ((nn (+ 1 (length nodeset
  (if (positive? nn) (node-pos nn) '(

Comments?

Cheers
-- 
t


signature.asc
Description: PGP signature

bug#62053: Guile compiler is unable to compile tiny program

[tomas]

On Wed, Mar 08, 2023 at 02:07:56PM +0300, var-vniiaes--- via Bug reports for 
GUILE, GNU's Ubiquitous Extension Language wrote:
> 
> Guile compiler is unable to compile tiny program:
>  
> (define (fn l)
>     (define (ok l)
>    (or (and (pair? l) l)
>    (error "list is empty")))
>     (cons (reverse (car l)) (ok l)))
>  
> amaya@picasso:~/tmp/guile-3.0.9
> $ ../prefix/bin/guile ~/tmp/guile-compiler-bug.scm
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;   or pass the --no-auto-compile argument to disable.
> ;;; compiling /home/amaya/tmp/guile-compiler-bug.scm
> ;;; WARNING: compilation of /home/amaya/tmp/guile-compiler-bug.scm failed:
> ;;; not found 22
>  
> Compiler reports confusing message here: `not found 22’.   

Bizarre. Can confirm 

tomas@trotzki:~/foo$ vim buggy.scm
  tomas@trotzki:~/foo$ guile buggy.scm 
  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
  ;;;   or pass the --no-auto-compile argument to disable.
  ;;; compiling /home/tomas/foo/buggy.scm
  ;;; /home/tomas/foo/buggy.scm:2:0: warning: possibly unbound variable `#{   
}#'
  ;;; /home/tomas/foo/buggy.scm:3:0: warning: possibly unbound variable `#{ 
 }#'
  ;;; /home/tomas/foo/buggy.scm:4:0: warning: possibly unbound variable `#{ 
 }#'
  ;;; WARNING: compilation of /home/tomas/foo/buggy.scm failed:
  ;;; not found 25

  tomas@trotzki:~/foo$ guile --version
  guile (GNU Guile) 3.0.8.57-bc3b1
  Copyright (C) 2022 Free Software Foundation, Inc.

  License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html>.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

(so in my case it's 25 instead of 22). Interestingly, my version also
produces warnings about possibly unbound variables). If I enter the
code line by line into a repl, I also get a "not found 22".

Interestingly, if I add a call to fn to the end of that snippet
(e.g. (fn '(a b))), the "not found" disappears. The unbound var
warnings stay.

Cheers
-- 
t




signature.asc
Description: PGP signature

bug#60528: uri->string swallows mandatory slashes

[tomas]

On Tue, Jan 03, 2023 at 09:00:48PM +0100, Liliana Marie Prikler wrote:
> Hi folks,
> 
> Below some unexpected behaviour observed in Guile 3.0.8, but it also
> dates back to 2.2.7 and possibly earlier versions.
> 
> scheme@(guile-user)> ,use (web uri)
> scheme@(guile-user)> (string->uri "file:///home") 
> $1 = #< scheme: file userinfo: #f host: #f port: #f path: "/home"
> query: #f fragment: #f>
> scheme@(guile-user)> (uri->string $1)
> $2 = "file:/home"

This looks strange, but not necessarily wrong. "file:///home" means
"empty authority", equivalent to "localhost" whereas "file:/home" means
"no authority". I'd expect the library to keep those two separate.
 
> scheme@(guile-user)> (uri->string (build-uri 'file #:host "" #:path
> "/home")) 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `uri-error' with args `("Expected valid host: ~s" (""))'.

Note that "no host" is not the empty string, but #f:

> scheme@(guile-user)> (uri->string (build-uri 'file #:host "" #:path
> "/home")) 

  scheme@(guile-user)> (uri->string (build-uri 'file #:host #f #:path "/home"))
  $6 = "file:/home"

So it is consistent, albeit (to me) surprising. I'd have expect
your `$2' above to be "file:///home", with three slashes.

Cheers
-- 
t


signature.asc
Description: PGP signature

bug#60522: make-vector takes 100% cpu if called without argument in the REPL

[tomas]

On Tue, Jan 03, 2023 at 05:57:19PM +0100, Sascha Ziemann wrote:
> The following throws an error:
> guile -c '(make-vector)'
> 
> But the evaluation of '(make-vector)' in the REPL generats just a warning:
> 
> ;;; :1:0: warning: possibly wrong number of arguments to `make-vector'
> 
> and seems to enter an endless loop afterwards.

Can confirm for 3.0.8.57-bc3b1. It actually eats CPU, can be interrupted
with c-C.

Cheers
-- 
t
> 


signature.asc
Description: PGP signature

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

[tomas]

On Wed, Dec 07, 2022 at 08:50:09AM +0100, rose gibson via Bug reports for 
GUILE, GNU's Ubiquitous Extension Language wrote:
> hi,
> 
> i noticed that if i, on my system, run "guile" from a shell and then type 
> into the command prompt that appears,
> 
> (string-ref "a string" -1)
> 
> guile appears to hang for a few seconds or so, and then prints the message 
> "Segmentation fault (core dumped)".
> 
> i'm not really sure if this report is worth anything, it might just be some 
> glitch in my distribution's build or something else unreproducable and weird, 
> idk.  but i thought i would say something.  just in case.
> 
> this is with guile 3.0.8 on arch linux.  i didn't do anything special with 
> respect to building guile myself or anything like that, it was (i'm pretty 
> sure) just installed from the repositories.

Hi,

this is Debian GNU/Linux, x86_64, but a self-compiled Guile:

| tomas@trotzki:~$ guile
| GNU Guile 3.0.8.57-bc3b1
| Copyright (C) 1995-2022 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)> (string-ref "a string" -1)
| ice-9/boot-9.scm:1685:16: In procedure raise-exception:
| Value out of range 0 to< 18446744073709551615: -1
| 
| Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
| scheme@(guile-user) [1]>

... so it's either fixed in the meantime, or there are differences
between our respective builds. Here, the bad index is caught, it
seems.

> i'm definitely curious what's up if anyone ever bothers to take the time 
> figuring it out.
> 
> thanks :)

That's as much as I can do for now, $DAYJOB calling :)

Cheers
-- 
t


signature.asc
Description: PGP signature

bug#59321: ice-9's open-input-pipe is unexpectedly slow on some systems

[tomas]

On Sun, Nov 20, 2022 at 06:24:57PM +0100, Ludovic Courtès wrote:
> Hi,
> 
> Andrew Whatson  skribis:
> 
> > Forcibly closing file descriptors like this shouldn't be necessary if
> > the application has properly opened descriptors with the FD_CLOEXEC
> > flag.  It would be good to get input from some more experienced Guile
> > hackers on the potential consequences of this change.
> 
> Libguile opens all its own file descriptors at O_CLOEXEC (one omission
> was recently fixed in 0aa1a9976fc3c6af4d1087e59d728cb8fe7d369a) so it
> may be possible to remove that FD-closing loop.  There’s still the
> possibility that application bug unwillingly leaks FDs, but we could
> consider it’s none of our business.
> 
> Thoughts?

Hm. Socket FDs don't "have" O_CLOEXEC. Arguably, they are at least as
"interesting" as file FDs (meaning: source of obscure bugs).

Moreover, misbehaving C libraries can be an additional source of bugs
we have no control of.

The reference I posted upthread makes a compelling case for at least
needing an option for this (admittedly ugly) close orgy (perhaps with
some additional platform-dependent mitigations, but that's an ugliness
in its own, sigh).

Cheers
-- 
t


signature.asc
Description: PGP signature

bug#59321: ice-9's open-input-pipe is unexpectedly slow on some systems

[tomas]

On Fri, Nov 18, 2022 at 02:49:05PM +1000, Andrew Whatson wrote:
> Hi Nate,
> 
> Thanks for reporting this!  I'm able to reproduce on my systems, and
> have identified the culprit:

[250k calls to close()]

Well spotted.

Here [1] is a good discussion on the problem. Spoiler alert:
there is no nice, simple and portable way around it. There
may be complex, platform-dependent solutions (like, for
example, under Linux go look in /proc//fd; BSD has other
tricks).

Of course, that doesn't mean that one should give up trying :)

Cheers

[1] 
https://stackoverflow.com/questions/56650579/why-should-i-close-all-file-descriptors-after-calling-fork-and-prior-to-callin

-- 
t


signature.asc
Description: PGP signature

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

[tomas]

On Sun, Nov 13, 2022 at 02:15:43AM +, jbranso--- via Bug reports for GUILE, 
GNU's Ubiquitous Extension Language wrote:
> November 12, 2022 12:58 PM, "Jean Abou Samra"  wrote:
> 
> >> 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? raises exception on #f]

[...]

> > It is normal for predicates to be defined only on certain types. You will 
> > find the same with
> > positive?, string-null? and the like.
> 
> Perhaps I am just being really pedantic.  I asked in the #guile irc chat if a 
> predicate should 
> be able to raise an exception.  The answer I was given was no.

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

signature.asc
Description: PGP signature

bug#51133: [PATCH 1/1] Tolerate http response line without reason phrase

[tomas]

On Tue, Oct 12, 2021 at 10:26:22AM +0200, Alexey Abramov via Bug reports for 
GUILE, GNU's Ubiquitous Extension Language wrote:
> Hi,
> 
> I agree that it is not a complient http response,

According to The Book [1] ;-) there should be at least one
space (SP) (as far as I understand this is really a true
honest space, Unicode codepoint 32. It is /not/ part of the
message (aka "reason phrase") , but a separator. The rule
is:

  status-line = HTTP-version SP status-code SP reason-phrase CRLF

The reason phrase itself can contain whatever funny whitespace
it wants:

  reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

and it /can/ be empty.

That said I'd agree that it makes sense to tolerate a missing
SP there. The legal minimum seems thus to be

  HTTP-version SP status-code SP CRLF

>  but unfortunately I
> came across with some http services (redfish, cimc from Cisco )

uh-oh. All bets are off, then ;-)


> where they don't put a reason phrase.

That would be OK, but they also eat the mandatory separator space
before the empty reason phrase. Bad folks, bad ;-)

As an onlooker I haven't much to say, but I think you are right
(but not Cisco :)

Cheers
 - t


signature.asc
Description: Digital signature

bug#49693: Bad address of FSF in module/language/elisp/compile-tree-il.scm

[Tomas Korbar]

Hi,
There is a bad address specified in the license of
module/language/elisp/compile-tree-il.scm file in version 3.0.7. I am
attaching a patch to fix this.
commit 5a888dc8cba740718d302e4e759b28bc19a9d06c
Author: Tomas Korbar 
Date:   Thu Jul 22 13:02:56 2021 +0200

Fix address of FSF

diff --git a/module/language/elisp/compile-tree-il.scm b/module/language/elisp/compile-tree-il.scm
index adbeb20..d9b2cd3 100644
--- a/module/language/elisp/compile-tree-il.scm
+++ b/module/language/elisp/compile-tree-il.scm
@@ -14,8 +14,8 @@
 ;;
 ;; You should have received a copy of the GNU General Public License
 ;; along with this program; see the file COPYING.  If not, write to
-;; the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-;; Boston, MA 02111-1307, USA.
+;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+;; Boston, MA 02110-1301 USA
 
 ;;; Code:
 

bug#49638: Guile 3.0.7 can not be compiled on Fedora rawhide

[Tomas Korbar]

Hi Guys,
I am trying to package guile 3.0.7 into Fedora but I encountered a problem.
In sources, there is a header lib/libc-config.h and then there is
preprocessor condition for presence of __attribute_maybe_unused__ macro.
This macro is newly defined in the latest version of glibc which we have in
Fedora rawhide but other macros upon which guile relies are not defined,
specifically it is __attribute_nonnull__. This causes that compilation uses
systems sys/cdefs.h header and not guiles copy of gnulib. Currently guile
3.0.7 can not be compiled on Fedora rawhide without manual removal of
previously described conditional.
Steps to reproduce are simple, try to compile guile 3.0.7 on Fedora rawhide.

Thanks for any help.

bug#46447: segfault with bugnum

[tomas]

On Thu, Feb 11, 2021 at 09:54:38PM +0100, Ricardo Wurmus wrote:
> This program sometimes causes Guile 3.0.5 to segfault:
> 
>   (define a (expt 2 (expt 3 (expt 4 2
>   (display (remainder a 10))
>   (display "\n")
> 
> And sometimes this program doesn’t terminate.  Here’s an example
> session with the program saved to foo.scm:

The first expr alone seems to segfault for me (Guile 3.0.4.38-64c894-dirty)
repeatably (well, that means 5 times in a row ;)

Cheers
 - t


signature.asc
Description: Digital signature

bug#46014: (define (thunk) (lambda (x) x)) should be a compile error?

[tomas]

On Fri, Jan 22, 2021 at 09:47:24AM -0500, jbranso--- via Bug reports for GUILE, 
GNU's Ubiquitous Extension Language wrote:
> Ricardo Wurmus  writes:
> 
> > Hi Joshua,
> >
> >> When I look at
> >>
> >> #+BEGIN_SRC scheme
> >> (define (thunk)
> >>(lambda (x)
> >>  x))
> >> #+END_SRC
> >
> > […]
> >
> >> My thought is, this is clearly a mistake.  This person needs to change
> >> the above code.
> >
> > How is this clearly a mistake?  The definition of “thunk” above is
> > perfectly fine and also common.
> 
> Thanks again for responding.  I'm still learning scheme, and it's cool
> that this email chain has helped clarify some things.  :)
> 
> Ahh.  I see now that the proper way to call thunk is to do this:
> ((thunk) "the")
> $1 = "the"
> 
> I had assumed that every time one called thunk, it would result in a
> runtime error.  I did not realize that there was a way to properly call
> thunk. Wow. Scheme is truly impressive.
> 
> Interestingly, I had wrongly assumed that
> 
> #+BEGIN_SRC scheme
> (thunk "test\n")  ;; I assumed program execution would stop here
> (display "Hello World\n")
> #+END_SRC
> 
> program execution would stop at (thunk "test\n").  But it actually
> caries on with execution of the program:

What happens is an "exception". It can be handled (then it's up
to the exception handler to end the program or do something else).

> #+BEGIN_SRC scheme
> :5:0: warning: possibly wrong number of arguments to `thunk'
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Wrong number of arguments to #
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> Hello World
> #+END_SRC

This is the REPL's exception handler talking to you. It's there to help
you debug the problem.

Were it a standalone program, it would have terminated right away.

(note that I'm not the most appropriate person to explain such things,
I can barely wrap my head around them :-)

Cheers

[1] https://www.gnu.org/software/guile/docs/master/guile.html/Exceptions.html

 - tomás


signature.asc
Description: Digital signature

bug#45923: Hot to intall Guile without Make

[tomas]

On Sun, Jan 17, 2021 at 09:18:59PM +0100, Dr. Arne Babenhauserheide wrote:
> 
> paul.eb...@mail.de writes:
> 
> > is there a way to install Guile or Make on Manjaro without an internet
> > connection and without having already installed one of them?
> 
> You’ll need to build and install make once without guile support (see
> ./configure --help), then install Guile with that reduced make and
> finally build and install make again with Guile support.

I took the problem off-thread with paul. I think the "bug" can be closed
now :)

I'd do if I knew how.

Cheers
-- t


signature.asc
Description: Digital signature

bug#45923: Hot to intall Guile without Make

[tomas]

On Sat, Jan 16, 2021 at 11:42:18PM +0100, paul.eb...@mail.de wrote:
> Hello everyone, I'm very sorry, if this is the wrong mail adress
> for my problem, but I couldn't find another to seek for help. I
> just thought that you are probably the expert for my question and
> are maybe willing to help me :)   Today I installed Linux (Manjaro)
> for the first time in my life on my brother's computer. To install
> the drivers for the "WiFi USB dongle" from a CD I need to install
> Make. Having spend the whole day to figuring out how to get most
> of the packages from "base-devel" installed without an internet
> connection, I'm left with installing Guile to finally install
> Make to be able to connect to the internet. Unfortunately,
> some versions of Guile that I encountered need a PGP-key to
> install, which results in an error message, since I have no
> internet connection. On the other hand, if I follow along your guide on
> (https://www.gnu.org/software/guile/manual/html_node/Obtaining-and-Installing-Guile.html)
> I need Make again, which I want to install in the first place.
> So is there a way to install Guile or Make on Manjaro without an
> internet connection and without having already installed one of them?
> Kind Regards, Paul Ebert

Hi, Paul

this is most probably the wrong list for that: this is the
Guile bug tracker. But no worries -- no harm done. Things
happen :)

Now to your original problem. I can't say for sure, because
lots of details are missing (and because I am not an expert
on Manjaro), but I am almost sure that you don't need to
install Guile to get Make running. They are (mostly) independent
of each other.

As seen from here, you best contact one of your local Linux
user groups and try to find a Manjaro (or Arch, since those
distributions are closely related) expert.

Don't hesitate to contact me via direct mail if you need
any further help. German language OK, too :)

@devels: I'd close this bug all by myself, but I'm unsure
whether I'm supposed/allowed to do so. Teach me, and you'll
have less work next time :^)

Cheers
-- tomás


signature.asc
Description: Digital signature

bug#43364: Possible bug with output redirection

[tomas]

On Sat, Sep 12, 2020 at 10:59:23PM +0200, pinoaffe wrote:
> Dear guilers,
> 
> When using with-output-to-string, the output of external processes
> started using system* and the like is not redirected to the temporary
> port. As far as I can tell, it just redirects things written/displayed
> from within guile.
> This seems to be a bug, or if this is intended behaviour it might be
> beneficial to document this somewhere.

I think this is intentional (or rather: out of Guile's scope). While the
Guile process's output functions are the scope of `with-output-to-string',
the subprocess started with `system' just happens to inherit the standard
output file descriptor, which is an operating system mechanism.

No idea, for example, about what would happen under Windows or other
(more or less) operating systems.

But you are right that it can be a bit confusing. I'm not sure whether a
hint in the doc would be in place.

What do oters think?

Cheers
-- t


signature.asc
Description: Digital signature

bug#43326: [3.0.x] Regression: Compilation error involving strings

[tomas]

On Fri, Sep 11, 2020 at 03:31:24PM +0700, Erik Dominikus wrote:
> Dear author(s) of the Guile 3.0.x compiler,
> 
> Background: I would like to report a problem that I found while trying
> to write a simple web server with get-string-n, sxml simple, and web
> server.
> 
> I have traced and reduced the problem into the minimal example below.
> 
> Some tested versions:
> - affected: 3.0.2 and 3.0.4
> - not affected: 2.0.13
> 
> How to reproduce:
> - Download the attached compile-error.scm into your working directory.
> - Run in Bash: GUILE_AUTO_COMPILE=0 guile -s compile-error.scm
> 
> Expected result: #t
> 
> Actual result: #f
> 
> Thank you.
> 
> Best regards,
> 
> Erik

> ;; GUILE_AUTO_COMPILE=0 guile -s compile-error.scm
> (define code '(lambda ()
> (define a (string #\x #\y))
> (define b (substring/shared a 0 1))
> (string-ref b 0)))
> (define compiled (compile code))
> (define interped (eval code (interaction-environment)))
> (write (equal? (compiled) (interped))) ;; #\nul vs #\x
> (newline)

Interesting: replacing "substring/shared" with just "substring" seems
to "fix" it (FWIW: the compiled version with "substring/shared" returns
"#\nul" (unexpected, for me), whereas the one with just "substring"
returns "#\x" (expected).

Cheers
 - t


signature.asc
Description: Digital signature

bug#42012: Reference Manual and Docstring on number->string

[tomas]

On Tue, Jun 23, 2020 at 12:51:23AM +0200, Sebastian Miele wrote:
> Guile 3.0.3. The reference manual and the docstring of number->string
> say: "If N is inexact, a radix of 10 will be used." But that is not what
> happens, e.g.,
> 
>   (let ((x 4.0)) (and (inexact? x) (number->string x 3)))
> 
> evaluates to "11.0" instead of #f or "4.0". Probably "if RADIX is not
> supplied, a radix of 10 will be used" is meant.

Confirmed for 3.0.2. At first I thought that the fractional part being
zero could be significant (as in your example), but

  scheme@(guile-user)> (number->string 0. 3)
  $5 = "0.1"

is clearly being done in radix 3, fractional part and all.

Cheers
-- t


signature.asc
Description: Digital signature

bug#41320: sxml attributes of some elements are in reverse order

[tomas]

On Sat, May 16, 2020 at 02:27:15PM +0200, Jan Synacek wrote:

[...]

> > just imagine another XML processor in the middle changing
> > attribute order. It would be spec compliant. What now?

[...]

> In the middle of the first processor reading the file?

No, I was thinking much simpler than that. For example, someone
augmenting/embellishing the xcb spec (because of, for example,
some change) and messing up the order for you, i.e. before your
program gets a shot at it.

But I see (elsethread) that your problem is solved :)

Cheers
-- t


signature.asc
Description: Digital signature

bug#41320: sxml attributes of some elements are in reverse order

[tomas]

On Sat, May 16, 2020 at 12:29:54PM +0200, Jan Synacek wrote:
> Consider the following code snippet running on Guile-3.0.2:

[...]

>   

[...]

>   (event (@ (number 2) (name KeyPress)) 

> Attributes 'number' and 'name' are in reverse compared to the original
> xml. On the other hand, 'type' and 'name' of the 'field' element are in
> correct order.

According to the XML spec, attribute order is irrelevant [1]

"Note that the order of attribute specifications in
 a start-tag or empty-element tag is not significant."

Now one could argue that we might want to be stricter in the
XML->SXML processor, which would be fine, but OTOH there's a
price to pay. The question is whether we want to go there --
just imagine another XML processor in the middle changing
attribute order. It would be spec compliant. What now?

Tough question.

Cheers
[1] https://www.w3.org/TR/REC-xml/#sec-starttags
-- t


signature.asc
Description: Digital signature

bug#40855: integer-length 0 should be 1

[tomas]

On Sat, Apr 25, 2020 at 11:15:40PM +0200, Bengt Richter wrote:
> I'm hoping this is the right place to report this bug :)
> 
> To reproduce, guile -c '(format #t "~s\n" (integer-length 0))'
> Expected result if correct: 1
> Observed result: 0
> 
> The following is to support the opinion that 1 is the correct result,
> and to explore how integer "length" generalizes to other radixes and
> also signed number writing other than sign-magnitude.

Hm. This is a tough one. The problem is that there are several
possible extensions to zero, and no one is quite right. For example,
one could interpret (integer-length n) as one plus the base-two
logarithm of n (well, its integer part). Or, in mathy jargon,
1 + floor(log2 n).

In this case, the integer-length of zero would be minus infinity!

And for negative n, we'd be in hot water (or in complex analysis or
something :)

Thus, the simple definition given in the doc "For positive N this
is how many bits to the most significant one bit" looks like a wise
choice to me -- and this leads to a value of 0 for 0 (or some
infinity, if you keep searching for the one bit you'll never find,
if you insist to find an one.

Cheers
-- tomás


signature.asc
Description: Digital signature

bug#40008: Backtraces can contain very long strings

[tomas]

On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
> I have the following backtrace:
> 
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>8 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 718:2  7 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  6 (_ #(#(#)))
> In ice-9/boot-9.scm:
>2806:4  5 (save-module-excursion _)
>   4351:12  4 (_)
> In /home/jsynacek/./git.scm:
>  72:0  3 (_)
> 61:16  2 (change-spec _ _ "66.33" _ #)
> 48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
> In unknown file:
>0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)
> 
> ERROR: In procedure make-regexp:
> Wrong type (expecting exact integer): "
> 
> "
> 
> While this is probably not considered an error, I guess it might be better
> to ellipsize strings in errors such is mine that are over a certain length
> long. The important part of the backtrace was scrolled away and I got
> confused about the string, as I thought it was part of the output and
> started wondering why (display ...) keeps the escaped newlines in the
> string.

Some want it, some want it not. I remember a couple of discussions
in guile-user and guile-devel about this topic.

Have you tried setting debug options `width' and/or `depth' (cf. procedure
`debug-options')?

(my current defaults are 79 columns/20 rows, this is Guile 3.0).

> If this is not considered a bug, please, at least consider it an RFE.

I guess one could argue about the current defaults, but it'll be
difficult to find values making all people happy all the time.

Cheers
-- t


signature.asc
Description: Digital signature

bug#38486: Compiler does not terminate

[tomas]

On Tue, Dec 03, 2019 at 09:58:00PM -0700, Zack Marvel wrote:
> Hello,
> 
> When compiling the following program, the compiler does not terminate.

[...]

> I can produce this behavior with Guile 2.2.4 and 2.2.6. I'm running
> Debian 10 amd64, and I compiled Guile with GCC 8.3.0.

FWIW, I just tried with guile 2.9.5 and the compile terminates:

  tomas@trotzki:~$ guile /tmp/zack.scm 
  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
  ;;;   or pass the --no-auto-compile argument to disable.
  ;;; compiling /tmp/zack.scm
  ;;; compiled /home/tomas/.cache/guile/ccache/3.0-LE-8-4.1/tmp/zack.scm.go

(after having saved your file to /tmp/zack.scm, that is).

So another data point, I assume :-)

Cheers
-- t


signature.asc
Description: Digital signature

bug#38398: non-obvious SCM_EOF_VAL rationale

[tomas]

On Wed, Nov 27, 2019 at 12:05:34PM +, Zefram via Bug reports for GUILE, 
GNU's Ubiquitous Extension Language wrote:

[...]

> But please don't get sidetracked.  This wasn't a feature request for
> "#eof" [...]

To be fair, you contributed strongly to this side-tracking. By waving
a big red flag:

  "This poor design precludes RnRS specifying read syntax for any
   EOF object [...]"

you yourself drew attention to the underlying issues of the design
instead of keeping things focused to the documentation.

I agree that the doc could improve in this case...

Cheers
-- tomás


signature.asc
Description: Digital signature

bug#38235: string-foldcase bug for trailing sigma

[tomas]

On Sat, Nov 16, 2019 at 09:41:05PM +0100, Andy Wingo wrote:
> Given the following example, using (rnrs unicode):
> 
>   (string-foldcase "ΜΈΛΟΣ")

Good catch. I think there's even a worse example: dotless
and dotted I [1]. Here it seems even impossible to do
up- and downcase correctly without knowing the language
context.

Cheers
[1] https://en.wikipedia.org/wiki/%C4%B0
-- tomás


signature.asc
Description: Digital signature

bug#36251: Regex library doesn't recognize ']' in a character class

[tomas]

On Tue, Jun 18, 2019 at 07:08:06AM -0400, Mark H Weaver wrote:
> Hi,
> 
> Abdulrahman Semrie  writes:
> 
> > I am using the pattern [\\[\\]a-zA-Z]+ to match a string with left or
> > right bracket in it [...]

> It turns out that there are several flavors of regular expressions in
> common use, with different features and syntax.  The link you provided
> is using PCRE (PHP) regular expressions (see the "flavor" pane on the
> left), and there are three other supported flavors on that web site.
> 
> Guile's (ice-9 regex) module provides a simpler flavor of regexps known
> as "POSIX extended regular expressions" [...]

D'oh! I forgot about Perl compatible regexps. In those, you /can/ escape
things with a backslash whithin [...]. This would have explained Abdulrhaman's
confusion better.

Thanks, Mark
-- t


signature.asc
Description: Digital signature

bug#36251: Regex library doesn't recognize ']' in a character class

[tomas]

On Sun, Jun 16, 2019 at 08:16:29PM +0300, Abdulrahman Semrie wrote:
> 
> I am using the pattern [\\[\\]a-zA-Z]+ to match a string with left or right 
> bracket in it. However, the string-match function doesn’t match the ‘]’ 
> character. To demonstrate with an example, try the following funciton:
> 
> (string-match "[\\[\\]a-zA-Z]+" "Text[ab]”)
> 
> The result for the above function should have been a match structure with 
> Text[ab] matched. However, the string-match returns #f which is incorrect. To 
> test if the pattern I am using was right, I tried on regex101.com and it 
> works. Here (https://regex101.com/r/VAl6aI/1) is the link that demonstrates 
> that it works.
> 
> Hence, the above leads me to believe there is a bug in the regex library that 
> mishandles ] character in character-classes

If I understood you correctly, you are using POSIX regular
expressions. Within a bracket expression ([...]), you can't
escape ']' with a backslash. Just put the ] as first character,
like so:

  [][a-zA-Z]

Quoting the man page (regex(7)):

   A bracket expression is a list of characters enclosed in "[]".
   It normally matches any single character from the list (but see
   below).  If the list begins  with  '^', it  matches  any  single
   character  (but see below) not from the rest of the list. [...]

   To  include  a  literal ']' in the list, make it the first
   character (following a possible '^').  To include a literal
   '-', make it the first or last character, or the second endpoint
   of a range [...]

See also [1], but the man page is more complete.

(I'm assuming your Guile is linked against some POSIX regex library).

Cheers
-- t


signature.asc
Description: Digital signature

bug#20339: Taking a step back (was: sxml simple: sxml->xml mishandles namespaces?)

[tomas]

Hi,

after mulling over it for a while, I think it's time to take
a step back and think a bit about where we'd like to go with
this.

Note that I'm ignoring technical details (the fact that the
SXML, and thus the XML serialization now has namespace declarations
everywhere down the path instead of just at the corresponding root
node, and the thing with the default namespaces, as noted in [1],
seem to me "fixable" technical details).

Your patch, Ricardo, takes a new approach wrt. the SXML resulting
from an XML parse: the full tag names (the QNAMEs, in XML parlance)
are now composed of : (mimicking the XML) instead
of :, as the former (sxml simple) used to
do. This has upsides and downsides.

I'll call your approach the "prefix" approach (as having the
prefixes to qualify the tag names) and the approach followed
by (sxml simple) up to now the "URI" approach, which haves
the full namespace URI qualifying the name.

In the URI approach, a qualified tag name would look like

  "http://example.org/namespaces/myns:node;

whereas in the prefix approach, it'd look like

  "myns:root"

plus the knowledge somewhere that the prefix "myns" stands for

  myns -> http://example.org/namespaces/myns

Upsides of the prefix approach:

 + it mimics more closely the XML syntax. Since that
   is what the XML folks see, that follows the "principle
   of least astonishment" (aka POLA)
 + it is forced to keep the prefix -> namespace associations
   (it would be semantically incomplete if not, since what
   counts semantically is the namespace URI)

Downsides

 - it contradicts current documentation
   "All namespaces in the XML document must be declared, via
xmlns attributes. SXML elements built from non-default
namespaces will have their tags prefixed with their
URI. Users can specify custom prefixes for certain
namespaces with the #:namespaces keyword argument to
xml->sxml." [2]

This can be changed, of course :-)
But perhaps someone is already relying on it?

  - working on the resulting SXML becomes harder, because
to compare two qualified names, we'd have to resolve
the namespace associations.

Upsides of the URI approach

 + it is what the documentation says
 + it follows more closely the XML semantics (the namespace
   prefix in itself is irrelevant after all). As a corollary,
   working on the SXML becomes easier: a comparison of two
   qualified names becomes a simple string comparison, etc.

   I think that is why (sxml simple)'s original design followed
   this path.

Downsides

   Well, negate the "prefix approach" upsides :-)

Let me just say that there seem to be precedents for the
prefix approach out there in the 'net: the Wikipedia
article [3] (yes, there's a wikipedia on that!) follows
the prefix approach. This nice blog post [4] too.

I think I'll stop here. Mi fingers itch with some hacking,
but I think we should pause and ponder before hacking.

Perhaps we should take this to guile-devel? OTOH, if someone
knows The Way Forward (TM), I'm willing to hack in this
direction.

Cheers & thanks

[1] Message ID <20190408121403.ga...@tuxteam.de>
http://lists.gnu.org/archive/html/bug-guile/2019-04/msg1.html
[2] https://www.gnu.org/software/guile/manual/guile.html#SXML
[3] https://en.wikipedia.org/wiki/SXML
[4] https://www.more-magic.net/posts/lispy-dsl-sxml.html

-- tomás


signature.asc
Description: Digital signature

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[tomas]

On Tue, Feb 05, 2019 at 01:57:11PM +0100, Ricardo Wurmus wrote:
> 
> Ricardo Wurmus  writes:
> 
> > In that case we coud have FINISH-ELEMENT add all namespace declarations
> > that are in scope to the current node that is about to be returned.  It
> > would be a little verbose, but more correct.
> 
> Like this:

Thanks again for your patch, and sorry for my glacial pace.

I now came around to test it (against Guile 2.2.4, commit
791cae940afcb2b2eb2c167fe438be1dc1008a73).

TL;DR:

 - The default namespace is still a problem (see below)
 - It would be nice to inhibit the down-inheritance of
   namespace declararions at xml->sxml time. Then, the
   sxml representation would closely mimic the XML, this
   has obvious advantages, since it'd give the user much
   more control over the generated XML.

I'd be willing to prepare a patch along these lines, but
for that, I'd like to get an idea of which direction we
want to take this whole thing to.

To see what's going on, I tried with a small XML example:

First with explicit (aka non-default) namespace:

  #+NAME: minimal-explicit
  #+BEGIN_EXAMPLE
  
  http://example.org/namespaces/myns;>

  
  #+END_EXAMPLE

Before your patch:

  #+NAME: minimal-explicit-before
  #+BEGIN_SRC scheme :results output verbatim :var the-xml=minimal-explicit
  (use-modules (sxml simple))
  (use-modules (ice-9 pretty-print))
  (pretty-print (xml->sxml the-xml))
  #+END_SRC

  #+RESULTS: minimal-explicit-before
  : :12:0: warning: possibly unbound variable `pretty-print'
  : :12:14: warning: possibly unbound variable `xml->sxml'
  : (*TOP* (*PI* xml "version=\"1.0\"")
  :(http://example.org/namespaces/myns:root
  :  "\n  "
  :  (http://example.org/namespaces/myns:subnode)
  :  "\n"))

As we know, this replaces the namespace prefixes with the namespace URIs

After your patch:

  #+NAME: minimal-explicit-after
  #+BEGIN_SRC scheme :results output verbatim :var the-xml=minimal-explicit
  (set! %load-path (cons "." %load-path))
  (use-modules (sxml simple))
  (use-modules (ice-9 pretty-print))
  (pretty-print (xml->sxml the-xml))
  #+END_SRC

  #+RESULTS: minimal-explicit-after
  #+begin_example
  :13:0: warning: possibly unbound variable `pretty-print'
  :13:14: warning: possibly unbound variable `xml->sxml'
  ;;; note: source file ./sxml/simple.scm
  ;;;   newer than compiled /usr/local/lib/guile/2.2/ccache/sxml/simple.go
  ;;; found fresh local cache at 
/home/tomas/.cache/guile/ccache/2.2-LE-8-3.A/home/tomas/guile/sxml-fix/sxml/simple.scm.go
  (*TOP* (*PI* xml "version=\"1.0\"")
 (myns:root
   (@ (xmlns:myns "http://example.org/namespaces/myns;))
   "\n  "
   (myns:subnode
 (@ (xmlns:myns "http://example.org/namespaces/myns;)))
   "\n"))
  #+end_example

(I've put sxml/simple.scm in the current directory, thus the manipulation
of %load-path). This mimics the XML more closely, using namespace prefixes
instead of namespaces in the sxml. This is compelling :-)

The only difference to the xml is that the namespace declaration is inherited
to lower-level nodes (that's why sxml->xml propagates them, too).

This works, with the above downside, which you noted too.

It doesn't work with a default namespace, though:

  #+NAME: minimal-implicit
  #+BEGIN_EXAMPLE
  
  http://example.org/namespaces/myns;>

  
  #+END_EXAMPLE

With your patch:

  #+NAME: minimal-implicit-after
  #+BEGIN_SRC scheme :results output verbatim :var the-xml=minimal-implicit
  (set! %load-path (cons "." %load-path))
  (use-modules (sxml simple))
  (use-modules (ice-9 pretty-print))
  (pretty-print (xml->sxml the-xml))
  #+END_SRC

  #+RESULTS: minimal-implicit-after
  : :13:0: warning: possibly unbound variable `pretty-print'
  : :13:14: warning: possibly unbound variable `xml->sxml'
  : ;;; note: source file ./sxml/simple.scm
  : ;;;   newer than compiled /usr/local/lib/guile/2.2/ccache/sxml/simple.go
  : ;;; found fresh local cache at 
/home/tomas/.cache/guile/ccache/2.2-LE-8-3.A/home/tomas/guile/sxml-fix/sxml/simple.scm.go
  : (*TOP* (*PI* xml "version=\"1.0\"")
  :(*DEFAULT*:root "\n  " (*DEFAULT*:subnode) "\n"))

Note that the namespace declaration for *DEFAULT* is missing,
so we lost that bit of information. Besides, this is not
serializable:

  #+NAME: reserialize-implicit
  #+BEGIN_SRC scheme :results output verbatim
  (set! %load-path (cons "." %load-path))
  (use-modules (sxml simple))
  (define the-sxml
'(*TOP* (*PI* xml "version=\"1.0\"")
   (*DEFAULT*:root "\n  " (*DEFAULT*:subnode) "\n")))
  (sxml->xml the-sxml)
  #+END_SRC

It catches the bad (xml) name starting with a star:

  #+RESULTS: reserialize-implicit
  : ERROR: In procedure scm-error:
  : Invalid name starting character "*DEFAULT*" *DEFAULT*:root
  : 
  : Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
  : scheme@(guile-user) [1]> 

Cheers
-- tomás


signature.asc
Description: Digital signature

bug#34457: GNU Guile: Error in docstring of proc reverse-list->string

[tomas]

On Tue, Feb 12, 2019 at 03:34:06PM +0400, Андрей wrote:
> Good day!
> 
> The docstring of `reverse-list->string` proc says:
> ```
> scheme@(guile-user)> (help reverse-list->string )
> `reverse-list->string' is a procedure in the (guile) module.
> 
> - Scheme Procedure: reverse-list->string chrs
>  An efficient implementation of `(compose string->list reverse)':
>  
>(reverse-list->string '(#\a #\B #\c)) ==> "cBa"
> 
> ```
> and it works as the example shows, but I think the description line
> should be `(compose list->string reverse)'

Yes, I think you are right: the result will be a string, so it has
to be "list->string".

Confusing, when compose goes right to left and -> by convention
left-to-right :-)

Cheers
-- t


signature.asc
Description: Digital signature

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[tomas]

On Mon, Feb 04, 2019 at 09:44:02PM +0100, Ricardo Wurmus wrote:
> Hello!
> 
> I just looked at this again and I think I came with something useful.
> Here’s some context:

[...]

> Attached is a patch that does the requested things.  The parser
> procedures like FINISH-ELEMENT have access to all the namespaces, so we
> I changed the FINISH-ELEMENT procedure to return the list of namespaces
> in addition to its SXML tree return value.

It's great that you pick that up, I'm excited :-)

I have lost a bit of contact to Guile as of late. But I'm preparing
some tooling to give your patches a whirl; in the meantime a couple
of comments from the peanut gallery:

As John has noted, the namespace mappings (i.e. the prefix -> namespace
URI binding) are kind of lexically scoped (I'd call it subtree scoped,
but structurally it is the same). While parsing is "easy" (assuming
well-formed XML), serializing is not unambiguous. In a way, the library
might want to be prepared to take hints from the application (as far
as the XML is to be read by humans, there might be "better" and "worse"
serializations).

It may take me a couple of days to come up to speed.

Thanks a lot & cheers
-- t


signature.asc
Description: Digital signature

bug#29684: exception printers - request for improvement

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jul 03, 2018 at 04:31:23PM -0300, David Pirotte wrote:
> Hi Ludovic,
> 
> > > It is perfectly fine, on the opposite side, to ask advanced scheme users 
> > > (who
> > > would want to, but I really don't see the point) configure guile s the 
> > > repl and
> > > the exception printer so it tries to print the full content of huge lsts,
> > > vectors, arrays ...  
> 
> > Perhaps you could arrange to set the REPL’s ‘print’ option right from
> > one of the Guile-OpenCV modules?  I mean the configuration you mention
> > have doesn’t have to be done manually by users.
> 
> I'll do that yes, since I failed to convince you it you be a better default 
> for all
> of us, not just Guile-CV :)

Hm. Applying the peanut gallery factor to my opinion (roughly 10e-7), I tend to
side with David's position: the default consumer of REPL's print is a human, and
feeding him/her with huge binary things isn't "tasty"...

But... grain of salt, and things. What would be David's position's downsides?

Thanks
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAls8k6QACgkQBcgs9XrR2kaJSgCePeZgTTphZmdrkww/uoVm/9mW
Ib4An2/NY2kWS6Oso7w9jzSP8s9x9mZz
=KsrJ
-END PGP SIGNATURE-

bug#26221: (define function nil should work in 2.2

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Mar 23, 2017 at 07:59:04PM +, Joshua Branson wrote:
> 
> I can confirm this bug.  Eshell accepts (defun hello nil (print “Hello"))  
> And (hello)  works properly.
> 
> M-x guiler
> 
> ,languages elisp
> 
> (defun hello nil (print “Hello”))  doesn’t work.
> 
> Joshua
> 
> P.S.  I didn’t even know (define function nil …) was a thing in elisp land.

No, no. It's not (defun nil) -- it's (defun foo nil ...), which, if you squint a
bit is the same (in Lisp!) as (defun foo () ...) -- defining function foo with
an empty argument list. This is a perfectly respectable thing to do.

That's because, for Lisp, nil, '() and false are all one and the same. Scheme
is pickier here, and I'd imagine that this is the reflection of one of those
translation pains. But I don't know enough about Guile's elisp implementation
to be sure (ah, I wish I had the time for that...)

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljU5J0ACgkQBcgs9XrR2kY2SACffmA4jJ06fft6EBCbhm3m7Zwj
8Y8AnitudhEOZQjCzsa/tu29vFtNEFhZ
=0umF
-END PGP SIGNATURE-

bug#26151: date-year-day screws up leap days prior to AD 1

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Mar 18, 2017 at 01:10:58AM +, Zefram wrote:

[...]

> Where did you get the idea to use a non-linear year numbering?  What's
> your opinion of SRFI-19's (lack of) text on this matter?  You should
> consider the possibility of changing your implementation to use the
> conventional astronomical year numbering in this slot.

It seems that there are both conventions, "with year zero" (astronomical)
and "without year zero" (the more "conventional" historical usage (aka
"Common Era"), see [1].

That said, these days (and ISO 8601) go by "with year zero". Therefore
I'd sympathize with your tendency. Perhaps an option or a different set
of functions might satisfy both camps?

Definitely it needs to be documented.

Regards
[1] https://en.wikipedia.org/wiki/Year_zero

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljNAIUACgkQBcgs9XrR2kZwUgCfen5ea8HCGVZzXCZd3ErwGi2V
MwoAnA+0Au3tNQNiFKJ1mcsMDHl6iCeT
=w9Dn
-END PGP SIGNATURE-

bug#24659: 'mkdir' procedure is neither thread-safe nor safe (2.0.12)

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Oct 10, 2016 at 06:39:47PM +0200, Ludovic Courtès wrote:
> Hello!

[...]

> Furthermore, AFAICS, the above logic is redundant with what the kernel
> does anyway.  That is, in a single-threaded program,
> 
>   mask = umask (0);
>   umask (mask);
>   mkdir (file, 0777 ^ mask);
> 
> is equivalent to:
> 
>   mkdir (file, 0777);
> 
> Am I right that we should just remove these two ‘umask’ calls?

According to umask(2), yes, you are right. Unless someone has been
trying to work around some platform-specific bug/idiosyncracy.

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlf73SEACgkQBcgs9XrR2kZehwCfQ+P2CMZt8doHe2tKi0u1Yc7f
RU0An0WY1oEq/b3vu/X1rNWjTP7ZxUsY
=7Jhs
-END PGP SIGNATURE-

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jul 14, 2016 at 12:10:17PM +0200, Andy Wingo wrote:
> Hi :)
> 
> On Wed 13 Jul 2016 15:24, to...@tuxteam.de writes:
> 
> > Referring to Oleg Kiseliov's paper [1], there are actually three
> > things involved:
> 
> This summary is helpful, thanks.
> > What is missing? From my point of view:
> >
> >  - At xml->sxml time, the user doesn't know which namespaces
> >are in the xml. So it would be nice if the XML parser
> >could provide that.
> 
> For some documents you do know, of course.
> 
> And for larger perspective, I think that SSAX gives you all the tools
> you need to build specialist and very flexible XML parsers.  So to an
> extent solving the general problem isn't necessary -- we can always
> point people to SSAX.  But that's a bit rude ;) so if there are common
> patterns we should try to capture them in xml->sxml.  I see this bug as
> being a search for those patterns, but without the requirement of
> solving the problem in its most general form.

It's (sxml simple), after all. I too hesitate to stuff too much into
it. For me, a documented "no, we don't do namespaces" would be one
valid pattern.

> >  - It would be super-nice if the XML parser could put that
> >into the same nodes it found it [...]

> ACK.
> 
> >  - At sxml->xml time there should be a way to somehow
> >generate prefixex [...]

> ACK.
> 
> What do you think the next step is?  I am happy to wait FWIW, dunno if
> Ricardo has any feelings here.

We meet this afternoon anyway. On my side, I'd be happy to try
something along the sketched lines when I'm back. If someone
who cares beats me at it, I'd be as happy.

> Enjoy your holiday :)

Looking forward to. BTW: if I understood properly the area you're
living in, we'll cycle past you (somewhat to the West) on our
way to the north.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAleHaNcACgkQBcgs9XrR2kaQgQCaAzyyBkI3w0XGJ0HUI9Dz/YXa
7yQAni4CWIDE5ezu+x0DwanoAjfH4Wr2
=DEuD
-END PGP SIGNATURE-

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Jul 13, 2016 at 03:24:03PM +0200, to...@tuxteam.de wrote:

[...]

> What is missing? From my point of view:
> 
>  - At xml->sxml time, the user doesn't know which namespaces
>are in the xml. So it would be nice if the XML parser
>could provide that.
> 
>  - It would be super-nice if the XML parser could put that
>into the same nodes it found it, as described in [1]
>(i.e. in the (*NAMESPACES* ...) pseudo-attribute).
>This way we wouldn't have a global mapping, but one
>that resembles the original XML, even with the same
>prefixes. Less surprises overall. The round trip
>xml -> sxml -> xml would be (nearly) the identity.
> 
>With Ricardo's patch it would lump all the namespace
>declarations up in the top node, which formally is
>correct, but might scare XML people a bit :-)
> 
>  - At sxml->xml time there should be a way to somehow
>generate prefixex for "new" namespaces. I don't know
>at the moment how this would work, that depends on
>how the user is supposed to insert new nodes in the
>SXML. Does she specify the namespace? Both prefix
>(aka namespace-id, under my current assumption) *and*
>namespace? (note that the namespace-id/prefix alone
>wouldn't be sufficient).

Argh. First post, then think, sorry.

Actually ditch the last point. I think it would be OK
to make the user responsible to keep the *NAMESPACES*
pseudo-attribute up-to-date whenever she adds nodes
with new namespaces to the SXML.

regards

[1] http://okmij.org/ftp/papers/SXML-paper.pdf

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAleGg7YACgkQBcgs9XrR2kY7hACdG5drjpPVlzB4wW6sXhuRKliv
h3cAnAmHC5RxiEc6RXi0tu5U3yF4YYbx
=7uGa
-END PGP SIGNATURE-

bug#20339: sxml simple: sxml->xml mishandles namespaces?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jun 23, 2016 at 09:32:16PM +0200, Andy Wingo wrote:
> See thread here as well:
> http://thread.gmane.org/gmane.lisp.guile.devel/17709
> 
> I like Ricardo's patch but have some comments here:
> http://article.gmane.org/gmane.lisp.guile.devel/18384

(sorry for cc'ing both of you, but I don't know whether you are
subscribed to the bug. Two copies seemed more polite than none).

Sorry folks for not coming back earlier. Real Life and things.

Since I'm going to be off the 'net for one month starting next Friday,
I thought I'll write a short note.

I'll be back the 15th of August and am really willing to do whatever
it takes to bring this forward. OTOH, if any of you decides to pick
it up, I'm sure the results will be better :-)

Referring to Oleg Kiseliov's paper [1], there are actually three
things involved:

 - the namespace. This is an XML thing and will typically be
   an URI (I don't quite remember whether it *must* be an
   URI, but that's irrelevant. It may contain nasty characters
   (to XML: it isn't an XML "Name", and potentially to Scheme:
   there may be patentheses and things in there, so some
   Schemes won't make a symbol of that; Guile doesn't mind)

 - the namespace prefix. Again, an XML thing, basically giving
   a non-nasty abbreviation for the namespace, to stick it to
   the Name, making a "QName". The association prefix -> namespace
   is scoped to a node and its descendants, and can be shadowed
   at some node below

 - the namespace-id, an SXML thing. In [1], this is typically
   the namespace, but Oleg Kyselyov made provisions in [1] for a
   similar "abbreviation" (the user-ns-shortcut in [1], page 3),
   whose mapping can be attached to any node via the
   pseudo-attribute *NAMESPACES* [2], which can also carry the
   original (XML) namespace prefix.

   As far as I understand the paper, most of the time this
   namespace-id will be identical to the URI, but it is this
   what will be prefixed to the tag name symbols in the
   SXML representation.

What Ricardo's patch does is to conflate namespace prefix and
namespace-id and provide a mapping (namespace-id aka prefix) ->
namespace. This is actually quite elegant, since we don't need
the distinction between (XML) prefix and (SXML) namespace-id.

I think that we can, at least as (sxml simple) is concerned,
ignore this distinction.

What is missing? From my point of view:

 - At xml->sxml time, the user doesn't know which namespaces
   are in the xml. So it would be nice if the XML parser
   could provide that.

 - It would be super-nice if the XML parser could put that
   into the same nodes it found it, as described in [1]
   (i.e. in the (*NAMESPACES* ...) pseudo-attribute).
   This way we wouldn't have a global mapping, but one
   that resembles the original XML, even with the same
   prefixes. Less surprises overall. The round trip
   xml -> sxml -> xml would be (nearly) the identity.

   With Ricardo's patch it would lump all the namespace
   declarations up in the top node, which formally is
   correct, but might scare XML people a bit :-)

 - At sxml->xml time there should be a way to somehow
   generate prefixex for "new" namespaces. I don't know
   at the moment how this would work, that depends on
   how the user is supposed to insert new nodes in the
   SXML. Does she specify the namespace? Both prefix
   (aka namespace-id, under my current assumption) *and*
   namespace? (note that the namespace-id/prefix alone
   wouldn't be sufficient).

Sorry for this wall of text. I hope it makes some sense.

Regards

[1] http://okmij.org/ftp/papers/SXML-paper.pdf
[2] Actually, I'm cheating here: the thing is part of an
   "annotations" part, which according to the grammar comes
   *last*, after all the attributes. But it looks a bit
   like an attribute, with a strange name and a more
   complex value.

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAleGQPMACgkQBcgs9XrR2kaMfgCeKbA4pWFrCZoxofDF4n9utgnZ
IzYAn1gozFwBLPd/rmNkZvJYDTJ9cIvr
=etJd
-END PGP SIGNATURE-

bug#23739: Unexpected behavior of 'add-to-load-path'.

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jun 10, 2016 at 02:17:23PM +0200, Mathieu Lirzin wrote:
> Hello,
> 
> I have noticed something that doesn't feel right when using
> ‘add-to-load-path’.
> 
> $ cat test.scm
> --8<---cut here---start->8---
> (define old %load-path)
> (add-to-load-path "foo")
> (pk %load-path)
> (pk old)
> --8<---cut here---end--->8---
> 
> first run:
> 
> $ guile test.scm
> --8<---cut here---start->8---
> ;;; [Compilation]
> ;;; (("foo" "foo" "/usr/share/guile/2.0" "/usr/share/guile/site/2.0" 
> "/usr/share/guile/site" "/usr/share/guile"))
> 
> ;;; (("foo" "/usr/share/guile/2.0" "/usr/share/guile/site/2.0" 
> "/usr/share/guile/site" "/usr/share/guile"))
> --8<---cut here---end--->8---
> 
> next runs:
> 
> $ guile test.scm
> --8<---cut here---start->8---
> ;;; (("foo" "/usr/share/guile/2.0" "/usr/share/guile/site/2.0" 
> "/usr/share/guile/site" "/usr/share/guile"))
> 
> ;;; (("/usr/share/guile/2.0" "/usr/share/guile/site/2.0" 
> "/usr/share/guile/site" "/usr/share/guile"))
> --8<---cut here---end--->8---

I can confirm half of it :-)

I mean: the double entry "foo" for %load-path in your first result
above doesn't happen for me. Could that be a typo?

As for the strangely different behaviour when running pre-compiled
(old has %load-path's old value) and compiling (old has %load-path's
value after (add-to-load-path ...) yes, that happens to me too, on

  tomas@rasputin:/tmp$ guile --version
  guile (GNU Guile) 2.0.11.133-d680
  Copyright (C) 2014 Free Software Foundation, Inc.

Looks like a bug to me.

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldaw5cACgkQBcgs9XrR2kZmoACfd8HliwAbrWdo3xK1jm44aIkQ
yPYAnj9MoF0OanAUD46iOnAoLLA1qrVu
=zuV2
-END PGP SIGNATURE-

bug#18592: FFI should have portable access to ‘errno’

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jan 05, 2016 at 10:24:35AM +0800, Chaos Eternal wrote:
> On Tue, Jan 5, 2016 at 3:14 AM, Nala Ginrut  wrote:
> > Hi Mark!
> > Thanks for all the advices.
> >
> > Here's the new patch according to your advices.
> > Include:
> > 1. Added new procedure pointer->procedure-with-errno with
> > #:return-errno?
> >
> > Question: Should we make #:return-errno? true in default? This would
> > make the name *-with-errno more reasonable. At present, it's false in
> > default.

Sorry for intervening from the peanut gallery, but if I understood Mark
correctly, he only was proposing to introduce a second function for the
C API (to keep backward compatibility at the linking-to-C level). At the
Guile source level, I guess all can be subsumed under one function.

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlaLdYQACgkQBcgs9XrR2kYBUQCfXIbqu8h/fhM/PyM9NXI1tR9M
thIAnjSo00Ts4P39cTdwGOIIXIzELU9A
=cCFX
-END PGP SIGNATURE-

bug#21855: eq?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Nov 07, 2015 at 01:58:48PM +0100, Atticus wrote:
> So I wanted to try out gnu guix and thus make myself more familiar with
> guile first. While running some tests I encountered a problem/bug with eq?:
> 
> $ guile -v
> guile (GNU Guile) 2.1.1
> 
> $ guile
> scheme@(guile-user)>
> (define (multirember a lat)
>   (cond
>((null? lat) '())
>((eq? (car lat) a) (multirember a (cdr lat)))
>(else (cons (car lat) (multirember a (cdr lat))
>
> scheme@(guile-user)> (multirember '(a b) '(x y (a b) z (a b)))
> $1 = (x y z)
> 
> So why does guile return (x y z)? I expected (x y (a b) z (a b)). I know
> eq? should only be used with symbols (and thus this example is more
> theoretical) but nevertheless the return value is not right, since (eq?
> '(a b) '(a b)) returns #f (Btw same in guile 2.0.11).

Hm. As far as I know (eq? '(a b) '(a b)) is not *guaranteed* to evaluate
to #f. The implementation might be free to re-use things it "knows" to be
constant (I might be wrong, though).

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlY/IpsACgkQBcgs9XrR2kZMoACZAc49Kzq9JzteJovmzRpH2WLv
M3YAnibf8NUd5bspCqCP2cQiAWNSiREt
=O1dE
-END PGP SIGNATURE-

bug#21373: compile for development version from git fails on OpenBSD

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Aug 28, 2015 at 09:47:51PM -0400, Jamil Egdemir wrote:
 Hi Guys,
 
 I just pulled the latest from the git repo and the build failed on
 OpenBSD 5.6 (output from dmesg is all the way at the bottom if that
 helps):
 
 $ git clone http://git.sv.gnu.org/r/guile.git 
 $ cd guile
 $ autoreconf --install
 $ ./configure --prefix=/home/me/usr \
 --with-libltdl-prefix=/usr/local  \
 --with-libgmp-prefix=/usr/local   \
 --with-libunistring-prefix=/usr/local
 $ gmake

[elided]

 flex -t ./c-tokenize.lex  c-tokenize.c || { rm c-tokenize.c; false; }
 ./c-tokenize.lex, line 1: unrecognized '%' directive
 ./c-tokenize.lex, line 7: bad character: #
 ./c-tokenize.lex, line 7: unknown error processing section 1
 ./c-tokenize.lex, line 8: bad character: #
 ./c-tokenize.lex, line 8: bad character: 
 ./c-tokenize.lex, line 8: bad character: .
 ./c-tokenize.lex, line 8: bad character: 
 ./c-tokenize.lex, line 9: bad character: #
 ./c-tokenize.lex, line 10: bad character: }

[elided]

Just as a first hunch, I'd double check whether you've got a suitable
version/variant of flex.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlXhpQ8ACgkQBcgs9XrR2kYskwCfU3Kd8+uwZ7/KIxNWV+9sk9PL
GBcAnRL0KMHnr4NzKknfCCXshWXjQDRt
=bbvm
-END PGP SIGNATURE-

bug#20339: sxml simple: sxml-xml mishandles namespaces?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Apr 23, 2015 at 09:04:46AM +0200, Ricardo Wurmus wrote:
 
 to...@tuxteam.de writes:
 
  What's yet missing (as far as I can read off the diff) is a way to
  dream up an abbreviation when it's not in the namespaces alist.
 
 True.
 
 Ideally, this should work even without passing a namespaces alist at all
 in both xml-sxml and sxml-xml.  The non-abbreviated namespaces
 should not cause sxml-xml to fail.
 
 Passing around a namespaces alist to both these procedures is the least
 invasive approach I could think of, but I still think that it *should*
 be made to work without explicitly declaring namespaces.

I think a combination of our approaches could work: the only difference
(apart of the code elegance) is that my patch grows this alist on its
way down the tree as it encounters new namespace. This meshes well with
the namespace declaration, which scopes recursively down the XML tree.

This afternoon, while I sit at the e-Lok waiting for the FSFE meeting
is a very good moment for me to look into it. I'll report tonight :-)

Thanks  later (dayjob calling)
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlU4ofIACgkQBcgs9XrR2kaFNwCfWzPunxHiiDJIJean02rx7pMT
92IAn2IGYW01Cx7aJt32MLRDQYuY9FbP
=owfk
-END PGP SIGNATURE-

bug#20339: [PATCH] sxml-xml and namespaces: updated patch

[tomas]

Hi,

I've embellished my proposed patch a bit:

 - use values resp. call-with-values instead of passing around
   lists.

   This was one thing I didn't like about my first patch candidate:
   the namespace -- ns abbreviation lookup had two things to return,
   for noe the abbreviation, and whether this abbreviation was new
   (for convenience in the form of a (namespace . abbreviation) pair).
   Instead of returning a list, now it returns multiple values.

 - patch is now against current stable instead of against whatever
   Debian stable packages, i.e. against

   d680713 2015-04-03 16:35:54 +0200 Ludovic Courtès (stable-2.0) doc: Update 
libgc URL.

I'm still not sure whether this is the way to go (i.e. mixing the
abbreviation stuff into the serialization), or whether a pre-pass
(replacing namespaces by abbreviations and generating the namespace
declaration attributes) would be the way to go.

Besides, I'd like to have some input on whether it'd be worth to
follow the usual convention and to put the namespace declarations
before regular attributes (forcing us to do two passes on a tag
node's attribute list). The generated XML looks pretty weird as
is now.

What I'd still like to introduce is a mapping preference as an
optional argument by the user, possibly per-node (like I'd like
'http://www.w3.org/1999/xlink' to be abbreviated as 'xlink' or
something like that). Other XML serializers offer that. I envision
this as a function, the library would fall back to generate the
abbreviation whenever the function returns #f.

The question on whether this patch (or whatever it evolves into)
has a chance of getting into Guile is still open: I'd have to
get my papers from the FSF in this case.

Inputs?
diff --git a/module/sxml/simple.scm b/module/sxml/simple.scm
index 703ad91..86b0784 100644
--- a/module/sxml/simple.scm
+++ b/module/sxml/simple.scm
@@ -215,29 +215,38 @@ port.
  (elements (reverse (parser port '()
 `(*TOP* ,@elements)))
 
-(define check-name
-  (let ((*good-cache* (make-hash-table)))
-(lambda (name)
-  (if (not (hashq-ref *good-cache* name))
-  (let* ((str (symbol-string name))
- (i (string-index str #\:))
- (head (or (and i (substring str 0 i)) str))
- (tail (and i (substring str (1+ i)
-(and i (string-index (substring str (1+ i)) #\:)
- (error Invalid QName: more than one colon name))
-(for-each
- (lambda (s)
-   (and s
-(or (char-alphabetic? (string-ref s 0))
-(eq? (string-ref s 0) #\_)
-(error Invalid name starting character s name))
-(string-for-each
- (lambda (c)
-   (or (char-alphabetic? c) (string-index 0123456789.-_ c)
-   (error Invalid name character c s name)))
- s)))
- (list head tail))
-(hashq-set! *good-cache* name #t))
+(define (ns-lookup ns nsmap)
+  Look up namespace ns in nsmap. Return its abbreviation or #f
+  (assoc-ref nsmap ns))
+
+(define ns-abbr-new
+  (let ((*nscounter* 0))
+(lambda ()
+  (set! *nscounter* (1+ *nscounter*))
+  (string-append ns (number-string *nscounter*)
+
+(define (ns-abbr name nsmap)
+  Takes a QName, SXML style (i.e a symbol whose string value is either a
+clean local name or a colon-concatenated pair of namespace:name, and returns
+two values: the string  nsabbrev:local-name and either a pair (namespace .
+nsabbrev) whenever namespace wasn't in nsmap, or #f when it was
+  ;; FIXME check for empty ns (e.g :foo)
+  ;; check (worse!) for empty locname (e.g. foo:)
+  (let* ((str (symbol-string name))
+ (i (string-rindex str #\:))
+ (ns (and i (substring str 0 i)))
+ (locname (or (and i (substring str (1+ i))) str)))
+(if ns
+(let ((nsabbr (ns-lookup ns nsmap)))
+  (if nsabbr
+  ;; known namespace:
+  (values (string-append nsabbr : locname) #f)
+  ;; unknown namespace
+  (let ((nsabbr (ns-abbr-new)))
+(values (string-append nsabbr : locname)
+  (cons ns nsabbr)
+;; empty namespace: clean local-name:
+(values locname #f
 
 ;; The following two functions serialize tags and attributes. They are
 ;; being used in the node handlers for the post-order function, see
@@ -260,42 +269,58 @@ port.
  port
 
 (define (attribute-xml attr value port)
-  (check-name attr)
   (display attr port)
   (display =\ port)
   (attribute-value-xml value port)
   (display #\ port))
 
-(define (element-xml tag attrs body port)
-  (check-name tag)
-  (display #\ port)
-  (display tag port)
-  (if attrs
-  (let lp ((attrs attrs))
-(if (pair? attrs)
-(let ((attr (car attrs)))
+(define (element-xml tag attrs body port nsmap)
+  (let 

bug#20339: sxml simple: sxml-xml mishandles namespaces?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I posted more details on guile-devel. Perhaps this was the wrong list?

When transforming SXML to XML, namespaces don't seem to be handled
properly:


  #!/usr/bin/guile -s
  !#
  (use-modules (sxml simple))
  
  ;; An XML with two namespaces (one default)
  (define the-svg svg xmlns='http://www.w3.org/2000/svg'
   xmlns:xlink='http://www.w3.org/1999/xlink'
rect x='5' y='5' width='20' height='20'
  stroke-width='2' stroke='purple' fill='yellow'
  id='rect1' /
rect x='30' y='5' width='20' height='20'
  ry='5' rx='8' stroke-width='2' stroke='purple' fill='blue'
  xlink:href='#rect1' /
  /svg)
  
  ;; Note how SXML handles QNames (just concatenating NS and
  ;; local-name with a colon):
  (define the-sxml
(with-input-from-string the-svg xml-sxml))
  (format #t ~A\n the-sxml)
  
  ;; If we try to serialize this: kaboom!
  (sxml-xml the-sxml)

The parsing into SXML goes well, the (format ...) outputs what
I'd expect. But the (sxml-xml ...) dies with:

  ERROR: In procedure scm-error:
  ERROR: Invalid QName: more than one colon http://www.w3.org/2000/svg:svg

The problem is that SXML used the concatenated (full) namespace with the
name as tag (and attribute) names for namespaced items. When serializing
to XML it should try to find abbreviations for those namespaces and issue
the corresponding namespace declarations.

Instead, sxml-xml tries to split the (namespace:name) combination
at the first colon and to check the name -- and fails miserably at
(namespace:name) combinations à la http://www.w3.org/1999/xlink:href;
(procedure check-name). Since there are two colons, the name part
has now a colon.

There are more details at:

http://lists.gnu.org/archive/html/guile-devel/2015-04/msg0.html

with a first attempt at a patch against guile (GNU Guile) 2.0.5-deb+1-3.
I'm more than willing to beat the patch into shape, but will possibly
need some guidance. Perhaps I'd need to sign papers with the FSF, which
I'd gladly do.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlUuwEIACgkQBcgs9XrR2kbJWQCfQ/ALFQrf0crOK47SbaOlJlMv
MwAAn3fxDBWOhgNF0L7E35k0skol2T0V
=FIId
-END PGP SIGNATURE-

Re: AG, that im living

[Tomas]

Banned CD! Government don't want me to sell it. See Now #


woody incurred precipitate jar confiscate anemone cheyenne nebula signify melon nonce beloit 
hackney innermost send gainful admission deane susan downgrade carla babylon filamentary applicable conglomerate brownell floppy apology greet auditory besiege koala taxiway acm discriminable them blackbird greater barcelona crewcut contagion newbold 
hillock awaken excusable codeposit chapter panorama quint chad del cognate mystify 
antwerp agrimony september abandon bellatrix crown spilt beachhead arithmetic compendia schemata artificial arcade coupon detoxify hook tuition anther 
biotic showdown weldon cannel augmentation cedilla decimal clip cerium balloon benedict flowery gloomy satin petrology hill colloq wrongful arterial delusive damage blister specie e.g trash dutiful heresy slovenia sans accipiter pilot mahayanist celsius acceptor fizeau electrophoresis 
marlin burden slain adapt lineup boisterous buoy diatomic culvert venerate underclassmen yah succession covariant thereon differentiable chef timber kinky augite riga carte stringent anode 


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: Strange behaviour of array?

[tomas]

On Fri, Nov 15, 2002 at 02:12:13AM -0600, Christopher Cramer wrote:
 On Tue, Nov 05, 2002 at 12:57:06PM +0100, [EMAIL PROTECTED] wrote:
[...]
 I distinctly remember sending a patch to fix this to either bug-guile or
 guile-devel a lng time ago, but I can't find it in the archives. I'm
 surprised it's not fixed in 1.6.0, but maybe it's because I never sent
 the patch in...

Thanks a zillion. I'll try this out when out of crunch mode.
I'll keep you informed

Regards
-- tomas


___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile