gmane.lisp.ansi-tests

Wrong test?

Juan Jose Garcia-Ripoll — 2011-12-26T15:26:51

(MACROLET ((%M (Z)
                   Z))
        (CTYPECASE (EXPAND-IN-CURRENT-ENV (%M :FOO))
          (INTEGER :BAD1)
          (KEYWORD :GOOD)
          (SYMBOL :BAD2)))

What is this supposed to check? In ECL this leads to the following code

(CTYPECASE :FOO
          (INTEGER :BAD1)
          (KEYWORD :GOOD)
          (SYMBOL :BAD2)))

This is in my opinion wrong.. CTYPECASE is supposed to contain a form for a
correctable error, including a replacement of the value of the form, in
this case :FOO. This means CTYPECASE expands at some point to (SETF :FOO
...) which is not a valid code, given that :FOO is a constant.

I know that SBCL and probably other implementations do not complain about
this until the assignment is performed, but this does not mean that the
code is valid.

Juanjo

Does this work at all?

Juan Jose Garcia-Ripoll — 2011-12-26T15:22:02

I submitted an email to the list some time ago, with some patches for
consideration, and received no answer so far.

I am worried because ECL now relies on this repository of the test suite
for operations such as "make check" and I need the test suite to be updated

Local function binding shadows global macro

Erik Huelsmann — 2011-08-25T21:09:05

This week, I fixed an error in ABCL for which there seems to be no
conformance test: a local function binding shadows global macros and
compiler macros.

I'm not really sure how to set up a good test for it within the ansi tests
framework, but this is the code which caused the issue in ABCL:


(defmacro var (name &optional value docs)
   `(defparameter ,name ,< at >(when value (list value))))

(defun make-var (the-name))

(defun foo (var-ref)
  (flet ((var (x) (second x)))
     `(make-var ,(var x))))


Any ideas about translating this into a good test to be committed?

Maybe we could come up with a similar test for compiler macros as well?


Bye,


Erik.
_______________________________________________
ansi-test-devel mailing list
ansi-test-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/ansi-test-devel

Problem with CTYPECASE.15

Juan Jose Garcia-Ripoll — 2010-12-24T16:39:26

(MACROLET ((%M (Z)
                   Z))
        (CTYPECASE (EXPAND-IN-CURRENT-ENV (%M :FOO))
          (INTEGER :BAD1)
          (KEYWORD :GOOD)
          (SYMBOL :BAD2)))

Is this test really correct? CTYPECASE must be able to write into the keyval
(in this case the form (EXPAND-IN-CURRENT-ENV (%M :FOO))). ECL properly
detects that this is impossible, because the expression is constant, but
this is not what the test suite expects.

Would the following make sense?

(MACROLET ((%M (Z)
                   Z))
        (CTYPECASE (LET ((X (EXPAND-IN-CURRENT-ENV (%M :FOO)))) X)
          (INTEGER :BAD1)
          (KEYWORD :GOOD)
          (SYMBOL :BAD2)))

Juanjo

pprint-tabular.6 et al

Sam Steingold — 2010-07-27T18:25:04

Tests pprint-tabular.6 &ff are failed by the reference implementation in
http://www.lispworks.com/documentation/HyperSpec/Body/f_ppr_fi.htm
why? is there some pitfall which the standard authors created and then missed?

print-unreadable-object.2 and 3?

Raymond Toy — 2010-04-21T03:06:35

Does any Lisp actually pass these two tests?  I think
print-unreadable-object.2 expects a space after the type in all cases.
Test 3 expects a space before the address in all cases.

Does anything think that that is what the spec really wants?

If no Lisp passes this test, can we just change them or remove them?

Ray

COMPILE-FILE.2 & COMPILE-FILE.2A

Sam Steingold — 2010-04-19T22:44:55

The aforementioned tests check that compile-file reports warnings and
style-warnings generated by the code being compiled (as opposed to the
compiler itself) as its secondary and tertiary values.

http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp_fi.htm
The secondary value, warnings-p, is false if no conditions of type
error or warning were detected by the compiler, and true otherwise.
The tertiary value, failure-p, is false if no conditions of type error
or warning (other than style-warning) were detected by the compiler,
and true otherwise.

the tests assume that if the code being compile does something like

(eval-when (:compile-toplevel)
  (define-condition w (warning) nil))
  (warn (make-condition 'w)))

then the compiler must notice this and report this (second value being T).

It seems to me that the spec requires the 2nd and 3rd values to
reflect the signaling from within the compiler, not whatever is
signaled by the code being compiled.

do you agree with my interpretation of the spec?

Patch for syntax.escape test

Raymond Toy — 2010-04-18T23:53:28

I would like to propose the following patch for a few of the
syntax.escape tests.  The tests currently compares the symbol name
against the given string.  Given that cmucl converts the string to NFC
form, the tests fails in a few cases.  This patch changes the test to
compare the symbol name against (find-symbol string).  For all other
lisps that do not modify the string, this should not change anything.

A similar patch could be done for read-symbol tests, but I am not
proposing that; I want those tests to continue to fail on cmucl.

Ray

Index: syntax.lsp
===================================================================
--- syntax.lsp(revision 2163)
+++ syntax.lsp(working copy)
< at >< at > -87,7 +87,7 < at >< at >
           for sym = (and c (read-from-string s))
           unless (or (not c)
                      (and (symbolp sym)
-                          (string= (symbol-name sym) s0)))
+                          (string= (symbol-name sym) (find-symbl s0))))
           collect (progn
                     (when (> (incf count) 100) (loop-finish))
                     (list i c s0 s sym))))
< at >< at > -102,7 +102,7 < at >< at >
         repeat 1000
         unless (or (not c)
                    (and (symbolp sym)
-                        (string= (symbol-name sym) s0)))
+                        (string= (symbol-name sym) (find-symbol s0))))
         collect (list i c s0 s sym))
   nil)
 
< at >< at > -128,7 +128,7 < at >< at >
           for sym = (and c (not bad) (read-from-string s))
           unless (or bad
                      (and (symbolp sym)
-                          (string= (symbol-name sym) s0)))
+                          (string= (symbol-name sym) (find-symbol s0))))
           collect (progn
                     (when (> (incf count) 100) (loop-finish))
                     (list c s0 s sym))))
< at >< at > -144,7 +144,7 < at >< at >
         repeat 1000
         unless (or bad
                    (and (symbolp sym)
-                        (string= (symbol-name sym) s0)))
+                        (string= (symbol-name sym) (find-symbol s0))))
         collect (list c s0 s sym))
   nil)
 
_______________________________________________
ansi-test-devel mailing list
ansi-test-devel< at >common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/ansi-test-devel

phase.[1-3]?

Raymond Toy — 2010-04-18T12:57:27

In the tests phase.1 through phase.3, the argument is rational, but the
tests expect 0.0 for the answer.  Doesn't the rule of float
substitutability allow 0 for the answer?

Ray

read-symbol.13 test?

Raymond Toy — 2010-04-16T21:45:40

In read-symbol.13, the test creates a symbol from a single character and
expects that the symbol-name of the symbol is exactly the same as
specified character.

CMUCL fails this test because intern, make-symbol, and friends convert
the string to Unicode NFC form first.  This conversion usually produces
the same string, but, for example, #\Combining_Grave_Tone_Mark (U+0340)
produces the symbol whose name is #\Combining_Grave_Accent.

I couldn't find anything that says that the string name of the symbol
must be exactly the same as the given string.

Ray

SYNTAX.SHARP-A.4 et al

Sam Steingold — 2010-04-16T17:02:51

I don't see how "2.4.8.12 Sharpsign A" implies that
"#1a#*000110" should be read as #(0 0 0 1 1 0)
and "#1a\"abcd\"" as #(#\a #\b #\c #\d)
It seems that reading those as bit-vectors and strings is just as valid.

Small update for cmucl

Raymond Toy — 2010-04-16T04:22:35

To make some tests pass, cmucl needs to turn off the extension that
ignores extra right parens.

Can someone add the following to doit.lsp?

(setf ext:*ignore-extra-right-parentheses* nil)

Thanks,

Ray

both-case-p and Unicode titlecase?

Raymond Toy — 2010-04-16T04:13:45

What do other implementations do with characters like
Greek_Capital_Letter_Omega_With_Prosgegrammeni?

In cmucl, this character is both-case-p, but is not lower-case-p and is
not upper-case-p.  Instead, it is title-case-p.  char-downcase returns
#\Greek_Small_Letter_Omega_With_Ypogegrammeni.

Issues like this cause cmucl to fail both-case-p.2 test.

Ray

WITH-STANDARD-IO-SYNTAX.23?

Raymond Toy — 2010-04-16T02:36:17

In this test, the expected result is ("FOO" "BAR").  Shouldn't the
expected answer be ("FOO" "CL-TEST::BAR")? 

(princ-to-string 'bar) should print the symbol cl-test::bar with
*package* set to the cl-user package, so package qualifer should be
printed, right?

Ray

extended-char.3.body?

Raymond Toy — 2010-04-15T19:01:28

AFAICT, extended-char.3.body is testing to see that no character is both
a base-char and an extended-char.  If such a character is found, it is
placed on a list and the list is returned.

But the test extended-char.3 expects T as the answer.

That seems not right.  What am I missing?  I must be missing something,
but I just can't see it right now.

Ray

Patch: char-upcase tests return character namesfor failed tests

Raymond Toy — 2010-04-15T13:18:54

Here is a small patch to make char-upcase and friends return the
character names instead of the characters themselves (in case the
external format is not set up correctly to display such characters).

Ray

Index: char-aux.lsp
===================================================================
--- char-aux.lsp    (revision 2157)
+++ char-aux.lsp    (working copy)
< at >< at > -208,7 +208,7 < at >< at >
                      (and
                       (or (lower-case-p x) (eqlt u x))
                       (eqlt u (char-upcase u)))))
-        collect x))
+        collect (char-name x)))
 
 (defun char-upcase.2.body ()
   (loop for i from 0 below (min 65536 char-code-limit)
< at >< at > -218,7 +218,7 < at >< at >
                      (and
                       (or (lower-case-p x) (eqlt u x))
                       (eqlt u (char-upcase u)))))
-        collect x))
+        collect (char-name x)))
 
 (defun char-downcase.1.body ()
   (loop for x in *universe*
< at >< at > -227,7 +227,7 < at >< at >
                      (and
                       (or (upper-case-p x) (eqlt u x))
                       (eqlt u (char-downcase u)))))
-        collect x))
+        collect (char-name x)))
 
 (defun char-downcase.2.body ()
   (loop for i from 0 below (min 65536 char-code-limit)
< at >< at > -237,7 +237,7 < at >< at >
                      (and
                       (or (upper-case-p x) (eqlt u x))
                       (eqlt u (char-downcase u)))))
-        collect x))
+        collect (char-name x)))
 
 (defun both-case-p.1.body ()
   (loop for x in *universe*
< at >< at > -248,7 +248,7 < at >< at >
                                 (lower-case-p x)))
                      (not (or (upper-case-p x)
                               (lower-case-p x)))))
-        collect x))
+        collect (char-name x)))
 
 (defun both-case-p.2.body ()
   (loop for i from 0 below (min 65536 char-code-limit)
< at >< at > -260,14 +260,14 < at >< at >
                                 (lower-case-p x)))
                      (not (or (upper-case-p x)
                               (lower-case-p x)))))
-        collect x))
+        collect (char-name x)))
 
 (defun char-code.2.body ()
   (loop for i from 0 below (min 65536 char-code-limit)
         for c = (code-char i)
         unless (or (not c)
                    (eqlt (char-code c) i))
-        collect c))
+        collect (char-name c)))
 
 (defun char-int.2.fn ()
   (declare (optimize (safety 3) (speed 1) (space 1)))

Multiple loop.10.106 tests

Raymond Toy — 2010-04-15T13:21:39

In loop10.lsp, there are two tests named loop.10.106.  I think they need
different names because they're testing slightly different things.

Ray

STRING-IS-NOT-VECTOR-OF-CHARACTER.1

Raymond Toy — 2010-04-14T16:56:22

CMUCL currently fails that test (and related) tests because base-char
and character are the same.  (I think that's what this test assumes.)

Can someone fix that?

Ray

WITH-STANDARD-IO-SYNTAX must bindPRINT-PPRINT-DISPATCH

Tobias C. Rittweiler — 2009-11-06T20:14:23

Seems obvious, but SBCL doesn't do that (and hence ABCL, too, as its
pprinter stems from SBCL's code base.)

Test case:

    (let ((*print-pprint-dispatch* (copy-pprint-dispatch nil)))
      (set-pprint-dispatch 'symbol #'(lambda (stream obj)
                                       (declare (ignore obj))
                                       (write-string "FOO" stream)))
      (with-standard-io-syntax
        (let ((*print-pretty* t))
          (assert (string= (princ-to-string 'bar) "BAR")))))

Would be cool if someone could add that to the suite as I'm scarce of
time right now.

  -T.

Small change for cmucl

Raymond Toy — 2009-10-16T23:32:21

Can the following be added to doit.lsp for cmucl?

#+cmu
(progn
  (rt:disable-note :nil-vectors-are-strings)
  (setf *ignore-extra-close-parentheses* nil))


May also need to disable :allow-nil-arrays since cmucl doesn't have nil
arrays.

Thanks,

Ray

Some questions on ansi tests

Raymond Toy — 2009-10-16T22:32:44

The test base-string.6 tests (subtypep 'string 'base-string), expecting
NIL, T.

Isn't that incorrect?  Nothing says that string and base-string must be
different types.  They are the same in cmucl.  (And cmucl doesn't have
the weird nil string stuff.)

Also loop.10.106 in loop10.lsp is defined twice, but the tests are
different.

In set-syntax-from-char.lsp, there's a loop that creates some tests
using Newline and Linefeed.  On cmucl, #\newline and #\linefeed are the
same character.  Not a big deal since the test will be the same.

Ray