July 2012 - armedbear-ticket - mailman3.common-lisp.net

[armedbear-ticket] [armedbear] #201: &WHOLE broken in DEFINE-METHOD-COMBINATION
by armedbear 05 Aug '12

05 Aug '12

#201: &WHOLE broken in DEFINE-METHOD-COMBINATION ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=aitoawlfp20ohzeq8vs4btepsaqltprtai… | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: CLOS | Version: 1.1.0-dev Keywords: | ----------------------------------------------------------------------------------------------+ I get an error whenever I call a function that uses the simple method combination shown here. {{{ CL-USER> (define-method-combination progn-with-whole () ((methods ())) (:arguments &whole whole) `(progn (format nil "using ~a" ,whole) ,@(mapcar (lambda (method) `(call-method ,method)) methods))) PROGN-WITH-WHOLE CL-USER> (defgeneric test-&whole (x) (:method-combination progn-with-whole) (:method (x) x)) #<STANDARD-GENERIC-FUNCTION TEST-&WHOLE {34315D04}> CL-USER> (test-&whole 4) }}} Here is the error: {{{ The value 4 is not of type LIST. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {C69203}> #<TYPE-ERROR {FE85ADF}> #<FUNCTION {C69203}>) 1: (APPLY #<FUNCTION {C69203}> (#<TYPE-ERROR {FE85ADF}> #<FUNCTION {C69203}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {FE85ADF}> #<FUNCTION {C69203}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {FE85ADF}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:379) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:420) 6: org.armedbear.lisp.LispObject.car(LispObject.java:156) 7: org.armedbear.lisp.Lisp.eval(Lisp.java:520) 8: org.armedbear.lisp.Lisp.evalCall(Lisp.java:559) 9: org.armedbear.lisp.Lisp.eval(Lisp.java:515) 10: org.armedbear.lisp.Lisp.progn(Lisp.java:684) 11: org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275) 12: org.armedbear.lisp.Lisp.eval(Lisp.java:505) 13: org.armedbear.lisp.Lisp.progn(Lisp.java:684) 14: org.armedbear.lisp.Primitives$sf_macrolet.execute(Primitives.java:3641) 15: ((LAMBDA (#:G13665) (MACROLET (#) (PROGN # #))) (4)) 16: (FUNCALL (LAMBDA (#:G13665) (MACROLET (#) (PROGN # #))) (4)) 17: (#<STANDARD-GENERIC-FUNCTION TEST-&WHOLE {34315D04}> 4) 18: (APPLY #<STANDARD-GENERIC-FUNCTION TEST-&WHOLE {34315D04}> (4)) 19: (MOP::INITIAL-DISCRIMINATING-FUNCTION #<STANDARD-GENERIC-FUNCTION TEST-&WHOLE {34315D04}> (4)) 20: (#<STANDARD-GENERIC-FUNCTION TEST-&WHOLE {34315D04}> 4) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/201> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #227: Invocation of an undefined function in a fresh ABCL crashes
by armedbear 01 Aug '12

01 Aug '12

#227: Invocation of an undefined function in a fresh ABCL crashes ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: blocker | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- Evaluating (slot-boundp) in a freshly started ABCL ("naked", not in SLIME) causes too many errors and terminates ABCL hard. No idea where the error is yet, but it's probably something to do with auto loading. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/227> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #175: abcl.release target fails occasionally
by armedbear 29 Jul '12

29 Jul '12

#175: abcl.release target fails occasionally --------------------------+------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.0 Component: build | Version: 0.27 Keywords: abcl.release | --------------------------+------------------------------------------------- The central abcl.release target can fail unpredictably, so it is current best to clean the intermediate build targets before making a release. 'abcl.release' currently *always* fails under MSFT Windows. @erik had noted this in #abcl. http://trac.common-lisp.net/armedbear/changeset/12419 -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/175> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 7

[armedbear-ticket] [armedbear] #60: Implement USE-FAST-CALLS properly
by armedbear 29 Jul '12

29 Jul '12

#60: Implement USE-FAST-CALLS properly -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- USE-FAST-CALLS is implemented at the moment by flipping an essentially global variable. The proper implementation would be to make turn it into a ABCL-specific declaration, and making sure it affects its lexically enclosing code only. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/60> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #224: Autoloader fails when *read-XXXX* variables bound to non-standard values
by armedbear 29 Jul '12

29 Jul '12

#224: Autoloader fails when *read-XXXX* variables bound to non-standard values ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: java | Version: 1.1.0-dev Keywords: | ------------------------+--------------------------------------------------- Durward McDonell reports: (defmacro foo-bar (s) `(sublis '((foo . bar)) ,s)) (defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it))) Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis". Blake McBride comments: I put his code in a file named yyy.lisp. I did not compile it. There is no yyy.fasl. CL-USER(1): (load "yyy.lisp") T CL-USER(2): (foo-bar-rb) (foo-bar '(foo)) Maximum error depth exceeded (11 nested errors) with 'FASL version mismatch; found '57' but expected '39' in with-standard-io-syntax'. CL-USER(3): -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/224> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #206: COMPILER-UNSUPPORTED-FEATURE-ERROR is derived from condition, rather than from ERROR
by armedbear 29 Jul '12

29 Jul '12

#206: COMPILER-UNSUPPORTED-FEATURE-ERROR is derived from condition, rather than from ERROR ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=aitoawmcq6mzgezjmpqv2tjhvs6isymf6t… | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | ----------------------------------------------------------------------------------------------+ Hello. My coade loads some ASDF systems, and wraps the asdf:operate call into handler-case {{{ (handler-case (asdf:operate ...) (serious-condition (condition) (... }}} This should help me to handle the build errors. But when I load the let-plus library, ABCL falls into debugger: {{{ #<THREAD "interpreter" {53B73EA7}>: Debugger invoked on condition of type COMPILER-UNSUPPORTED-FEATURE-ERROR COMPILE-FORM unhandled case ((ANAPHORA:IT #:THIS-S100224)) Restarts: 0: RETRY Retry compiling #<ASDF:CL-SOURCE-FILE "let-plus" "let-plus">. 1: ACCEPT Continue, treating compiling #<ASDF:CL-SOURCE-FILE "let-plus" "let-plus"> as having been successful. 2: ABORT Give up on "let-plus" [1] LET-PLUS(1): 0 }}} This happens because COMPILER-UNSUPPORTED-FEATURE-ERROR is derived from CONDITION (see src/org/armedbear/lisp/CompilerUnsupportedFeatureError.java) CLHS says: "Conditions of type error might be signaled by the compiler in situations where the compilation cannot proceed without intervention." http://www.lispworks.com/documentation/lw51/CLHS/Body/03_be.htm It would be better to derive COMPILER-UNSUPPORTED-FEATURE-ERROR from ERROR (or at least from SERIOUS-CONDITION) - Anton Vodonosov -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/206> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

Re: [armedbear-ticket] [armedbear] #198: Hunchentoot load failure
by armedbear 28 Jul '12

28 Jul '12

#198: Hunchentoot load failure ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: assigned Priority: blocker | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: | ----------------------+----------------------------------------------------- Comment(by mevenson): Reproduced from the form {{{ (ASDF::LOAD-SYSDEF "jna" #P"jar:file:/home/evenson/work/abcl/dist/abcl- contrib.jar!/mvn/jna.asd") }}} I think this has something to do with *DEFAULT-PATHNAME-DEFAULTS* being a JAR-PATHNAME. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/198#comment:10> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #191: Compiling SHARPSIGN SHARPSIGN form causes stack overflow
by armedbear 28 Jul '12

28 Jul '12

#191: Compiling SHARPSIGN SHARPSIGN form causes stack overflow ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.0.1 Component: compiler | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2142 Anton reports] that compiling the alexandria tests from Quicklisp 2011-12-03 results in a stack overflow. The offending form seems to be {{{ (deftest circular-tree-p.2 (alexandria:circular-tree-p '#1=(#1#)) t) }}} where the problem seems to occur in the compiling ADD-ENTRY function {{{ 0: (#<FUNCTION {47D2FBB5}> #<STORAGE-CONDITION {18010D30}> #<FUNCTION {47D2FBB5}>) 1: (APPLY #<FUNCTION {47D2FBB5}> (#<STORAGE-CONDITION {18010D30}> #<FUNCTION {47D2FBB5}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {18010D30}> #<FUNCTION {47D2FBB5}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {18010D30}>) […] 31: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2853) 32: (#<FUNCTION {5F4298A5}>) 33: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {5F4298A5}>) 34: (SYSTEM::CONVERT-TOPLEVEL-FORM (REGRESSION-TEST::ADD-ENTRY (REGRESSION-TEST::MAKE-ENTRY :PEND T :NAME 'ALEXANDRIA-TESTS::CIRCULAR- TREE-P.2 :PROPS ...)) NIL) 35: (SYSTEM::PROCESS-TOPLEVEL-FORM (REGRESSION-TEST::ADD-ENTRY (REGRESSION-TEST::MAKE-ENTRY :PEND T :NAME 'ALEXANDRIA-TESTS::CIRCULAR- TREE-P.2 :PROPS ...)) #<FILE-STREAM {D33A97F}> NIL) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/191> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

Re: [armedbear-ticket] [armedbear] #198: Hunchentoot load failure
by armedbear 28 Jul '12

28 Jul '12

#198: Hunchentoot load failure ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: assigned Priority: blocker | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: | ----------------------+----------------------------------------------------- Comment(by mevenson): The taskmaster.abcl fasl doesn't seem to be a problem any more. But Hunchentoot still fails to load, as (require :jna) fails even with a suitable mvn installed. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/198#comment:9> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #220: Lambda list checking too lenient
by armedbear 28 Jul '12

28 Jul '12

#220: Lambda list checking too lenient ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: java | Version: 1.1.0-dev Keywords: | ------------------------+--------------------------------------------------- ArgumentListProcessor allows &body as a variable indicator, which is in violation with the spec -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/220> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1