bug#40252: [PATCH] [R7RS] cond-expand in define-library forms

It looks like this bug was caused by a missing dot in a list in the cond-expand macro. This small patch fixes it: diff --git a/module/ice-9/r7rs-libraries.scm b/module/ice-9/r7rs-libraries.scm index 6db9de873..221806ad1 100644 --- a/module/ice-9/r7rs-libraries.scm +++ b/module/ice-9/r7rs

bug#40719: [PATCH 3/4] (ice-9 getopt-long): substantially re-written to pass all the new tests

All of the original tests also still pass. Also the entire guile build actually depends on the correct functioning of this module, so we can be quite confident that nothing has been broken. * module/ice-9/getopt-long.scm: Substantially re-written. --- module/ice-9/getopt-long.scm | 476 +++

bug#40719: [PATCH 4/4] (ice-9 getopt-long): update commentary and doc-strings

Emphasise importance of predicate part of specification of options with optional values. Minor clarifications elsewhere. Update copyright years and authorship. * module/ice-9/getopt-long.scm: Small changes only in non-code parts of source file. --- module/ice-9/getopt-long.scm | 117 +++

bug#40719: [PATCH 2/4] test *broken*: augmented tests of (ice-9 getopt-long)

This is to prepare the ground for some test-driven development mainly to make the module satisfy the needs of the GNU Mcron project. The main requirement is for the module to be more intelligent when dealing with optional values to command-line options: if the following argument looks like a new

bug#40719: [PATCH 1/4] test: augment testing of (ice-9 getopt-long) module

Adding some 28 new tests which explore some undefined (or at least implied) behaviour of the module. These are all non-controversial, and the existing module passes all of the tests. * test-suite/tests/getopt-long.test: new code added, some slight re-arrangement of existing code but nothing w

bug#41127: [PATCH 2/2] doc: Explain the *command-line-processor* module in texinfo.

in "vixie"))) + "format of data passed as standard input or file " + "arguments, 'guile' or 'vixie' (default guile)") + help-postamble + "Mandatory or optional arguments to long options are also mandat

bug#41127: [PATCH 1/2] Introduce (ice-9 command-line-processor) module.

a space-separated mix of selection +;;; words followed by their respective declarations. The selection +;;; words are ‘application’, ‘author’, ‘bug-address’, ‘copyright’, +;;; ‘help-preamble’, ‘help-postamble’, ‘license’, ‘option’, ‘usage’ and +;;; ‘version’, and can appear in any order

bug#41126: [PATCH] doc: Added very minimal doc strings to (srfi srfi-9 gnu).

* module/srfi/srfi-9/gnu.scm: Added some doc strings. --- module/srfi/srfi-9/gnu.scm | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/module/srfi/srfi-9/gnu.scm b/module/srfi/srfi-9/gnu.scm index 219bcdebb..0b9024e75 100644 --- a/module/srfi/srfi-9/gnu.scm +++ b/module/

bug#41127: [PATCH 0/2] New (ice-9 command-line-processor).

Modelled after GNU libc's argp command-line parser, and building on (ice-9 getopt-long), this new module allows a one-stop specification of how the command line options should work, (process-command-line (command-line) application "my-app" version "1.0" usage

bug#41045: transcoded-port turns input/output ports into output ports

Hello schemers, The transcoded-port procedure from (rnrs) does not handle input/output ports properly: --8<---cut here---start->8--- GNU Guile 3.0.2 Copyright (C) 1995-2020 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details typ

bug#39999: sed -i non-POSIX

wlharvey4--- via "Bug reports for GUILE, GNU's Ubiquitous Extension Language" writes: > Greg, > > Good point. The BSD sed man page says: > > "The -E, -a and -i options are non-standard FreeBSD extensions and may not be > available on other operating syst

bug#39999: sed -i non-POSIX

Greg, Good point. The BSD sed man page says: "The -E, -a and -i options are non-standard FreeBSD extensions and may not be available on other operating systems." So perhaps a better solution is to not use the -i option at all and be POSIX compliant? Informally looking through some of the cod

bug#39999: BSD sed vs Gnu sed

"W. Lincoln Harvey" via "Bug reports for GUILE, GNU's Ubiquitous Extension Language" writes: > backup file, BSD sed’s -i option requires a zero-length string as a > mandatory argument, while Gnu sed’s -i option does not take any > argument. In cases like this,

bug#39999: BSD sed vs Gnu sed

Sorry; my explanation above is not correct. What I meant to say is that to edit a file in place WITHOUT CREATING a backup file, BSD sed’s -i option requires a zero-length string as a mandatory argument, while Gnu sed’s -i option does not take any argument. If a backup file is wanted, then the

bug#39999: MacOS Catalina with sed

MacOS uses BSD sed. When the -i option to sed is used, it has a mandatory argument, which should be a zero length string to edit the file in-place. Gnu sed’s -i option uses an optional argument, rather than a mandatory argument, which if not present allows the file to be edited in-place. Add

bug#40954: See #39999

This problem is discussed in #3; sorry. The error is caused by MacOS using BSD sed, which requires a mandatory argument of a zero-length string to the -i option to edit a file in-place, whereas Gnu sed has an optional argument to the -i option to edit a file in-place. The different syntax

bug#40954: Guile 3.0.2 Fails to compile on macOS Catalina

The following line in: libguile Makefile target: install-data-hook during a “make install” call results in a "sed -e file not found" error and stops installation. $(INSTANTIATE) "$(DESTDIR)$(libdir)/$$libname-gdb.scm” When it is removed from the Makefile, Guile can be installed and “make chec

bug#40744: guile-2.2.4 (integer-length 0) erroneously returns 0, not 1

On Tue, 28 Apr 2020 20:08:10 +0200 Björn Höfling wrote: > Bugreport was re-opened under the guile package here: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40855 > > Closing this one. Oh, I didn't realize they were merged. So, I reopened them again :-) Björn

bug#40744: guile-2.2.4 (integer-length 0) erroneously returns 0, not 1

On Sat, 25 Apr 2020 23:33:50 +0200 Bengt Richter wrote: > Apologies for my faux pas ;-/ > > This was not a guix bug, and you have rightly ignored my report. > (now submitted to bug-guile, with hopes of nz human acks :) > > (I guess it will get a new number, so 40744 can be

bug#40855: integer-length 0 should be 1

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

bug#40855: integer-length 0 should be 1

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 &quo

bug#40847: compile errors and missing dependencies when building in mingw32 on windows

I'm trying to compile guile 3.0.2 on a windows 32bit machine using Mingw32. I was able to successfully run the configure script with no errors. FYI I had to compile the following libraries from source in order for the configure script to finish because for some reason the libraries installed by p

bug#40809: Apology: documentation for srfi-modules broken?

Hello Guilers! I submitted my patch for srfi-171 which got merged. I built it (or rather: I believe I did) on my little arm board without issues. However, after finally getting some computer time yesterday I tried to build guile master on my Mac, and when I checked the terminal window quickly t

bug#31777: guile-2.2 FTCBFS for mipsel

Hello, Looks like this one should be closed. Downstream is closed, marked as fixed. Tell me if I did wrong. -- Vincent Legoll

bug#40792: .dir-locals.el has unbalanced parens

Two too many right parens on line 44 in .dir-locals.el, causing the file to be unbalanced. Looks like this happened in this commit: 7ed92f0a9 * Add syntax-parameterize indentation to .dir-locals.el. -Dale

bug#40780: guile 3.0.2: Prevent warning using libguile with -Wpedantic (redefinition)

Dear Maintainer, 2 warnings as shown below for libguile 3.0.2 (i.e. usage of libguile in external C code) with gcc 9.3.0 and option -Wpedantic are indicated. In contrast I get no warnings for libguile 2.2.7 with the same compiler options. Therefore, please fix this easy to circumvent warning. Be

bug#40737: Even more info

And with threshold set to 0: # GUILE_JIT_THRESHOLD=0 guile Pre-boot error; key: misc-error, args: (#f "parent is not a exception type ~S" (#) #f)Aborted (core dumped) Program terminated with signal SIGABRT, Aborted. #0 0x76acd6b6 in ?? () [Current thread is 1 (LWP 515)] (gdb) thread apply all bac

bug#40737: Even more info

Also forgot to mention this is guile 3.0.2. It doesn't fail all the time. When run with GUILE_JIT_THRESHOLD=-1 , there are never any problems. With GUILE_JIT_THRESHOLD=0 , it always fails, but I'm not sure it's in the same place. -Dale

bug#40737: Forgot command output

# ulimit -c unlimited # guile Backtrace: Exception thrown while printing backtrace: Unrecognized keyword: #:exports Segmentation fault (core dumped) -Dale

bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

Here is a backtrace of running guile on a builtroot constructed system for rpi3. Thumb2 instructions: BR2_ARM_INSTRUCTIONS_THUMB2=y Gcc 7.5: BR2_GCC_VERSION="7.5.0" Glibc. Uses the patch from https://gitlab.com/wingo/lightening/-/merge_requests/3 I hope this makes it through the mail client ok.

bug#40723: [PATCH 4/4] (ice-9 getopt-long): update commentary and doc-strings

>From 6acbbb37a2f9a1968fcdbc8f3be3c805d28ef901 Mon Sep 17 00:00:00 2001 From: Dale Mellor Date: Sun, 19 Apr 2020 18:01:06 +0100 Subject: [PATCH 4/4] (ice-9 getopt-long): update commentary and doc-strings Emphasise importance of predicate part of specification of options with optional values. Min

bug#40720: [PATCH 3/4] (ice-9 getopt-long): substantially re-written to pass all the new tests

>From 7d169c24c0fdbbaa56c646985dd2861b12e2bca5 Mon Sep 17 00:00:00 2001 From: Dale Mellor Date: Sun, 19 Apr 2020 18:00:48 +0100 Subject: [PATCH 3/4] (ice-9 getopt-long): substantially re-written to pass all the new tests All of the original tests also still pass. Also the entire guile build ac

bug#40721: [PATCH 1/4] test: augment testing of (ice-9 getopt-long) module

>From b08d1cc7dc03d5e69dfd1f93e50617b81230b5e3 Mon Sep 17 00:00:00 2001 From: Dale Mellor Date: Sun, 19 Apr 2020 18:00:04 +0100 Subject: [PATCH 1/4] test: augment testing of (ice-9 getopt-long) module Adding some 28 new tests which explore some undefined (or at least implied) behaviour of the mod

bug#40722: [PATCH 2/4] test *broken*: augmented tests of (ice-9 getopt-long)

>From 57da5a3ae02008c4c66da21055749e51342fdd7e Mon Sep 17 00:00:00 2001 From: Dale Mellor Date: Sun, 19 Apr 2020 18:00:33 +0100 Subject: [PATCH 2/4] test *broken*: augmented tests of (ice-9 getopt-long) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This

bug#40719: [PATCH 0/4] GNU Mcron and the (ice-9 getopt-long) module

/Mcron/ is a GNU package which runs unattended jobs in the operating system at dynamically computed times; it is 99% Guile but currently shrouded in a thin veneer of C code for historical reasons, which have by now vanished. The Guile /getopt-long/ module parses a command lineʼs arguments for opti

bug#40584: R7RS string-for-each does not work two or more strings on its argument

OKUMURA Yuki wrote: > Actually it's my own bug but let me report here: (scheme base) lacks > implementation for string-for-each thus following code does not work; > > (import (scheme base)) > > (string-for-each > (lambda (e f) 'ok) > "01234" >

bug#40681: srfi-18 mutex-unlock! breaks mutex on timeout

hi, when mutex-unlock! is called (master: module/srfi/srfi-18.scm +306) with a condition and a timeout, it first resets the owner and then waits for the condition. If the timeout is reached (threads:wait-condition-variable returns #f) the cond's else condition returns #f. Now the owner is #f, whic

bug#40584: R7RS string-for-each does not work two or more strings on its argument

Hi, Actually it's my own bug but let me report here: (scheme base) lacks implementation for string-for-each thus following code does not work; (import (scheme base)) (string-for-each (lambda (e f) 'ok) "01234" "slas") Please note that we already have incompa

bug#40582: Valid URIs are rejected

Hi, Using (web uri), I was trying to parse "uri://a/c". Reading RFC3986, it should be a valid URI (see rule for reg-name in 3.2.2). However, passing it to string->uri results in #f. I've tracked this down to valid-host? which returns #f for "a". The reason is that the regexp checking if the ho

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

Am Do., 2. Apr. 2020 um 21:05 Uhr schrieb Andy Wingo : > In the concrete case of the SRFI modules, importing e.g. (srfi 9) works > AFAIU. Does this not work for you? > In this clause, it is checked whether every part of the library's name is a symbol: http://git.savannah.gnu.org/gitweb/?p=guile

bug#40486: http-get doesn't respect #:verify-certificate?

When I run the following piece of code: (use-modules (web client)) (http-get "https://bugzilla.redhat.com/rest/bug/1"; #:verify-certificate? #f) I get: ... In web/client.scm: 563:0 1 (http-get "https://bugzilla.redhat.com/rest/bug/1"; # _ # …) 231:6 0 (tls-wrap # _

bug#39863: Guile 1.8, apparent segfault on some Macs running Mojave

On Sun, Apr 5, 2020 at 9:29 AM Ludovic Courtès wrote: > Hi, > > Marnen Laibow-Koser skribis: > > > There’s now an lldb backtrace at > > https://gitlab.com/marnen/lilypond-mac-builder/issues/16#note_317315811 > . > > Hopefully it’s somewhat useful? > > Sorry, I can’t make much sense of it. :-/ >

bug#39863: Guile 1.8, apparent segfault on some Macs running Mojave

Hi, Marnen Laibow-Koser skribis: > There’s now an lldb backtrace at > https://gitlab.com/marnen/lilypond-mac-builder/issues/16#note_317315811 . > Hopefully it’s somewhat useful? Sorry, I can’t make much sense of it. :-/ Ludo’.

bug#39863: Guile 1.8, apparent segfault on some Macs running Mojave

On Sat, Mar 7, 2020 at 3:36 PM Ludovic Courtès wrote: > Hi, > > Marnen Laibow-Koser skribis: > > > On Sat, Mar 7, 2020 at 10:12 AM Ludovic Courtès wrote: > > [...] > > >> Could you provide a backtrace of the segfault? > >> > > > > I’m not sure how I would be able to get any more detailed debugg

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

as > to start with an import and cannot start with some `(cond-expand (guile > ...))'. (Besides, `cond-expand' has its own problems: > https://lists.gnu.org/archive/html/bug-guile/2020-03/msg00097.html > <https://lists.gnu.org/archive/html/bug-guile/2020-03/msg00097.

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

eral as an R7RS top-level program has to start with an import and cannot start with some `(cond-expand (guile ...))'. (Besides, `cond-expand' has its own problems: https://lists.gnu.org/archive/html/bug-guile/2020-03/msg00097.html). As a quick-and-dirty workaround, I would suggest that t

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

In the concrete case of the SRFI modules, importing e.g. (srfi 9) works AFAIU. Does this not work for you? I think that allowing numbers as module name components, beyond the SRFI modules, is not currently a good idea for Guile. I had a look at it and it's a bit too intrusive. Andy On Wed 01 A

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

An R7RS library name consists of parts, where each part is either a symbol or a non-negative exact integer. Guile doesn't support the latter ones. This is unfortunate as the implementation of a SRFI NNN is usually delivered in form of a library named (srfi NNN). When this is corrected, for intero

bug#40314: `guild doc-snarf -l c mycfile.c` does not extract docs

Hi, Running the command `guild doc-snarf -l c mycfile.c` does not extract docs. I have tried with this file https://git.zrythm.org/cgit/zrythm/tree/src/guile/audio/position.c?id=fd9881f34096f616a876d257bc74233c1f14218d as well as with libguile/alist.c from the guile distribution and I get emp

bug#40294: Documentation for arity procedures doesn't match behavior

Interaction showing the problem $ guile GNU Guile 2.2.6 Copyright (C) 1995-2019 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'

bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`

Ludovic Courtès writes: > Hi, > > Andreas Rottmann skribis: > >>> Andreas Rottmann skribis: >>> Andreas Rottmann writes: > [...] I isolated the cause; the following snippet hangs on Guile 2.2 > and 3.0, while it worked as expected on 2.0: > > [...] > > It see

bug#21897: verified in 3.0.2

This still exists in 3.0.2 scheme@(guile-user)> ,use (ice-9 control) scheme@(guile-user)> (call/ec (lambda (c) (with-continuation-barrier (lambda () (c "through continuation"))) "c-w-b returned")) $1 = "through continuation" scheme@(guile-user)> (version) $2 = "3.0.2"

bug#27209: patch

Hi Matt, Matt Wette skribis: >>From 2c3f7ea9ddd9d245a000ad8b19176f132607405b Mon Sep 17 00:00:00 2001 > From: Matt Wette > Date: Fri, 27 Mar 2020 10:19:53 -0700 > Subject: [PATCH] * doc/ref/compiler.texi: for description of > lambda-case argument 'kw' added "or @code{#f} if there

bug#27209: patch

attached is patch : added ", or @code{#f} if there are no keyword arguments" >From 2c3f7ea9ddd9d245a000ad8b19176f132607405b Mon Sep 17 00:00:00 2001 From: Matt Wette Date: Fri, 27 Mar 2020 10:19:53 -0700 Subject: [PATCH] * doc/ref/compiler.texi: for description of lambda-case argument 'kw' add

bug#40252: [R7RS] cond-expand in define-library forms

The following valid R7RS library definition is not handled correctly by Guile: (define-library (guile-test) (export fold) (cond-expand ((library (scheme list)) (import (scheme list))) ((library (srfi srfi-1)) (import (srfi srfi-1) This is what I get: $ guile --r7rs -L .

bug#30920: closed (Re: bug#30920: doc: Inconsistent parentheses in "(guile) sxml-match")

>> These snippets fail to evaluate. Could you check? > > I can confirm. Would be worth fixing. I have opened a separate bug report https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40235 for this. > Applied, thanks! Thanks! signature.asc Description: PGP signature

bug#40235: Failing snippets in sxml-match manual page

Two of the code snippets in "(guile) sxml-match" fail to evaluate. They are: * The first snippet in the "Matching the Unmatched Attributes" subsection @lisp (sxml-match '(a (@@ (z 1) (y 2) (x 3)) 4 5 6) ((a (@@ (y ,www) . ,qqq) ,t ,u ,v) (list www qqq t u v))) @end lisp * The snippet in th

bug#30920: doc: Inconsistent parentheses in "(guile) sxml-match"

Hi Arun, Arun Isaac skribis: > While working on this patch, I found that two of the code snippets don't > work. They work neither with square brackets nor with round > brackets. The two snippets are > > * The first snippet in the "Matching the Unmatched Attributes" subsection > > @lisp > (sxml-m

bug#40215: [PATCH 4/4] doc: Mention (ice-9 time) module path.

* doc/ref/scheme-using.texi (Profile Commands): Mention (ice-9 time) module path. --- doc/ref/scheme-using.texi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/ref/scheme-using.texi b/doc/ref/scheme-using.texi index ac265fcca..31981cb5d 100644 --- a/doc/ref/scheme-using.texi +++ b/doc/r

bug#40215: [PATCH 3/4] doc: Document default delimiter of string-join.

* doc/ref/api-data.texi (String Constructors): Document default delimiter of the string-join function. --- doc/ref/api-data.texi | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/ref/api-data.texi b/doc/ref/api-data.texi index a6b09c478..3dd5109c4 100644 --- a/doc/ref/

bug#40215: [PATCH 1/4] doc: Fix minor typo in the HTTP headers documentation.

* doc/ref/web.texi (HTTP Headers): Fix minor typo. --- doc/ref/web.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/ref/web.texi b/doc/ref/web.texi index 2d07dd7b1..31630def7 100644 --- a/doc/ref/web.texi +++ b/doc/ref/web.texi @@ -774,7 +774,7 @@ The MD5 digest of a re

bug#40215: [PATCH 2/4] doc: Improve content-range HTTP header documentation.

* doc/ref/web.texi (HTTP Headers): Improve punctuation in content-range HTTP header documentation. --- doc/ref/web.texi | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/ref/web.texi b/doc/ref/web.texi index 31630def7..93cd0214f 100644 --- a/doc/ref/web.texi +++ b/

bug#40215: [PATCH 0/4] A few minor documentation fixes and improvements

A few minor documentation fixes and improvements follow. Arun Isaac (4): doc: Fix minor typo in the HTTP headers documentation. doc: Improve content-range HTTP header documentation. doc: Document default delimiter of string-join. doc: Mention (ice-9 time) module path. doc/ref/api-data.te

bug#40206: guile should delete unix listen socket when quit

Suppose I start guile to listen on a unix socket /tmp/guile like so: $ guile --listen=/tmp/guile When I quit guile, the socket file still remains. The next time I start guile to listen on /tmp/guile, guile errors out with the following error. It would be better if guile deleted the socket file o

bug#40194: Weak sets keep growing

Ludovic Courtès skribis: > The size of the weak set keeps growing, even when GC happens. Commit 02e3dc6ab95fe51786b68a8200322e163f8da478 mostly addresses it: --8<---cut here---start->8--- $ ./meta/guile -s ~/src/guile-debugging/weak-set-growth.scm ;;; (10 #)

bug#30920: doc: Inconsistent parentheses in "(guile) sxml-match"

Hi, > I agree with you that consistency would be nice and a patch in that > direction would be welcome! Please find attached a patch. While working on this patch, I found that two of the code snippets don't work. They work neither with square brackets nor with round brackets. The two snippets a

bug#38486: done

scm (preserve-eq?): New helper. (sigbits-union): Use the new helper. Fixes bugs.gnu.org/38486. Thanks to Zack Marvel for the bug report and Matt Wette for tracking it down.

bug#40194: Weak sets keep growing

Hello, Consider this code: --8<---cut here---start->8--- (define (create-symbols) (let loop ((i 1)) (unless (zero? i) (gensym) (loop (1- i) (let loop ((i 10)) (unless (zero? i) (pk i (%symbols)) (create-symbols) (loop (1

bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`

Hi, Andreas Rottmann skribis: >> Andreas Rottmann skribis: >> >>> Andreas Rottmann writes: >>> [...] I isolated the cause; the following snippet hangs on Guile 2.2 and 3.0, while it worked as expected on 2.0: ;; -- (import (rnrs)) (let* ((p (p

bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`

Ludovic Courtès writes: > Hi Andreas, > > And welcome back! :-) > Thanks -- and thanks in return for looking into this! > Andreas Rottmann skribis: > >> Andreas Rottmann writes: >> >>> [...] I isolated the cause; the following snippet hangs on Guile 2.2 >>> and 3.0, while it worked as expect

bug#39361: continuation and gc performance

Hi, Stefan Israelsson Tampe skribis: > That function marks the working stack no, what about stack segments in > continuations will they be marked correctly as well? Oh you’re right, from a quick look at continuations.c, a continuation’s stack appears to be conservatively scanned (allocated with

bug#29001: git patch

Hi Matt, Matt Wette skribis: >>From 71ff7e79369a4514a961fc5cf76593b254c32d4c Mon Sep 17 00:00:00 2001 > From: Matt Wette > Date: Sun, 22 Mar 2020 09:12:37 -0700 > Subject: [PATCH] 2020-03-22 Matt Wette > > * configure.ac: > Provide new option: --disable-tmpnam > This is made available for inst

bug#29001: git patch

Attached is the git patch against the following guile commit: bef5e0b3938cc88e3a1a1ac590b009875cc38162 >From 71ff7e79369a4514a961fc5cf76593b254c32d4c Mon Sep 17 00:00:00 2001 From: Matt Wette Date: Sun, 22 Mar 2020 09:12:37 -0700 Subject: [PATCH] 2020-03-22 Matt Wette * configure.ac: Provid

bug#38486: specialize-numbers.scm: compute-significant-bits

I've narrowed it down to the named let loop "lp" in this routine in module/language/cps/specialize-numbers.scm (define (compute-significant-bits cps types kfun)   "Given the locally inferred types @var{types}, compute a map of VAR -> BITS indicating the significant bits needed for a variable.  B

bug#21076: dynamic-link often fails to load libraries

Hi Isaac, Isaac Jurado skribis: > From b337d412b3c10cabe355df07d2295c4d0a560b10 Mon Sep 17 00:00:00 2001 > From: Isaac Jurado > Date: Sat, 8 Jun 2019 14:00:29 +0200 > Subject: [PATCH] Interpret dynamic library name as literal path first. > > Fixes . > > * libguile/dy

bug#39162: [PATCH] Fix file lookup of modules with a dot in their name.

Hi! Jan Nieuwenhuizen skribis: > Much to my surprise, Guile (v2.2 and 3.0 alike) fail to load a module > that has a dot in its base name. Directory names with dots > (e.g. ice.10/boot-10.scm => (ice.10 boot-10)) are fine. [...] > - /* If FILENAME has an extension, don't try to add EXTENSIONS

bug#38486: hang

So I hacked modules/cps/optimize.scm to display the optimization phases. Here is what I got up to the point where guile hangs. It looks like it's hanging in specialize-numbers. running eliminate-dead-code running prune-top-level-scopes running simplify running contify running inline-constructors

bug#30920: doc: Inconsistent parentheses in "(guile) sxml-match"

Hi Arun, Arun Isaac skribis: > All examples in "(guile) sxml-match" use square parentheses around each > match clause. However, in the subsection "Guards in Patterns" alone, the > example has round parentheses. I think it would be nice to use round > parentheses consistently in all examples so t

bug#29001: --disable-tmpnam

Hi Matt, Matt Wette skribis: > "make" and "make check" succeeds on 3.0.1 / Ubuntu 18.04 / x86_64 with > 1) --disable-tmpnam > 2) --enable-tmpnam > 3) neither > > This updates libguile/posix.c and configure.ac to allow extra > configuration option --disable-tmpnam.   This is made available > for

bug#38486: try all options

The behavior is that guild compile 38486-1.scm hangs These optimization flags eliminate that behavior: the code compiles quickly:  -O0  -O1  -Ono-simplify  -Ono-contify  -Ono-cse  -Ono-specialize-numbers These optimization flags are ineffective: the behavior remains:  -Ono-partial-eval  -Ono-eli

bug#39361: continuation and gc performance

That function marks the working stack no, what about stack segments in continuations will they be marked correctly as well? On Sat, Mar 21, 2020 at 6:33 PM Ludovic Courtès wrote: > Hi Stefan, > > Stefan Israelsson Tampe skribis: > > > I think I found a gc leak in guile 3.0 > > > > Isn't it so t

bug#38486: compile livelock

I reproduced the behavior on 2.2.7.   I also found that -O0 and -O1 do not have a problem: $ meta/guild compile -O0 38486-1.scm -o 38486-1.go wrote `38486-1.go' $ meta/guild compile -O1 38486-1.scm -o 38486-1.go wrote `38486-1.go' $ meta/guild compile -O2 38486-1.scm -o 38486-1.go ^Cerror: int

bug#29001: patch

Note: The above patch makes tmpnam report that it is deprecated.

bug#29001: --disable-tmpnam

"make" and "make check" succeeds on 3.0.1 / Ubuntu 18.04 / x86_64 with 1) --disable-tmpnam 2) --enable-tmpnam 3) neither This updates libguile/posix.c and configure.ac to allow extra configuration option --disable-tmpnam.   This is made available for installations that don't want to allow the ins

bug#39954: [3.0.0] ‘frame-local-ref’ returns (SCM)0x0

More generally, it seems that ‘frame-local-ref’ gets it wrong anytime it sees a stack frame for a subr. Ludo’.

bug#39586: pfds 0.3 hamt-fold crashes with guile-2.0 and guile-3.0

if it might be a guile bug, or > if it's more likely an issue with pfds. > > (use-modules >((pfds hamts) #:prefix hamts/) >((srfi srfi-69) #:prefix hash/)) > > (define x (hamts/hamt-set > (hamts/hamt-set > (hamts/ha

bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`

Hi Andreas, And welcome back! :-) Andreas Rottmann skribis: > Andreas Rottmann writes: > >> [...] I isolated the cause; the following snippet hangs on Guile 2.2 >> and 3.0, while it worked as expected on 2.0: >> >> ;; -- >> (import (rnrs)) >> >> (let* ((p (pipe)) >>(in

bug#39361: continuation and gc performance

Hi Stefan, Stefan Israelsson Tampe skribis: > I think I found a gc leak in guile 3.0 > > Isn't it so that so the continuation keep a copy of the stack. The issue is > that in the stack a raw integer or float may be present and so the gc > properties is less then ideal as those may be interpreted

bug#40075: patch

Hi Matt, Matt Wette skribis: > Below is a patch against guile-3.0.1. > > "make" works, "make check" works. > > null-threads.c was not seeing "SCM_USE_NULL_THREADS" so include > libguile/scmconfig.h > null-threads.c was not seeing def of SCM_API so include "libguile/scm.h" > web-server.test used

bug#40075: patch

Below is a patch against guile-3.0.1. "make" works, "make check" works. null-threads.c was not seeing "SCM_USE_NULL_THREADS" so include libguile/scmconfig.h null-threads.c was not seeing def of SCM_API so include "libguile/scm.h" web-server.test used (if (provided? 'threads) ) so #undefined if

bug#40075: pthreads

I have duplicated this w/ 3.0.1 on ubuntu 18.04, x86_64. I will look into this today. Matt

bug#40075: oops

scratch that - 29001 is about the tmpnam issue

bug#21076: dynamic-link

I have encountered this issue with dynamic-link. I propose a small patch to Guile (works on v3.0.1) to address it. At least this allows me to load the file if I know the exact name. This patch fixes issue with libtool and OSes which use non-standard extensions for shared libraries.  The libltdl f

bug#29001: tmpnam

On 3/18/20 4:48 PM, Matt Wette wrote: This is related to 4075 at debbugs.gnu.org \ er  40075 at debbugs.gnu.org working on patch against 3.0.1 going better this time

bug#29001: tmpnam

This is related to 4075 at debbugs.gnu.org

bug#40075: tmpnam

This is related to 29001 at debbugs.gnu.org

bug#28211: Stack marking issue in multi-threaded code, 2020 edition

8a846d6b51b172f7c. \o/ I confirmed with and without rr that it no longer triggers the dreaded crash. BTW, pro tip: to run ./meta/guile under rr, I do: sed -i libguile/guile \ -e 's/exec /exec rr record -n --syscall-buffer-sig=SIGUSR1 /g' where ‘-n’ disables stack switching. &

bug#40075: guile-3.0.1: --without-threads build failure on NetBSD

Hi! guile-2.2.7 builds fine, but when I try to build guile 3.0.1 --without-threads on NetBSD-9.99.49/amd64, I see: CCLD libguile-3.0.la ld: .libs/libguile_3.0_la-posix.o: in function `scm_tmpnam': /scratch/wip/guile30/work/guile-3.0.1/libguile/posix.c:1605: warning: warning: tmpnam() possi

bug#17940: (begin)

I have run into this also, in writing macros. My workaround is to always add (if #f #f) in my forms that allow no expressions in the body. See second-to-last line below. (define-syntax sx-match-1   (syntax-rules ()     ((_ v (pat exp ...) c1 ...) (let ((kf (lambda () (sx-match-1 v c1 ...

bug#36811: Guix fails to build with libgc 8.0.4

<    8   9   10   11   12   13   14   15   16   17   >