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

[armedbear-ticket] [armedbear] #210: Add JFLI to contrib
by armedbear 29 May '12

29 May '12

#210: Add JFLI to contrib -------------------------------+-------------------------------------------- Reporter: mevenson | Owner: mevenson Type: enhancement | Status: new Priority: major | Milestone: 1.1.0 Component: libraries | Version: Keywords: jfli abcl-contrib | -------------------------------+-------------------------------------------- Include Rich Hickey's JFLI in ABCL-CONTRIB Alex notes that he has possible additional patches. https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp /jfli-abcl/jfli-abcl.lisp -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/210> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #194: ansi-compiled CL-TEST::LOOP-16 test has stack overflow on java7
by armedbear 24 May '12

24 May '12

#194: ansi-compiled CL-TEST::LOOP-16 test has stack overflow on java7 ---------------------------------+------------------------------------------ Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: unscheduled Component: compiler | Version: 1.0.1 Keywords: java7 ansi-compiled | ---------------------------------+------------------------------------------ {{{ Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: 0: [RETRY] Retry #<STANDARD-CLASS ASDF:TEST-OP {3EF04B6}> on #<ASDF:SYSTEM "ansi-compiled">. 1: [ACCEPT] Continue, treating #<STANDARD-CLASS ASDF:TEST-OP {3EF04B6}> on #<ASDF:SYSTEM "ansi-compiled"> as having been successful. 2: [ABORT] Abort compilation. 3: [*ABORT] Return to SLIME's top level. 4: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {17A4682F}> #<STORAGE-CONDITION {2AB3F1C9}> #<FUNCTION {17A4682F}>) 1: (APPLY #<FUNCTION {17A4682F}> (#<STORAGE-CONDITION {2AB3F1C9}> #<FUNCTION {17A4682F}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {2AB3F1C9}> #<FUNCTION {17A4682F}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {2AB3F1C9}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:379) 5: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1315) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 8: org.armedbear.lisp.rt_63.execute(rt.lsp:228) 9: org.armedbear.lisp.rt_67.execute(rt.lsp:228) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 11: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1308) 12: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 14: org.armedbear.lisp.rt_62.execute(rt.lsp:228) 15: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) 16: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 17: org.armedbear.lisp.LispThread.execute(LispThread.java:666) 18: org.armedbear.lisp.rt_78.execute(rt.lsp:348) 19: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 20: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 21: org.armedbear.lisp.rt_77.execute(rt.lsp:335) 22: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) 23: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 24: org.armedbear.lisp.Lisp.evalCall(Lisp.java:544) 25: org.armedbear.lisp.Lisp.eval(Lisp.java:515) 26: org.armedbear.lisp.Lisp.progn(Lisp.java:684) 27: org.armedbear.lisp.Closure.execute(Closure.java:426) 28: org.armedbear.lisp.Time$1.execute(Time.java:56) 29: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 30: org.armedbear.lisp.Lisp.evalCall(Lisp.java:550) 31: org.armedbear.lisp.Lisp.eval(Lisp.java:515) 32: org.armedbear.lisp.Lisp.eval(Lisp.java:508) 33: org.armedbear.lisp.Load.loadStream(Load.java:570) 34: org.armedbear.lisp.Load.loadFileFromStream(Load.java:526) 35: org.armedbear.lisp.Load.load(Load.java:201) 36: org.armedbear.lisp.Load.load(Load.java:686) 37: org.armedbear.lisp.Load$_load.execute(Load.java:636) 38: org.armedbear.lisp.Symbol.execute(Symbol.java:837) 39: org.armedbear.lisp.LispThread.execute(LispThread.java:701) 40: org.armedbear.lisp.load_1.execute(load.lisp:33) 41: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 42: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 43: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 44: org.armedbear.lisp.ASDF_TMP_package_5.execute(package.lisp:22) 45: org.armedbear.lisp.Time$1.execute(Time.java:56) 46: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 47: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 48: org.armedbear.lisp.ASDF_TMP_package_1.execute(package.lisp:22) 49: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) 50: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 51: org.armedbear.lisp.LispThread.execute(LispThread.java:666) 52: org.armedbear.lisp.Primitives$pf_funcall.execute(Primitives.java:2710) 53: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {18E070C}>) 54: (#<FUNCTION {1370A5A0}>) 55: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {1370A5A0}>) 56: (REGRESSION-TEST::DO-ENTRY #S(REGRESSION-TEST::ENTRY :PEND T :NAME CL-TEST::CLASS-07.2 :PROPS NIL :FORM (LET ((CL-TEST::C #)) (VALUES (CL- TEST::NOTNOT #) (CL-TEST::S1 CL-TEST::C) (SLOT-BOUNDP CL-TEST:.. Locals: "??" = "??" 57: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 58: abcl_211bc8a2_78e5_4d5d_b332_2512480e939c.execute(Unknown Source) 59: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 60: org.armedbear.lisp.rt_64.execute(rt.lsp:228) 61: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 62: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1308) 63: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 64: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 65: org.armedbear.lisp.rt_63.execute(rt.lsp:228) 66: org.armedbear.lisp.rt_67.execute(rt.lsp:228) 67: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 68: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1308) 69: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 70: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 71: org.armedbear.lisp.rt_62.execute(rt.lsp:228) 72: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) 73: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 74: org.armedbear.lisp.LispThread.execute(LispThread.java:666) 75: org.armedbear.lisp.rt_78.execute(rt.lsp:348) 76: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 77: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 78: org.armedbear.lisp.rt_77.execute(rt.lsp:335) 79: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) 80: org.armedbear.lisp.LispThread.execute(LispThread.java:633) 81: org.armedbear.lisp.Lisp.evalCall(Lisp.java:544) 82: org.armedbear.lisp.Lisp.eval(Lisp.java:515) 83: org.armedbear.lisp.Lisp.progn(Lisp.java:684) 84: org.armedbear.lisp.Closure.execute(Closure.java:426) 85: org.armedbear.lisp.Time$1.execute(Time.java:56) 86: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 87: org.armedbear.lisp.Lisp.evalCall(Lisp.java:550) 88: org.armedbear.lisp.Lisp.eval(Lisp.java:515) 89: org.armedbear.lisp.Lisp.eval(Lisp.java:508) 90: org.armedbear.lisp.Load.loadStream(Load.java:570) 91: org.armedbear.lisp.Load.loadFileFromStream(Load.java:526) 92: org.armedbear.lisp.Load.load(Load.java:201) 93: org.armedbear.lisp.Load.load(Load.java:686) 94: org.armedbear.lisp.Load$_load.execute(Load.java:636) 95: org.armedbear.lisp.Symbol.execute(Symbol.java:837) 96: org.armedbear.lisp.LispThread.execute(LispThread.java:701) 97: org.armedbear.lisp.load_1.execute(load.lisp:33) 98: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 99: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 100: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 101: org.armedbear.lisp.ASDF_TMP_package_5.execute(package.lisp:22) 102: org.armedbear.lisp.Time$1.execute(Time.java:56) 103: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 104: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 105: org.armedbear.lisp.ASDF_TMP_package_1.execute(package.lisp:22) 106: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) 107: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 108: org.armedbear.lisp.LispThread.execute(LispThread.java:666) 109: org.armedbear.lisp.Primitives$pf_funcall.execute(Primitives.java:2710) 110: (DELETE-PACKAGE "LOOP.16.PACKAGE") 111: (#<FUNCTION {233F70E0}>) 112: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {233F70E0}>) 113: (#<FUNCTION (LAMBDA ()) {1A0B9434}>) 114: (#<FUNCTION {6E2EEF47}>) 115: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {6E2EEF47}>) 116: (#<FUNCTION {4B5F56D4}>) 117: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {4B5F56D4}>) 118: (REGRESSION-TEST::DO-ENTRY #S(REGRESSION-TEST::ENTRY :PEND NIL :NAME CL-TEST::LOOP.16.70 :PROPS NIL :FORM (LET NIL (IGNORE-ERRORS (DELETE- PACKAGE "LOOP.16.PACKAGE")) (LET (#) (LOOP #:FOR CL-TEST::X #:.. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/194> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #199: RESTAS fails when MOP:INITIAL-DISCRIMINATING-FUNCTION
by armedbear 22 May '12

22 May '12

#199: RESTAS fails when MOP:INITIAL-DISCRIMINATING-FUNCTION ------------------------------+--------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.0.2 Component: (A)MOP | Version: 1.0.1 Keywords: quicklisp restas | ------------------------------+--------------------------------------------- For the [https://github.com/archimag/restas RESTAS framework] loaded by the Feb 2012 Quicklisp the following MOP call fails when trying to run the 'examples/example-1.lisp' code: {{{ (MOP::INITIAL-DISCRIMINATING-FUNCTION #<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> (#<RESTAS::PKG-SUBMODULE{23452A3E})) }}} I would like to either fix this for abcl-1.0.2 or get [http://trac.common- lisp.net/armedbear/ticket/198 abcl-1.1.0-dev working with Hunchentoot again], as I'm pretty sure this should be fixed easily in Rudi's code. {{{ Wrong number of arguments for #<FUNCTION (LAMBDA (ARGS NEXT-EMFUN)) {4B658B53}>. [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry SLIME interactive evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {17144A84}> #<PROGRAM-ERROR {35282BF2}> #<FUNCTION {17144A84}>) 1: (APPLY #<FUNCTION {17144A84}> (#<PROGRAM-ERROR {35282BF2}> #<FUNCTION {17144A84}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {35282BF2}> #<FUNCTION {17144A84}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {35282BF2}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:381) 5: org.armedbear.lisp.Function.execute(Function.java:312) 6: org.armedbear.lisp.Primitive.execute(Primitive.java:113) 7: (#<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> #<RESTAS ::PKG-SUBMODULE {605D3821}>) 8: (APPLY #<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> (#<RESTAS::PKG-SUBMODULE {605D3821}>)) 9: (MOP::INITIAL-DISCRIMINATING-FUNCTION #<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> (#<RESTAS::PKG-SUBMODULE {605D3821}>)) 10: (RESTAS:SUBMODULE-ROUTES #<RESTAS::PKG-SUBMODULE {605D3821}>) 11: (RESTAS:CONNECT-SUBMODULE #<RESTAS::PKG-SUBMODULE {605D3821}> #<ROUTES:MAPPER {8102FF4}>) 12: (RESTAS::ADD-TOPLEVEL-SUBMODULE #<RESTAS::PKG-SUBMODULE {605D3821}> NIL 8080) 13: (RESTAS:START #:RESTAS.EXAMPLE-1 :PORT 8080) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/199> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 19

[armedbear-ticket] [armedbear] #209: ASDF uses compile time rather than load time values for computing fasl location
by armedbear 18 May '12

18 May '12

#209: ASDF uses compile time rather than load time values for computing fasl location ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: ASDF | Version: 1.0.1 Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2307 Paul Nathan reports] {{{ I installed Armed Bear Common Lisp 1.0.1-svn-13750-13751 in order to run it on my OSX 10.6 (Snow Leopard) 64-bit system (Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64), for the purpose of executing cl-test-grid. However, I observed that the fasls were being stored in ~/.cache/common- lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86 }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/209> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #205: JSS logic for resolving methods a little wonky (could use better diagnostics on why resolution has failed)
by armedbear 16 May '12

16 May '12

#205: JSS logic for resolving methods a little wonky (could use better diagnostics on why resolution has failed) -----------------------------------+---------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: libraries | Version: 1.0.1 Keywords: jss method-resolution | -----------------------------------+---------------------------------------- [http://thread.gmane.org/gmane.lisp.armedbear.devel/2252 Jonathan P. Bona is working with Alan Ruttenberg] to port LSW from JSS 1 to JSS 3: {{{ I'm working with Alan Ruttenberg to port LSW from the old version of JSS to the JSS that is now part of abcl-contrib. We've run into the following bug when using with-constant-signature: ; these first two work fine: (#"substring" "some string" 2 4) ; "me" (#"substring" "some string" 2) ; "me string" ; and so does this (with-constant-signature ((substring "substring")) (substring "some string" 2 4)) ; "me" ; but this breaks: (with-constant-signature ((substring "substring")) (substring "some string" 2)) ; Wrong number of arguments for public java.lang.String java.lang.String.substring(int,int): expected 2, got 1 ; [Condition of type PROGRAM-ERROR] A problem seems to be in jss::invoke-find-method, which is finding the two argument version of java.lang.String.substring no matter how many arguments its given: (jss::invoke-find-method "substring" "this is a string" '(1)) ; should return the java.lang.String.substring method with one int arg ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2) ) ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6 7 8) ) ; should be an error ; #<method public java.lang.String java.lang.String.substring(int,int) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/205> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #74: slow compilation test
by armedbear 06 May '12

06 May '12

#74: slow compilation test -------------------------+-------------------------------------------------- Reporter: trittweiler | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: | -------------------------+-------------------------------------------------- (eval-when (:compile-toplevel :load-toplevel :execute) (defclass foo () ())) (defun quux (x) (case x (#. (find-class 'foo) :foo) (t :quux))) (flet ((test (x) (format t "~&(QUUX ~S) => ~S~%" x (quux x)))) (test 42) (test (find-class 'foo))) COMPILE-FILE'ing that takes over a second. No real life case, of course, still you may be interested. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/74> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #196: STABLE-SORT is only stable for lists
by armedbear 06 May '12

06 May '12

#196: STABLE-SORT is only stable for lists ------------------------------+--------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.0.1 Keywords: ansi-conformance | ------------------------------+--------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2204 Jorge Tavares reports on armedbear-devel@]: {{{ Recently I started to investigate the different CL sort implementations and found that stable-sort in ABCL does not execute as required. The problem is that stable-sort is only stable for lists and not for all type of sequences (i.e., elements considered equal by the predicate should stay in their original order). A very simple test shows this error: idesk:~ jast$ abcl Armed Bear Common Lisp 1.0.1 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.399 seconds. Startup completed in 1.069 seconds. Loading /Users/jast/.abclrc completed in 4.8 seconds. Type ":help" for a list of available commands. CL-USER(1): (defparameter *stuff* #((1 0.31648433) (0 0.2704757) (0 0.48931926) (1 0.9958766) (0 0.49251676))) *STUFF* CL-USER(2): (setf *stuff* (stable-sort *stuff* #'< :key #'first)) #((0 0.49251676) (0 0.2704757) (0 0.48931926) (1 0.31648433) (1 0.9958766)) The above test is short and simple to understand: *stuff* contains an array where each element is a pair. The first element of a pair is the key and the second the data. With this in mind, the expected result should have been: #((0 0.2704757) (0 0.48931926) (0 0.49251676) (1 0.31648433) (1 0.9958766)). The same error happens with larger arrays and other types of data. I also tested it in SBCL, CCL, ECL and CLisp and for these implementations the results are the expected. Only ABCL differs form the major open source implementations (I didn't test in ACL or LW). The reason for this bug is actually quite simple. In sort.lisp, in the definition of stable-sort, seq-dispatch calls for the non-list sequences the quicksort algorithm, which is not stable. For lists it calls merge sort (which is stable) and the problem does not arise. As a quick fix, I send in attach a patch that uses in stable-sort merge sort for all sequences. This is done by coercing the sequence to list, calling merge sort and coercing it back to the original sequence type. However, as a long term improvement, the best solution would be to implement a merge sort for non-list sequences. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/196> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #204: abcl-asdf maybe-parse-mvn ignores version information
by armedbear 01 Apr '12

01 Apr '12

#204: abcl-asdf maybe-parse-mvn ignores version information ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=aitoawkpp0-51624vwa6xzgzn5lml-cy-k… | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: ASDF | Version: Keywords: abcl-asdf version | ----------------------------------------------------------------------------------------------+ If one tries to add an :mvn component to an ASDF system, the version info is always ignored and "LATEST" is used. e.g. in an example like this .... :components ((:mvn "junit/junit" :version "3.8.2") .... the version info is ignored. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/204> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

Re: [armedbear-ticket] [armedbear] #198: Hunchentoot load failure
by armedbear 29 Feb '12

29 Feb '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: | ----------------------+----------------------------------------------------- Changes (by mevenson): * owner: ehuelsmann => mevenson * status: new => assigned -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/198#comment:8> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

Re: [armedbear-ticket] [armedbear] #199: CL:DEFMETHOD cannot parse &AUX arguments
by armedbear 29 Feb '12

29 Feb '12

#199: CL:DEFMETHOD cannot parse &AUX arguments -----------------------------------------------+---------------------------- Reporter: ehuelsmann | Owner: mevenson Type: defect | Status: assigned Priority: critical | Milestone: 1.1.0 Component: (A)MOP | Version: 1.1.0-dev Keywords: quicklisp restas ansi-conformance | -----------------------------------------------+---------------------------- Changes (by mevenson): * keywords: quicklisp restas => quicklisp restas ansi-conformance * reporter: mevenson => ehuelsmann Comment: Reassigning to Erik. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/199#comment:8> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0