Re: [j-devel] The plan to fix DEFUN.* and LABELS.* (compiled) ansitests

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Ok, here is a patch the works on trunk/abcl At revision 11519.

a) It eliminates CompiledClosure (renamed it to CompiledClosureXXX) just to make sure it's never used before SVN removal.
b) It eliminates setPropertyList(list2(Symbol.CLASS_BYTES, classBytes));  Since the classbytes should be on the clone anyways.
c) It simply clones the CTF instead of wrapping in a CC

First, here is the l --eval '(load "compileit.lsp")' with the 11519 for a sanity test.

45 out of 21704 total tests failed:
(DEFINE-SETF-EXPANDER.1
DEFINE-SETF-EXPANDER.6
DEFINE-SETF-EXPANDER.7
CATCH.6
DEFUN.6
DEFUN.7
LABELS.7C
LABELS.7D
REINITIALIZE-INSTANCE.ERROR.1
SHARED-INITIALIZE.ERROR.4
CHANGE-CLASS.1.11
CHANGE-CLASS.ERROR.4
MAKE-INSTANCE.ERROR.3
MAKE-INSTANCE.ERROR.4
DEFGENERIC.ERROR.20
DEFGENERIC.ERROR.21
DEFGENERIC.30
CALL-NEXT-METHOD.ERROR.1
CALL-NEXT-METHOD.ERROR.2
DEFMETHOD.ERROR.14
DEFMETHOD.ERROR.15
MAKE-CONDITION.3
MAKE-CONDITION.4
DELETE-PACKAGE.5
DELETE-PACKAGE.6
MAP.48
TYPE-OF.1
PRINT.RANDOM-STATE.1
PPRINT-FILL.14
PPRINT-FILL.15
PPRINT-LINEAR.14
PPRINT-TABULAR.13
PPRINT-LOGICAL-BLOCK.17
PPRINT-POP.7
PPRINT-POP.8
FORMAT.C.4A
FORMATTER.C.4A
FORMAT.LOGICAL-BLOCK.CIRCLE.1
FORMAT.LOGICAL-BLOCK.CIRCLE.2
FORMAT.LOGICAL-BLOCK.CIRCLE.3
COMPILE-FILE.17
COMPILE-FILE.18
LOAD-PATHNAME.1
LOAD-TRUENAME.1
TRACE.8)
248.295 seconds real time
36991294 cons cells

Now with the PATCH
[root@titan abcl]# patch -p0 < patchCTF11519.patch
patching file src/org/armedbear/lisp/CompiledClosure.java
patching file src/org/armedbear/lisp/compiler-pass2.lisp
patching file src/org/armedbear/lisp/ClosureTemplateFunction.java
patching file src/org/armedbear/lisp/Lisp.java
patching file src/org/armedbear/lisp/Primitives.java

46 out of 21704 total tests failed:
(DEFINE-SETF-EXPANDER.1
DEFINE-SETF-EXPANDER.6
DEFINE-SETF-EXPANDER.7
CATCH.6
DEFUN.6
DEFUN.7
LABELS.7C
LABELS.7D
REINITIALIZE-INSTANCE.ERROR.1
SHARED-INITIALIZE.ERROR.4
CHANGE-CLASS.1.11
CHANGE-CLASS.ERROR.4
MAKE-INSTANCE.ERROR.3
MAKE-INSTANCE.ERROR.4
DEFGENERIC.ERROR.20
DEFGENERIC.ERROR.21
DEFGENERIC.30
CALL-NEXT-METHOD.ERROR.1
CALL-NEXT-METHOD.ERROR.2
DEFMETHOD.ERROR.14
DEFMETHOD.ERROR.15
MAKE-CONDITION.3
MAKE-CONDITION.4
DELETE-PACKAGE.5
DELETE-PACKAGE.6
MAP.48
TYPE-OF.1
PRINT.RANDOM-STATE.1
PPRINT-FILL.14
PPRINT-FILL.15
PPRINT-LINEAR.14
PPRINT-TABULAR.13
PPRINT-LOGICAL-BLOCK.17
PPRINT-POP.7
PPRINT-POP.8
FORMAT.C.4A
FORMATTER.C.4A
FORMAT.LOGICAL-BLOCK.CIRCLE.1
FORMAT.LOGICAL-BLOCK.CIRCLE.2
FORMAT.LOGICAL-BLOCK.CIRCLE.3
COMPILE-FILE.17
COMPILE-FILE.18
LOAD-PATHNAME.1
LOAD-TRUENAME.1
DISASSEMBLE.5
TRACE.8)
247.654 seconds real time
38008876 cons cells

The bad news it starts failing DISASSEMBLE.4?! :<

 DISASSEMBLE.4
Test DISASSEMBLE.5 failed
Form: (DISASSEMBLE-IT (FUNCALL (COMPILE NIL (QUOTE (LAMBDA NIL (LET ((X 0)) (FUNCTION (LAMBDA NIL (INCF X)))))))))
Expected values: T
                 NIL
Actual value: #<SIMPLE-ERROR {5CA5C369}>.

Although SIMPLE-ERRORs at at least least are simple to track down .. maybe you guys know something I forgot in the patch.

----- Original Message ----- 
From: <dm...@us...>
To: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; "Ville Voutilainen" <vil...@gm...>; "Mark Evenson" <ev...@pa...>
Cc: <arm...@li...>
Sent: Tuesday, December 30, 2008 6:09 PM
Subject: Re: [j-devel] The plan to fix DEFUN.* and LABELS.* (compiled) ansitests

> Sorry I missed everyone on irc today!
>
> I might be not really here tommorow even though my irc nick will be there.  We'll see though..
> We all have strange timezones that make us somehow intersect.
>
> When I get back in a couple days  I think I see how to get CompileTemplateFunctions (CTFs) to do the correct thing and act more 
> like CompliledClosures (CCs).
> Usually CCs just wrap a CTF and do nothing usefull on their own. Except they allow its own context field to override the CTF it 
> wraps.
> So anyway pretty much am sure know how to fix the clone() thing work and pass the tests.. Just the new years holiday is holding me 
> hostage. :)
>
>
> ----- Original Message ----- 
> From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> To: <dm...@us...>
> Cc: "Ville Voutilainen" <vil...@gm...>; <arm...@li...>
> Sent: Tuesday, December 30, 2008 4:43 AM
> Subject: Re: [j-devel] The plan to fix DEFUN.* and LABELS.* (compiled) ansitests
>
>
>> On Tue, Dec 30, 2008 at 1:28 PM,  <log...@gm...> wrote:
>>> I am about to read the this thread but I wanted to get my 2 cents in. At
>>>
>>> I am going to suggest for sanity test.. leave the compiler-pass[1|2].lisp as
>>> it is the trunk this will make it continue to call
>>> Lisp.makeCompileClosure(....) then change the code in the Lisp.java file to
>>> try out your cloneing ideas.. once you have it nailed down.. then go ahead
>>> and write the bytecode to do what works.. but confirm it does the right
>>> thing first from the .java file
>>>
>>>
>>> Current CODE:
>>>
>>>  public static final LispObject makeCompiledClosure(LispObject template,
>>> LispObject[] context)
>>>   throws ConditionThrowable
>>>  {
>>>   ClosureTemplateFunction ctf = (ClosureTemplateFunction) template;
>>>   CompiledClosure result = new CompiledClosure(ctf, context);
>>>   LispObject classBytes =
>>>     getf(ctf.getPropertyList(), Symbol.CLASS_BYTES, NIL);
>>>   if (classBytes != NIL)
>>>     result.setPropertyList(list2(Symbol.CLASS_BYTES, classBytes));
>>>   return result;
>>>  }
>>>
>>>
>>> I  tried this myself but I could not wrap my head arround how we switch
>>> gears from CompiledClosure to CompiledTemplateFunction.
>>>
>>>
>>>  public static final LispObject makeCompiledClosure(LispObject template,
>>> LispObject[] context)
>>>   throws ConditionThrowable
>>>  {
>>>   ClosureTemplateFunction result  = ((ClosureTemplateFunction)
>>> template).dup(); // alias to clone()
>>>   result .setContext(context);
>>>   return result;
>>>  }
>>>
>>> Cloning the CompiledTemplateFunction and then setContext was still not
>>> sufficent to passing the tests.
>>
>> Which is basically my question: both CompiledClosure and
>> ClosureTemplateFunction inherit from Function (the latter through
>> Closure). So, Since CompiledClosure only overrides methods, they
>> specify the same interface.
>>
>> So, from the perspective of the class hierarchy, I'm not expecting surprises.
>>
>> Bye,
>>
>> Erik.
> 