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

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

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

+#: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 fix

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

es 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 whet

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

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

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

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, en

bug#68087: Signal handlers not called after ‘primitive-fork’

Ludovic Courtès skribis: > Fixes . > > * libguile/scmsigs.h (scm_i_signals_pre_fork, scm_i_signals_post_fork): > New declarations. > (scm_i_signal_delivery_thread): Change type to SCM.. > * libguile/threads.c (scm_all_threads): Adjust accordingly and exclude > threads

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

Hi, Tomas Volf <~@wolfsden.cz> skribis: > 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

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

Hi, Tomas Volf <~@wolfsden.cz> skribis: > 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

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

Hi, Tomas Volf <~@wolfsden.cz> skribis: > 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).

bug#63366: Docs: Revise or delete reference to “benevolent dictators” in Manual Introduction

Hi, Sebastian Carlos skribis: > My suggestion is to delete the sentence altogether. I think the paragraph > still makes sense without it, as the reader gets enough information to > understand how Scheme differs from other programming languages. I’ve (finally) removed that sentence. Thanks! Lu

bug#68673: FW: can't export conditional variable set with 'cond'

Let’s include a copy of the actual bug report: Hi, Suppose I have the following module "testexport" with the auxiliary module "env.scm", used to set global environment variables: -testexport.scm begin-- (define-module (testexport)

bug#68673: can't export conditional variable set with 'cond')

>Why can I reset the variables with both 'cond' and 'if' in >env.scm, but >only the variable reset with 'if' is exported with the updated >value? Because apparently that’s a bug in Guile, presumably in the implementation of inlining. I propose sending the mail to bug-guile@gnu.org.

bug#62590: Strange put-char encoding-error "conversion to port encoding failed"

Hi, > (encoding-error put-char conversion to port encoding failed 84 > # s) Could the error be due to the 7-bit encoding in HTTP headers? [1] The "84" is EILSEQ from errno.h. [2] Wingo added the functionality here. [3] I also submitted a patch to resolve in the errno. [4] A similar issue appear

bug#68624: [PATCH] Decode errno for encoding errors.

* libguile/strings.c (scm_encoding_error): Decode errno. --- Hi, Even experienced users do not memorize errno values. [1][2] Why not decode them as a courtesy? Kind regards Felix Lechner [1] https://debbugs.gnu.org/62590 [2] https://debbugs.gnu.org/59510 libguile/strings.c | 2 +- 1 file chang

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

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-1

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

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): Exp

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

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, en

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

ot;. +** 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, wit

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

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#68417: scm_from_stringn throws error regardless of failed conversion handler

Here is a test program that defines a Guile extension to convert invalid UTF-8 bytes to a string using each of the failed conversion handlers described at https://www.gnu.org/software/guile/manual/html_node/Conversion-to_002ffrom-C.html#index-scm_005ft_005fstring_005ffailed_005fconversion_005fhan

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

ame segfault using list-ref > with the debian 3.0.8 version FWIW.) I looked it up and it is indeed the same bug. It's fixed in 3.0.9. Thanks for the report!

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

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

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

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

Hi, Tomas Nordin writes: > $ 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 `,sho

bug#68362: Wrong Guile version and a new error message

Sorry, I have provided the wrong version number used to produce the segmentation fault. The true version is: guile (GNU Guile) 3.0.5 Packaged by Debian (3.0.5-deb+3.0.5-4) Copyright (C) 2021 Free Software Foundation, Inc. License LGPLv3+: GNU LGPL 3 or later

bug#68362: Segmentation fault when a procedure is called with no arguments

I get the following output: Backtrace: In ice-9/boot-9.scm: 1736:10 7 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 6 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 5 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 4 (_ #(#

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

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 redistribu

bug#68087: [PATCH] Stop signal thread before forking, restart it afterwards.

ved a copy of the GNU Lesser General Public +;;; License along with this library; if not, write to the Free Software +;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + +;;; Test the bug described at <https://bugs.gnu.org/68087>: the signal +;;; thread would not

bug#68221: abort in call-scm<-scmn-scmn

I've got a core dump of Guile reaching the abort in call-scm<-scmn-scmn. #0 0x7fb8912d8fec in __pthread_kill_implementation () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6 #1 0x7fb89128f202 in raise () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-

bug#68087: Signal handlers not called after ‘primitive-fork’

In 3.0.9 and current ‘main’, I get this: --8<---cut here---start->8--- $ cat sigaction-fork.scm (use-modules (ice-9 match)) ;; This call spawns the signal delivery thread as a side effect. (sigaction SIGALRM (lambda (signal) (pk 'got-signal! signal))) (m

bug#67959: Smobs chapter in doc says '“applicable SMOBs” discussed below', which aren't

Hi, Reading the chapter on Smobs (info '(guile) Smobs'), it mentions: > With the exception of the so-called “applicable SMOBs” discussed below, > smobs are now a legacy interface and are headed for eventual > deprecation. But I don't see "applicable" SMOBS being discussed anyhere in the remainin

bug#67797: non-free license listed in module/ice-9/psyntax.scm

Hi, Mike Gran writes: >> Hi Mike, > >> Do I understand correctly that any copyright license comes with an >> implicit "lawful" condition so as to be considered valid, per the law of >> USA at least?  And that making this explicit is thus not considered a >> restriction on the use? > > That is ho

bug#67797: non-free license listed in module/ice-9/psyntax.scm

> Hi Mike, > Do I understand correctly that any copyright license comes with an > implicit "lawful" condition so as to be considered valid, per the law of > USA at least?  And that making this explicit is thus not considered a > restriction on the use? That is how I understand it. I am not a lawy

bug#67797: non-free license listed in module/ice-9/psyntax.scm

Hi Mike, Mike Gran writes: > On Tuesday, December 12, 2023 at 12:51:11 PM PST, Maxim Cournoyer > wrote: >>> This confirms my hunch that there is no issue with the license. > >>That's great, but... why is it not a problem?  :-) > >>When we find out, we should add an explanation next to the lic

bug#67797: non-free license listed in module/ice-9/psyntax.scm

On Tuesday, December 12, 2023 at 12:51:11 PM PST, Maxim Cournoyer wrote: >> This confirms my hunch that there is no issue with the license. >That's great, but... why is it not a problem?  :-) >When we find out, we should add an explanation next to the license text, >why it's deemed alright. M

bug#67797: non-free license listed in module/ice-9/psyntax.scm

Hi David, "Thompson, David" writes: > Hey Maxim, > > On Tue, Dec 12, 2023 at 10:53 AM Maxim Cournoyer > wrote: >> >> Hello, >> >> In our syntax-case implementation, module/ice-9/psyntax.scm, the >> following license text can be found: >> >> --8<---cut here---start---

bug#67801: [PATCH] Copy descriptions from manual into docstrings

* module/ice-9/binary-ports.scm (call-with-output-bytevector, seek, make-custom-binary-input-port, make-custom-binary-output-port, make-custom-binary-input/output-port): * module/ice-9/ports.scm (open-input-file, open-output-file, with-input-from-port, with-output-to-port, with-error-to-port): * mo

bug#67797: non-free license listed in module/ice-9/psyntax.scm

Hey Maxim, On Tue, Dec 12, 2023 at 10:53 AM Maxim Cournoyer wrote: > > Hello, > > In our syntax-case implementation, module/ice-9/psyntax.scm, the > following license text can be found: > > --8<---cut here---start->8--- > ;;; Portable implementation of syntax-c

bug#67797: non-free license listed in module/ice-9/psyntax.scm

Hello, In our syntax-case implementation, module/ice-9/psyntax.scm, the following license text can be found: --8<---cut here---start->8--- ;;; Portable implementation of syntax-case ;;; Originally extracted from Chez Scheme Version 5.9f ;;; Authors: R. Kent Dyb

bug#66776: SRFI-64 test-error doesn't match error types

Hi Taylan, Taylan Kammer writes: > On 27.10.2023 20:40, Maxim Cournoyer wrote: >> >> There is a more modern implementation of SRFI-64 out there for Guile >> which may provide clues or be used wholesale, though I haven't tried it: >>

bug#43521: ports.test "non-revealed port is closed" breaks other tests

Quoting myself, as this message appears to have been ignored for 1 year and 258 days: Looks like it has been resolved now, see the commit by Rob Browing: Do we close the issue now, or only at the

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

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

bug#67487: Minor typo in the manual.

bug#67487: Minor typo in the manual.

close 67487 Fixed in commit d8df317b. On Mon, Nov 27, 2023 at 3:47 PM 無無 wrote: > In < > https://www.gnu.org/software/guile/manual/html_node/Modules-and-the-File-System.html > >: > > When a program evaluates (use-modules (ice-9 popen)), and the > module is not loaded, Guile searches for a c

bug#65363: Missing support for (library ...) match condition in 'cond-expand'

Hi, Zhu Zihao writes: > In R7RS, page 14, section 4.2.1 Conditionals. The form 'cond-expand' can > accept following conditions > > ``` > A takes one of the following forms: > > - > - (library ) > - (and ...) > - (or ...) > - (not ) > ``` > > The form (library ) is used to test whether a R7RS

bug#67487: Minor typo in the manual.

In : When a program evaluates (use-modules (ice-9 popen)), and the module is not loaded, Guile searches for a conventionally-named file from in the load path. "from in the" should probably be "in the".

bug#67412: [PATCH v2 2/2] r7rs-libraries: Better support R7RS SRFI library names.

9/r7rs-libraries.scm @@ -103,12 +103,56 @@ #'(rename (from-identifier to-identifier))) (identifier #'identifier))) +(define (r7rs-name->r6rs-name name) + ;; This is a hack to support (srfi N x ...) modules in R7RS. The + ;; longer term solution woul

bug#67412: [PATCH v2 1/2] Use R7RS 'rename' syntax for exports.

From: Timothy Sample * module/ice-9/r7rs-libraries.scm (define-library): Convert R7RS exports to R6RS exports before passing them on to 'library'. Fixes: https://bugs.gnu.org/67255 Reported-by: Maxim Cournoyer . Modified-by: Maxim Cournoyer --- (no changes since v1) module/ice-9/r7rs-librari

bug#67255: [PATCH v2] Use R7RS 'rename' syntax for exports.

From: Timothy Sample * module/ice-9/r7rs-libraries.scm (define-library): Convert R7RS exports to R6RS exports before passing them on to 'library'. Fixes: https://bugs.gnu.org/67255 Reported-by: Maxim Cournoyer . Modified-by: Maxim Cournoyer --- Changes in v2: - Improve pattern variable names

bug#67412: [PATCH 1/2] Use R7RS 'rename' syntax for exports.

From: Timothy Sample * module/ice-9/r7rs-libraries.scm (define-library): Convert R7RS exports to R6RS exports before passing them on to 'library'. Fixes: https://bugs.gnu.org/67255 Reported-by: Maxim Cournoyer . --- module/ice-9/r7rs-libraries.scm | 9 +++-- 1 file changed, 7 insertions(+)

bug#67412: [PATCH 2/2] r7rs-libraries: Better support R7RS SRFI library names.

ort))) +(define (r7rs-name->r6rs-name name) + ;; This is a hack to support (srfi N x ...) modules in R7RS. The + ;; longer term solution would be to add support at the level of + ;; resolve-interface (bug #40371). + (define (n? stx) +(let ((n (syntax->da

bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers

Hi, Maxim Cournoyer writes: > Hello, > > Martin Becze writes: > >> Here is a patch that makes things usable for srfi's. (import (srfi >> )) will work. It just remove the guard condition that was catching >> the Integers. Does anyone know why the guard was there and if it is >> really needed

bug#67412: (resolve-r6rs-interface '(srfi 160 u8) tries to load (srfi srfi-160)

Hi, Investigating, I've found this: --8<---cut here---start->8--- trace: | (_ # (160 (u8) ())) trace: | (_ 160 (u8) ()) trace: | | (syntax->datum 160) trace: | | (strip 160) trace: | | | (syntax? 160) trace: | | | #f trace: | | 160 trace: | | (n

bug#67412: (resolve-r6rs-interface '(srfi 160 u8) tries to load (srfi srfi-160)

Hello, While working on integrating SRFI 178, I've encountered the following problem: --8<---cut here---start->8--- Backtrace: In system/base/compile.scm: 53:4 19 (call-once #) In ice-9/boot-9.scm: 1755:12 18 (with-exception-handler # ?) In system/base/c

bug#67255: define-library does not support 'rename' directives

Hey, Maxim Cournoyer writes: > Timothy Sample writes: > >> Fixes . >> Reported by Maxim Cournoyer . > > Nitpick: at least 'Reported-by' is a common git trailer, and these > must appear at the bottom of the git commit. That’s a fair point. I’m following what seems t

bug#40371: [R7RS] Guile does not accept library name parts that are non-negative exact integers

Hello, Martin Becze writes: > Here is a patch that makes things usable for srfi's. (import (srfi > )) will work. It just remove the guard condition that was catching > the Integers. Does anyone know why the guard was there and if it is > really needed? Is still still an issue when working w

bug#67255: define-library does not support 'rename' directives

Hello! Timothy Sample writes: > Timothy Sample writes: > >> Maxim Cournoyer writes: >> >>> Our R7RS define-library syntax, from (ice-9 r7rs-library) does not >>> support renaming bindings to export, via 'rename' directives. >> >> I appreciate your R7RS debugging effort. Thanks! > > Actions sp

bug#66046: [PATCH v3 1/3] libguile/fports.c: Remove extraneous include.

* libguile/fports.c: Delete "hashtab.h" include, which is unused. --- (no changes since v1) libguile/fports.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libguile/fports.c b/libguile/fports.c index 9d4ca6ace..8f19216b7 100644 --- a/libguile/fports.c +++ b/libguile/fports.c @@ -52,7 +52,6

bug#66046: [PATCH v3 3/3] ice-9: Fix 'include' when used in compilation contexts.

Fixes bug #66046. Introduce a '%file-port-stripped-prefixes' fluid that captures the pre-canonicalized file name used when compiling a file, before it gets modified in fport_canonicalize_filename. That reference that can then used by 'include' when searching for include

bug#66046: [PATCH v3 2/3] tests: Add new compile-file tests.

Add a test for bug #66046. To run just the compiler tests: ./meta/guile -L test-suite -L . test-suite/tests/compiler.test * test-suite/tests/compiler.test (with-temporary-directory): New syntax. (delete-file-recursively): New procedure. ("compile-file: relative include works") (&qu

bug#66046: [PATCH v2 2/3] tests: Add new compile-file tests.

Add a test for bug #66046. To run just the compiler tests: ./meta/guile -L test-suite -L . test-suite/tests/compiler.test * test-suite/tests/compiler.test (with-temporary-directory): New syntax. (delete-file-recursively): New procedure. ("compile-file: relative include works") (&qu

bug#66046: [PATCH v2 3/3] ice-9: Fix 'include' when used in compilation contexts.

Fixes bug #66046. Introduce a '%file-port-stripped-prefixes' fluid that captures the pre-canonicalized file name used when compiling a file, before it gets modified in fport_canonicalize_filename. That reference that can then used by 'include' when searching for include

bug#66046: [PATCH v2 1/3] libguile/fports.c: Remove extraneous include.

* libguile/fports.c: Delete "hashtab.h" include, which is unused. --- (no changes since v1) libguile/fports.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libguile/fports.c b/libguile/fports.c index 9d4ca6ace..8f19216b7 100644 --- a/libguile/fports.c +++ b/libguile/fports.c @@ -52,7 +52,6

bug#67370: FAIL: asyncs.test: preemption via sigprof (nondeterministic test failure)

Hi, I'm sometimes getting this test failure when running on the tip of the main branch, commit: d579848cb. The test does not seem to fail when run individually (via './meta/guile -L test-suite -L . test-suite/tests/asyncs.test'). Guile was configured using './configure --enable-mini-gmp'. It se

bug#67255: define-library does not support 'rename' directives

Timothy Sample writes: > Maxim Cournoyer writes: > >> Our R7RS define-library syntax, from (ice-9 r7rs-library) does not >> support renaming bindings to export, via 'rename' directives. > > I appreciate your R7RS debugging effort. Thanks! Actions speak louder than words, so here’s a patch! Th

bug#67255: define-library does not support 'rename' directives

Hi Maxim, Maxim Cournoyer writes: > Our R7RS define-library syntax, from (ice-9 r7rs-library) does not > support renaming bindings to export, via 'rename' directives. I appreciate your R7RS debugging effort. Thanks! > Our define-module syntax does not have such a feature (of renaming > *expor

bug#66046: Relative includes in R7RS define-library seem broken

Hello, I've just found a cross-compilation buggy interaction with my fix: --8<---cut here---start->8--- $ touch ./module/srfi/srfi-151.scm maxim@hurd ~/src/guile [env]$ touch ./module/srfi/srfi-160/base.sld maxim@hurd ~/src/guile [env]$ m make all-recursive

bug#67255: define-library does not support 'rename' directives

Hi, Our R7RS define-library syntax, from (ice-9 r7rs-library) does not support renaming bindings to export, via 'rename' directives. For example, attempting to build srfi/125.sld, which reads: --8<---cut here---start->8--- (define-library (srfi srfi-125) (e

bug#20272: Support reproducible builds

Parallel builds with guile-3.0.9 still introduce non-determinism I tested with openSUSE's guile-newt package and found (with filterdiff[1]) filterdiff strings */site-ccache/newt/checkboxtree.go produced among others newtCheckboxTree -/usr/lib64/libnewt +config +%libnewt dynamic-link dynamic-f

bug#67194: Stuck in wait-condition-variable

I seem to have got Guile stuck in wait-condition-variable. This is Guile 3.0.9 (specifically /gnu/store/x4m56h5qkim0pnvx6vgvp541mrdwdrah-guile-3.0.9/bin/guile). Here's some strace output. futex(0x7f52a1495af4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1700032632, tv_nsec=0}, FU

bug#66046: Relative includes in R7RS define-library seem broken

Hello, Amirouche writes: > If I am not mistaken, the patch is not backward compatible. > > The problem with the current patch is that it force the included file > to be next to the including file, there is no fallback mechanism. > The algorithm should be dynamic using an ordered list a priori

bug#66046: Relative includes in R7RS define-library seem broken

If I am not mistaken, the patch is not backward compatible. The problem with the current patch is that it force the included file to be next to the including file, there is no fallback mechanism. The algorithm should be dynamic using an ordered list a priority to the favorite behavior. The mo

bug#67063: [PATCH] Fix unread-string

Hello, This patch simply fixes bug 67063. Thanks, Juli * doc/ref/api-io.texi (Venerable Port Interfaces): Bring unread-string procedure documentation in line with other procedures in the section. * libguile/ports.c (scm_unread_string): Make port argument optional. * test-suite/tests/ports.test

bug#67063: unread-string does not match documented functionality

Hello, The procedure unread-string is documented to only optionally accept a port argument, but the implementation in fact requries it. I've written a patch to resolve this and will be sending it along shortly. Thanks, Juli

bug#52239: R7RS define-library does not support cond-expand

Hi, Amirouche writes: > fixed in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40252 Great! Closing, by replying to '52239-d...@debbugs.gnu.org'. -- Thanks, Maxim

bug#41956: is this still current ?

Hi, Adriano Peluso writes: > I understand that a overhaul of the exceptions stack intervened while > this bug was open > > Is this still current ? Yes. The affected code hasn't been touched since 2019. To recall, the reproducer is this: --8<---cut here

bug#66046: [PATCH 1/2] tests: Add new compile-file tests.

Add a test for bug #66046. To run just the compiler tests: ./meta/guile -L test-suite -L . test-suite/tests/compiler.test * test-suite/tests/compiler.test (with-temporary-directory): New syntax. (delete-file-recursively): New procedure. ("compile-file: relative include works") (&qu

bug#66046: [PATCH 2/2] ice-9: Fix 'include' when used in compilation contexts.

Fix bug #66046. Introduce a 'compilation-source-file-name' fluid that captures the pre-canonicalized file name used when compiling a file, before it gets modified in fport_canonicalize_filename. That reference that can then used directly by 'include', avoiding problems. *

bug#66046: Relative includes in R7RS define-library seem broken

Hello, Here's a new test that reproduces the issue: 1 file changed, 65 insertions(+) test-suite/tests/compiler.test | 65 + modified test-suite/tests/compiler.test @@ -18,6 +18,7 @@ (define-module (tests compiler) #:use-module

bug#66046: Relative includes in R7RS define-library seem broken

Hi, [...] > That's what Guile does (it attempts to locate the directory of the > including source file), but helas, it happens after the file port > corresponding to the including file has been relativized, which appears > ot strip the prefix of its file name that is in the load path. > > e.g.: .

bug#66046: Relative includes in R7RS define-library seem broken

Hi, I also encountered that problem while working on adding new SRFIs to Guile. Timothy Sample writes: > Hi Daphne, > > Daphne Preston-Kendal writes: > >> A standard layout for R7RS libraries is to have an .sld file >> containing the library import and export declarations with a parallel >> .s

bug#66046: Relative includes in R7RS define-library seem broken

Hi Daphne, Daphne Preston-Kendal writes: > A standard layout for R7RS libraries is to have an .sld file > containing the library import and export declarations with a parallel > .scm file with the same name in the same directory, which the .sld > file (include ...)s. > > [...] > > Guile supports

bug#66898: imported module (rnrs hashtables) overrides core binding `symbol-hash'

Hello, While working on integrating SRFI 126, I've noticed the following: --8<---cut here---start->8--- WARNING: (srfi srfi-126): imported module (rnrs hashtables) overrides core binding `symbol-hash' --8<---cut here---end---

bug#66852: Pipes not working in MSYS2

Hello Pipes are not working in Windows (MSYS2) here is an example program (use-modules (ice-9 popen) (ice-9 rdelim)) (let ((pipe (open-pipe* OPEN_READ "uname"))) (display (read-line pipe)) (close-pipe pipe)) and its output λ guile -s main.scm # of course `uname` works in t

bug#66776: SRFI-64 test-error doesn't match error types

On 27.10.2023 20:40, Maxim Cournoyer wrote: > > There is a more modern implementation of SRFI-64 out there for Guile > which may provide clues or be used wholesale, though I haven't tried it: > . > FYI, this is how I check wheth

bug#66776: SRFI-64 test-error doesn't match error types

Hello, I've mean meaning to use 'test-error' in test suites, but as a comment in its source says, it's currently incomplete: --8<---cut here---start->8--- ;; TODO: decide how to specify expected error types for Guile. --8<---cut here---e

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

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. On Friday, October 13, 2023 at 11:20:11 AM PDT, Tomas Volf wrote: On 2023-10-13 17:30:06 +, Mike Gran wrote: > > Both macros were

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

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

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

> 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

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

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

bug#66432: procedure 'display' incorrectly displays curly braces (3.0.9)

Dear Guile team , displaying the Scheme symbols "{" and "}" seems erroneous to me , see log below . Many thanks ! Mirko scheme@(guile-user)> (version) $1 = "3.0.9" scheme@(guile-user)> (symbol? '{) $2 = #t scheme@(guile-user)> (display '{) ; wrong #{\x7b;}#scheme@(guile-user)> (char? #\{) $3 = #t

bug#66366: [PATCH] doc: Add explanation on how to avoid escaping in SXML

>From 7754fda28a6029116ee49172af28b5aa28bcda7e Mon Sep 17 00:00:00 2001 From: Ekaitz Zarraga Date: Thu, 5 Oct 2023 22:42:44 +0200 Subject: [PATCH] doc: Add explanation on how to avoid escaping in SXML * doc/ref/sxml.texi (Reading and Writing XML): Add explanation on using a procedure to avoid e

bug#66365: [PATCH] Fix typo in doc

>From a23879367c7b7d89a6d0ec2880dc93e70f69fa87 Mon Sep 17 00:00:00 2001 From: Ekaitz Zarraga Date: Thu, 5 Oct 2023 22:41:36 +0200 Subject: [PATCH] Fix typo in doc * doc/ref/sxml.texi (Reading and Writing XML): Remove "." --- doc/ref/sxml.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

bug#65132: ...

Patch applied in 1e3b5390e3c24e66013118e9751db4de5025a4a2. Thanks, Daniel

bug#40584: ...

Patch applied in 3243d96bb5b9658f08847a7073fe6c0b2ccab6be. Thanks, Daniel

bug#66135: Unable to download Guile tar file

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 yo

bug#66135: Unable to download Guile tar file

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. On Sat, 23 Sept 2023, 13:18 , wrote: > It worked for me too. > > On Sat, Sep 23, 2023 at

bug#66135: Unable to download Guile tar file

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 restrictio

bug#66135: Unable to download Guile tar file

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

bug#66135: Unable to download Guile tar file

Not working for me, i can share the screenshot. On Fri, 22 Sept 2023, 23:26 Mikael Djurfeldt, wrote: > It (the link you provided) works for me. Can you try again? > > Den tors 21 sep. 2023 15:12ahmad khizir skrev: > >> Dear team, >> >> I tried to download a guile tar file from the below list

<    1   2   3   4   5   6   7   8   9   10   >