Discussion:
[armedbear-devel] The value :LONG is not of type (MEMBER NIL :BOOLEAN)
Chun Tian (binghe)
2011-03-20 15:52:32 UTC
Permalink
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)))))))
Mark Evenson
2011-03-20 16:17:53 UTC
Permalink
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote:

[…]
Post by Chun Tian (binghe)
Now I need help. If one could spend 5 minutes do a SVN checkout of
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.
Post by Chun Tian (binghe)
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."
Chun Tian (binghe)
2011-03-21 09:00:44 UTC
Permalink
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 写道:
Post by Mark Evenson
[…]
Post by Chun Tian (binghe)
Now I need help. If one could spend 5 minutes do a SVN checkout of
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.
Post by Chun Tian (binghe)
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
http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Alessio Stalla
2011-03-21 10:54:04 UTC
Permalink
Post by Chun Tian (binghe)
Hi, Mark
#-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.
Chun Tian (binghe)
2011-03-21 11:10:14 UTC
Permalink
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 写道:
Post by Alessio Stalla
Post by Chun Tian (binghe)
Hi, Mark
#-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.
Alessio Stalla
2011-03-21 11:21:44 UTC
Permalink
Post by Chun Tian (binghe)
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.
; 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.
 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
Chun Tian (binghe)
2011-03-21 11:37:20 UTC
Permalink
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 写道:
Post by Alessio Stalla
Post by Chun Tian (binghe)
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.
; 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
Alessio Stalla
2011-03-21 11:45:07 UTC
Permalink
Post by 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.
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
Post by Chun Tian (binghe)
(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 写道:
Post by Alessio Stalla
Post by Chun Tian (binghe)
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.
; 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
Chun Tian (binghe)
2011-03-21 11:55:03 UTC
Permalink
Post by Chun Tian (binghe)
(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) 写道:
Post by 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.
(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)
Chun Tian (binghe)
2011-03-21 11:58:06 UTC
Permalink
God, you're right again ... I removed the type declaration and everything goes fine now ...

--binghe

在 2011-3-21,19:45, Alessio Stalla 写道:
Post by Alessio Stalla
Post by 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.
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
Post by Chun Tian (binghe)
(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 写道:
Post by Alessio Stalla
Post by Chun Tian (binghe)
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.
; 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
Mark Evenson
2011-03-27 10:57:22 UTC
Permalink
On 3/20/11 4:52 PM, Chun Tian (binghe) wrote:
[…]
Post by Chun Tian (binghe)
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)
[…]
Post by Chun Tian (binghe)
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."
Chun Tian (binghe)
2011-03-27 20:11:31 UTC
Permalink
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 写道:
[…]
Post by Chun Tian (binghe)
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)
[…]
Post by Chun Tian (binghe)
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."
Mark Evenson
2011-03-28 10:04:28 UTC
Permalink
Post by Chun Tian (binghe)
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."
Mark Evenson
2011-05-30 13:46:29 UTC
Permalink
Content preview: On 3/28/11 12:04 , Mark Evenson wrote: […] > I have filed
[ticket #144][1] to track fixing this bug. > > [1]: http://trac.common-lisp.net/armedbear/ticket/144
Finally fixed with [r13306] traced to an ancient typo presumable entered
by the long gone ABCL compiler God(s). [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[166.84.1.89 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-BeenThere: armedbear-***@common-lisp.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <armedbear-devel.common-lisp.net>
List-Unsubscribe: <http://lists.common-lisp.net/cgi-bin/mailman/options/armedbear-devel>,
<mailto:armedbear-devel-***@common-lisp.net?subject=unsubscribe>
List-Archive: <http://lists.common-lisp.net/pipermail/armedbear-devel>
List-Post: <mailto:armedbear-***@common-lisp.net>
List-Help: <mailto:armedbear-devel-***@common-lisp.net?subject=help>
List-Subscribe: <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel>,
<mailto:armedbear-devel-***@common-lisp.net?subject=subscribe>
Errors-To: armedbear-devel-***@common-lisp.net
X-Spam-Score: -100.7 (---------------------------------------------------)
X-Spam-Report: Spam detection software, running on the system "common-lisp.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: On 3/28/11 12:04 , Mark Evenson wrote: […] > I have filed
[ticket #144][1] to track fixing this bug. > > [1]: http://trac.common-lisp.net/armedbear/ticket/144
Finally fixed with [r13306] traced to an ancient typo presumable entered
by the long gone ABCL compiler God(s). [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[166.84.1.89 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.editors.j.devel/4567>

On 3/28/11 12:04 , Mark Evenson wrote:
[…]
Post by Mark Evenson
I have filed [ticket #144][1] to track fixing this bug.
[1]: http://trac.common-lisp.net/armedbear/ticket/144
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."
Loading...