bug#41355: [PATCH] Fix typos in the manual

From: Jan Synacek * doc/ref/api-control.texi: * doc/ref/r6rs.texi: * doc/ref/sxml.texi: Fix typos. --- doc/ref/api-control.texi | 4 ++-- doc/ref/r6rs.texi| 2 +- doc/ref/sxml.texi| 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/ref/api-control.texi

bug#41354: equal? has no sensible code path for symbols

In Scheme, symbols can be compared using eq? for equality. However, since they have garbage-collected content attached, they do not meet the predicate SCM_IMP in the short-circuit evaluation at the start of equal? This means that unequal symbols compared using equal? fall through a whole bunch

bug#41353: (const x) is a thunk

With guile-3.0.2: scheme@(guile-user)> (thunk? (const 1)) $1 = #t Since thunk is a procedure that does not accept arguments (section 6.9.7, documentation for 'thunk?'), the result of the above evaluation should be #f.

bug#41352: incomprehensible paragraph in info pages

In guile-3.0.2 manual, section 6.9.3 Compiled Procedures, there is: Compiled procedures, also known as “programs”, respond all procedures that operate on procedures. In addition, there are a few more accessors for low-level details on programs. The first compound sentence doesn't make much

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

On Sat, 16 May 2020, at 14:27, Jan Synacek wrote: > I don't really have a strong opinion. I simply thought that the order > in XML->SXML should be the same. Otherwise, I don't see how sxml-match > is actually useful in such a case. Attributes ordering should not matter in sxml-match, as per

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

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.

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

On Sat, May 16, 2020 at 2:36 PM Linus Björnstam wrote: > > > On Sat, 16 May 2020, at 14:27, Jan Synacek wrote: > > > I don't really have a strong opinion. I simply thought that the order > > in XML->SXML should be the same. Otherwise, I don't see how sxml-match > > is actually useful in such a

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

On Sat, May 16, 2020 at 1:35 PM wrote: > > 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

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

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

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

Consider the following code snippet running on Guile-3.0.2: (use-modules (sxml simple) (sxml xpath)) (define doc (call-with-input-file "/home/jsynacek/src/xcb-proto-1.13/src/xproto.xml" (lambda (port) (xml->sxml port (define events ((sxpath '(// event)) doc))

bug#41204: port-revealed count is initially > 30000

Hi, Caleb Ristvedt skribis: > (port-revealed (open-input-file "/dev/null")) > => 32539 Fixed in b1bdd791cefa1b6d113f9b3972550342d8f4aa9f. Guile up to 2.2.7/3.0.2 included (but not 2.0) would thus leak the file descriptors of all the file ports not explicitly closed. It’s probably not that

bug#41204: port-revealed count is initially > 30000

(port-revealed (open-input-file "/dev/null")) => 32539 The little investigating I've done so far suggests that this is because scm_i_fdes_to_port calls scm_gc_malloc_pointerless and initializes only the 'fdes' and 'options' fields, leaving 'revealed' uninitialized. The comment above

bug#41142: [PATCH] GUILE_PKG bails out when 'pkg-config' is missing

* meta/guile.m4 (GUILE_PKG): Ensure that 'pkg-config' is available. Use AC_REQUIRE for PKG_PROG_PKG_CONFIG to avoid unnecessary invocations. --- meta/guile.m4 | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/guile.m4 b/meta/guile.m4 index bc0daaf46..508f8b9d4 100644

bug#41131: Bug in hash-table-merge! (and patch)

Hi, I just found this bug in the hash-table-merge! function (modul/srfi/srfi-69.scm). Instead of merging both hash tables, it was ignoring one of them (other-ht). Attached is the fix, where it now folds over other-ht and store its data in ht. Cheers, Ricardo G. Herdt From

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

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

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

ixie"))) + "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 mandatory or " + "optiona

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

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

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 systems.&

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

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, it is

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

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.

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

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

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 pg

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 following i

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 "length"

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

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

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.

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

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.

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

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

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

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

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,

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 incompatible stri

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

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:

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 # _ # _) web/

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

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

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

rt 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.html>). > > As a quick-and-dir

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

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 the Guiles (syntax-case?) parser of

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

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

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

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

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'

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

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 >

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

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

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

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

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.

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

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

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

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

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

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

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

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:

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. 

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

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

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

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

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  

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

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:

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

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

t 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/hamt-set >

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#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)) >>

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

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