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" > "slas") > > Please note that we already have

bug#38263: Bug in srfi-11

Hi Tim, > Mark H Weaver writes: >> I agree that this example indicates a bug in Guile's 'let-values' >> implementation (which was written by Andy Wingo in August 2009), but I >> disagree that it should evaluate to '(9 2 (3) (4)). I think that your >>

bug#38263: Bug in srfi-11

Hi Tim, Tim Gesthuizen wrote: > Hi, > I had a look today into the srfi-11 specificiation. It requires that the > variables are bound to fresh locations so let me rephrase the bug: > >> (let ((a 1) >> (b (let-values (((a . b) (values 2 3)) >> (c (begin (set! a 9) 4)))

bug#38236: R7RS reader does not support datum labels

Hi Andy, Andy Wingo writes: > R7RS defines a lexical feature called "datum labels"; see section 2.4 in > the report. An example would be: > >#0=(a b c . #0#) > > Guile's reader doesn't support this feature and it's not clear if we > should, in general. FYI, I already implemented R7RS datum

bug#37037: Guile 2.0.13+1-5.1 FTBFS on GNU/Hurd due to one failing test.

Svante Signell writes: > On Thu, 2019-08-22 at 17:01 -0400, Mark H Weaver wrote: >> It looks like this issue was already fixed in Guile 2.0.14, by commit >> f2764cb1031379c47a17c02fef3f8164a6ce9cda on the 'stable-2.0' branch: >> >> https://git.savannah.gn

bug#37037: Guile 2.0.13+1-5.1 FTBFS on GNU/Hurd due to one failing test.

Hi Svante, Svante Signell writes: > When building Debian version 2.0.13+1-5.1 one test fails making the > whole build to fail. The problem is in the file test- > suite/tests/statprof.test. According to that file it is known that > ITIMER_PROF is not implemented: > > ;; Throw `unresolved' upon EN

bug#37086: Guile Ice-9 Readline with-readline-completion-function

tags 37086 + notabug close 37086 thanks Hi Matthew, Matthew Henry writes: > Seen in: guile (GNU Guile) 2.2.4 > > When using the with-readline-completion-function, the passed readline > uses the default (apropos) completion function instead of the one > provided to with-readline-completion-funct

bug#36677: [PATCH] Don't truncate backtraces

Hi David, > I am very pleased to read that you think it is important to enable > truncated printing as a default for backtrace, I think so to. But > maybe Guile could provide an easy mechanism to overwrite these > defaults, using procedures, or parameters? (not depending on an > 'external' variabl

bug#36709: Likely bug in scm_port_poll

I sent the following message about a month ago, and now am forwarding to bug-guile so that we do not forget about it. Mark From: Mark H Weaver Subject: Likely bug in scm_port_poll Date: Tue, 18 Jun 2019 00:40:27 -0400 Message-ID: <87a7ef1p61@netris.org> Cc: guile-de...@gnu.

bug#36677: [PATCH] Don't truncate backtraces

Hi Robert, Robert Vollmert writes: > * module/system/repl/debug.scm (print-frame): Print full object if > width keyword is #f. > * libguile/backtrace.c (display_backtrace_body): Call print-frames > with #:width #f. > --- > > This change was prompted by recent discussion on the Guix lists: > ht

bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-8

Hi John, John Cowan writes: > That's a mug's game: I've been there and tried it (not in Scheme). I > recommend writing a strftime in Scheme from scratch. It's not that > hard; the most annoying thing is getting into the locale files to > handle the locale-sensitive directives (month name, weekd

bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-8

reopen 35920 thanks Hi Ludovic, > Mark H Weaver skribis: > >> Here's a patch that might fix the problem, but I don't have time to test >> it right now. > > It works! :-) I wrote tests and pushed it as > ab2fd70ef1e36c6532128b73082809ef3c056556. On my s

bug#36342: accept4 detection on illumos needs -lsocket -lnsl

Hi Michal, Michal Nowak writes: > GNU Guile 2.2.5 build fails because accept4 detection on OpenIndiana > 2019.04 (illumos distribution) [1] fails due to "-lsocket -lnsl" not > being part of the linking process and the build system then tries to > build it's vendored accept4: I believe this is a

bug#36338: guile-2.2.5 fails to build with -ffast-math

tags 36338 + notabug wontfix close 36338 thanks Hi Cyprien, Cyprien Nicolas writes: > I apologize if the issue was already reported, but I didn't find a > previous record. > > At Gentoo, users build packages themselves, and have the freedom to > choose the CFLAGS they want. > > We had several r

bug#36350: [2.2.5] ‘read-headers’ blocks, thereby breaking web servers

Ludovic Courtès writes: > Perhaps we should consider releasing 2.0.6 soon and use that in Guix > on ‘core-updates’. Sure, sounds like a good idea. Mark

bug#36350: [2.2.5] ‘read-headers’ blocks, thereby breaking web servers

Hi Ludovic, Ludovic Courtès writes: > ./meta/guile examples/web/hello.scm & > wget -O - http://localhost:8080 > > You’ll notice that ‘wget’ hangs (never receives a response) because the > server is actually stuck in a read(2) call that will never complete, in > ‘read-headers’. > > Reverting

bug#36314: missing scmconfig.h, guile 2.2.4 and 2.2.5, build error

Hi Carl, Carl Hansen writes: > make[1]: Entering directory > '/td2/carlstuff/build/gsrc/pkg/gnu/guile/work/guile-2.2.5' > make -C libguile scmconfig.h > make[2]: Entering directory > '/td2/carlstuff/build/gsrc/pkg/gnu/guile/work/guile-2.2.5/libguile' > \ > if [ "no" = "yes" ]; then \ >

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

Hi, Abdulrahman Semrie writes: > I am using the pattern [\\[\\]a-zA-Z]+ to match a string with left or > right bracket in it. However, the string-match function doesn’t match > the ‘]’ character. To demonstrate with an example, try the following > funciton: > > (string-match "[\\[\\]a-zA-Z]+" "T

bug#36170: configure fails on FreeBSD

Roger Mason writes: > I cloned the git repo yesterday (2019-06-10, most recent commit > 8d469660525d74734f3184cb9ed01b6f2dcd0445). I ran autogen.sh in the > source directory. I had to comment out the call to m4 --version, which > failed (I have m4-1.4.18). That's the latest stable m4 release,

bug#36170: configure fails on FreeBSD

Hi Roger, Roger Mason writes: > I cloned the git repo yesterday (2019-06-10, most recent commit > 8d469660525d74734f3184cb9ed01b6f2dcd0445). I ran autogen.sh in the > source directory. I had to comment out the call to m4 --version, which > failed (I have m4-1.4.18). I created a build director

bug#36079: unhelpful error message

Hi Ricardo and Robert, Ricardo Wurmus writes: >> Working on Guix, I encountered the following: >> >> Within a guix checkout, I edited gnu/packages/haskell.scm, accidentally >> making a Haskell comment: >> >> (arguments >> `(#:tests? #f)) -- sporadic failure: >> https://github.com/fpco/

bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-8

Here's a patch that might fix the problem, but I don't have time to test it right now. Mark --8<---cut here---start->8--- diff --git a/libguile/stime.c b/libguile/stime.c index b681d7ee3..9a21b61fe 100644 --- a/libguile/stime.c +++ b/libguile/stime.c @@

bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-8

There might also be related problems with 'strptime'. These problems date back to when Guile was first extended to support non-ASCII strings. Here's the relevant commit in 2009 that added non-ASCII support to 'strftime' and 'strptime', but did so imperfectly: 587a33556fdef90025c1b7d4d172af649c8ebb

bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-8

Hi Christopher, Christopher Lam writes: > Addendum - wish to confirm if guile bug (guile-2.2 on Windows): > - set locale to non-Anglo so that (setlocale LC_ALL) returns > "French_France.1252" > - call (strftime "%B" 400) - that's 4x10^6 -- this should return > "février 1970" > > but the foll

bug#31776: [PATCH] Fix gc.test "after-gc-hook gets called" failures

Hi Andrea, Andrea Azzarone writes: > "after-gc-hook gets called" test randomly fails as reported > downstream, for example: > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31776 > - https://bugs.launchpad.net/ubuntu/+source/guile-2.2/+bug/1823459 > > I'm attaching a patch that seems to fix the

bug#34860: Probing broken symlinks always involves errors

Hi Tim, Tim Gesthuizen writes: > I wrote a little application that tries to probe whether a symlink > exists. The `stat` function has an undocumented optional parameter that > lets stat return #f when the file does not exist. With this argument one > can probe for any files excluding broken syml

bug#32367: sigaction hangs

Hi Matt, Matt Wette writes: > On 12/15/18 8:46 AM, Matt Wette wrote: >> -s seems to end up using load-in-vicinity: I can re-create this way: >> >> mwette$ guile -L `pwd` -c '(load-in-vicinity (getcwd) "foo.scm")' >> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 >> ;;;   or

bug#33403: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation

A few more notes: I wrote earlier: > However, before doing this, some warnings are in order: > > When in noncanonical mode, the normal processing of ERASE (usually DEL > or Ctrl-H) and KILL (usually Ctrl-U) characters are disabled, Also the handling of Ctrl-D appears to be disabled in noncanonica

bug#33403: [Geiser-users] bug#33403: Data length limit in Guile/Geiser/Scheme evaluation

Hello all, "Jose A. Ortega Ruiz" writes: > On Fri, Nov 16 2018, Neil Jerram wrote: > >> Neil Jerram writes: >> >>> Mark H Weaver writes: >>> >>>> This is a documented limitation in Linux's terminal handling when in >>>

bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation

Mark H Weaver writes: > If, after pasting this, you type another close quote, 5 close parens, > and then repaste the last two lines, it will print the garbled input and > return to a prompt. Actually, instead of pasting the last two lines as-is, I replaced "(length classif

bug#33403: [Geiser-users] Data length limit in Guile/Geiser/Scheme evaluation

Hi Neil, Neil Jerram writes: > Hi, this is a report for Guile 2.2: > > neil@henry:~$ guile --version > guile (GNU Guile) 2.2.3 > Packaged by Debian (2.2.3-deb+1-3ubuntu0.1) > > I'm seeing something that looks like a line or sexp length limit when > reading from a terminal. Sample in

bug#22925: ice-9/match named match-let is not working

Stefan Israelsson Tampe writes: > This is fixed in the latest upstream match.scm released in the chibi > repo. Thanks, and sorry for the long delay. This is now fixed in commit 8e86dd93a0640161fe0098a80ccc9b814280 on the stable-2.2 branch. That commit also includes several other fixes from

bug#33340: named match-let doesn't work

Alex Kost writes: > Ernesto Gabriel (2018-11-11 00:44 -0300) wrote: > >> match-let works as advertised, but a named match-let gives errors > > I think this is the same as: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22925 Indeed, thanks for pointing that out. The bug is now fixed by commit

bug#26164: time-difference mishandles leap seconds

Zefram writes: > Mark H Weaver wrote: >> every UTC day has >>exactly 86400 UTC seconds, > > No, that's not how UTC works. There are some time scales derived from UTC > that have exactly 86400 seconds for each U

bug#26164: time-difference mishandles leap seconds

Zefram writes: > Mark H Weaver wrote: >>Having said all of this, I should admit that I'm not an expert on time >>standards, > > I am. Okay, you claim to be one, and maybe you're right, but I've also done a great deal of research on this recently and in the

bug#22034: time-utc->date shows bogus zone-dependent leap second

Hi John, John Cowan writes: > On Mon, Oct 29, 2018 at 3:17 AM Mark H Weaver wrote: > > Can you please be more concrete and tell me what numbers you think > should be in the second column, to properly reflect the column heading? > I'm not asking for a prose description

bug#22034: time-utc->date shows bogus zone-dependent leap second

Mark H Weaver writes: > John Cowan writes: > >> On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver wrote: >> >> The difference between the two measuring tapes is that they assign >> different numbers to the markings, and moreover that the UTC analogue >> has

bug#22034: time-utc->date shows bogus zone-dependent leap second

Hi John, John Cowan writes: > On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver wrote: > > The difference between the two measuring tapes is that they assign > different numbers to the markings, and moreover that the UTC analogue > has a small handful of places where two adjacen

bug#22034: time-utc->date shows bogus zone-dependent leap second

Hi John, John Cowan writes: > On Mon, Oct 22, 2018 at 2:12 AM Mark H Weaver wrote: > > Universal Time (UT) is not a measure of physical time, but rather is a > measure of the rotation angle of the Earth with respect to distant > quasars. A UT second is identified with a

bug#26632: TAI<->UTC conversion botches 1961 to 1971

should add it to Guile. I'm vaguely concerned about violating widely-held assumptions, e.g. that UTC runs at the same rate as TAI (except when leap seconds are introduced), which might cause some code on top of Guile to misbehave if the system clock is set pre-1972, although admittedly such a s

bug#22034: time-utc->date shows bogus zone-dependent leap second

John Cowan writes: > On Sat, Oct 20, 2018 at 5:43 PM Mark H Weaver wrote: > > If I understand correctly, 'time-utc->date' should never return a date > object with 60 in the seconds field, because those extra seconds have no > representation in time-utc. They

bug#21912: TAI<->UTC conversion botches the unknown

Hi John, John Cowan writes: > What is more, there are no TAI<->UTC conversion tables from before > 1961 (when UTC began) and probably never will be. There was heated > debate in the R7RS-small working group, and we finally settled on a > compromise: > > (current-second) [r]eturns an inexact num

bug#26163: time-difference doesn't detect error of differing time types

Zefram writes: > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (time-difference (make-time time-tai 0 1) (make-time > time-utc 0 1)) > $1 = # > > SRFI-19 is explicit that it "is an error" if the arguments to > time-difference are of different time types, and correspond

bug#26162: time-duration screws up negative durations

Zefram writes: > Computing a difference between two SRFI-19 times, using time-difference, > produces sensible results if the result is positive, but often nonsense > if it's negative: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (time-difference (make-time time-tai

bug#26164: time-difference mishandles leap seconds

Zefram writes: > Computing the duration of the period between two UTC times, using > SRFI-19 mechanisms: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 > 2012 0))) > scheme@(guile-user)> (define t1 (date->time-u

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

This is fixed by commit a58c7abd72648f77e4ede5f62a2c4e7969bb7f95 on the stable-2.2 branch. I'm closing this bug now, but please reopen if appropriate. Thanks! Mark

bug#26165: date-week-day screws up prior to AD 1

Zefram writes: > Looking at day of the week, via SRFI-19's date-week-day: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (julian-day->date 1721426 0) > $1 = # 1 zone-offset: 0> > scheme@(guile-user)> (date-week-day (julian-day->date 1721426 0)) > $2 = 1 > scheme@(gu

bug#32367: 2.2.4 hangs when a script uses a module that calls sigaction

I've attached a preliminary patch to fix this bug. Mark >From 897a6f76280612e83f48d63430bf962520c0e7b3 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 21 Oct 2018 09:56:16 -0400 Subject: [PATCH] DRAFT: Fix thread-safe module loading. * module/ice-9/boot-9.scm (%modul

bug#31878: Module autoloading is not thread safe

I've written a preliminary patch to implement the improved thread-safe module autoloading that I outlined in earlier messages in this bug report. Comments, suggestions, and testing welcome. Mark >From 897a6f76280612e83f48d63430bf962520c0e7b3 Mon Sep 17 00:00:00 2001 From: Mark

bug#21903: date->string duff ISO 8601 negative years

Mark H Weaver writes: > Mark H Weaver writes: > >> Zefram writes: >> >>> The date->string function from (srfi srfi-19), used on ISO 8601 formats >>> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error:

bug#21904: date->string duff ISO 8601 format for non-4-digit years

Mark H Weaver writes: > Another question is whether or not we should raise an exception when > attempting to print a year that cannot be represented in the requested > year format. I thought about it some more, and I'm now inclined to think that the approach in your patches is rea

bug#21906: julian-day->date negative input breakage

Zefram writes: > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (julian-day->date 0 0) > $1 = # year: -4714 zone-offset: 0> > scheme@(guile-user)> (julian-day->date -1 0) > $2 = # year: -4714 zone-offset: 0> > scheme@(guile-user)> (julian-day->date -10 0) > $3 = # ye

bug#21903: date->string duff ISO 8601 negative years

Mark H Weaver writes: > Zefram writes: > >> The date->string function from (srfi srfi-19), used on ISO 8601 formats >> "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error: >> >> scheme@(guile-user)> (use-mod

bug#21904: date->string duff ISO 8601 format for non-4-digit years

Zefram writes: > For year numbers 1 and above, it is necessary to use more than four > digits for the year, and that's permitted, but ISO 8601 requires that > more than four digits are preceded by a sign. For positive year numbers > the sign must be "+". So one should write "+22666" rather

bug#21904: date->string duff ISO 8601 format for non-4-digit years

Zefram writes: > scheme@(guile-user)> (date->string (julian-day->date 1722000 0) "~1") > $4 = "2-07-29" > scheme@(guile-user)> (date->string (julian-day->date 173 0) "~1") > $5 = "24-06-23" > scheme@(guile-user)> (date->string (julian-day->date 200 0) "~1") > $6 = "763-09-18" This partic

bug#21903: date->string duff ISO 8601 negative years

Zefram writes: > The date->string function from (srfi srfi-19), used on ISO 8601 formats > "~1", "~4" and "~5", for years preceding AD 1, has an off-by-one error: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (date->string (julian-day->date 0 0) "~4") > $1 = "-4714-

bug#21901: bit shift wrong on maximal right shift

Zefram writes: > With Guile 2.0.11: > > scheme@(guile-user)> (ash 123 (ash -1 63)) > $1 = 123 Fixed in commit 1990aa916382d0afcebd5315a6d6f555949ff654 on the stable-2.2 branch. Closing this bug now. Thanks very much for finding this subtle bug. Mark

bug#21912: TAI<->UTC conversion botches the unknown

Zefram writes: > Guile ought to be aware of how far its leap table extends, and signal > an error when asked to perform a TAI<->UTC conversion that falls outside > its scope. I sympathize with your preference to raise an error rather than return invalid results, but unfortunately I don't think t

bug#22033: time-utc format is lossy

tags 22033 + notabug close 22033 thanks Hi Zefram, Zefram writes: > I wrote: >> These two seconds are perfectly >>distinct parts of the UTC time scale, and the time-utc format ought to >>preserve their distinction. > > This is a problematic goal. At the time I

bug#21902: doc incorrectly describes Julian Date

Zefram writes: > The manual says, in the section "SRFI-19 Introduction", > > #Also, for those not familiar with the terminology, a "Julian Day" is > # a real number which is a count of days and fraction of a day, in UTC, > # starting from -4713-01-01T12:00:00Z, ie. midday Monday 1 Jan 4713 B.

bug#22034: time-utc->date shows bogus zone-dependent leap second

Zefram writes: > time-utc->date seems to think that a leap second occurs at a different > time in each time zone: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (define (tdate d) (write (list (date->string d "~4") > (date->string (time-utc->date (date->time-utc d) 3

bug#21911: TAI-to-UTC conversion leaps at wrong time

Zefram writes: > Probing the TAI-to-UTC conversion offered by srfi-19's time-tai->date, > in the minutes around the leap second in 2012: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (for-each (lambda (d) (write (list d > (date->string (time-tai->date (add-duration

bug#33044: Guile misbehaves in the "ja_JP.sjis" locale

Mark H Weaver writes: > I'll leave this bug open at least until 'seed->random-state your-seed' > is fixed to support wide strings. This part is now fixed in commit fbdcf6358519c415bd2041ca09bee9b16e9d528a on the stable-2.2 branch. Mark

bug#33053: scm_i_mirror_backslashes assumes ASCII-compatible locale encoding

tags 33053 + notabug close 33053 thanks Mark H Weaver writes: > Mark H Weaver writes: > >> The 'scm_i_mirror_backslashes' in load.c operates on C strings in the >> locale encoding, and assumes that the locale encoding is ASCII >> compatible. In the Shift_JIS

bug#33036: Bug with the procedure nil? inside a specific code

Hi Andy, Andy Wingo writes: > Thank you, Mark! That looks great. Great, thanks for looking it over. I pushed it to the stable-2.2 branch as commit c3e14b74e81d0fd3266b97e6bd629cd4e2f98803. I'm closing this bug now, but feel free to reopen if appropriate. Thanks! Mark

bug#33044: Guile misbehaves in the "ja_JP.sjis" locale

Hi Tom, Tom de Vries writes: > On 10/16/18 3:57 AM, Mark H Weaver wrote: >> Thanks for the report, analysis and patch. I agree with your analysis, >> and the patch looks good. >> > > If so, can the patch be committed? I just pushed commit c2a654b7d29f5e2f32fd

bug#33044: Guile misbehaves in the "ja_JP.sjis" locale

Mark H Weaver writes: > Shift_JIS is _mostly_ ASCII-compatible, except that code points 0x5C and > 0x7E, which represent backslash (\) and tilde (~) in ASCII, are mapped > to the Yen sign (¥) and overline (‾) in Shift_JIS. Backslash (\) and > tilde (~) are multibyte characters

bug#33044: Guile misbehaves in the "ja_JP.sjis" locale

retitle 33044 Guile misbehaves in the "ja_JP.sjis" locale thanks Hi Tom, Thanks for the report, analysis and patch. I agree with your analysis, and the patch looks good. However, there's also a much deeper problem here. You found and fixed one occurrence of Guile assuming that the locale encod

bug#33057: Guile's reader assumes the port encoding is ASCII-compatible

In several places, Guile's reader assumes that the port encoding is ASCII-compatible. For example: * 'scm_token' reads raw bytes and passes them to the CHAR_IS_DELIMITER macro to check for delimiters. * 'scm_read_mixed_case_symbol' checks for the (optional) postfix keyword syntax by comparin

bug#33053: scm_i_mirror_backslashes assumes ASCII-compatible locale encoding

Mark H Weaver writes: > The 'scm_i_mirror_backslashes' in load.c operates on C strings in the > locale encoding, and assumes that the locale encoding is ASCII > compatible. In the Shift_JIS encoding, used in the "JP_jp.sjis" locale, > backslash '\' i

bug#33053: scm_i_mirror_backslashes assumes ASCII-compatible locale encoding

The 'scm_i_mirror_backslashes' in load.c operates on C strings in the locale encoding, and assumes that the locale encoding is ASCII compatible. In the Shift_JIS encoding, used in the "JP_jp.sjis" locale, backslash '\' is mapped to a multibyte character, and the Yen sign '¥' is represented using c

bug#26058: utf16->string and utf32->string don't conform to R6RS

Hi Taylan, taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > Andy Wingo writes: > >> Adopting the behavior is more or less fine. If it can be done while >> relying on the existing behavior, that is better than something ad-hoc >> in a module. In general, I agree with Andy's se

bug#21883: unnecessary bit shifting range limits

Stefan Israelsson Tampe writes: > how would this slow down the code. just add the correction where you > throw the exception which should be in a branch outside the hot path. If you have a suggestion that's simpler than what I did in commits 011aec7e, 9448a078, and 1990aa91, and just as fast in t

bug#21901: bit shift wrong on maximal right shift

Zefram writes: > With Guile 2.0.11: > > scheme@(guile-user)> (ash 123 (ash -1 63)) > $1 = 123 > > Correct result would of course be zero. Problem only occurs for > exactly this shift distance: one bit less produces the right answer. Nice catch! It's finally fixed in commit 1990aa916382d0afcebd

bug#21883: unnecessary bit shifting range limits

Zefram writes: > Not really outright bugs, but these responses are less than awesome: > > $ guile -c '(write (logbit? (ash 1 100) 123))' > ERROR: Value out of range 0 to 18446744073709551615: > 1267650600228229401496703205376 > $ guile -c '(write (ash 0 (ash 1 100)))' > ERROR: Value out of range

bug#32644: bytevector bug

Stefan Israelsson Tampe writes: > The code velow does not compile when the define-inlinable of id is active. If > in stead > id defined by define is used it all compiles just fine. The problem was that, in some cases, the type inferrer would call 'ash' with (- 1 (expt 2 64)) as the second argume

bug#32938: guile 2.2.4 crashes (u8-list->bytevector (make-bytevector 32 0))

Josh Datko writes: > If you try to convert a bytevector, to a bytevector, using > u8-list->bytevector, guile crashes. Fixed in commit fe73fedab40cf716cc39139a61c078e2c9a2f37f on the stable-2.2 branch. Thanks for the report! Mark

bug#33036: Bug with the procedure nil? inside a specific code

Mark H Weaver writes: > calcium writes: >> There is a page that speak about nil : >> https://www.gnu.org/software/guile/manual/html_node/Nil.html >> However it doesn’t mention the nil? Procedure >> >> The only documentation that I found about nil? is this one

bug#33036: Bug with the procedure nil? inside a specific code

Mark H Weaver writes: > calcium writes: >> Here is the bug that I found : >> >> ;;; -START- code with the bug -START- ;;; >> >> (define (strange lst) >> (let loop ((lst lst) >> (is-empty '())) >> (cond ((nil? lst) >&g

bug#33036: Bug with the procedure nil? inside a specific code

Hi, calcium writes: > The procedure nil? is not listed in the procedure index : > https://www.gnu.org/software/guile/docs/docs-2.0/guile-ref/Procedure-Index.html The link above is the manual for Guile 2.0, which didn't have 'nil?'. It was added in Guile 2.2. > There is a page that speak about n

bug#32786: (system* ...) call somehow interferes with atomic-box on armv7l

it. > > - MB. Respectfully > > On Thu, Sep 27, 2018 at 01:49:23AM -0400, Mark H Weaver wrote: >> Hi, >> >> Thanks for the additional details. I was able to reproduce the bug, and >> I believe I now see the problem. >> >> 'atomic-box-comp

bug#32938: guile 2.2.4 crashes (u8-list->bytevector (make-bytevector 32 0))

Josh Datko writes: > If you try to convert a bytevector, to a bytevector, using > u8-list->bytevector, guile crashes. > > $ guile -q > GNU Guile 2.2.4 > Copyright (C) 1995-2017 Free Software Foundation, Inc. > > Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. > This program i

bug#32786: (system* ...) call somehow interferes with atomic-box on armv7l

so. My access to armv7l boxes is somewhat limited. Thanks for this report. Mark >From 958d37686a9ac65f48cb2ca32a341cf182c24b5a Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Thu, 27 Sep 2018 01:00:11 -0400 Subject: [PATCH] UNTESTED: Fix 'atomic-box-compare-and-s

bug#32841: assoc-set fails with dot notation association list

Hi Christopher, "Hood, Christopher L." writes: > This fails with code pulled straight out of the Guile manual example > (section 6.6.20.6). Indeed, the example code in the manual is bad. Thanks for bringing this to our attention. > (define capitals '(("New York" . "Albany") >

bug#32847: Wrong macro expansion in eval

Hi Stefan, Stefan Israelsson Tampe writes: > This for guile 2.4 and master, > >> (eval `(let-syntax ((f (lambda (x) ,#'(+ (pk 'a 1) 2 f) >> (current-module)) > > ;;; (# 1) > > But without eval: >> (let-syntax ((f (lambda (x) #'(+ (pk 'a 1) 2 f) > > ;;; (a 1) I think the mistake is i

bug#32786: (system* ...) call somehow interferes with atomic-box on armv7l

Hi, Михаил Бахтерев writes: > I attach the code sample, which expected behaviour is: > > 1. to periodically restart thread, which executes «sleep 1s» with > system* call; > > 2. and then to check if it should repeat the execution. > > The flag, which controls that re-execution is manage

bug#15221: reiterating the request

Hi Tom, Tom Tromey writes: > Hi. I tried guile today and was surprised to find that it doesn't use > readline by default. I think this would be a big improvement to the > REPL. > > Second best would be a command line option, or editing some config file. You can enable it by adding the followin

bug#32644: bytevector bug

Stefan Israelsson Tampe writes: > The code velow does not compile when the define-inlinable of id is active. If > in stead > id defined by define is used it all compiles just fine. > > Tested on latest tar ball for guile 2.4 Did you mean to write guile 2.2.4? Mark > ---

bug#32528: http-post breaks with XML response payload containing boundary

Mark H Weaver writes: > Ricardo Wurmus writes: > >> I’m having a problem with http-post and I think it might be a bug. I’m >> talking to a Debbugs SOAP service over HTTP by sending (via POST) an XML >> request. The Debbugs SOAP service responds with a string of XML

bug#32528: http-post breaks with XML response payload containing boundary

Ricardo Wurmus writes: > I’m having a problem with http-post and I think it might be a bug. I’m > talking to a Debbugs SOAP service over HTTP by sending (via POST) an XML > request. The Debbugs SOAP service responds with a string of XML. > > Here’s a simplified version of what I do: > > (use-

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

Hi Daniel, Daniel Tam writes: > I'm excited to have a look but I have 0 knowledge of the code base (and > am just learning Scheme although that's probably not an issue in this > case whatsoever). It's okay, please don't feel any obligation to work on this. Sometimes people are impatient to fix

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

I wrote: >> The right fix might be to simply remove the 'if' check above. > > Actually, it probably won't be that simple. Whereas in emacs mode, we > can probably rely on these bindings being added to the correct keymap, > namely 'emacs_standard_keymap', when in vi mode it's likely that these > b

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

Hello again, I wrote: > The relevant function is 'init_bouncing_parens' in > guile-readline/readline.c: > > static void > init_bouncing_parens () > { > if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2)) > { > rl_bind_key (')', match_paren); > rl_bind_key

bug#31878: Module autoloading is not thread safe

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Since Guile (unfortunately) allows cyclic module dependencies, we would >> need a mechanism to avoid deadlocks in case modules A and B both import >> each other, and two threads concurrent

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

Hi again, > Daniel Tam writes: > >> I've activated readline support for the Guile repl, but I've found that >> if my inputrc enables vi-mode, then the bouncing parentheses feature >> doesn't work. Disabling vi-mode does the trick. > > Indeed. For some reason that I cannot determine, the bouncing

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

Hi Daniel, Daniel Tam writes: > I've activated readline support for the Guile repl, but I've found that > if my inputrc enables vi-mode, then the bouncing parentheses feature > doesn't work. Disabling vi-mode does the trick. Indeed. For some reason that I cannot determine, the bouncing parenth

bug#31878: Module autoloading is not thread safe

I wrote: > I thought about how to fix this thread-safety problem a long time ago, > and came up with a rough outline of a solution. The idea is that the > module should not be added to the global module table until the module > has finished loading. While the module is being loaded, it would be

bug#32367: 2.2.4 hangs when a script uses a module that calls sigaction

Hi Derek, Derek Upham writes: > Thanks. I built from 4c91de3e4 and was able to reproduce the problem. > Then I reverted 761cf0fb8c364e885e4c6fced34563f8157c3b84 and I was not > able to reproduce it. Thanks for checking. I've reopened which led to the faulty commit

bug#31878: Module autoloading is not thread safe

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> l...@gnu.org (Ludovic Courtès) skribis: >> >>> I believe this comes from the fact that ‘autoloads-done’ and related >>> alists in (ice-9 boot-9) are manipulated in a non-thread-safe fashion. >> >> He

bug#32367: 2.2.4 hangs when a script uses a module that calls sigaction

I don't have time now for a proper investigation, but this might be related to commit 761cf0fb8c364e885e4c6fced34563f8157c3b84 (Make module autoloading thread-safe). Mark

  1   2   3   4   5   6   >