bug#71303: [PATCH] doc: Fix typo in PEG example.

[lloda]

Patch applied in 4fe6d19a5baa43910f346656539c6942d436572b.

Thank you!

bug#69725: Incorrect comapration between exact and inexact numbers

[lloda]

Patch committed to 54c4753dd3f7506bee2778b36d7263b613ffd579, with a couple 
extra tests.

Thanks

Daniel

bug#69725: Incorrect comapration between exact and inexact numbers

[lloda]

Thanks for the report! Patch attached.

regards

  Daniel




0001-Add-missing-branch-in-scm_is_less_than.patch
Description: Binary data

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

[lloda]

> On 11 Jan 2024, at 18:57, Tomas Nordin  wrote:
> 
> lloda  writes:
> 
>> I think this is another dupe of https://debbugs.gnu.org/58154.
> 
> Highly possible. Like Ricardo I cannot reproduce this with a local build
> I made from the tip of the repo. (I saw the same segfault using list-ref
> with the debian 3.0.8 version FWIW.)

I looked it up and it is indeed the same bug. It's fixed in 3.0.9.

Thanks for the report!

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

[lloda]

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

bug#65132: ...

[lloda]

Patch applied in 1e3b5390e3c24e66013118e9751db4de5025a4a2.

Thanks,

  Daniel

bug#40584: ...

[lloda]

Patch applied in 3243d96bb5b9658f08847a7073fe6c0b2ccab6be.

Thanks,

  Daniel

bug#61660: [feature request] optimization of case-lambda

[lloda]

> On 27 Feb 2023, at 11:11, Ludovic Courtès  wrote:
> 
> Hi Daniel,
> 
> lloda  skribis:
> 
>> From 61ed612fb36108e395bdee4b1bbb46b49ef017b3 Mon Sep 17 00:00:00 2001
>> From: Daniel Llorens 
>> Date: Thu, 23 Feb 2023 17:38:10 +0100
>> Subject: [PATCH] peval reduces some inlined case-lambda calls
>> 
>> * module/language/tree-il/peval.scm (peval): Reduce multiple case lambda
>>  in  trees according to the number of arguments. Do not try to
>>  reduce case-lambda using keyword arguments.
>> * test-suite/tests/peval.test: Tests.
> 
> [...]
> 
>> +++ b/module/language/tree-il/peval.scm
>> @@ -1668,6 +1668,29 @@ top-level bindings from ENV and return the resulting 
>> expression."
>> 
>>   (log 'inline-end result exp)
>>   result)
>> +   (($  src-proc meta orig-body)
>> +;; If there are multiple cases and one matches nargs, omit all 
>> the others.
>> +(or (and
>> + (lambda-case-alternate orig-body)
>> + (let ((nargs (length orig-args)))
>> +   (let loop ((body orig-body))
>> + (match body
>> +   (#f #f) ;; No matching case; an error.
>> +   (($  src-case req opt rest kw inits 
>> gensyms case-body alt)
>> +(cond (kw
>> +   ;; FIXME: Not handling keyword cases.
>> +   #f)
> 
> Maybe s/FIXME/XXX/ since it’s at most a limitation, certainly not a bug.
> 
> It LGTM and Andy already approved it on IRC, so go ahead!
> 
> Ludo’.

Apologies for not seeing this earlier. Pushed to 
3b47f87618047ebb8812788c64a44877a4f2e0dd. Thanks!

  - Daniel

bug#61766: Typo in docs

[lloda]

> On 24 Feb 2023, at 15:54, Giorgos Tzampanakis  
> wrote:
> 
> Hi,
> 
> In the signature of raise-exception in [1] it should say "continuable?" 
> instead of just "continuable".
> 
> [1] 
> https://www.gnu.org/software/guile/manual/html_node/Raising-and-Handling-Exceptions.html


Fixed in 52465f0ce7eb0c2e001f6c7439ecd867ea0f18f4. Thank you!

bug#61660: [feature request] optimization of case-lambda

[lloda]

Fixed patch handling rest & #:optional, with test cases.



0001-peval-reduces-some-inlined-case-lambda-calls.patch
Description: Binary data

bug#61660: [feature request] optimization of case-lambda

[lloda]

Patch attached, tests tbd. Thoughts?



0001-peval-reduces-some-inlined-case-lambda-calls.patch
Description: Binary data

bug#61660: [feature request] optimization of case-lambda

[lloda]

On 3.0.9


> ,optimize ((case-lambda (() 0)))
= 0

but 

> ,optimize ((case-lambda (() 0) ((a) 1)))
= ((case-lambda (() 0) ((a) 1)))


The problem with this is that when the output of a macro contains case-lambda, 
recursive application results in geometrical increase of code size. It seems 
that it should be possible to resolve the application on the spot; at last to 
reduce the case-lambda to a simple lambda when the arity is available (which 
now only happens when the case-lambda contains a single clause).

Thanks

  Daniel

bug#60971: GNU Guile 3.0.9rc1 available for testing!

[lloda]

lgtm, no other issues on mac os.

thanks

  Daniel

bug#60971: build failure of v3.0.9rc1 on mac os 12.6

[lloda]

Hello,

v3.0.9rc1 fails on mac os 12.6.2 & gcc 12.2 or clang 14, same error in either 
case. gcc's error is:


CC   libguile_3.0_la-posix.lo
In file included from ../../../src/guile4/libguile/posix.c:82:
../../../src/guile4/libguile/posix.c:109:9: error: lvalue required as unary '&' 
operand
  109 | verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
  | ^~~
../../../src/guile4/lib/verify.h:213:57: note: in definition of macro 
'_GL_VERIFY'
  213 | # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
  | ^
../../../src/guile4/libguile/posix.c:109:1: note: in expansion of macro 'verify'
  109 | verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
  | ^~
../../../src/guile4/libguile/posix.c:109:9: error: expression in static 
assertion is not an integer
  109 | verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
  | ^~~
../../../src/guile4/lib/verify.h:213:57: note: in definition of macro 
'_GL_VERIFY'
  213 | # define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
  | ^
../../../src/guile4/libguile/posix.c:109:1: note: in expansion of macro 'verify'
  109 | verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
  | ^~


The problematic section in libguile/posix.c

...

#if HAVE_SYS_WAIT_H
# include 
#endif
#ifndef WEXITSTATUS
# define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
#endif
#ifndef WIFEXITED
# define WIFEXITED(stat_val) (((stat_val) & 255) == 0)
#endif

#ifndef W_EXITCODE
/* Macro for constructing a status value.  Found in glibc.  */
# ifdef _WIN32/* see Gnulib's posix-w32.h */
#  define W_EXITCODE(ret, sig)   (ret)
# else
#  define W_EXITCODE(ret, sig)   ((ret) << 8 | (sig))
# endif
#endif
verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
...

adding -o .libs/libguile_3.0_la-posix.i -E to the build line shows line 109 as

_Static_assert ( (((*(int *)&((( 127 ) << 8 | ( 0  >> 8) & 0x00ff) == 
127, "verify (" "WEXITSTATUS (W_EXITCODE (127, 0)) == 127" ")");
^

forcing redefinition of WEXITSTATUS shows the previous definition at 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h

...

#if defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE)
#define _W_INT(i)   (i)
#else
#define _W_INT(w)   (*(int *)&(w))  /* convert union wait to int */   
<- problem
#define WCOREFLAG   0200
#endif /* (_POSIX_C_SOURCE && !_DARWIN_C_SOURCE) */

/* These macros are permited, as they are in the implementation namespace */
#define _WSTATUS(x) (_W_INT(x) & 0177)
#define _WSTOPPED   0177/* _WSTATUS if process is stopped */

/*
 * [XSI] The  header shall define the following macros for
 * analysis of process status values
 */
#if __DARWIN_UNIX03
#define WEXITSTATUS(x)  ((_W_INT(x) >> 8) & 0x00ff)
#else /* !__DARWIN_UNIX03 */
#define WEXITSTATUS(x)  (_W_INT(x) >> 8)
#endif /* !__DARWIN_UNIX03 */
/* 0x13 == SIGCONT */
#define WSTOPSIG(x) (_W_INT(x) >> 8)
#define WIFCONTINUED(x) (_WSTATUS(x) == _WSTOPPED && WSTOPSIG(x) == 0x13)
#define WIFSTOPPED(x)   (_WSTATUS(x) == _WSTOPPED && WSTOPSIG(x) != 0x13)
#define WIFEXITED(x)(_WSTATUS(x) == 0)
#define WIFSIGNALED(x)  (_WSTATUS(x) != _WSTOPPED && _WSTATUS(x) != 0)
#define WTERMSIG(x) (_WSTATUS(x))
#if (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))
#define WCOREDUMP(x)(_W_INT(x) & WCOREFLAG)

#define W_EXITCODE(ret, sig)((ret) << 8 | (sig))
#define W_STOPCODE(sig) ((sig) << 8 | _WSTOPPED)
#endif /* (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)) */

...

so that's the problem, but I'm not sure what the solution is. The way it's
written, W_EXITCODE() is always going to give up a number...

Thanks

  Daniel

bug#60234: Build failure on mac os 12.6 / gcc 12.2

[lloda]

> On 18 Jan 2023, at 23:16, Ludovic Courtès  <mailto:l...@gnu.org>> wrote:
> 
> Hi Daniel,
> 
> lloda mailto:ll...@sarc.name>> skribis:
> 
>> .../libguile/threads.h:194:43: error: 'scm_i_current_thread' is defined with 
>> tls model global-dynamic
>> 194 | SCM_INTERNAL SCM_THREAD_LOCAL scm_thread *scm_i_current_thread;
>> |   ^
>> .../libguile/threads.c:357:30: note: previously defined here as local-dynamic
>> 357 | SCM_THREAD_LOCAL scm_thread *scm_i_current_thread = NULL;
>> 
>> Simply repeating SCM_INTERNAL in the .c fixes it...
> 
> The problem is that ‘SCM_INTERNAL’ is synonymous with ‘extern’, which
> makes no sense for a definition (threads.c:357), so rightfully GCC
> GNU/Linux rightfully complains:
> 
> --8<---cut here---start->8---
> CC   libguile_3.0_la-threads.lo
> threads.c:358:43: warning: 'scm_i_current_thread' initialized and declared 
> 'extern'
> 358 | SCM_INTERNAL SCM_THREAD_LOCAL scm_thread *scm_i_current_thread = NULL;
> |   ^~~~
> --8<---cut here---end--->8---
> 
> It’s just a warning, but still not looking good.

Hi,

Agreed, I had the same warning on mac os. Looked like the least bad choice...

> Is there something else at play, such as a ‘-ftls-model’ flag being
> passed to GCC somehow (info “(gcc) Code Gen Options")?
> 
> If not, should we have:
> 
> #define SCM_THREAD_LOCAL \
>   __thread __attribute__ ((__tls_model__ ("global-dynamic")))
> 
> instead (info "(gcc) Common Variable Attributes")?
> 
> Would that work with Clang?
> 
> Ludo’.

I don't seem to have any such flags.

The attribute does fix the issue on mac os with gcc 12.

I hadn't tried clang before, but I did now, and clang 14 works fine with or 
without the attribute. So the fix would only be for gcc.

Thanks

 Daniel

bug#60928: [PATCH] bugfix/make_hash_table: fix segfault when arg< 0 for make-hash-table

[lloda]

No worries, thanks for the report!

I note that there's already an old test for (make-hash-table -1) in hash.test. 

Regards

  Daniel

bug#60928: [PATCH] bugfix/make_hash_table: fix segfault when arg< 0 for make-hash-table

[lloda]

It seems this is the same bug as https://bugs.gnu.org/60488 and 
https://bugs.gnu.org/58154, at least it doesn't segfault in main anymore.

bug#44505: Guile 3.0.4 build fails on macOS Big Sur / ARM

[lloda]

Fixed in 3bdcc3668fd8f9a5b6c9a313ff8d70acb32b2a52.

Thanks

  Daniel

bug#60234: Build failure on mac os 12.6 / gcc 12.2

[lloda]

Patched in f859e0f58b211eedcb0dce4f2382cfebf37010d7.

bug#60234: Build failure on mac os 12.6 / gcc 12.2

[lloda]

The error is

.../libguile/threads.h:194:43: error: 'scm_i_current_thread' is defined with 
tls model global-dynamic
  194 | SCM_INTERNAL SCM_THREAD_LOCAL scm_thread *scm_i_current_thread;
  |   ^
.../libguile/threads.c:357:30: note: previously defined here as local-dynamic
  357 | SCM_THREAD_LOCAL scm_thread *scm_i_current_thread = NULL;

Simply repeating SCM_INTERNAL in the .c fixes it...

regards

  Daniel

bug#59540: Calling length on a very long improper list is disastrous.

[lloda]

> On 10 Dec 2022, at 18:27, Ludovic Courtès  wrote:
> 
> ...

> Of these only #2 is something we could work on.  However, truncation has
> proven to be a hindrance sometimes (in backtraces, objects are
> automatically), so I’m not sure we want to enable it by default on
> wrong-type-arg error messages.
> 
> Thoughts?
> 
> Ludo’.

There's previous discussion on this, going both ways.

I think excessive output is a more serious problem, because it should be 
possible to go to a backtrace frame and look at objects directly. On the other 
hand, it should also be possible to C-c when guile starts to flood the 
terminal. But neither of these workarounds is reliable :-/ Ultimately this 
printing should be configurable.

We already have the repl-option system (repl-option-set! repl 'print ...). This 
system doesn't apply to exception messages nor backtraces. I think if it did, 
that would mostly solve the problem.

I also think that, besides options to truncate or not, we should have a pager 
(display at most a page, give options to next/stop/all). That would be the best 
default.

bug#59874: Segfault from string-ref with negative 'k'

[lloda]

Hello,

This is the same bug as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58154 
 which is fixed in git 
(http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=c0004442b7691f59a0e37869ef288eb26382ad9e
 
).

This bug is quite terrible so hopefully we'll get a new release out soon.

Thank you

  Daniel

bug#58154: fluid-ref* with negative index segfaults

[lloda]

Fixed in c0004442b7691f59a0e37869ef288eb26382ad9e. Thank you!

bug#57808: [PATCH] string-fun: Fix typo

[lloda]

Applied in 9592516bfa23056542e9b05b00a4449d0809c6bc. Ty!

bug#56493: close

[lloda]

Fixed in eb5ecf4944cd646341f7e47dda5396cf96a4b8a3.

bug#50068: [PATCH] In curried definitions, move docstrings to outermost lambdas

[lloda]

Applied in 61d8dab8eafd498306ce618582aab37497df77b4. Thank you!

bug#57145: [PATCH] Add xcons example

[lloda]

Hi jgart,

looks good, but could you do a patch for several of these at once?

regards

Daniel


> On 12 Aug 2022, at 00:03, jgart via Bug reports for GUILE, GNU's Ubiquitous 
> Extension Language  wrote:
> 
> ---
> doc/ref/srfi-modules.texi | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
> index bce5b4eac..22a6f9844 100644
> --- a/doc/ref/srfi-modules.texi
> +++ b/doc/ref/srfi-modules.texi
> @@ -262,6 +262,10 @@ Like @code{cons}, but with interchanged arguments.  
> Useful mostly when
> passed to higher-order procedures.
> @end deffn
> 
> +@example
> +(xcons '(u i x) 'g) @result{} (g u i x)
> +@end example
> +
> @deffn {Scheme Procedure} list-tabulate n init-proc
> Return an @var{n}-element list, where each list element is produced by
> applying the procedure @var{init-proc} to the corresponding list
> -- 
> 2.37.1
> 
> 
> 
> 

bug#57098: patch

[lloda]

Applied in c746586de3a1bee77185a414971b48f52de2547b. Thanks!

bug#51129: gperf

[lloda]

Fixed in 50d4b5020333275eadcdba71f0bdd3fc2571101c.

Thank you!

bug#39947: [3.0.0] Compiler mishandles literal bignums passed to

[lloda]

Related: https://debbugs.gnu.org/50609

bug#50609: number overflow

[lloda]

I've applied the patch in c6b1171c6b5632ac04120f482af786444e17d3fe. Thanks for 
the report!

bug#48150: breaking gmp

[lloda]

Fixed in bf9d30f3c3fd03cb37d604f1927e9ce5c699338b. Thanks!

bug#50609: number overflow

[lloda]

Not quite comfortable poking around in the compiler, but find a patch attached.

I also found this related bug: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32644.




0001-Limit-the-range-of-ash-round-ash-count-argument-to-I.patch
Description: Binary data


0002-Avoid-ash-with-arguments-that-might-overflow-in-lang.patch
Description: Binary data

bug#45595: recvfrom! optional start and end parameter invalid

[lloda]

Hi,

Your patch didn't allow for start == end, which is valid as far as I can tell.

With that amended, applied in 1a8294f495cb202f8fcd0f260627c58e7a4c4d10. Thanks!

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

[lloda]

Patch applied in c5f443de79d1cb16ddf34873adb185599836a91b. Thanks!

bug#43987: strerror return value

[lloda]

Patch applied in ab9c0c9ca787da60ac9b956fdbcf4c1fa68c3300. Thanks!

bug#48816: guile: Add ARC support

[lloda]

Applied in 492bd638835c4c00623239190032770583e09714. Thanks!

bug#39601: srfi library naming in r7rs

[lloda]

Applied in a960d7869bc82bb56d5446ece01b8efff9b15fef. Thank you!

bug#39601: srfi library naming in r7rs

[lloda]

Hi Taylan,

Your patch leaks a bunch of identifiers, could you fix that?

thanks

Daniel

bug#51276: Problems with format and scaling floats

[lloda]

Thank you very much, patch applied!

Now that you've dived into (ice-9 format), what about this one:

(format #t "~,,2f~%" 0.01)
=> 1.0
(format #t "~,,3f~%" 0.01) ; !!
=> 010.0
(format #t "~,,3f~%" 0.001)
=> 1.0
(format #t "~,,4f~%" 0.001) ; !!
=> 0010.0
(format #t "~,,4f~%" 0.0001)
=> 1.0
(format #t "~,,5f~%" 0.0001) ; ok somehow...
=> 10.0

regards


> On 18 Oct 2021, at 23:22, Timothy Sample  wrote:
> 
> Hi Guilers,
> 
> It turns out there’s a little blunder in ‘format’ (from ‘ice-9’).  Look
> at what happens when using the SCALE argument to format a fixed-point
> float (this is Guile from the Git repo at the time of writing):
> 
>GNU Guile 3.0.7.6-22120
>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 `,help' for help.
>scheme@(guile-user)> (format #t "~,,3f~%" 0.00123)
>0.23
>$3 = #t
>scheme@(guile-user)> (format #t "~,,1f~%" 0.00123)
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>Value out of range 0 to 400: -1
> 
>Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> 
> The first example gives the wrong result.  Scaling 0.00123 by 3 should
> yield 1.23, not 0.23.  For the second example, instead of 0.0123, we get
> an error!  What’s going on here?
> 
> Well, our ‘format’ code comes from SLIB and was written in 1998, so it’s
> not easy to explain.  There’s so much mutation even a C programmer would
> blush!  ;)  The issue happens in the ‘format:parse-float’ procedure
> (which is defined inside of ‘format’).  It normalizes the string
> representation of a number, and applies the scale argument when needed.
> It does this by keeping a string of digits and the location of the
> decimal point.  Another thing it keeps track of the leading zeros in a
> variable called ‘left-zeros’.  Here’s the code that does the final
> shifting and places the decimal point:
> 
>(if (> left-zeros 0)
>(if (<= left-zeros shift) ; shift always > 0 here
>(format:fn-shiftleft shift) ; shift out 0s
>(begin
>  (format:fn-shiftleft left-zeros)
>  (set! format:fn-dot (- shift left-zeros
>(set! format:fn-dot (+ format:fn-dot shift)))
> 
> The issue is that the cases in the inner ‘if’ form are reversed.  That
> is, if there are MORE leading zeros than we need to shift, we can just
> shift.  Otherwise (if there are FEWER leading zeros), we need to shift
> out the zeros and then move the decimal point (‘format:fn-dot’).
> 
> AFAICS, this bug was in the original SLIB implementation (1998) and has
> not been fixed since then.  It’s been in Guile since 1999.
> 
> Anyway, that’s more than anyone cares to know  Here’s a patch with
> tests!  :)
> 
> From c31d1f5d44343da1201ea1be86bc6b2ac8af6c8d Mon Sep 17 00:00:00 2001
> From: Timothy Sample 
> Date: Mon, 18 Oct 2021 17:07:41 -0400
> Subject: [PATCH] ice-9 format: Fix scaling floats with leading zeros
> 
> ---
> module/ice-9/format.scm  |  4 ++--
> test-suite/tests/format.test | 10 --
> 2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/module/ice-9/format.scm b/module/ice-9/format.scm
> index 48d9c0c84..ee7cba910 100644
> --- a/module/ice-9/format.scm
> +++ b/module/ice-9/format.scm
> @@ -1359,10 +1359,10 @@
>   (else
>(if (> left-zeros 0)
>(if (<= left-zeros shift) ; shift always > 0 here
> -   (format:fn-shiftleft shift) ; shift out 0s
>(begin
>  (format:fn-shiftleft left-zeros)
> - (set! format:fn-dot (- shift left-zeros
> + (set! format:fn-dot (- shift left-zeros)))
> +   (format:fn-shiftleft shift)) ; shift out 0s
>(set! format:fn-dot (+ format:fn-dot shift
> 
>(let ((negexp  ; expon format m.nnnEee
> diff --git a/test-suite/tests/format.test b/test-suite/tests/format.test
> index b9aa7a854..d5111f1c6 100644
> --- a/test-suite/tests/format.test
> +++ b/test-suite/tests/format.test
> @@ -2,7 +2,7 @@
>  Matthias Koeppe  --- June 2001
> 
>  Copyright (C) 2001, 2003, 2004, 2006, 2010, 2011, 2012,
> -   2014, 2017 Free Software Foundation, Inc.
> +   2014, 2017, 2021 Free Software Foundation, Inc.
> 
>  This library is free software; you can redistribute it and/or
>  modify it under the terms of the GNU Lesser General Public
> @@ -121,7 +121,13 @@
>   ;; in guile prior to 1.6.9 and 1.8.1, leading zeros were incorrectly
>   ;; stripped, moving the decimal point and giving "25.0" here
>   (pass-if "string 02.5"
> -(string=? "2.5" (format #f "~f"

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

[lloda]

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 unable to test with the 
newer glibc versions. 

Thanks

Daniel

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

[lloda]

Applied in c78c130b1ddef6d6c290533f74ce1fbd51a4b19d. Thank you!


> On 20 Jul 2021, at 12:54, Maxime Devos  wrote:
> 
> Maxime Devos schreef op zo 18-07-2021 om 21:47 [+0200]:
>> 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.
> 
> With the revised patch, tests succeed and the Guile
> library now compiles successfully.
> 
> Greetings,
> Maxime.
From 40b0b29c05d521cd8901988fa2bc71547f917f48 Mon Sep 17 00:00:00 2001
From: Maxime Devos 
Date: Sun, 18 Jul 2021 19:59:32 +0200
Subject: [PATCH] ice-9/read: Parse #{}}# properly.

This is a regression since Guile 3.0.2 and breaks compilation
of a Guile library.

* module/ice-9/read.scm
  (%read)[read-parenthesized]: When SAW-BRACE? is #t but CH isn't
  #\#, don't eat CH.
* test-suite/tests/reader.test
  ("#{}#): Add four test cases.
---
 module/ice-9/read.scm| 7 +--
 test-suite/tests/reader.test | 5 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/module/ice-9/read.scm b/module/ice-9/read.scm
index ac407739f..283933064 100644
--- a/module/ice-9/read.scm
+++ b/module/ice-9/read.scm
@@ -556,12 +556,15 @@
 (string->symbol
  (list->string
   (let lp ((saw-brace? #f))
-(let ((ch (next-not-eof)))
+(let lp/inner ((ch (next-not-eof))
+   (saw-brace? saw-brace?))
   (cond
(saw-brace?
 (if (eqv? ch #\#)
 '()
-(cons #\} (lp #f
+;; Don't eat CH, see
+;; .
+(cons #\} (lp/inner ch #f
((eqv? ch #\})
 (lp #t))
((eqv? ch #\\)
diff --git a/test-suite/tests/reader.test b/test-suite/tests/reader.test
index 1481a0a5d..ad7c6d575 100644
--- a/test-suite/tests/reader.test
+++ b/test-suite/tests/reader.test
@@ -536,6 +536,11 @@
 
 (with-test-prefix "#{}#"
   (pass-if (equal? (read-string "#{}#") '#{}#))
+  ;; See 
+  (pass-if (equal? (read-string "#{}}#") (string->symbol "}")))
+  (pass-if (equal? (read-string "#{}}}#") (string->symbol "}}")))
+  (pass-if (equal? (read-string "#{{}}#") (string->symbol "{}")))
+  (pass-if (equal? (read-string "#{{}b}#") (string->symbol "{}b")))
   (pass-if (not (equal? (read-string "(a #{.}# b)") '(a . b
   (pass-if (equal? (read-string "#{a}#") 'a))
   (pass-if (equal? (read-string "#{a b}#") '#{a b}#))
-- 
2.32.0

bug#42574: Probable (system vm trace) bug

[lloda]

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

[lloda]

Fixed in f499754bc8291a044c5034b634ac02a01bde9b49. Thanks!

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

[lloda]

Patch applied in d1c6ae19f4e6ab8b3b607a5b14f65c437c06e065. Thanks!

bug#45339: Readline filename completion

[lloda]

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 17:14:35 +0200
Subject: [PATCH] Fixed style for 02439a124

* guile-readline/readline.c (scm_filename_completion_function)
---
 guile-readline/readline.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/guile-readline/readline.c b/guile-readline/readline.c
index 7bb2394ba..469d6ec7d 100644
--- a/guile-readline/readline.c
+++ b/guile-readline/readline.c
@@ -379,7 +379,6 @@ SCM_DEFINE (scm_filename_completion_function, "filename-completion-function", 2,
 #define FUNC_NAME s_scm_filename_completion_function
 {
   char *s;
-  SCM ans;
   char *c_text = scm_to_locale_string (text);
 #ifdef HAVE_RL_FILENAME_COMPLETION_FUNCTION
   s = rl_filename_completion_function (c_text, scm_is_true (continuep));
@@ -387,11 +386,10 @@ SCM_DEFINE (scm_filename_completion_function, "filename-completion-function", 2,
   s = filename_completion_function (c_text, scm_is_true (continuep));
 #endif
   free (c_text);
-  if (!s) {
+  if (!s)
 return SCM_BOOL_F;
-  }
-  ans = scm_take_locale_string (s);
-  return ans;
+
+  return scm_take_locale_string (s);
 }
 #undef FUNC_NAME
 
-- 
2.31.1

bug#48412: duplicate ?

[lloda]

Patch applied in f9f55b9ce74898d1b0a77dcc9b4aa260e5cd208d. Thanks!


> On 16 May 2021, at 09:09, Adriano Peluso  wrote:
> 
> 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 can tracepoint my procedure
> 
> 
> 
> 

bug#47538: ice-9 regex procedures not found when trying to use from r7rs-style defined library

[lloda]

Perhaps an acceptable fix would be to re-export from (ice-9 regex) before 
eventually deprecating the other export.

> On 2 May 2021, at 15:50, Andy Wingo  wrote:
> 
> Hi,
> 
> On Thu 01 Apr 2021 09:06, Arvydas Silanskas  
> writes:
> 
>> foo.scm:
>> (define-library (foo)
>>(import 
>>  (scheme base)
>>  (ice-9 regex))
>>(export bar)
>> 
>>(begin
>>  (define (bar)
>>(make-regexp "a"
> 
> The issue AFAIU is that make-regexp is part of (guile), and not exported
> by (ice-9 regex).  You would need to add (only (guile) make-regexp) to
> your import set.  I know it's somewhat terrible but perhaps in the near
> future we will be able to replace this regexp support with something
> more consistent.
> 
> Please reopen if I misunderstood the bug.
> 
> Cheers,
> 
> Andy
> 
> 
> 

bug#42713: srfi-64 : Reset test-runner-current if done

[lloda]

Patched in 
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=de5d1a7f99b8e952b115237ebc29633062f99bb9.

Thanks for the report!

Regards

Daniel

bug#41353: (thunk? (const 1))

[lloda]

> On 17 May 2020, at 16:46, Jan Synacek  wrote:
> 
> On Sun, May 17, 2020 at 4:09 PM David Kastrup  wrote:
>> I think this is more a matter of the documentation being not quite right:
>> 
>> -- Scheme Procedure: thunk? obj
>> -- C Function: scm_thunk_p (obj)
>> Return ‘#t’ if OBJ is a thunk—a procedure that does not accept
>> arguments.
>> 
>> "if OBJ can serve as a thunk—a procedure called without arguments."
>> 
>> Note that (thunk? (lambda x x)) also returns #t and that ((const 1))
>> returns 1.
> 
> But both (lambda x ...) and (const whatever) are still a procedure that 
> accepts
> an argument, aren't they? My understanding of thunk is (lambda () ...),
> because that's a procedure that takes zero arguments.

(lambda x ...) takes any number of arguments, including none.

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

[lloda]

(import (srfi 9)) doesn't work, but (import (srfi :9)) does.



> On 2 Apr 2020, at 21:47, Marc Nieper-Wißkirchen  wrote:
> 
> 
> 
> 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?
> 
> I use Guile 3.9.1.
> 
> I can do (import (srfi srfi-9)), but I can't do (import (srfi 9)).
> 
> That latter yields the error:
> 
> source expression failed to match any pattern in form (srfi 9).
>  
> 
> 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.
> 
> If numbers are not allowed, Guile will be severely crippled with respect to 
> R7RS code. Most SRFIs are distributed under the name `(srfi NNN)' so many 
> R7RS programs intended to be portable will try to import libraries of the 
> form, say `(srfi 9)' and Guile would complain.
> 
> `cond-expand' is not helpful here in general as an R7RS top-level program has 
> to start with an import and cannot start with some `(cond-expand (guile 
> ...))'. (Besides, `cond-expand' has its own problems: 
> https://lists.gnu.org/archive/html/bug-guile/2020-03/msg00097.html 
> ).
> 
> As a quick-and-dirty workaround, I would suggest that the Guiles 
> (syntax-case?) parser of library names accepts numbers as module name 
> components but treats them internally as symbols (say, by prefixing them with 
> a colon) so that the main module code doesn't have to be touched. The locator 
> for library code in the file system will then have to look for a filenname 
> with a colon and without.
> 
> Marc
> 
>  
> 
> Andy
> 
> On Wed 01 Apr 2020 12:47, Marc Nieper-Wißkirchen  > writes:
> 
> > 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 interoperability, it would be great if Guile 
> > offers
> > the included SRFIs not only under the name (srfi srfi-NNN) but also under
> > (srfi NNN).
> >
> > Thanks,
> >
> > Marc

bug#39634: All keyowrds hash to the same value

[lloda]

> On 25 Feb 2020, at 21:56, Andy Wingo  wrote:
> 
> On Thu 20 Feb 2020 17:19, Ludovic Courtès  writes:
> 
>> Of all the scm_tc7_ values listed in ‘scm.h’, the following are not
>> explicitly listed (so they go to the default case that hashes the first
>> word):
> 
> Reformatting your list so I can check one by one :)
> 
>>  variable,
>>  hashtable,
>>  fluid,
>>  dynamic_state,
>>  frame,
>>  atomic_box,
>>  program,
>>  vm_cont,
>>  weak_set,
>>  weak_table,
>>  port
> 
> No equal? implementation, so should hashq() instead.
> 
>>  bytevector,
>>  array,
>>  bitvector,
> 
> These have equal? implementations, and what's more, a bitvector can
> equal? an array... I think we have another bug!
> 
>  ;; Project 2d array as 1d array (scm_tc7_array)
>  (define x
>(make-shared-array #2b((#t #t #t)) (lambda (i) (list 0 i)) '(0 2)))
>  ;; scm_tc7_bitvector
>  (define y #*111)
> 
>  (equal? x y) ;; => #t
>  (equal? (hash x #x) (hash y #x)) ;; => #f
> 
> Similarly for 1-d scm_tc7_array versus regular vectors, bytevectors,
> etc.
> 
> Fixing this will not be straightforward...  I think basically 1d arrays
> need some special hashing logic so that e.g. vectors and 1d arrays hash
> to the same thing.

I cannot check at the moment but I think that use of make-shared-array is 
special cased to return a bitvector because the shared array and the root 
happen to be equivalent. So your x isn't a scm_tc7_array but a 
scm_tc7_bitvector. The same is true for the other vector types. You can see 
that if you make a shared array with bounds '(0 1) instead of '(0 2) for 
example, or non-unit step or non-zero lower bound or anything that cannot be 
represented as a root vector.

Now it is true that functionally a root vector and a 1d array with the same 
bounds and the same elements are equivalent even if the array has non-unit 
stride and so on, but we had that logic before were you could use the root 
vector functions on arrays and it was an absolute mess. I think there should be 
a logic to hash n-d arrays that extends to 1-d arrays so there's no need to 
make special cases. All vectors can be treated as 1-d arrays so that should 
work fine for those too.

Partially related, I have a series of patches on wip-vector-cleanup to make 
sure that the various vector implementations don't depend on arrays (as they 
still do on some cases) but rather the other way around, strictly. I haven't 
posted about it b/c it changes a few interfaces and I haven't figured out the 
deprecation route.

regards





> 
>>  stringbuf,
>>  values,
> 
> These are never exposed to Scheme, and never compared using equal?
> AFAIU.  No need for special cases.
> 
> Basically I think the tc7 case should default to hashq, and include
> special cases for the ones that have equal? implementations or which
> have read syntax.
> 
> Sound right to you?
> 
> Andy
> 
> 
> 

bug#35315: It's not a bug, sorry

[lloda]

> On 22 Apr 2019, at 23:45, Jan  wrote:
> 
> I've found out it's not a bug, I just didn't  add (define-module (my-modules 
> displays)) - the name of the folder to my module. Sorry for that.
> 
> Have a nice day!
> 
> 
> --
> Jan
> 


Tbh I've always find this requirement a bit annoying. Clearly in an inline 
definition the full name must be given, but if the module is found through the 
path, which is the most common case, all you get from the module declaration is 
a chance to make a mistake.

I guess I'd like for it to be a nameless variant (define-module) that would 
work only in module-files, or even no declaration at all, just calling 
(use-modules (a b c)), then if a/b/c.scm is found, would make the contents of 
c.scm into a module (a b c). I dunno.