bug#39954: bug#50153: Acknowledgement (call-with-values outside tail position + backtrace + compilation causes segfault)

I did some debugging on the C side, using 'rr': LD_LIBRARY_PATH=.libs ../meta/uninstalled-env rr record ./.libs/guile --fresh-auto-compile -l ../crash.scm it leads to a segfault, as expected. According to #39954, which looks similar, 'frame-local-ref' returns (SCM)0x0. So I tried some reverse

bug#50153: Acknowledgement (call-with-values outside tail position + backtrace + compilation causes segfault)

This looks rather similar to 39...@debbugs.gnu.org, looking at the backtrace from GDB, maybe the cause is the same? Thread 1 "guile" received signal SIGSEGV, Segmentation fault. 0x77f40f3f in scm_is_values (x=) at values.h:30 30return SCM_HAS_TYP7 (x, scm_tc7_values); (gdb) bt #0

bug#50153: call-with-values outside tail position + backtrace + compilation causes segfault

Hi guilers, Write the following to "crash.scm": > (call-with-values backtrace list) > #t (the trailing #t is important) and run > # --auto-compile works too, but --no-auto-compile doesn't cause a crash > guile --fresh-auto-compile -l crash.scm it will segfault during the printing of the

bug#50127: [PATCH] doc: Fix typos.

> As the author of most of the part with corrections: thank you. I am > cleaning up the reference implementation as well, so this is very > welcome! You're welcome! :-) I find SRFI-171 to be very useful. It has changed the way I write scheme code. signature.asc Description: PGP signature

bug#50127: [PATCH] doc: Fix typos.

As the author of most of the part with corrections: thank you. I am cleaning up the reference implementation as well, so this is very welcome! -- Linus Björnstam On Thu, 19 Aug 2021, at 22:18, Arun Isaac wrote: > * doc/ref/api-foreign.texi, doc/ref/srfi-modules.texi: Fix typos. > --- >

bug#50127: [PATCH] doc: Fix typos.

* doc/ref/api-foreign.texi, doc/ref/srfi-modules.texi: Fix typos. --- doc/ref/api-foreign.texi | 2 +- doc/ref/srfi-modules.texi | 32 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/ref/api-foreign.texi b/doc/ref/api-foreign.texi index

bug#49930: glibc-2.34 build failure in gnulib (needs a sync)

On Mon, 16 Aug 2021 19:41:36 +0200 lloda wrote: > Hi, > > I have updated gnulib in > http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=b4a80f4239b19fea4d2cc3e9d197f24b809f0624 > >

bug#49930: glibc-2.34 build failure in gnulib (needs a sync)

Hi, I have updated gnulib in http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=b4a80f4239b19fea4d2cc3e9d197f24b809f0624 . Please let me know if this solves the issue – I am

bug#50068: Curried definitions lose docstrings

When a docstring is used in the body of a curried definition, it ends up on the result of the application of the resulting curried function, not on the function itself. Example: (use-modules (ice-9 curried-definitions)) (define ((curried a) b)   "Docstring of curried"   'whatever)

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

Even when guile is run with --no-auto-compile, the REPL still seems to be compiling the source. $ guile --no-auto-compile GNU Guile 3.0.5.130-5a1e7 [Legalese…] scheme@(guile-user)> unbound-variable ;;; :1:0: warning: possibly unbound variable `unbound-variable' [Backtrace…] This "possibly

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

Hello, Please have a look at the following session: $ cat bug.scm (format #t "~f\n" 42) $ guile --no-auto-compile bug.scm Backtrace:    1 (primitive-load "/home/jean/repos/guile/bug.scm")    0 (simple-format #t "~f\n" 42) ERROR: In procedure simple-format: In procedure

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

Note that this does not happens with Guile 2.2

bug#49941: [PATCH] module/system/base/target.scm: support riscv32

Fix the following build failure on riscv32: system/base/target.scm:132:16: In procedure triplet-pointer-size: unknown CPU word size "riscv32" Fixes: - http://autobuild.buildroot.org/results/6705630c1484239ec8b73d57ebc2e2570fbfc8f8 Signed-off-by: Fabrice Fontaine ---

bug#49930: glibc-2.34 build failure in gnulib (needs a sync)

Hi bug-guile! Recent glibc-2.34 released changed attribute macros slightly which broke older gnulib macros. Fixed in gnulib upstream as: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=0c907f7da13232908f05c415b8cec56024071906 guile.git now fails to build on x86_64-linux

bug#49911: [PATCH] api-control: Fix misprint in code example.

* doc/ref/api-control.texi (Simple Conditional Evaluation): Correct the typo in the example unless form. Delete trailing whitespaces. --- doc/ref/api-control.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/ref/api-control.texi b/doc/ref/api-control.texi index

bug#49623: [PATCH v2] Parse #{{}}# properly.

#\#) '() -(cons #\} (lp #f +;; Don't eat CH, see + ;; <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49623>. +(cons #\} (lp/inner ch #f ((eqv? ch #\}) (lp #t)) ((eqv?

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

F0 39E9 ED1B 597A > GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 I tried to make a pitch for (integer-length 0) =-> 1 in [1]https://lists.gnu.org/archive/html/bug-guile/2020-04/msg00027.html though I now think integer-length is a useful measure of mathematical in

bug#49707: Documentation and behavior differ for match (not ...) pattern

The documentation states: > (not pat_1 ... pat_n) if all pat_1 thru pat_n don't match The code only implements (not pat), for a singular pattern, e.g: (match 2 ((not 1) 'not-one) (1 'one) (2 'two)) => not-one According to the documentation this should work, but the

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

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

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

Hello, At the Guile prompt: scheme@(guile-user)> (if #t (begin (define var 5) (display var)) While compiling expression: Syntax error: unknown file:#f:#f: definition in expression context, where definitions are not allowed, in form (define var 5) The "#f:#f:" part in the error message does

bug#49085: Unicode in uri-decode: we’re parsing IRIs, so NFC (unicode normalization) applies.

maximed in #guix pointed out that there should not be any non-ascii character in a URI, so what I was trying to do is simultaneously parse an IRI and convert it to an URI. For this to work, unicode normalization is required. From 39fd259ac1aa126ca311c687041baa5568cfdc09 Mon Sep 17 00:00:00 2001

bug#49623: [PATCH v2] Parse #{{}}# properly.

r ((ch (next-not-eof)) + (saw-brace? saw-brace?)) (cond (saw-brace? (if (eqv? ch #\#) '() -(cons #\} (lp #f +;; Don't eat CH, see +;; <https://debbugs.gnu.org/cgi/

bug#45788: ‘non-revealed port is closed’ test case is already fixed

Hi guilers and guix, I (and some other people) encountered this bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43521#11 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45788 https://issues.guix.gnu.org/48389#8 There is already a fix: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43521#11

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

Hi Guys, I am trying to package guile 3.0.7 into Fedora but I encountered a problem. In sources, there is a header lib/libc-config.h and then there is preprocessor condition for presence of __attribute_maybe_unused__ macro. This macro is newly defined in the latest version of glibc which we have

bug#49623: Fwd: [PATCH] Parse #{{}}# properly.

It turns out that the test fails when the patch is applies to guile@3.0.7. I'll rebase and try to figure things out. signature.asc Description: This is a digitally signed message part

bug#49623: [PATCH] Parse #{{}}# properly.

Hi guilers, This fixes bug #49623. I also added two additional test cases. I'm rebuilding Guile right now and will re-run the entire test suite, and I'll build the affected guile library with the fixed guile. Greetings, Maxime. From 9fb7cff1a2544aae3827db1a781be6e5c367d8c0 Mon Sep 17 00:00:00

bug#49623: Guile 3.0.7 can't read #{{}}#

Hi, A scheme library I'm working on now fails to compile after switching from 3.0.2 to Guile 3.0.7. The issue is that Guile can't read #{{}}# anymore. In guile 3.0.7: scheme@(guile-user)> '#{{}}# }# $1 = #{\x7b;\x7d;# }# ; the }# should result in a syntax error scheme@(guile-user)> '#{{}}# ;

bug#49617: guile fails to build with jit on x86_64-pc-linux-gnux32

On x86_64-pc-linux-gnux32 guile fails to build with segfault at "GEN guile-procedures.texi". Backtrace from coredump or from gdb-uninstalled-guile appears to be garbage or empty. Tested current git, 3.0.7 tarball and several other versions from git where jit is enabled and works on plain

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

Hmm, the zero result appears to be intentional, i.e. it's mentioned in the examples here: https://www.gnu.org/software/guile/manual/guile.html#Arithmetic and is also specified by Chez Scheme and SRFI-60: https://www.scheme.com/csug8/numeric.html

bug#34691: Guile 2.2.4 make check failure

David Lisle writes: > FAIL: test-out-of-memory Thanks for the report -- for what it's worth, in Debian at least we've marked that one as unreliable:

bug#49452: Confusing behavior with (include) used in file in GUILE_LOAD_PATH

Hello Bengt, Unfortunately that still doesn't work :( I think they should be considered the same though, when this bug gets fixed. Vijay On 7/7/21 4:22 PM, Bengt Richter wrote: > Hi Vijay, > > On +2021-07-06 19:31:38 -0500, Vijay Marupudi wrote: >> Hello all, >> >&g

bug#49452: Confusing behavior with (include) used in file in GUILE_LOAD_PATH

Thank you Taylan. This does appear to be the same bug. This bug can be closed as a duplicate. Looks like Andy Wingo suggested a potential fix, but there was no follow-up. If someone is willing to show me the ropes when I need them, I can take a stab at learning the Guile codebase and fixing

bug#49452: Confusing behavior with (include) used in file in GUILE_LOAD_PATH

Hi Vijay, On +2021-07-06 19:31:38 -0500, Vijay Marupudi wrote: > Hello all, > > It is unclear to me what the intended behavior for (include > "filename.scm") is, so I'm sending an email about this potential bug. > > The Local Inclusion docs > <https://www.gnu.o

bug#49452: Confusing behavior with (include) used in file in GUILE_LOAD_PATH

On 07.07.2021 02:31, Vijay Marupudi wrote: > Hello all, > > It is unclear to me what the intended behavior for (include > "filename.scm") is, so I'm sending an email about this potential bug. > > The Local Inclusion docs > <https://www.gnu.org/software/guile/man

bug#49452: Confusing behavior with (include) used in file in GUILE_LOAD_PATH

Hello all, It is unclear to me what the intended behavior for (include "filename.scm") is, so I'm sending an email about this potential bug. The Local Inclusion docs <https://www.gnu.org/software/guile/manual/html_node/Local-Inclusion.html> seem to state that relative paths ar

bug#49404: Cross module inlining causes unbound make-struct/no-tail ref

This commit casuses lokke's compilation to fail: commit fd5cb457fb3a450b4b14eb89c8dbd764ba8df52e Date: Mon Apr 5 20:58:03 2021 +0200 Implement cross-module inlining * module/language/tree-il/optimize.scm (make-optimizer): Pass cross-module-inlining? to peval. *

bug#49363: eof-object? is not exported from (ice-9 binary-ports)

red. I suppose I should import 'eof-object?' from (rnrs io ports) as I am using RnRS library forms. Still, this seems a bug in (ice-9 binary-ports) or the documentation and easy to fix. Greetings, Maxime. signature.asc Description: This is a digitally signed message part

bug#49363: eof-object? is not exported from (ice-9 binary-ports)

Isn't eof-object? available in the default environment? -- Linus Björnstam On Sat, 3 Jul 2021, at 22:24, Maxime Devos wrote: > According to the manual: > > 6.12.2 Binary I/O > - > > [...] >To use these routines, first include the binary I/O module: > > (use-modules

bug#49363: eof-object? is not exported from (ice-9 binary-ports)

According to the manual: 6.12.2 Binary I/O - [...] To use these routines, first include the binary I/O module: (use-modules (ice-9 binary-ports)) [...] The end-of-file object is unlike any other kind of object: it’s not a pair, a symbol, or anything else. To check

bug#49311: (null?) cannot be compiled (error from (language typs types))

Dr. Arne Babenhauserheide schreef op do 01-07-2021 om 13:44 [+0200]: > Maxime Devos writes: > > scheme@(guile-user)> (null?) > > ;;; :1:0: warning: possibly wrong number of arguments to `null?' > > This is a correct warning: null? requires an argument (the list to check > for emptyness). The

bug#49311: (null?) cannot be compiled (error from (language typs types))

Hi Maxime, thank you for investigating! Maxime Devos writes: > scheme@(guile-user)> (null?) > ;;; :1:0: warning: possibly wrong number of arguments to `null?' This is a correct warning: null? requires an argument (the list to check for emptyness). The path forward from here is to find out why

bug#49311: (null?) cannot be compiled (error from (language typs types))

Hi, While hacking on Guix, I encountered the following backtace: In system/base/compile.scm: 265:44 19 (_ _ _) 261:33 18 (_ _ #) In language/cps/optimize.scm: 128:12 17 (_ _ _) 87:0 16 (optimize-higher-order-cps _ _) In language/cps/dce.scm: 430:33 15 (eliminate-dead-code _)

bug#49305: Regression regarding #nil in syntax expansions in 3.0.7

In 3.0.7, this: (define-syntax foo (syntax-rules () ((_ x) (eq? #nil x (foo #t) began crashing like this: ice-9/psyntax.scm:2795:12: In procedure syntax-violation: Syntax error: unknown location: unexpected syntax in form () git bisect suggested the source of the

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

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

bug#49085: Handle more unicode characters in uri-decode

Dear guilers, uri-decode should accept unicode characters. This is difficult to implement so that different encodings can be used, but here is my solution. Best regards, Vivien From 7adb0e333624c617f7c95796053df60d0a504ec9 Fri Jun 18 11:57:13 2021 From: Vivien Kraus Date: Fri, 18 Jun 2021

bug#49064: Libraries page displays "guile-email" wrongly as "guile-email.systemreboot"

Hi, The libraries page at https://www.gnu.org/software/guile/libraries/ displays "guile-email" wrongly as "guile-email.systemreboot.net". This is because lines 76-82 of https://git.savannah.gnu.org/cgit/guile/guile-web.git/tree/website/apps/base/libraries-page.scm#n76 make certain problematic

bug#47875: Elisp reader doesn't handle keywords

Leo Prikler writes: > You could define Elisp symbolp as > (lambda (thing) > (or (funcall (@ (guile) symbol?) thing) > (funcall (@ (guile) keyword?) thing))) You are right, I haven't thought about changing the implementaion of symbolp. > but perhaps there's an even faster way to check

bug#47875: Elisp reader doesn't handle keywords

Am Samstag, den 05.06.2021, 18:51 +0300 schrieb Ivan Sokolov: > In Scheme keywords and symbols are separate entities, but in Elisp > keywords are just self-quoted symbols. I think your solution will > cause problems with Elisp algorithms that expect keywords to be > symbolp. You could define Elisp

bug#48847: statprof does not print call counts

Guile version: 3.0.7.6-22120-dirty Statprof profiler does not print call counts even though you specify "#:count-calls? #t" in the argument list. Steps to reproduce: 1. Copy the following program to file test.scm: ---cut here--- (use-modules (statprof)) (statprof (lambda ()    

bug#47875: Elisp reader doesn't handle keywords

Leo Prikler writes: > Using Guile 3.0.5, the elisp reader does not seem to support keywords > written in Elisp's preferred prefix-style notation (:keyword). > > Meanwhile in Emacs M-: :keyword yields :keyword. Using Scheme-style > keywords also does not work: > > I think Guile should produce

bug#48816: guile: Add ARC support

Hi, I'm trying to bootstrap Debian on ARC and need to add arc support in guile 2.x and 3.x. Patch attached. Thx, -Vineet From d7229d384e503d7a3893e13e71fe0ad16c2e8003 Mon Sep 17 00:00:00 2001 From: Vineet Gupta Date: Tue, 6 Apr 2021 15:03:07 -0700 Subject: [PATCH] add support for arc

bug#16363: is this still current ?

Can this issue be closed ?

bug#15228: can this be closed ?

Is this bug still current ? Can this be closed ?

bug#41956: is this still current ?

I understand that a overhaul of the exceptions stack intervened while this bug was open Is this still current ?

bug#48765: `member` from (scheme base) returns empty list instead of #f when item is not found

NG: (guile-user): imported module (scheme base) overrides core binding > `member' > $1 = #f > scheme@(guile-user)> (member 'a '(b a)) > $2 = (a) > > > -Dale > > > - > > From: "Arvydas Silanskas" > To:

bug#48765: `member` from (scheme base) returns empty list instead of #f when item is not found

e-user)> (member 'a '(b a)) $2 = (a) -Dale -From: "Arvydas Silanskas" To: 48...@debbugs.gnu.org Cc: Sent: Monday May 31 2021 5:10:12PM Subject: bug#48765: `member` from (scheme base) returns empty list instead of #f when item is

bug#48765: `member` from (scheme base) returns empty list instead of #f when item is not found

Default `member` works fine: $ guile > (member 'a '(b)) $1 = #f However, using scheme base it returns empty list $ guile --r7rs > (import (scheme base)) > (member 'a '(b)) $1 = () Other functions (memq, memv) seem to work fine. I am using version 3.0.5 as distributed by debian bullseye

bug#48758: [PATCH] Elisp reader does not support non-decimal integers

This patch improves Elisp compatibility. I added support for binary, octal, hexadecimal and arbitrary radix integer literals as described in Elisp manual [1], except for the final period. It should not take long to add support for the final period, but in this patch I did not do this because

bug#48712: (is-a? #nil ) --> #f (oop goops)

I want to make sure some Scheme code using (oop goops) can be used from elisp. The method I'm defining is something like this (overly simplified): ;; TODO: Define a instead of working with raw integers? (define-method (send-message! (msg ) (data ) (remote )) [ write data to msg ] [ call

bug#48658: Elisp lexer misreads ESC in escape sequence form

Hello, I found that Elisp lexer interprets Elisp escape sequence for ESC as something different. The backtrace I got eralier (not present here) points to line 328 in language/elisp/lexer.scm, I think get-character is wrong.

bug#48368: thanks

Fixed in 17aab66e75136cf23c7f0d4942b61d6947f98f9b. Thanks for the report :)

bug#48368: reduced test case

Test case: (define (f a b) (let ((c (if (and (eq? a 'foo) (eq? b 'bar)) 'ERROR a))) (pk c))) If you run as (f 'not-foo 'bar), you get 'ERROR. Yeeps!

bug#42345: "Wrong number of arguments to 1"

Note: merged with https://bugs.gnu.org/42757 as it's the same bug. Andy is in CC since we almost certainly need his input. :-) I've been working on this since a few days (had to learn much about the VM) and here's an explanation of what's going on. Firstly here's a minimal procedure

bug#48368: bug#47172: Shepherd 0.8.1 tests fail on core-updates

'status >>action))) >> ;; Send the command. > > Cc'ing the relevant Guile bug: > > https://bugs.gnu.org/48368 Oh nice! (It would have saved me a bit of time to catch up on email beforehand. :-)) > See also commit 79be6a

bug#48368: bug#47172: Shepherd 0.8.1 tests fail on core-updates

Ludovic Courtès skriver: > Ludovic Courtès skribis: > >> This turns out to be due to a… miscompilation bug. >> >> In (shepherd scripts herd), ‘run-command’ has this code: >> >> (let ((sock(open-connection socket-file)) >> (act

bug#42574: Probable (system vm trace) bug

This has been fixed in f9f55b9ce74898d1b0a77dcc9b4aa260e5cd208d. Apologies for not noticing the earlier patch... there were a couple later duplicates. Thanks!

bug#44182: Bug in nftw function

Fixed in f499754bc8291a044c5034b634ac02a01bde9b49. Thanks!

bug#46273: bug #46273: Fix typo in lambda documentation

Patch applied in d1c6ae19f4e6ab8b3b607a5b14f65c437c06e065. Thanks!

bug#48566: call-with-blocked-asyncs does not like escape continuations

,bt 2 (call-with-blocked-asyncs #) 1 (call-with-unblocked-asyncs #) In ice-9/boot-9.scm: 1669:16 0 (raise-exception _ #:continuable? _) This bug was found while trying to test whether the definition of with-mutex is correct in the present of asynchronicities (system-async-m

bug#48565: Using move->fdes to move stdin to 9 + interrupt (C-c) exits guile

user@hostname ~$ guile GNU Guile 3.0.5 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter

bug#48563: move->fdes somewhat broken (EBADFD)

version: 3.0.5 Reproducer: a.scm: (define (test p) (let loop ((i 0)) (when (< (pk 'i i) 40) (move->fdes p i) (loop (+ 1 i) (test (car (pipe)) Run guile -l a.scm. The result is non-deterministic. Output (try #1--#2): ;;; (i 0) [...] ;;; (i 9) Backtrace: In

bug#45339: Readline filename completion

Applied in f3a23edf9ed111caab7bbad583874ad34ff8652d. Thanks! > On 19 May 2021, at 17:24, "" wrote: > > Since my patch didn't follow GNU C style here's an update. > Sorry guys! > From 0a62b75813cd8a94b87284395ee8d97e16069bb0 Mon Sep 17 00:00:00 2001 From: jakub-w Date: Wed, 19 May 2021

bug#48412: duplicate ?

It's in #43102 >> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43102 > > I applied this patch > > It does solve the issue, it seems > > Now I can tracepoint my procedure > > > >

bug#45339: Readline filename completion

Since my patch didn't follow GNU C style here's an update. Sorry guys! From 0a62b75813cd8a94b87284395ee8d97e16069bb0 Mon Sep 17 00:00:00 2001 From: jakub-w Date: Wed, 19 May 2021 17:14:35 +0200 Subject: [PATCH] Fixed style for 02439a124 * guile-readline/readline.c

bug#26221: (defun function nil ...) should work in 2.2

Closing as it works in 3.0. -- Taylan

bug#22901: drain-input doesn't decode

Closing this since it's 5 years old and fixed in Guile 2.1 and higher. -- Taylan

bug#26107: Inaccurate location info for unbound-variable errors

On 18.05.2021 22:11, Ludovic Courtès wrote: > Hi, > > Taylan Kammer skribis: > >> FWIW this seems fixed in 3.0, but I can reproduce with 2.2.7. >> >> Are we still supporting 2.2 for non-critical stuff? > > There’s no plan to do so. > > Ludo’. > Closing then. :-) -- Taylan

bug#26107: Inaccurate location info for unbound-variable errors

Hi, Taylan Kammer skribis: > FWIW this seems fixed in 3.0, but I can reproduce with 2.2.7. > > Are we still supporting 2.2 for non-critical stuff? There’s no plan to do so. Ludo’.

bug#26107: Inaccurate location info for unbound-variable errors

FWIW this seems fixed in 3.0, but I can reproduce with 2.2.7. Are we still supporting 2.2 for non-critical stuff? -- Taylan

bug#48503: [PATCH] Improve error reporting of getpw and getgr.

Tag: patch Severity: minor The attached patch fixes/improves the error-reporting of getpw and getgr. -- Taylan From 0b3faa5c01ed2d41fd7fc30e7bb4490d79ec2586 Mon Sep 17 00:00:00 2001 From: Taylan Kammer Date: Tue, 18 May 2021 19:32:10 +0200 Subject: [PATCH] Improve error reporting of getpw and

bug#32580: Setting variables %load-should-autocompile and GUILE_AUTO_COMPILE in ~/.guile doesn't prevent compiling

Closing as this was not a bug. Exporting GUILE_AUTO_COMPILE=0 works as intended; must be done before start. The variable %load-should-autocompile is for internal use by Guile only. -- Taylan

bug#30600: repl metacommands do not discard remaining input after syntax error in an expression

Attached is a small patch to fix this. -- Taylan From 0ba67891624647105e0dbdc33b0079cba655cec1 Mon Sep 17 00:00:00 2001 From: Taylan Kammer Date: Tue, 18 May 2021 18:15:08 +0200 Subject: [PATCH] Better REPL behavior on syntax errors in meta commands. * module/system/repl/command.scm

bug#30542: https://www.gnu.org/software/guile/docs/ needs an update

> Hi, > > https://www.gnu.org/software/guile/docs/ needs an update. > > Following the link "Reference Manual for Guile 2.0 (the current stable > release series)" results in "GNU Guile 2.2.3 Reference Manual" > > I did not compare text and content of the other links. > > Regard > Frank Seems

bug#16364: auto-compile noise can't be avoided by script

On 18.05.2021 00:31, Taylan Kammer wrote: > Attached is a patch ... Accidentally sent a broken version of the patch. Here's the right one. -- Taylan From 81b0ed712b435816175414313bfe11fedd5ce11a Mon Sep 17 00:00:00 2001 From: Taylan Kammer Date: Tue, 18 May 2021 00:21:54 +0200 Subject:

bug#16364: auto-compile noise can't be avoided by script

Attached is a patch that adds a command-line switch --silence-auto-compile which disables all diagnostics about auto-compilation except when the auto-compilation of a file fails. This can be used the following way in a script: #!/usr/bin/guile \ --silence-auto-compile --any --other --switches

bug#19236: load-compiled procedure leaks memory

I don't know if it still leaks but Guile's behavior on loading thousands of files seems to have regressed further. I get "Too many root sets" after only about 1900 iterations, after which it aborts. Primitive-load still works fine. -- Taylan

bug#18914: 2.0.11 REPL server listens on 127.0.0.1 but not "localhost"

uld it be that "nc" is trying to connect to an IPv6 address? Maybe that was the case on that system for some reason, despite the IPv4 address being on top in /etc/hosts and nslookup giving 127.0.0.1. Maybe it was even a bug with the ncat I had installed, who knows. -- Taylan

bug#18835: load-from-path is inconsistent when looking for a compiled version of the source file

In 2016, Andy wrote: > The logic in load.c is that we only add on .go if the file > doesn't already have an extension. If the file has an extension and > it's not .go, then we don't grovel in the path at all. I guess this is > the wrong thing? > > I am not sure if we can change this in 2.0 or

bug#15536: Problem with listing of online Guile manuals on gnu.org

In 2013, Mark wrote: > http://www.gnu.org/software/guile/manual/ includes the following: > > --8<---cut here---start->8--- > PostScript file > (%%PS_GZ_SIZE%%K bytes gzipped). > --8<---cut here---end--->8--- > > where

bug#48480: [a-Z] is not a valid regex range in 3.0.7

Taylan Kammer skriver: > On 17.05.2021 17:09, Marius Bakke wrote: >> Hello, >> >> (make-regexp "[a-Z]") fails in Guile 3.0.7 with "Invalid range end". >> >> This is a regression since 3.0.5. >> > > I think that's normal. > > $ grep -E '[a-Z]' > grep: Invalid range end > > You're supposed

bug#48480: [a-Z] is not a valid regex range in 3.0.7

This *is* the error returned by the underlying C library. For example: #include #include #include int main() { char buf[128] = {0}; regex_t rx = {0}; int status = regcomp(, "[a-Z]", REG_EXTENDED); size_t ret = regerror(status, , buf, sizeof buf); printf("status: %d, ret: %d, buf: [%s]n",

bug#48480: [a-Z] is not a valid regex range in 3.0.7

On 17.05.2021 17:09, Marius Bakke wrote: > Hello, > > (make-regexp "[a-Z]") fails in Guile 3.0.7 with "Invalid range end". > > This is a regression since 3.0.5. > I think that's normal. $ grep -E '[a-Z]' grep: Invalid range end You're supposed to use [a-zA-Z] or better yet, something

bug#48480: [a-Z] is not a valid regex range in 3.0.7

Hello, (make-regexp "[a-Z]") fails in Guile 3.0.7 with "Invalid range end". This is a regression since 3.0.5. signature.asc Description: PGP signature

bug#26955: macroexpand: documentation and actual behavior differ

Closing this report as it seems fixed. -- Taylan

bug#22901: drain-input doesn't decode

Are we still maintaining 2.0, or can this issue be closed? -- Taylan

bug#29531: [guile-2.2.3] ChangeLog has nothing

Guile generally doesn't offer change logs in the ChangeLog format anymore. You can see the detailed log of changes in the git commit history, and the release announcement for each version tends to contain a summary. I'm leaving this bug open though as I'm not sure why an empty ChangeLog file

bug#48412: duplicate ?

Il giorno ven, 14/05/2021 alle 11.13 +0200, Adriano Peluso ha scritto: > I just noticed someone sent a patch that seems relevant here > > It's in #43102 > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43102 I applied this patch It does solve the issue, it seems Now I ca

bug#43102: what is this about ?

Hi would you give a bit of context ? What error is this patch supposed to fix ? Has this anything to do with #48412 ? https://lists.gnu.org/archive/html/bug-guile/2021-05/msg00033.html Thanks

bug#43102: what is this about ?

Il giorno dom, 16/05/2021 alle 08.52 +0200, Adriano Peluso ha scritto: > Hi > > would you give a bit of context ? > > What error is this patch supposed to fix ? > > Has this anything to do with #48412 ? > > https://lists.gnu.org/archive/html/bug-guile/2021-05/msg00

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

On 16.05.2021 02:07, Taylan Kammer wrote: > > Will investigate more tomorrow. > It seems that commit 1c33be992e8120abd20add8021e4d91d226f5b6a removed much of the programs API at the C level but forgot to make the changes to the corresponding Scheme module. (It was a big commit, part of

<    3   4   5   6   7   8   9   10   11   12   >