From: <log...@gm...> - 2008-12-31 10:25:56
Attachments:
patchCTF11519.patch
|
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. > |
From: Ville V. <vil...@gm...> - 2008-12-31 10:50:13
|
On Wed, Dec 31, 2008 at 12:26 PM, <log...@gm...> wrote: > The bad news it starts failing DISASSEMBLE.4?! :< > Although SIMPLE-ERRORs at at least least are simple to track down .. maybe > you guys know something I forgot in the patch. I'm just wondering where the lambdaName and lambdaList should be coming from. The Primitive you patched is FUNCTION_LAMBDA_EXPRESSION, which seems to be used in the DISASSEMBLE.5 (it's 5, not 4, that fails). Then again, that bit of code seems to tolerate a null name just fine, so I don't know exactly what's wrong here. |