[armedbear-devel] The value :LONG is not of type (MEMBER NIL :BOOLEAN)
Hi, ABCL developers I found my program have some CLOS code which could get the weakness of ABCL ... It's cl-net-snmp [1], which I just release a whole new version few days ago. My goal on ABCL is to make sure the server-side version (a pure Lisp SNMP Agent) run as a separated thread in JVM, so that people can use my program to remotely monitor any Java (or ABCL) servers. (I know some ABCL people are fixing bordeaux-threads, I'm watching this work and hope it could be done soon) Now I need help. If one could spend 5 minutes do a SVN checkout of the release branch: https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6 and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN). I have no idea how to fix it. Regards, Chun Tian (binghe) [1] http://common-lisp.net/project/cl-net-snmp/snmp.html Below are the error outputs when compiling a lisp file from cl-net-snmp: #<THREAD "interpreter" {24CCF86}>: Debugger invoked on condition of type TYPE-ERROR The value :LONG is not of type (MEMBER NIL :BOOLEAN). Restarts: 0: TRY-RECOMPILING Try recompiling pdu 1: RETRY Retry compiling component ("snmp" "pdu"). 2: ACCEPT Continue, treating compiling component ("snmp" "pdu") as having been successful. 3: TOP-LEVEL Return to top level. [1] SNMP(2): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {6BA52C90}>) 2: (JVM::COMPILE-FORM #<JVM::LET/LET*-NODE {2910D926}> JVM::STACK :LONG) 3: (JVM:COMPILE-DEFUN NIL (LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) NIL "/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/packages/snmp/ASDF_TMP_pdu_6.cls" #<FILE-STREAM {6539DEFE}> NIL) 4: (#<FUNCTION {753896F2}>) 5: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {753896F2}>) 6: (SYSTEM::C-E-M-1 (MOP::ENSURE-METHOD 'SNMP::GENERATE-REQUEST-ID :LAMBDA-LIST '(SNMP::PDU) :QUALIFIERS 'NIL :SPECIALIZERS (LIST 'SNMP::COMMON-PDU) :FUNCTION #'(LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FAST-FUNCTION #'(LAMBDA (SNMP::PDU) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FUNCTION) 7: (SYSTEM::CONVERT-ENSURE-METHOD (MOP::ENSURE-METHOD 'SNMP::GENERATE-REQUEST-ID :LAMBDA-LIST '(SNMP::PDU) :QUALIFIERS 'NIL :SPECIALIZERS (LIST 'SNMP::COMMON-PDU) :FUNCTION #'(LAMBDA (MOP::ARGS MOP::NEXT-EMFUN) (DECLARE (IGNORE MOP::NEXT-EMFUN)) (LET ((SNMP::PDU (%CAR MOP::ARGS))) (DECLARE (IGNORABLE SNMP::PDU)) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))) :FAST-FUNCTION #'(LAMBDA (SNMP::PDU) (DECLARE (IGNORABLE SNMP::PDU)) (BLOCK SNMP::GENERATE-REQUEST-ID (WITH-SLOTS (SNMP::REQUEST-ID-COUNTER) SNMP::PDU (THE (UNSIGNED-BYTE 32) (LOGAND (PORTABLE-THREADS:ATOMIC-INCF SNMP::REQUEST-ID-COUNTER) 4294967295)))))))
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote: […]
Now I need help. If one could spend 5 minutes do a SVN checkout of the release branch:
https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6
and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN).
I have reproduced your error with ABCL trunk.
I have no idea how to fix it.
It is not immediately clear whether this is actually CLOS or the compiler, as the file seems to eval without errors. We'll need a little time to investigate but hopefully we'll have you on your way to SNMP land in Java via CL in no time… Thanks for the bug report. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Hi, Mark The problem definition in the pdu.lisp is this two: #-portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (incf request-id-counter) #xffffffff)))) #+portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (portable-threads:atomic-incf request-id-counter) #xffffffff)))) The only difference between two versions, is the use of INCF being replaced to ATOMIC-INCF, which is a thread-safe version of INCF. If I always use the first version in ABCL (there's another similar method in message.lisp), than ABCL can pass this, and directly goes to the second issue (it's definitely CLOS related, I think)... I wrote some basic extension code for GBBopen's portable-threads.lisp to support threading in ABCL (no cond var), and the form (portable-threads:atomic-incf request-id-counter) will be macro-expanded into (PORTABLE-THREADS:AS-ATOMIC-OPERATION (INCF REQUEST-ID-COUNTER 1)) then (PORTABLE-THREADS:WITH-LOCK-HELD (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1)) and then (simplified) (THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1)) Consider ATOMIC-INCF itself works just right. I think maybe ABCL compiler cannot handle a macro form inside method definition quite well, shouldn't be CLOS/MOP's fault. Hope this helps. Regards, Chun Tian (binghe) 在 2011-3-21，00:17， Mark Evenson 写道：
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote:
[…]
Now I need help. If one could spend 5 minutes do a SVN checkout of the release branch:
https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6
and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN).
I have reproduced your error with ABCL trunk.
I have no idea how to fix it.
It is not immediately clear whether this is actually CLOS or the compiler, as the file seems to eval without errors. We'll need a little time to investigate but hopefully we'll have you on your way to SNMP land in Java via CL in no time…
Thanks for the bug report.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Mark
The problem definition in the pdu.lisp is this two:
#-portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (incf request-id-counter) #xffffffff))))
#+portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (portable-threads:atomic-incf request-id-counter) #xffffffff))))
The only difference between two versions, is the use of INCF being replaced to ATOMIC-INCF, which is a thread-safe version of INCF.
If I always use the first version in ABCL (there's another similar method in message.lisp), than ABCL can pass this, and directly goes to the second issue (it's definitely CLOS related, I think)...
I wrote some basic extension code for GBBopen's portable-threads.lisp to support threading in ABCL (no cond var), and the form
(portable-threads:atomic-incf request-id-counter)
will be macro-expanded into
(PORTABLE-THREADS:AS-ATOMIC-OPERATION (INCF REQUEST-ID-COUNTER 1))
then
(PORTABLE-THREADS:WITH-LOCK-HELD (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
and then (simplified)
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
Consider ATOMIC-INCF itself works just right. I think maybe ABCL compiler cannot handle a macro form inside method definition quite well, shouldn't be CLOS/MOP's fault.
I don't think this has anything to do with CLOS at all, it's probably some bug in the compilation of the logand form.
Hi, Alessio Thank you for pointing out this. You're right. IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass. The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file: ; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ... ; Compilation unit finished ; Caught 1 STYLE-WARNING condition java.lang.VerifyError: (class: org/armedbear/lisp/ASDF_TMP_snmp_get_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Register 4 contains wrong type at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.newInstance0(Class.java:326) at java.lang.Class.newInstance(Class.java:308) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:111) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:149) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:547) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:542) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Load.faslLoadStream(Load.java:608) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:414) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:547) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Load.loadStream(Load.java:575) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:531) at org.armedbear.lisp.Load.load(Load.java:198) at org.armedbear.lisp.Load.load(Load.java:683) at org.armedbear.lisp.Load$_load.execute(Load.java:633) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:688) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2799) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.map_1.execute(map.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:670) at org.armedbear.lisp.asdf_389.execute(asdf.lisp:1965) at org.armedbear.lisp.clos_308.execute(clos.lisp:1950) at org.armedbear.lisp.clos_287.execute(clos.lisp:1718) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_391.execute(asdf.lisp:1972) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.clos_312.execute(clos.lisp:2064) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.asdf_394.execute(asdf.lisp:1975) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.asdf_396.execute(asdf.lisp:1975) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2802) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_393.execute(asdf.lisp:1975) at org.armedbear.lisp.clos_310.execute(clos.lisp:2059) at org.armedbear.lisp.clos_287.execute(clos.lisp:1718) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_448.execute(asdf.lisp:2105) at org.armedbear.lisp.compiler_pass2_374.execute(compiler-pass2.lisp:7474) at org.armedbear.lisp.LispThread.execute(LispThread.java:620) at org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1228) at org.armedbear.lisp.Symbol.execute(Symbol.java:790) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7474) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:790) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.asdf_447.execute(asdf.lisp:2105) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2802) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_446.execute(asdf.lisp:2105) at org.armedbear.lisp.clos_308.execute(clos.lisp:1950) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.clos_297.execute(clos.lisp:1884) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.clos_290.execute(clos.lisp:1718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Lisp.funcall(Lisp.java:166) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2850) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:688) at org.armedbear.lisp.asdf_462.execute(asdf.lisp:2171) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Lisp.progn(Lisp.java:674) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3741) at org.armedbear.lisp.Lisp.eval(Lisp.java:495) at org.armedbear.lisp.Lisp.progn(Lisp.java:674) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:484) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:276) at org.armedbear.lisp.Symbol.execute(Symbol.java:790) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.Symbol.execute(Symbol.java:780) at org.armedbear.lisp.LispThread.execute(LispThread.java:620) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:620) at org.armedbear.lisp.Interpreter.run(Interpreter.java:353) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:680) #<THREAD "interpreter" {2FEE9422}>: Debugger invoked on condition of type ERROR Caught java.lang.VerifyError: (class: org/armedbear/lisp/ASDF_TMP_snmp_get_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Register 4 contains wrong type. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(10): :bt 16 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<ERROR {27E33378}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:373) 3: org.armedbear.lisp.Lisp$1.execute(Lisp.java:305) 4: org.armedbear.lisp.Symbol.execute(Symbol.java:790) 5: org.armedbear.lisp.LispThread.execute(LispThread.java:636) 6: org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:780) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:620) 10: org.armedbear.lisp.top_level_51.execute(top-level.lisp:423) 11: org.armedbear.lisp.LispThread.execute(LispThread.java:620) 12: org.armedbear.lisp.Interpreter.run(Interpreter.java:353) 13: org.armedbear.lisp.Main$1.run(Main.java:48) 14: java.lang.Thread.run(Thread.java:680) 15: (APPLY #<FUNCTION {1785F0D}> (#<ASDF:COMPILE-OP NIL {5A84F3C}> #<ASDF:CL-SOURCE-FILE "snmp" "snmp-get">)) Do you have any idea about this? i.e. What's "Register 4"? --binghe 在 2011-3-21，18:54， Alessio Stalla 写道：
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Mark
The problem definition in the pdu.lisp is this two:
#-portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (incf request-id-counter) #xffffffff))))
#+portable-threads (defmethod generate-request-id ((pdu common-pdu)) (with-slots (request-id-counter) pdu (the (unsigned-byte 32) (logand (portable-threads:atomic-incf request-id-counter) #xffffffff))))
The only difference between two versions, is the use of INCF being replaced to ATOMIC-INCF, which is a thread-safe version of INCF.
If I always use the first version in ABCL (there's another similar method in message.lisp), than ABCL can pass this, and directly goes to the second issue (it's definitely CLOS related, I think)...
I wrote some basic extension code for GBBopen's portable-threads.lisp to support threading in ABCL (no cond var), and the form
(portable-threads:atomic-incf request-id-counter)
will be macro-expanded into
(PORTABLE-THREADS:AS-ATOMIC-OPERATION (INCF REQUEST-ID-COUNTER 1))
then
(PORTABLE-THREADS:WITH-LOCK-HELD (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
and then (simplified)
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
Consider ATOMIC-INCF itself works just right. I think maybe ABCL compiler cannot handle a macro form inside method definition quite well, shouldn't be CLOS/MOP's fault.
I don't think this has anything to do with CLOS at all, it's probably some bug in the compilation of the logand form.
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Alessio
Thank you for pointing out this. You're right. IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass.
The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file:
; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ...
; Compilation unit finished ; Caught 1 STYLE-WARNING condition
java.lang.VerifyError: (class: org/armedbear/lisp/ASDF_TMP_snmp_get_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Register 4 contains wrong type at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.newInstance0(Class.java:326) at java.lang.Class.newInstance(Class.java:308) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:111) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:149) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:547) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:542) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Load.faslLoadStream(Load.java:608) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:414) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:547) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Load.loadStream(Load.java:575) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:531) at org.armedbear.lisp.Load.load(Load.java:198) at org.armedbear.lisp.Load.load(Load.java:683) at org.armedbear.lisp.Load$_load.execute(Load.java:633) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:688) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2799) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.map_1.execute(map.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.Symbol.execute(Symbol.java:813) at org.armedbear.lisp.LispThread.execute(LispThread.java:670) at org.armedbear.lisp.asdf_389.execute(asdf.lisp:1965) at org.armedbear.lisp.clos_308.execute(clos.lisp:1950) at org.armedbear.lisp.clos_287.execute(clos.lisp:1718) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_391.execute(asdf.lisp:1972) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.clos_312.execute(clos.lisp:2064) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.asdf_394.execute(asdf.lisp:1975) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.asdf_396.execute(asdf.lisp:1975) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2802) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_393.execute(asdf.lisp:1975) at org.armedbear.lisp.clos_310.execute(clos.lisp:2059) at org.armedbear.lisp.clos_287.execute(clos.lisp:1718) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_448.execute(asdf.lisp:2105) at org.armedbear.lisp.compiler_pass2_374.execute(compiler-pass2.lisp:7474) at org.armedbear.lisp.LispThread.execute(LispThread.java:620) at org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1228) at org.armedbear.lisp.Symbol.execute(Symbol.java:790) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7474) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:790) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.asdf_447.execute(asdf.lisp:2105) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2802) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.asdf_446.execute(asdf.lisp:2105) at org.armedbear.lisp.clos_308.execute(clos.lisp:1950) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.clos_297.execute(clos.lisp:1884) at org.armedbear.lisp.Symbol.execute(Symbol.java:801) at org.armedbear.lisp.clos_290.execute(clos.lisp:1718) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.LispThread.execute(LispThread.java:653) at org.armedbear.lisp.Lisp.funcall(Lisp.java:166) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2850) at org.armedbear.lisp.Primitive.execute(Primitive.java:148) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:688) at org.armedbear.lisp.asdf_462.execute(asdf.lisp:2171) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:505) at org.armedbear.lisp.Lisp.progn(Lisp.java:674) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3741) at org.armedbear.lisp.Lisp.eval(Lisp.java:495) at org.armedbear.lisp.Lisp.progn(Lisp.java:674) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:484) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:276) at org.armedbear.lisp.Symbol.execute(Symbol.java:790) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.Symbol.execute(Symbol.java:780) at org.armedbear.lisp.LispThread.execute(LispThread.java:620) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:620) at org.armedbear.lisp.Interpreter.run(Interpreter.java:353) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:680) #<THREAD "interpreter" {2FEE9422}>: Debugger invoked on condition of type ERROR Caught java.lang.VerifyError: (class: org/armedbear/lisp/ASDF_TMP_snmp_get_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Register 4 contains wrong type. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(10): :bt 16
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<ERROR {27E33378}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:373) 3: org.armedbear.lisp.Lisp$1.execute(Lisp.java:305) 4: org.armedbear.lisp.Symbol.execute(Symbol.java:790) 5: org.armedbear.lisp.LispThread.execute(LispThread.java:636) 6: org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:780) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:620) 10: org.armedbear.lisp.top_level_51.execute(top-level.lisp:423) 11: org.armedbear.lisp.LispThread.execute(LispThread.java:620) 12: org.armedbear.lisp.Interpreter.run(Interpreter.java:353) 13: org.armedbear.lisp.Main$1.run(Main.java:48) 14: java.lang.Thread.run(Thread.java:680) 15: (APPLY #<FUNCTION {1785F0D}> (#<ASDF:COMPILE-OP NIL {5A84F3C}> #<ASDF:CL-SOURCE-FILE "snmp" "snmp-get">))
Do you have any idea about this? i.e. What's "Register 4"?
It's a JVM register, used to hold some intermediate result. The compiler is producing incorrect code: probably it doesn't derive the right type for the atomic-incf form. I see that (THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1)) expands to (LET ((#:G3433 PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*)) (WHEN (THREADS:GET-MUTEX #:G3433) (UNWIND-PROTECT (PROGN (INCF REQUEST-ID-COUNTER 1)) (THREADS:RELEASE-MUTEX #:G3433)))) Maybe there's a problem with the derived type of unwind-protect forms, but I don't have the source at hand now to check. Alessio
Hi, Alesio Oh, sorry, maybe I didn't say it clearly, the "Register 4 contains wrong type" is not produced by the file with THREADS:WITH-MUTEX. It's another issue, not relevant to the first post in this mail thread. Following function caused the "Register 4 contains wrong type" issue: (defun generate-table (vars vbs non-repeaters max-repetitions) (declare (type fixnum non-repeaters max-repetitions)) (let* ((var-number (list-length vars)) (n (min non-repeaters var-number)) (m max-repetitions) (r (max (- var-number n) 0)) (real-vbs (mapcar #'(lambda (x) (coerce x 'list)) (coerce vbs 'list))) result-table) ;; non-repeaters (dotimes (i n) (push (pop real-vbs) result-table)) ;; table (when (and (plusp m) (plusp r)) (dotimes (i m) (push (let (record) (dotimes (j r (nreverse record)) (push (pop real-vbs) record))) result-table))) (values (nreverse result-table) (mapcar #'oid vars)))) If I temporary disable it by #+ignore or #-abcl, than the whole project compiles with no error any more. I'll try to continue look for which exactly form in this function caused the error. Regards, Chun Tian (binghe) 在 2011-3-21，19:21， Alessio Stalla 写道：
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Alessio
Thank you for pointing out this. You're right. IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass.
The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file:
; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ...
Do you have any idea about this? i.e. What's "Register 4"?
It's a JVM register, used to hold some intermediate result. The compiler is producing incorrect code: probably it doesn't derive the right type for the atomic-incf form. I see that
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
expands to
(LET ((#:G3433 PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*)) (WHEN (THREADS:GET-MUTEX #:G3433) (UNWIND-PROTECT (PROGN (INCF REQUEST-ID-COUNTER 1)) (THREADS:RELEASE-MUTEX #:G3433))))
Maybe there's a problem with the derived type of unwind-protect forms, but I don't have the source at hand now to check.
Alessio
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Alesio
Oh, sorry, maybe I didn't say it clearly, the "Register 4 contains wrong type" is not produced by the file with THREADS:WITH-MUTEX. It's another issue, not relevant to the first post in this mail thread.
Ah, sorry, I misunderstood. As a quick experiment, you might try removing the type declarations; but I'm really just speculating. Hopefully I'll find some time to investigate it this evening. Bye Alessio
Following function caused the "Register 4 contains wrong type" issue:
(defun generate-table (vars vbs non-repeaters max-repetitions) (declare (type fixnum non-repeaters max-repetitions)) (let* ((var-number (list-length vars)) (n (min non-repeaters var-number)) (m max-repetitions) (r (max (- var-number n) 0)) (real-vbs (mapcar #'(lambda (x) (coerce x 'list)) (coerce vbs 'list))) result-table) ;; non-repeaters (dotimes (i n) (push (pop real-vbs) result-table)) ;; table (when (and (plusp m) (plusp r)) (dotimes (i m) (push (let (record) (dotimes (j r (nreverse record)) (push (pop real-vbs) record))) result-table))) (values (nreverse result-table) (mapcar #'oid vars))))
If I temporary disable it by #+ignore or #-abcl, than the whole project compiles with no error any more. I'll try to continue look for which exactly form in this function caused the error.
Regards,
Chun Tian (binghe)
在 2011-3-21，19:21， Alessio Stalla 写道：
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Alessio
Thank you for pointing out this. You're right. IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass.
The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file:
; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ...
Do you have any idea about this? i.e. What's "Register 4"?
It's a JVM register, used to hold some intermediate result. The compiler is producing incorrect code: probably it doesn't derive the right type for the atomic-incf form. I see that
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
expands to
(LET ((#:G3433 PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*)) (WHEN (THREADS:GET-MUTEX #:G3433) (UNWIND-PROTECT (PROGN (INCF REQUEST-ID-COUNTER 1)) (THREADS:RELEASE-MUTEX #:G3433))))
Maybe there's a problem with the derived type of unwind-protect forms, but I don't have the source at hand now to check.
Alessio
God, you're right again ... I removed the type declaration and everything goes fine now ... --binghe 在 2011-3-21，19:45， Alessio Stalla 写道：
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Alesio
Oh, sorry, maybe I didn't say it clearly, the "Register 4 contains wrong type" is not produced by the file with THREADS:WITH-MUTEX. It's another issue, not relevant to the first post in this mail thread.
Ah, sorry, I misunderstood. As a quick experiment, you might try removing the type declarations; but I'm really just speculating. Hopefully I'll find some time to investigate it this evening.
Bye Alessio
Following function caused the "Register 4 contains wrong type" issue:
(defun generate-table (vars vbs non-repeaters max-repetitions) (declare (type fixnum non-repeaters max-repetitions)) (let* ((var-number (list-length vars)) (n (min non-repeaters var-number)) (m max-repetitions) (r (max (- var-number n) 0)) (real-vbs (mapcar #'(lambda (x) (coerce x 'list)) (coerce vbs 'list))) result-table) ;; non-repeaters (dotimes (i n) (push (pop real-vbs) result-table)) ;; table (when (and (plusp m) (plusp r)) (dotimes (i m) (push (let (record) (dotimes (j r (nreverse record)) (push (pop real-vbs) record))) result-table))) (values (nreverse result-table) (mapcar #'oid vars))))
If I temporary disable it by #+ignore or #-abcl, than the whole project compiles with no error any more. I'll try to continue look for which exactly form in this function caused the error.
Regards,
Chun Tian (binghe)
在 2011-3-21，19:21， Alessio Stalla 写道：
2011/3/21 Chun Tian (binghe) <binghe.lisp@gmail.com>:
Hi, Alessio
Thank you for pointing out this. You're right. IF I temporary removed the LOGAND form and just return the inner ATOMIC-INCF form, then everything goes well, compilation can pass.
The next issue happens in a file which has some method definitions, ABCL report "Register 4 contains wrong type" when loading a just compiled .abcl file:
; Loading #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13251-fasl37-macosx-java/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp-get.abcl" ...
Do you have any idea about this? i.e. What's "Register 4"?
It's a JVM register, used to hold some intermediate result. The compiler is producing incorrect code: probably it doesn't derive the right type for the atomic-incf form. I see that
(THREADS:WITH-MUTEX (PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*) (INCF REQUEST-ID-COUNTER 1))
expands to
(LET ((#:G3433 PORTABLE-THREADS::*ATOMIC-OPERATION-LOCK*)) (WHEN (THREADS:GET-MUTEX #:G3433) (UNWIND-PROTECT (PROGN (INCF REQUEST-ID-COUNTER 1)) (THREADS:RELEASE-MUTEX #:G3433))))
Maybe there's a problem with the derived type of unwind-protect forms, but I don't have the source at hand now to check.
Alessio
Continue narrow down the problem, it's caused by this part in the function:
(dotimes (i m) (push (let (record) (dotimes (j r (nreverse record)) (push (pop real-vbs) record))) result-table))
The DOTIMES is the key, my purpose is just loop for m times (m is a positive integer), even I replace it into this form: (dotimes (j m)) it still fails to load (after compile), but if I use a LOOP instead of DOTIMES, problem solved ... That's really weird. Regards, Chun Tian (binghe) 在 2011-3-21，19:37， Chun Tian (binghe) 写道：
Hi, Alesio
Oh, sorry, maybe I didn't say it clearly, the "Register 4 contains wrong type" is not produced by the file with THREADS:WITH-MUTEX. It's another issue, not relevant to the first post in this mail thread.
Following function caused the "Register 4 contains wrong type" issue:
(defun generate-table (vars vbs non-repeaters max-repetitions) (declare (type fixnum non-repeaters max-repetitions)) (let* ((var-number (list-length vars)) (n (min non-repeaters var-number)) (m max-repetitions) (r (max (- var-number n) 0)) (real-vbs (mapcar #'(lambda (x) (coerce x 'list)) (coerce vbs 'list))) result-table) ;; non-repeaters (dotimes (i n) (push (pop real-vbs) result-table)) ;; table (when (and (plusp m) (plusp r)) (dotimes (i m) (push (let (record) (dotimes (j r (nreverse record)) (push (pop real-vbs) record))) result-table))) (values (nreverse result-table) (mapcar #'oid vars))))
If I temporary disable it by #+ignore or #-abcl, than the whole project compiles with no error any more. I'll try to continue look for which exactly form in this function caused the error.
Regards,
Chun Tian (binghe)
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote: […]
It's cl-net-snmp [1], which I just release a whole new version few days ago. My goal on ABCL is to make sure the server-side version (a pure Lisp SNMP Agent) run as a separated thread in JVM, so that people can use my program to remotely monitor any Java (or ABCL) servers. (I know some ABCL people are fixing bordeaux-threads, I'm watching this work and hope it could be done soon)
[…]
https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6
and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN).
I have no idea how to fix it.
We filed [ticket #142][1] to track this issue which has just been fixed with [r13257][2]. SNMP now compiles and loads, so we consider this issue closed. Please let us know if you have additional problems. [1]: http://trac.common-lisp.net/armedbear/ticket/142 [2]: http://trac.common-lisp.net/armedbear/changeset/13257 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Hi, Mark Thanks for solving the LOGAND issue, but it seems that the other issue I mentioned (Register 4 contains wrong type) still haven't been fixed, I have to comment the type declaration line in one of my function as suggested by Alessio Stalla. --binghe 在 2011-3-27，18:57， Mark Evenson 写道：
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote: […]
It's cl-net-snmp [1], which I just release a whole new version few days ago. My goal on ABCL is to make sure the server-side version (a pure Lisp SNMP Agent) run as a separated thread in JVM, so that people can use my program to remotely monitor any Java (or ABCL) servers. (I know some ABCL people are fixing bordeaux-threads, I'm watching this work and hope it could be done soon)
[…]
https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6
and try to ASDF load it (you'll need usocket 0.5 and ironclad), two major CLOS bug of ABCL will show up, one is at "pdu.lisp", as what the mail title said, The value :LONG is not of type (MEMBER NIL :BOOLEAN).
I have no idea how to fix it.
We filed [ticket #142][1] to track this issue which has just been fixed with [r13257][2].
SNMP now compiles and loads, so we consider this issue closed. Please let us know if you have additional problems.
[1]: http://trac.common-lisp.net/armedbear/ticket/142 [2]: http://trac.common-lisp.net/armedbear/changeset/13257
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 3/27/11 22:11 , Chun Tian (binghe) wrote:
Hi, Mark
Thanks for solving the LOGAND issue, but it seems that the other issue I mentioned (Register 4 contains wrong type) still haven't been fixed, I have to comment the type declaration line in one of my function as suggested by Alessio Stalla.
Thanks for the reminder, as I apparently didn't quite understand that you had found two separate errors (and the version of your SNMP system that I have synced from svn loaded fine). I have filed [ticket #144][1] to track fixing this bug. [1]: http://trac.common-lisp.net/armedbear/ticket/144 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 3/28/11 12:04 , Mark Evenson wrote: […]
I have filed [ticket #144][1] to track fixing this bug.
Finally fixed with [r13306] traced to an ancient typo presumable entered by the long gone ABCL compiler God(s). [r13306]: http://trac.common-lisp.net/armedbear/changeset/13306 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (3)
-
Alessio Stalla -
Chun Tian (binghe) -
Mark Evenson