This looks like a bug (v2.0.6).
I was cleaning up an old script which goes like this:
(define (eval-case ...)
...
val)
(define var (eval-case ...))
This worked from the REPL, but when loading the file with (load "script"), var
was always #. It turns out that (my) eval-case is never execut
There's a bug with generalized-vector->list and shared arrays. I have seen this
kind of bug before, I'm not sure if it wasn't fixed last time or it has
resurfaced somehow.
GNU Guile 2.0.6
Copyright (C) 1995-2012 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; fo
To clarify, the report above is for v2.0.6 (1321a36…)
See the thread here
http://lists.gnu.org/archive/html/guile-user/2012-11/msg00032.html
In Guile 2.0.6
(define f (case-lambda*
((x #:optional y) 1)
((x #:key y) 2)
((x y #:key z)3)))
(f 1 2 #:z 3) -> Odd length of keyword argument list
Also
(de
In 2.0.7
scheme@(guile-user)> (import (ice-9 format))
scheme@(guile-user)> (format #t "~!")
;;; :2:0: warning: "~!": wrong number of `format' arguments: expected 1,
got 0
$1 = #t
scheme@(guile-user)> (format #t "~!" 3)
$2 = #t
scheme@(guile-user)> (format #t "~!~a" 3 9)
3$3 = #t
scheme@(guile-
There is an obvious bug in faabd16… in the handling of "-l"
,arg0 should be ,(car args)
However, even after fixing this, there are problems with the load path
> cat x.scm
(define hello 1) ^D
> guile -l x.scm
[backtrace ...] Unable to find file "ice-9/x.scm" in load path
> guile -L /home/daniel/
Ok, it seems that this was fixed before I reported it. Close?
On Jan 24, 2013, at 12:42, Mark H Weaver wrote:
> Can you verify that the "problems with the load path" you referred to
> are now fixed?
>
>Thanks,
> Mark
Yes, that should be the change load -> load-in-vicinity. This was an issue also
with -s, etc. It works for me now.
Regards,
I think this isn't working as it should either.
scheme@(guile-user)> +1i
$1 = 0.0+1.0i
scheme@(guile-user)> 1i
;;; : warning: possibly unbound variable `#{1i}#'
ERROR: In procedure #:
ERROR: In procedure module-lookup: Unbound variable: #{1i}#
On Mar 6, 2013, at 17:55, Mark H Weaver wrote:
> Daniel Llorens writes:
>
>> I think this isn't working as it should either.
>>
>> scheme@(guile-user)> +1i
>> $1 = 0.0+1.0i
>> scheme@(guile-user)> 1i
>> ;;; : warning: possibly unbound var
Not necessarily a bug, but I'd like to hear some thoughts on this.
In current Guile
(max -inf.0 9) => 9.0
The manual says
> R5RS requires that, with few exceptions, a calculation involving inexact
> numbers always produces an inexact result [...] The only exception to the
> above requirement
On Mar 8, 2013, at 19:59, Mark H Weaver wrote:
> By the way, there's an easy way to accomplish what you want. Simply use
> 'reduce' (from SRFI-1) instead of 'fold':
>
> (reduce max -inf.0 exact-number-list)
I was about to roll my own, but this is exactly the case where fold doesn't
work and r
Compare
(define f (lambda (a) a))
(call-with-values (lambda () (values 3 3)) f)
vs
(call-with-values (lambda () (values 3 3)) (lambda (a) a))
The first one fails with
:1:0: In procedure f:
:1:0: Wrong number of arguments to #
The second one gives 3.
This is Guile 2.0.7.112-f5ea5.
The beh
On Mar 1, 2013, at 10:44, Andy Wingo wrote:
> On Fri 01 Mar 2013 10:01, Daniel Llorens writes:
>
>> scheme@(guile-user)> ,optimize (vector-ref #(1 2 3) 0)
>> $1 = 1
>> scheme@(guile-user)> ,optimize (array-ref #(1 2 3) 0)
>> $2 = (array-ref '#(1 2 3) 0)
On Mar 27, 2013, at 20:31, Andy Wingo wrote:
> If you would like to make a precise list, that would be helpful.
At least everything from §6.6.2.7 to §6.6.2.13 in
http://www.gnu.org/software/guile/manual/html_node/
I've noticed that a few of these are already reduced, it seems quite random.
F
The following code:
(define-syntax define-lues
(syntax-rules ()
((_ () exp)
(call-with-values (lambda () exp) (lambda () 'unspecified)))
((_ (var . vars) exp)
(begin
(define var (call-with-values (lambda () exp) list))
(define-lues vars (apply values (cdr var)))
stable-2.0 with either cut or cute works. The compiler in master works for cut
but not for cute.
scheme@(guile-user)> (import (srfi srfi-26))
scheme@(guile-user)> (cute < 1 <> 2)
While compiling expression:
ERROR: Wrong number of arguments to #
Thanks,
Daniel
Hello,
this is with current master, I don't know what stable 2.0 does, although I
don't think it's changed there.
scheme@(guile-user)> (format #t "~{~{~a~^ ~}\n~}" '((1 2) (3 4)))
;;; :1:0: warning: "~{~{~a~^ ~}\\n~}": wrong number of `format'
arguments: expected 2, got 1
1 2
3 4
$1 = #t
appa
The default history-length is 200. When one imports (ice-9 readline), history
is stifled to this value, so it doesn't matter if you set history-length to a
larger value later on. I'm surprised that this has gone unnoticed up to now,
since 200 is really small. I may be missing something...
The
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=eb3d623da57e6d31a58d95f932345fb761f9b701
on master fixes printing of scm_tc7_array (shared array) to be #1(...) or
#1typetag(...) so they aren't confused with actual vectors or bytevectors.
With respect to the lack of capability to
The error seems to happen in the error reporting, not actually because of the
shift.
The following backtrace is with Guile compiled with -O1 -g, the same error
happens with -O2.
GNU Guile 2.1.1.125-ae0380-dirty
Copyright (C) 1995-2014 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY
(format #f "~2f" 9.9) fails in master. You can try different combinations, it
doesn't fail when it rounds down or there're more spaces for example.
The first bad commit is 0f2f5949a21572fad8355473200c7adc6d74f882 'Better
unboxing' on the master branch.
See the full error below. 184467440737095
I cannot reproduce this anymore on a9dc553893dcd26f047afecc8dc84d30c9bdcde6.
So closing.
On 20 Jun 2016, at 18:19, Andy Wingo wrote:
> On Fri 18 Mar 2016 16:35, Daniel Llorens writes:
>
>> The error seems to happen in the error reporting, not actually because of
>> the
I can't fix the compiler, so just patch format:fn-round. Includes a
test.
From: Daniel Llorens
* module/ice-9/format.scm (format:fn-round): Don't let i become
negative.
* test-suite/tests/format.test: Regression test for "~2f".
---
module/ice-9/format.scm | 15 ---
test-suite/tests/format.test | 6 +-
2 files changed, 13 i
Fixed in 2660c0b3c86bf76fab465c200a5ca20fb37cf811.
See below.
The bug happens after commit 35a90592501ebde7e7ddbf2486ca9d315e317d09, ‘Add
unboxed floating point comparison instructions.’
> ./meta/guile
GNU Guile 2.1.6
Copyright (C) 1995-2016 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
T
It's a trivial patch. I don't know how to test it though.
From a0028723da283d39e5ab4e43f8934506a917498b Mon Sep 17 00:00:00 2001
From: Daniel Llorens
Date: Tue, 7 Feb 2017 12:14:15 +0100
Subject: [PATCH] Fix bug #25492
* libguile/vm-engine.c (BR_F64_ARITHMETIC): Fix type.
---
l
Fixed in a0028723da283d39e5ab4e43f8934506a917498b.
Tags: notabug
> From: Jan Wedekind
> Subject: bug#29387: Guile-2.2.2 complex numbers edge case
> Date: 21 Nov 2017 23:09:57 GMT+1
> To: 29...@debbugs.gnu.org
> Reply-To: Jan Wedekind
>
>
> Hi,
> I think I encountered a bug in the numerical stack.
> i times i should equal -1:
>
>(equal? -1 (* 0+i 0+i))
On 22 Nov 2017, at 19:32, Jan Wedekind wrote:
> Thanks Daniel,
> I see. So I need to use "=" for numerical comparisons. "equal?" is only true
> if the types are the same, too:
>
> (equal? 1.0 1)
> ; #f
> (= 1.0 1)
> ; #t
>
> Sorry for filing a bug report. Feel free to close the bug.
no probl
Agreed with David that this is an important issue. Without a patch, working
with a large data structure is guaranteed to kill the REPL session sooner or
later. There was a thread a while ago here:
https://lists.gnu.org/archive/html/guile-user/2017-02/msg00188.html
Right now, the REPL will catc
I think, regardless of whether GUILE_AUTO_COMPILE works correctly or not (and
public variables should all be documented, so if %load-should-autocompile
isn't, I'd call that its own bug), I agree with the substance of the complaint.
The autocompilation messages aren't warnings and shouldn't be
This is from git, 8aa47f2…
> (expt 2 -inf.0)
ERROR: In procedure integer-expt:
ERROR: Wrong type argument in position 2: -inf.0
These do work:
> (expt 2. -inf.0)
$1 = 0.0
> (expt 1 -inf.0)
$2 = 1
Regards,
Daniel
I meant 1.9.14 and not 1.9.4, sorry.
> This is from git, 8aa47f2...
>
>> (expt 2 -inf.0)
> ERROR: In procedure integer-expt:
> ERROR: Wrong type argument in position 2: -inf.0
>
> These do work:
>
>> (expt 2. -inf.0)
> $1 = 0.0
>> (expt 1 -inf.0)
> $2 = 1
>
> Regards,
>
> Daniel
th-input-file, but probably both should be errors.
Anyway, here is a patch for call-with-input/output-file that avoids the issue.
Regards,
Daniel
From 06f8aea901cd3da68a409a9932757209d91efc40 Mon Sep 17 00:00:00 2001
From: Daniel Llorens
Date: Mon, 2 May 2011 14:54:20 +020
On May 2, 2011, at 19:46, Mark H Weaver wrote:
> Daniel Llorens writes:
>> scheme@(guile-user)> (call-with-input-string "hello" (lambda (p) (values 1
>> 2)))
>> $1 = 1
>> $2 = 2
>>
>> but:
>>
>> scheme@(guile-user)>
On May 2, 2011, at 22:55, Andy Wingo wrote:
> We are brushing the copyright assignment limits here; I'll apply this,
> but if you are interested in sending further patches to Guile, would you
> be OK with assigning copyright to the FSF? Please let me know, and I'll
> send you details in a privat
In the latest git,
scheme@(guile-user)> #0(1)
While executing meta-command:
ERROR: Wrong type argument in position 1: #0(1)
The trivial patch attached fixes this problem. However make check passes
without the patch, even though arrays.test contains the offending syntax #2((1
2) (3 4) (5 6)). I
(define nn #2u32((0 1) (2 3)))
(array-ref (array-row nn 1) 0)
(generalized-vector-ref (array-row nn 1) 0)
Regards,
Daniel
%< -
From 58e544c0034582de01f3b54f52228bfa2273578b Mon Sep 17 00:00:00 2001
From: Daniel Llorens
Date: Thu, 8 Dec 2011 18:49:00 +0100
Subject: [PATCH] Fix a
I've found an bug in array output. It's peculiar. I haven't tried to debug it
or bisect it, hopefully it rings a bell somewhere. It only happens when the
rank of the array is not 1. This was tested in the last stable-2.0 (bbe34).
scheme@(guile-user)> (define c (make-array 0 2 2))
scheme@(guile-
This is with the latest from git.
(use-modules (srfi srfi-26))
(define (f! A B) (array-fill! B 0.))
(define x (make-typed-array 'f64 0. 2))
(cut f! #2f64((0 1) (2 3)) <>)
Throw to key `wrong-type-arg':
ERROR: Wrong type (expecting array): #< key: f!>
Entering the debugger. Type `bt' for a backt
On 30 Mar, 2010, at 21:24, Andy Wingo wrote:
On Tue 30 Mar 2010 17:02, Daniel Llorens del Río
writes:
0 (assoc-ref ((#< key: f!> . 1)) #2f64
((0 1) (2 3)))
This was actually a problem with the runtime, not the compiler: equal?
on an array and a non-array bombed. Fixed,
On 31 Mar, 2010, at 17:55, Daniel Llorens del Río wrote:
Although this one also works…
> (call-with-values (lambda () (f #s32() #f64())) (lambda (a b)
(format #f "~a ~a" a b)))
=> "#s32() #f64()"
Sorry, this should be … (lambda () (values #s32() #f64())) …
Regards,
Daniel
45 matches
Mail list logo
