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

[armedbear-ticket] [armedbear] #211: closure-common fails to load correctly after compilation
by armedbear 17 Nov '12

17 Nov '12

#211: closure-common fails to load correctly after compilation ---------------------------------------------------------------+------------ Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: clos compiler needs-test quicklisp closure-common | ---------------------------------------------------------------+------------ When compiling the fasl for closure-common/ystream.abcl an error in StandardClass.getClassLayout(StandardClass:205) in reading back the parameters. Interestingly, if the system is restarted, the fasl *can* be loaded without complaint, so there seems to be some artifact of the compilation process "hanging around" in memory which causes this problem. Unknown whether this affects the actual us of closure-common This error existed in abcl-1.0.1 as well, so it has nothing to do with the recent work on the MOP. {{{ 0: (#<FUNCTION {50F2A460}> #<TYPE-ERROR {79D34CA}> #<FUNCTION {50F2A460}>) 1: (APPLY #<FUNCTION {50F2A460}> (#<TYPE-ERROR {79D34CA}> #<FUNCTION {50F2A460}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {79D34CA}> #<FUNCTION {50F2A460}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {79D34CA}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:379) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:420) 6: org.armedbear.lisp.Cons.length(Cons.java:240) 7: org.armedbear.lisp.Cons.copyToArray(Cons.java:352) 8: org.armedbear.lisp.LispThread.pprint(LispThread.java:896) 9: org.armedbear.lisp.LispThread.pprint(LispThread.java:916) 10: org.armedbear.lisp.LispThread.pprint(LispThread.java:916) 11: org.armedbear.lisp.LispThread.printBacktrace(LispThread.java:825) 12: org.armedbear.lisp.LispThread.printBacktrace(LispThread.java:807) 13: org.armedbear.lisp.StandardClass.getClassLayout(StandardClass.java:206) 14: org.armedbear.lisp.Layout$6.execute(Layout.java:269) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 17: org.armedbear.lisp.clos_728.execute(clos.lisp:3470) 18: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:185) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:760) 20: org.armedbear.lisp.Lisp.funcall(Lisp.java:186) 21: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2817) 22: (SYSTEM:%MAKE-INSTANCES-OBSOLETE #<STANDARD-CLASS RUNES::OCTET-INPUT- STREAM {7F83698F}>) 23: (#<FUNCTION {1455BCD7}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS :TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5}> #<STANDARD-CLASS GRAY-S.. 24: (APPLY #<FUNCTION {1455BCD7}> (#<STANDARD-CLASS RUNES::OCTET-INPUT- STREAM {7F83698F}> :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY- STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5}> #<STANDARD-CLASS.. 25: (#<STANDARD-GENERIC-FUNCTION REINITIALIZE-INSTANCE {665C1EAE}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> :DIRECT- SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM- MI.. 26: (APPLY #<STANDARD-GENERIC-FUNCTION REINITIALIZE-INSTANCE {665C1EAE}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> :DIRECT- SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STR.. 27: (#<FUNCTION {5FE63CB6}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> RUNES::OCTET-INPUT-STREAM :DIRECT-SUPERCLASSES (#<STANDARD- CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5.. 28: (APPLY #<FUNCTION {5FE63CB6}> (#<STANDARD-CLASS RUNES::OCTET-INPUT- STREAM {7F83698F}> RUNES::OCTET-INPUT-STREAM :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7.. 29: (#<STANDARD-GENERIC-FUNCTION ENSURE-CLASS-USING-CLASS {1A3526CF}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> RUNES::OCTET-INPUT- STREAM :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-S.. 30: (APPLY #<STANDARD-GENERIC-FUNCTION ENSURE-CLASS-USING-CLASS {1A3526CF}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> RUNES ::OCTET-INPUT-STREAM (:DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL.. 31: (SYSTEM:ENSURE-CLASS RUNES::OCTET-INPUT-STREAM :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5}> #<STANDARD-CLASS GRAY-STREAMS:FUNDAMENTAL-BINARY-INPUT-.. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/211> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #215: ABCL-ASDF:RESOLVE should work in more (some?) cases
by armedbear 13 Oct '12

13 Oct '12

#215: ABCL-ASDF:RESOLVE should work in more (some?) cases -----------------------------+---------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: 1.1.0 Component: other | Version: 1.1.0-dev Keywords: abcl-asdf maven | -----------------------------+---------------------------------------------- Failure #1: {{{ (abcl-asdf:resolve "com.sun.jna:jna") WARNING: Using LATEST for unspecified version. METADATA_RESOLVING com.sun.jna:jna/maven-metadata.xml @ /home/evenson/.m2/repository (enhanced) METADATA_RESOLVED com.sun.jna:jna/maven-metadata.xml @ /home/evenson/.m2/repository (enhanced) METADATA_RESOLVING com.sun.jna:jna/maven-metadata.xml @ central (, releases+snapshots) METADATA_DOWNLOADING com.sun.jna:jna/maven-metadata.xml @ central (, releases+snapshots) METADATA_DOWNLOADED com.sun.jna:jna/maven-metadata.xml (/home/evenson/.m2/repository/com/sun/jna/jna/maven-metadata-central.xml) @ central (, releases+snapshots) METADATA_RESOLVED com.sun.jna:jna/maven-metadata.xml @ central (, releases+snapshots) ; Evaluation aborted on #<JAVA-EXCEPTION org.sonatype.aether.collection.DependencyCollectionException: Failed to collect dependencies for com.sun.jna:jna:jar:LATEST (runtime) {39D9F91C}>. CL-USER> }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/215> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #213: ABCL-ASDF breakage on trunk
by armedbear 12 Sep '12

12 Sep '12

#213: ABCL-ASDF breakage on trunk -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.1.0-dev Keywords: | -------------------------+-------------------------------------------------- Changeset 1834:d7370bc12860: bad The first bad revision is: changeset: 1834:d7370bc12860 user: ehuelsmann@1c010e3e-69d0-11dd-93a8-456734b0d56f date: Sun Jan 29 20:56:08 2012 +0000 summary: (Re)factor function call argument matching out of Closure.java. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/213> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #186: org.armedbear.lisp.IntegrityError means you need to check out how ABCL is finding boot.lisp
by armedbear 02 Sep '12

02 Sep '12

#186: org.armedbear.lisp.IntegrityError means you need to check out how ABCL is finding boot.lisp ----------------------------+----------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: unscheduled Component: other | Version: 1.0 Keywords: IntegrityError | ----------------------------+----------------------------------------------- [http://paste.lisp.org/+2P0S/1 org.armedbear.lisp.IntegrityError] -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/186> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #130: SLIME under Windows has "extra" CRLF
by armedbear 02 Sep '12

02 Sep '12

#130: SLIME under Windows has "extra" CRLF ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: minor | Milestone: Component: other | Version: Keywords: | ----------------------+----------------------------------------------------- Reported by ehu via #abcl -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/130> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #225: One of the paths in STD-COMPUTE-DISCRIMINATING function not working
by armedbear 01 Sep '12

01 Sep '12

#225: One of the paths in STD-COMPUTE-DISCRIMINATING function not working ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- In r14021, I've committed a note regarding a code path that's not working. Creating this ticket to create a log of the fact that I've been investigating and my findings so far. (Which are in the code now.) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/225> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #216: JVM stack inconsistency triggered by compiler
by armedbear 01 Sep '12

01 Sep '12

#216: JVM stack inconsistency triggered by compiler -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -----------------------+---------------------------------------------------- {{{ CL-USER(50): (lisp-implementation-version) "1.1.0-dev-svn-13998M" CL-USER(51): (lambda (a b c) (declare (optimize (safety 0))) (ash 3 (min 2 (the integer (block b (catch 'ct a)))))) #<FUNCTION (LAMBDA (A B C)) {374FB6BE}> CL-USER(52): (compile nil *) ; Caught STYLE-WARNING: ; The variable B is defined but never used. ; Caught STYLE-WARNING: ; The variable C is defined but never used. #<THREAD "interpreter" {5D4AAA93}>: Debugger invoked on condition of type INTERNAL-COMPILER-ERROR Stack inconsistency detected in NIL at index 36: found 2, expected 1. Restarts: 0: CONTINUE Eventually use interpreted form instead 1: TOP-LEVEL Return to top level. }}} (reported by Eric Marsden on armedbear-devel July 10, 2012) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/216> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #189: Compiler fails for 'unsigned-byte type declaration
by armedbear 01 Sep '12

01 Sep '12

#189: Compiler fails for 'unsigned-byte type declaration --------------------------------+------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: 1.0.1 Component: compiler | Version: 1.0 Keywords: compiler, has-test | --------------------------------+------------------------------------------- From [http://article.gmane.org/gmane.lisp.armedbear.devel/2122 On <armedbear-devel@…>, Eric Marsden reports]: The following code seems to be miscompiled (works fine with an INTEGER type declaration). {{{ CL-USER(23): (lisp-implementation-version) "1.1.0-dev-svn-13695M" CL-USER(24): (compile nil (lambda (a) (declare (type unsigned-byte a)) (max 28105919 a 1016934843))) #<FUNCTION (LAMBDA (A)) {2D53EAFD}> NIL NIL CL-USER(25): (funcall * 10545160975) 1955226383 }}} (From ansi-test/random suite) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/189> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #207: DECLARE should signal conditions when type declaration are violated
by armedbear 01 Sep '12

01 Sep '12

#207: DECLARE should signal conditions when type declaration are violated ------------------------------+--------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.1.0-dev Keywords: ansi-conformance | ------------------------------+--------------------------------------------- On #abcl, chtune notes http://paste.lisp.org/display/129139: {{{ defun test (x) (let ((j 10)) (declare (integer x)) (+ x j))) (test 10.4) ; => 20.4 ; I would expect this to throw a type error }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/207> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #219: Keyword argument checking for lambda lists is too lenient for ANSI
by armedbear 21 Aug '12

21 Aug '12

#219: Keyword argument checking for lambda lists is too lenient for ANSI ------------------------------+--------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.0.1 Keywords: ansi-conformance | ------------------------------+--------------------------------------------- From #abcl on Thu Jul 26 2012 {{{ <chturne> I don't run the latest and greatest ABCL, but you allow &BODY in ordinary lambda lists, which is an ANSI violation. There are probably other such violations, as I see little discrimination in the argument parsing code. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/219> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2