Re: Some leftover bugs for this release
Hi Mike,
Mike Gran writes:
>> > Also, the netbsd build will likely fail because there is new
>> > 'condition is always true' condition in array-handle.c:103
>> >
>> > 100 SCM
>> > 101 scm_array_handle_element_type (scm_t_array_handle *h)
>> > 102 {
>> > 103
>> if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
>> > 104 abort (); /* guile programming error */
>> > 105 return scm_i_array_element_types[h->element_type];
>> > 106 }
>>
>> Hmm, an enum variable can possibly hold any integer value, so why would
>> this always be true? Are you actually hitting this?
[...]
> So when I enable -Wtype-limits on my build, it warns for any enum
> value that is beyond those enumerated in the type definition. The
> smallest value in this enum is zero, hence the warning.
Then we could just use ‘-Wtype-limits’ and remove the above run-time
check. Andy?
Thanks,
Ludo’.
Re: GNU Guile 1.9.2 problems with guile-lib
On Sat 15 Aug 2009 19:53, Barry Fishman writes: > Although guile-lib git master works with Guile 1.9.1, there seems to be > a problem with Guile 1.9.2. > > Seen from: Ubuntu Jaunty x86_64 > > $ guile > Guile Scheme interpreter 0.5 on Guile 1.9.2 > Copyright (C) 2001-2008 Free Software Foundation, Inc. > > Enter `,help' for help. > scheme@(guile-user)> (use-modules (htmlprag)) > scheme@(guile-user)> (html->shtml "") This works now. I suspect it was the 7f7b85cbf68a8b83e1ad7bc78379cf2764fc9a1b fix that did it. However we have another problem: scheme@(guile-user)> (define prime:sieve #y(0 0 1 1 0 1 0 1 0 0 0)) ERROR: In procedure make-generalized-vector: ERROR: Wrong type argument in position 1 (expecting array type): y ERROR: In procedure scm_read_expression: ERROR: #:3:47: unexpected ")" What is a #y vector? Does anyone know? Andy -- http://wingolog.org/
Re: simplex.scm fails after recent changes in master
Hi Juhani, On Sat 15 Aug 2009 13:54, Juhani Viheräkoski writes: > [simplex] now seems to run forever when compiled but works with the > interpreter. It used to work when I last tried, that was maybe a week > ago. This was fixed in 7f7b85cbf68a8b83e1ad7bc78379cf2764fc9a1b. Thanks for the report! Andy -- http://wingolog.org/
Re: i guess we're frozen & stuff
Hi Ken, On Tue 11 Aug 2009 15:59, Ken Raeburn writes: > Perhaps I'm building [Guile] in ways that are unusual for the other > developers (build dir != src dir, libgmp and guile-1.8 installed in > the same place, libgmp and libunistring installed in different > nonstandard directories)? I think I fixed the case in which $prefix was not in LD_LIBRARY_PATH or the like. Can you update us on the status of your build issues? Andy -- http://wingolog.org/
Re: debug and backtrace
Hi Mike, On Sun 13 Sep 2009 16:30, l...@gnu.org (Ludovic Courtès) writes: > Mike Gran writes: > >> With the default behavior of 1.9.x, REPL debug and backtrace are broken. > > Indeed, it looks like the VM frames are ignored. Hopefully by the next release, and certainly by the following one, this will be fixed: by having everything on the VM stack. So yes it sucks now, but it's because we have so many kinds of procedures and stacks that it's tough to make a nice debugging interface. Andy -- http://wingolog.org/
Re: Some leftover bugs for this release
On Wed 16 Sep 2009 02:20, Mike Gran writes: > [Insert standard rant about using -Werror here.] We should not be making releases with -Werror. Andy -- http://wingolog.org/
Re: Constant folding
On Tue 08 Sep 2009 15:17, l...@gnu.org (Ludovic Courtès) writes: > We should implement constant folding in the tree-il->glil pass. A naive > implementation looks like this: > > diff --git a/module/language/tree-il/compile-glil.scm > b/module/language/tree-il/compile-glil.scm > index 86b610f..57a46c8 100644 > --- a/module/language/tree-il/compile-glil.scm > +++ b/module/language/tree-il/compile-glil.scm Do it as a tree-il -> tree-il pass, as part of (language tree-il optimize), and you'll be happer. It will be easier to unit test, too. I think we should simply implement Waddell's algorithm. Andy -- http://wingolog.org/
Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2
On Tue 01 Sep 2009 08:26, Ken Raeburn writes: > On Sep 1, 2009, at 02:23, Ken Raeburn wrote: >> I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as >> needed, change == to scm_is_eq. The initializers make it slightly >> less trivial, and I can imagine different courses of action. > > Okay, not quite so trivial as I blithely asserted. > > It looks like the eval code is going to be annoying too All this will be gone within a month, hopefully. Further details to come. I don't see it as such a big problem to play "fast and loose" with types, honestly... one day we'll have native compilation, and it's all just words there. Andy -- http://wingolog.org/
Re: Should psyntax pass through a compiled VM program?
On Sun 13 Sep 2009 23:17, Neil Jerram writes: > I think that's the right eventual question, anyway. The context is > running Alan Grover's mod_lisp-for-guile in 1.9.2. > > The mod_lisp-for-guile code includes a use of read-hash-extend to > define a syntax for a compiled regular expression - so that you can > write things like > > (if (#m/^Error: +/ line) > ...) > > with a similar effect to Perl > > if (line ~= /^Error: +/) > ... > > So: > > (read-hash-extend #\m (lambda (c port) > ... > (lambda (string) > ...))) > > In other words, the custom reader procedure returns another > procedure. So what happens when you compile this file? You would have to serialize that procedure somehow, a procedure that could be a closure, etc... No, I think all macros have to return syntax and not values. This particular case is a bit unfortunate, though. You really want to compile the regex once, preferably at compile-time... ideally the regex compiles to scheme, and thence to bytecode/native code, but that's not how things are right now. So yes, I think the best we can do is to do what you did: > (define-public (make-regexp-fn regexp-string) > (lambda (string) > ...)) And make-regexp-fn should memoize results. > but I wonder if there is a case for supporting the code as it was > before, by I'm afraid not, because you need to be able to compile a file to bytecode, write it out to disk, then load it later. > Also, is it definitely correct to call read-hash-extend procedures > first, and do the psyntax pass later? I guess it must be, as we need > to call the read-hash-extend procedure in order even to determine the > extent of the relevant lexeme. Right. More thought (and documentation!) is needed here, though. Andy -- http://wingolog.org/
Re: Some leftover bugs for this release
Hi,
On Wed 16 Sep 2009 11:09, l...@gnu.org (Ludovic Courtès) writes:
>>> > 100 SCM
>>> > 101 scm_array_handle_element_type (scm_t_array_handle *h)
>>> > 102 {
>>> > 103
>>> if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
>>> > 104 abort (); /* guile programming error */
>>> > 105 return scm_i_array_element_types[h->element_type];
>>> > 106 }
>>>
>>> Hmm, an enum variable can possibly hold any integer value, so why would
>>> this always be true? Are you actually hitting this?
>
> [...]
>
>> So when I enable -Wtype-limits on my build, it warns for any enum
>> value that is beyond those enumerated in the type definition. The
>> smallest value in this enum is zero, hence the warning.
>
> Then we could just use ‘-Wtype-limits’ and remove the above run-time
> check. Andy?
The struct could get corrupted somehow of course. It's not a bad check,
but the typechecker is working against us :P
Andy
--
http://wingolog.org/
Re: GNU Guile 1.9.2 problems with guile-lib
Hi, Andy Wingo writes: > What is a #y vector? Does anyone know? No idea. Where does it come from? Ludo’.
Re: GNU Guile 1.9.2 problems with guile-lib
> What is a #y vector? Does anyone know? From the 1.3.2 changelog 1998-10-18 Mikael Djurfeldt * unif.c (scm_raprin1): Changed print syntax for byte vectors from #bytes(...) to #y(...), and syntax for short vectors from #short(...) to #h(...). This may seem nutty, but, like the other uniform vectors, byte vectors and short vectors want to have the same print and read syntax (and, more basic, want to have read syntax!). Changing the read syntax to use multiple characters after the hash sign breaks with the conventions used in R5RS and the conventions used for the other uniform vectors. It also introduces complexity in the current reader, both on the C and Scheme levels. (The Right solution is probably to change the syntax and prototypes for uniform vectors entirely.) - Mike
Re: GNU Guile 1.9.2 problems with guile-lib
l...@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> Andy Wingo writes:
>
>> What is a #y vector? Does anyone know?
>
> No idea. Where does it come from?
>
> Ludo’.
>From the error message it is a generalized vector, which no longer
exists. What seems to be wanted is a bitvector. There does not
seem to be a literal for a bitvector although its printed like:
#*00110101000
Maybe something like:
diff --git a/src/math/primes.scm b/src/math/primes.scm
index 9873ae4..43745e9 100644
--- a/src/math/primes.scm
+++ b/src/math/primes.scm
@@ -103,7 +103,7 @@ being labelled prime) is @code{(expt 2 (- prime:trials))}."
(or (null? lst) (and (= 1 (gcd n (car lst))) (mapf (cdr lst)))
(define prime:prime-sqr 121)
(define prime:products '(105))
-(define prime:sieve #y(0 0 1 1 0 1 0 1 0 0 0))
+(define prime:sieve (bitvector #f #f #t #t #f #t #f #t #f #f #f))
(letrec ((lp (lambda (comp comps primes nexp)
(cond ((< comp (quotient most-positive-fixnum nexp))
(let ((ncomp (* nexp comp)))
@@ -112,9 +112,9 @@ being labelled prime) is @code{(expt 2 (- prime:trials))}."
(next-prime nexp (cons ncomp comps)
((< (quotient comp nexp) (* nexp nexp))
(set! prime:prime-sqr (* nexp nexp))
- (set! prime:sieve (make-uniform-vector nexp #\nul 0))
+ (set! prime:sieve (make-bitvector nexp #f))
(for-each (lambda (prime)
- (uniform-vector-set! prime:sieve prime 1))
+ (bitvector-set! prime:sieve prime #t))
primes)
(set! prime:products (reverse (cons comp comps
(else
@@ -132,7 +132,7 @@ being labelled prime) is @code{(expt 2 (- prime:trials))}."
There is a slight chance, @code{(expt 2 (- prime:trials))}, that a
composite will return @code{#t}."
(set! n (abs n))
- (cond ((< n (uniform-vector-length prime:sieve)) (positive?
(uniform-vector-ref prime:sieve n)))
+ (cond ((< n (bitvector-length prime:sieve)) (bitvector-ref prime:sieve n))
((even? n) #f)
((primes-gcd? n prime:products) #f)
((< n prime:prime-sqr) #t)
There are still other issues with guile-lib with 4 of 25 tests failing.
I have been looking at them as a background task.
--
Barry Fishman
Re: debug and backtrace
Andy Wingo writes:
> Hi Mike,
>
> On Sun 13 Sep 2009 16:30, l...@gnu.org (Ludovic Courtès) writes:
>
>> Mike Gran writes:
>>
>>> With the default behavior of 1.9.x, REPL debug and backtrace are broken.
>>
>> Indeed, it looks like the VM frames are ignored.
>
> Hopefully by the next release, and certainly by the following one, this
> will be fixed: by having everything on the VM stack. So yes it sucks
> now, but it's because we have so many kinds of procedures and stacks
> that it's tough to make a nice debugging interface.
Actually I think I just found and fixed one problem. From the time when
a # was a SMOB, really_make_boot_program in vm.c was still
using SCM_SET_SMOB_FLAGS to set the SCM_F_PROGRAM_IS_BOOT flag - which
meant that it was setting flag 1<<32 :-) which obviously was then missed
by the SCM_PROGRAM_IS_BOOT calls in stacks.c.
So now, with my test script
((lambda _
(car 1) 23))
I get a backtrace:
n...@arudy:~/SW/Guile/git$ meta/guile --debug -s ../testcar.scm
Backtrace:
In ice-9/boot-9.scm:
1772: 0* [save-module-excursion #]
In unknown file:
?: {1}* [dynamic-wind #
...]
In ice-9/boot-9.scm:
935: 2* [load "../testcar.scm"]
In unknown file:
?: 3* [with-fluid* # #f #]
In ice-9/boot-9.scm:
940: 4* [#]
In unknown file:
?: 5* [load-compiled/vm
"/home/neil/SW/Guile/git/cache/guile/ccache/1.9-0.D-LE-4/home/neil/SW/Guile/testcar.scm.go"]
In ../testcar.scm:
2: 6* [# 23]
ERROR: In procedure vm-debug-engine:
ERROR: Wrong type argument in position 1 (expecting pair): 1
I'll push the fix a bit later. (I also have fixes for the incorrect
stack count warning.)
But I notice that there is only ever one frame per VM. E.g. with code
like
(define (foo n)
(let ((a 1))
(let ((b 2))
(string-append (* a b)
(which deliberately passes an invalid arg to string-append), the
interpreter backtrace would show the two `let' frames, whereas the VM
backtrace doesn't.
Is that intended, or something else to investigate?
Regards,
Neil
