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

[Camm Maguire]

Greetings!

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

> 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.)
> 

OK, am happy to report some recently checked in (to cvs HEAD) changes
supporting (setf ...) function names, which together with attending
pcl fixes, has removed many defgeneric and method-combination test
failures.

1) I happened across some old posts by Peter Wood on this issue before
   he left the project.  His strategy was to add a new setf function
   definition element to each symbol -- instead, I've opted (so far)
   for pushing the function onto the symbol's plist to save space.  Of
   course the other way is faster in general, but I'm not sure by how
   much.  Thoughts appreciated.

2) Paul, I had to change one of your test files --
   clas-precedence-lists.lsp: 

Index: ansi-tests/class-precedence-lists.lsp
===================================================================
RCS file: /cvsroot/gcl/gcl/ansi-tests/class-precedence-lists.lsp,v
retrieving revision 1.7
diff -u -r1.7 class-precedence-lists.lsp
--- ansi-tests/class-precedence-lists.lsp       12 Jul 2003 13:46:01 -0000      
1.7
+++ ansi-tests/class-precedence-lists.lsp       7 Oct 2003 19:45:59 -0000
@@ -8,10 +8,11 @@
 (eval-when (:load-toplevel :compile-toplevel :execute)
   (unless #| (fboundp 'class-precedence-list) |# nil
     (report-and-ignore-errors
-      (defgeneric class-precedence-list (x)
+      (defgeneric class-precedence-list-foo (x)
        (:method-combination list)
        .
        #.(loop for s in *cl-types-that-are-classes-symbols*
+               when (ignore-errors (pcl::find-class-from-cell s 
(pcl::find-class-cell s)))
                collect
                `(:method list ((x ,s)) ',s))))))
 
@@ -27,7 +28,7 @@
                                        "-CPL")
                           :cl-test))
        (let* ((obj ,objform)
-             (cpl (class-precedence-list obj)))
+             (cpl (class-precedence-list-foo obj)))
         (or ,(if ordered
                  nil
                `(and (not (eql (class-of obj) (find-class ',(first 
expected-cpl))))

        
        GCL doesn't yet define all the classes, so the defgeneric
        definition never occurred in the old version.  There are
        separate problems with trying to overwrite the standard
        defgeneric definition for class-precedence-list, so I made a
        dummy name which works fine.  The aim of the test is still
        achieved -- undefined classes show as test failures, but the
        working cases don't needlessly fail do to the defgeneric
        failure.  Actually, the original version resulted in a strange
        loop in pcl which I could not track down and which overflowed
        the value stack.

3)  I think we could benefit from resurrecting the #+new-kcl-wrapper
    options in PCL.  cmucl implements wrappers with a structure, and
    it appeared that kcl could at one time too.

4) The diffs with cmucl's pcl tree are actually quite manageable.  I
   think we should work toward merging their mods into ours, but I'd
   like to leave in the #= options for a while until we're sure all is
   working.

5) Several pseudo-functions were defined via 'inlines' in
   pcl_gcl_low.lisp which relied on the optimizer inserting inlined
   code -- i.e. there were no real function definitions which were
   skipped by the optimizer at all!  Mike ran into this when he tried
   to compile with safety settings.  I've added a few of these which
   enabled me to load pcl on an interpreted basis into saved_mod_gcl.
   I haven't yet tested a safety pcl compile, but we certainly should
   be a lot closer now.  Unfortunately, building an interpreted pcl
   takes forever due to the involved walking algorithm.  

6) Following on 5), so far pcl_fin.lisp in particular must be built at
   present with optimization.  This is because the low level closure
   environment manipulating routines in pcl_gcl_low.lisp only work at
   present on compiled closures.  Should be straightforward to extend
   the relevant functions to handle (lamda ...)'s, but I'm not sure if
   this is particularly important at this stage.

7) 928 failures are now down to:

717 out of 14000 total tests failed: COMMON-LISP-USER-PACKAGE-NICKNAMES, 
    
   at least for me.

Take care,

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