R6RS test suite

>Ypsilon
>-------
>[If there's a library-autoload mechanism, we didn't figure it out. Better ideas are welcome...]

I have released Ypsilon 0.9.5-update2 at:
http://code.google.com/p/ypsilon/downloads/list
It recognize '.sls' extension and autoload test suite libraries.

I write the description for "Hints on running the tests" section.
Please check.
===============================
Ypsilon 0.9.5-update2
------

Put this directory at "<somewhere>/tests/r6rs" and run with "run.sps"

cd <somewhere>
ypsilon --sitelib=. --no-letrec-check tests/r6rs/run.sps

or run an individual library's test, such as "run/program.sps" as

cd <somewhere>
ypsilon --sitelib=. --no-letrec-check tests/r6rs/run/program.sps
================================
*Because Ypsilon check letrec restriction violation during macro
expansion, the expression "(letrec ((x y) (y x)) 'should-not-get-
here)" in test/r6rs/base.sls raises exception during load. I added '--
no-letrec-check' to avoid this problem.

Finally, running all tests on Ypsilon 0.9.5-update2 show "93 of 8836
tests failed"
Thank you for your great work!

---
Yoshikatsu Fujita

On Jul 26, 2:49*am, y.fujita....@gmail.com wrote:
> I have released Ypsilon 0.9.5-update2 at:http://code.google.com/p/ypsilon/downloads/list
> It recognize '.sls' extension and autoload test suite libraries.
>
> I write the description for "Hints on running the tests" section.

Great! I've updated "README.txt" in SVN.

Thanks,
Matthew

On Jul 26, 4:49*am, y.fujita....@gmail.com wrote:

> *Because Ypsilon check letrec restriction violation during macro
> expansion, the expression "(letrec ((x y) (y x)) 'should-not-get-
> here)" in test/r6rs/base.sls raises exception during load. I added '--
> no-letrec-check' to avoid this problem.

I believe that the R6RS requires that this check be done at runtime
(at least sometimes). In section 11.4.6, discussing `letrec', it says,
under Implementation Responsibilities (emphasis mine):

Implementations must detect references to a <variable> during the
EVALUATION of the <init> expressions (using one particular evaluation
order and order of evaluating the <init> expressions).

There are some examples where it would be hard (or impossible) to
determine during macro expansion whether the letrec restriction will
be violated. For example (letrec ([x (if (eq? (cons 1 2) (cons 1 2))
x 1)]) x) should always return 1, but the analysis is not obvious.

sam th

On Jul 26, 2:59*pm, samth <sam...@gmail.com> wrote:
>*For example *(letrec ([x (if (eq? (cons 1 2) (cons 1 2))
> x 1)]) x) should always return 1, but the analysis is not obvious.

That's a good test to add

>On Jul 26, 9:59 pm, samth <sam...@gmail.com> wrote:
> On Jul 26, 4:49*am, y.fujita....@gmail.com wrote:
>
> > *Because Ypsilon check letrec restriction violation during macro
> > expansion, the expression "(letrec ((x y) (y x)) 'should-not-get-
> > here)" in test/r6rs/base.sls raises exception during load. I added '--
> > no-letrec-check' to avoid this problem.
>
> I believe that the R6RS requires that this check be done at runtime
> (at least sometimes). In section 11.4.6, discussing `letrec', it says,
> under Implementation Responsibilities (emphasis mine):
>
> Implementations must detect references to a <variable> during the
> EVALUATION of the <init> expressions (using one particular evaluation
> order and order of evaluating the <init> expressions).
>
> There are some examples where it would be hard (or impossible) to
> determine during macro expansion whether the letrec restriction will
> be violated. *For example *(letrec ([x (if (eq? (cons 1 2) (cons 1 2))
> x 1)]) x) should always return 1, but the analysis is not obvious.
>
> sam th

Thank you for your input.
Now I understand why the letrec violation raises &asserion but not
&syntax!
I'm very happy to know that

On Jul 26, 10:25 pm, leppie <xacc....@gmail.com> wrote:
> On Jul 26, 2:59 pm, samth <sam...@gmail.com> wrote:
>
> > For example (letrec ([x (if (eq? (cons 1 2) (cons 1 2))
> > x 1)]) x) should always return 1, but the analysis is not obvious.
>
> That's a good test to add

Yes, it is!

As testimony to the value of a good test suite,
here are test results for Larceny v0.963. Please
compare to the results for v0.962 that I posted
one week ago.

Thanks again, Matthew.

Will

--------

Summary of results for
R6RS test suite for PLT Scheme (revision 10978)
29 July 2008
system tested:
Larceny v0.963
test machine:
MacBook Pro (2.4 GHz Intel Core 2 Duo, 4 GB RAM)
Mac OS X 10.5.3

45 of 8843 tests failed.

library under test summary of outcome
================== ==================
(rnrs arithmetic bitwise) 232 tests passed
(rnrs arithmetic fixnums) 4355 tests passed
(rnrs arithmetic flonums) 1 of 365 tests failed.
(rnrs base) 8 of 1995 tests failed.
(rnrs bytevectors) 464 tests passed
(rnrs conditions) 131 tests passed
(rnrs control) 11 tests passed
(rnrs enums) 26 tests passed
(rnrs eval) 3 tests passed
(rnrs exceptions) 10 tests passed
(rnrs hashtables) 249 tests passed
(rnrs io ports) 35 of 431 tests failed.
(rnrs io simple) 56 tests passed
(rnrs lists) 74 tests passed
(rnrs mutable-pairs) 3 tests passed
(rnrs mutable-strings) 3 tests passed
(rnrs programs) 2 tests passed
(rnrs r5rs) 71 tests passed
(rnrs reader) 70 tests passed
(rnrs records procedural) 21 tests passed
(rnrs records syntactic) 53 tests passed
(rnrs sorting) 4 tests passed
(rnrs syntax-case) 1 of 96 tests failed.
(rnrs unicode) 118 tests passed

On Jul 30, 4:11*am, William D Clinger <cesur...@yahoo.com> wrote:
> As testimony to the value of a good test suite,
> here are test results for Larceny v0.963. *Please
> compare to the results for v0.962 that I posted
> one week ago.
>
> Thanks again, Matthew.
>
> Will
>
> --------
>
> Summary of results for
> R6RS test suite for PLT Scheme (revision 10978)
> 29 July 2008
> system tested:
> * * Larceny v0.963
> test machine:
> * * MacBook Pro (2.4 GHz Intel Core 2 Duo, 4 GB RAM)
> * * Mac OS X 10.5.3
>
> 45 of 8843 tests failed.
>
> library under test * * * * * * *summary of outcome
> ================== * * * * * * *==================
> (rnrs arithmetic bitwise) * * * 232 tests passed
> (rnrs arithmetic fixnums) * * * 4355 tests passed
> (rnrs arithmetic flonums) * * * 1 of 365 tests failed.
> (rnrs base) * * * * * * * * * * 8 of 1995 tests failed.
> (rnrs bytevectors) * * * * * * *464 tests passed
> (rnrs conditions) * * * * * * * 131 tests passed
> (rnrs control) * * * * * * * * *11 tests passed
> (rnrs enums) * * * * * * * * * *26 tests passed
> (rnrs eval) * * * * * * * * * * 3 tests passed
> (rnrs exceptions) * * * * * * * 10 tests passed
> (rnrs hashtables) * * * * * * * 249 tests passed
> (rnrs io ports) * * * * * * * * 35 of 431 tests failed.
> (rnrs io simple) * * * * * * * *56 tests passed
> (rnrs lists) * * * * * * * * * *74 tests passed
> (rnrs mutable-pairs) * * * * * *3 tests passed
> (rnrs mutable-strings) * * * * *3 tests passed
> (rnrs programs) * * * * * * * * 2 tests passed
> (rnrs r5rs) * * * * * * * * * * 71 tests passed
> (rnrs reader) * * * * * * * * * 70 tests passed
> (rnrs records procedural) * * * 21 tests passed
> (rnrs records syntactic) * * * *53 tests passed
> (rnrs sorting) * * * * * * * * *4 tests passed
> (rnrs syntax-case) * * * * * * *1 of 96 tests failed.
> (rnrs unicode) * * * * * * * * *118 tests passed

Looking good

I still got almost 140 in IronScheme!

Cheers

leppie

On Jul 23, 11:03 pm, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> On Jul 23, 2:20 pm, leppie <xacc....@gmail.com> wrote:
>
> > Some more bugs (the conditions should all be wrapped with (record-type-
> > descriptor)):
>
> > - Line 80 of test.sls
> > - Line 264 & line 266 of flonums.sls
>
> Fixed in SVN.
>
> Thanks,
> Matthew

Hi Matthew

Can the some of the arithmetic tests be adjusted to detect whether a
signed zero is a supported? Eg:

(log -1.0-0.0i)
=> 0.0-3.141592653589793i ; approximately
; if -0.0 is distinguished

The tests currently requires you distinguish between +0.0 and -0.0.

You could also add the following test: (test (= +nan.0 +nan.0) #f)

Cheers

leppie

On Jul 31, 9:30*pm, leppie <xacc....@gmail.com> wrote:
> You could also add the following test: (test (= +nan.0 +nan.0) #f)

Also overflow and divide by zero tests for fixnums

On Jul 31, 1:30*pm, leppie <xacc....@gmail.com> wrote:
> Can the some of the arithmetic tests be adjusted to detect whether a
> signed zero is a supported? Eg:
>
> (log -1.0-0.0i)
> * * * * * * * * => 0.0-3.141592653589793i ; approximately
> ; if -0.0 is distinguished
>
> The tests currently requires you distinguish between +0.0 and -0.0.

I've wrapped the `log' and `angle' tests with

(unless (eqv? 0.0 -0.0) ....)

Is that right? Are there other tests that need a wrapper?

> You could also add the following test: (test (= +nan.0 +nan.0) #f)

Ok - added.


Matthew