gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Calling for top ten ANSI issues ...


From: Camm Maguire
Subject: Re: [Gcl-devel] Calling for top ten ANSI issues ...
Date: 21 Sep 2003 22:07:10 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, Paul!

"Paul F. Dietz" <address@hidden> writes:

> Camm Maguire wrote:
> 
> > Greetings!  I think its time to work on this some more.  What are the
> > top ten issues in order of priority revealed by Paul's latest tests?
> 
> Here's a list of ten bugs (or classes of bugs) from the test suite that
> may have a high impact on the test suite.  Take this as advisory only,
> though, and work on what seems easiest to you.
> 
> (BTW, do *not* work on the (array nil) or nil-string tests until
> everything else is out of the way, if then.  My guess is these 'features'
> will be removed from the spec at some point.)
> 
> 
> 1. When a condition is defined, it's not always detected as a subtype
>    of CONDITION.
> 
>     Example:
>     Test CONDITION-1/IS-SUBTYPE-OF/CONDITION failed
>     Form: (SUBTYPEP* 'CONDITION-1 'CONDITION)
>     Expected values: T
>                      T
>     Actual values: NIL
>                    NIL.
> 
> 2. :ALLOW-OTHER-KEYS processing is broken
> 
>     Example: (MAKE-LIST.ALLOW-OTHER-KEYS.4)
> 
>     (MAKE-LIST 5 :ALLOW-OTHER-KEYS T :ALLOW-OTHER-KEYS NIL 'BAD T)
>       Should be: (nil nil nil nil nil)
>       gcl instead: raises an error
>       The *leftmost* occurence of :ALLOW-OTHER-KEYS has priority
>         over later occurences of the same keyword parameter.
> 

OK, this fix is simple if I understand from you correctly what is
supposed to happen -- :allow-other-keys is supposed to allow any other
garbage arguments of any type, not just other possibly unknown keyword
value pairs.  i.e. there is no assumption that keywordp will return
true on the arguments that follow.  Right?  Currently, I believe we
have the 'leftmost' behavior working, but only read allow-other keys
as allowing genuine keywordp-true keywords to pass.

> 3. Some number comparison tests cause the test driver to break.
> 
>     <.4, <=.4, >.4, >=.4 all raise a condition that can't be printed:
> 
>      Test <.4 failed
>      Form: (LOOP
>              FOR
>              (X Y RESULT . REST)
>              IN
>              *NUMBER-LESS-TESTS*
>              UNLESS
>              (IF (< X Y) RESULT (NOT RESULT))
>              COLLECT
>              (LIST* X Y RESULT REST))
>      Expected value: NIL
>      Actual value:
>      Error in EVAL [or a callee]: Can't print a non-number.
> 
>      Fast links are on: do (use-fast-links nil) for debugging
>      Broken at DO-TEST.  Type :H for Help.
>       1 (Abort) Return to top level.
>      dbl:CL-TEST>>
> 

As in the earlier email, the problem is with (float
most-positive-double-float 1.0s0), and I'm not sure what is supposed
to be returned here.  But apart from this, should we be printing Nans
and Infs?  Is there an ANSI format for these?

> 4. Builtin method combinations aren't working.
> 
>     See the DEFGENERIC-METHOD-COMBINATION* tests, as well as the CPL
>     tests (which use a nonstandard builtin method combination.)
> 
> 5. LOOP errors
> 
>     These can probably be fixed by using the CMUCL or SBCL LOOP macro.
> 

We are actually using a cmucl version currently from late 2002.  I see
there have been recent updates, perhaps in response to your tests?
I'll try grabbing the latest, unless you tell me of a preferred
version. 


More later,

> 6. Numerous error cases not properly handled.
> 
>     Many list functions, for example, are required to signal a type error
>    if the list argument is not a proper list (see many of the error cases
>    in tests loaded from load-cons.lsp.)
> 
> 7. The function SIMPLE-CONDITION-FORMAT-CONTROL isn't defined, and
>    SIMPLE-ERROR doesn't admit a :FORMAT-CONTROL initialization argument.
>    (There's much more condition-related breakage, but I haven't gone
>     through that in detail.)
> 
> 8. (SETF <symbol>) should be a valid function name.
> 
> 9. PARSE-INTEGER should produce PARSE-ERRORs, not STREAM-ERRORs.
> 
> 10. I've put together a random stress tester (see random-int-form.lsp).
>    This is having great impact on flushing out compiler bugs in other
>    lisps, but I can't get it to run anything in gcl.  Could this be fixed?
> 
> 
> Finally: BROADCAST-STREAM isn't defined, but I haven't written stream
> tests yet.  This is breaking a few tests of other things.
> 
>       Paul
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]