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

[armedbear-ticket] [armedbear] #118: Lisp.getUpgradedElementType returns more types than supported by 'make_array.java'
by armedbear 07 Dec '12

07 Dec '12

#118: Lisp.getUpgradedElementType returns more types than supported by 'make_array.java' ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- The above leads to possible failure: each upgraded element type has its own associated defaultInitialValue. If the code does not specify the right initial value, NIL is taken, which probably is not a good fit. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/118> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 8

[armedbear-ticket] [armedbear] #174: Conformance bug in time implementation
by armedbear 17 Nov '12

17 Nov '12

#174: Conformance bug in time implementation ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=AItOawkDgxhblL5hWamZidYhAD6W-l7W_L… | Owner: somebody Type: defect | Status: new Priority: trivial | Milestone: Component: other | Version: 0.27 Keywords: time, macro, conformance bug | ----------------------------------------------------------------------------------------------+ ABCL's time implementation does not return multiple values as specified in HyperSpec. (time (values 1 2)) => 1 instead of 1 and 2 a test could be (assert (= 2 (length (multiple-value-list (time (values 1 2)))))) an implementation is given [http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/file/6afcecc6bb2c/src/mac… here]. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/174> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 15

[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] #113: DEFSTRUCT redefinition can crash ABCL on MAKE-FOO
by armedbear 19 Aug '12

19 Aug '12

#113: DEFSTRUCT redefinition can crash ABCL on MAKE-FOO ---------------------+------------------------------------------------------ Reporter: mseddon | Owner: nobody Type: defect | Status: new Priority: minor | Milestone: Component: java | Version: Keywords: | ---------------------+------------------------------------------------------ CL-USER(1): (defstruct foo x y) FOO CL-USER(2): (defstruct foo x y z) FOO CL-USER(3): (make-foo :x 1 :y 2 :z 3) ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.StructureObject.writeToString(StructureObject.java :483) Multiple DEFSTRUCTs do not change the underlying structure class, but seem to cause StructureObject to assert if the new (almost ignored) definition had a different number of slots than the old. For example, while the above example crashes out ABCL, the following example does not: CL-USER(1): (defstruct foo a b c) FOO CL-USER(2): (defstruct foo x y z) FOO CL-USER(3): (make-foo :x 1 :y 2 :z 3) #S(FOO :A 1 :B 2 :C 3) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/113> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 10

[armedbear-ticket] [armedbear] #176: Patch to get CFFI to find the JNA libraries dynamically via Maven3
by armedbear 13 Aug '12

13 Aug '12

#176: Patch to get CFFI to find the JNA libraries dynamically via Maven3 ----------------------------+----------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: unscheduled Component: libraries | Version: Keywords: quicklisp cffi | ----------------------------+----------------------------------------------- Need to get the following upstream to CFFI to ease use of JNA: {{{ #+abcl (eval-when (:load-toplevel) (require 'abcl-contrib) (require 'abcl-asdf) (java:add-to-classpath (abcl-asdf:resolve-dependencies "com.sun.jna" "jna" "3.0.9"))) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/176> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #168: Compilation fails for quicklisp let-plus
by armedbear 08 Aug '12

08 Aug '12

#168: Compilation fails for quicklisp let-plus ----------------------------------------+----------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 0.28 Component: compiler | Version: Keywords: quicklisp ansi_confromance | ----------------------------------------+----------------------------------- let-plus-20110730-git, a dependency for LLA, cannot be compiled resulting in the following error: {{{ ; Loading /Users/evenson/.cache/common-lisp/abcl-0.27.0-dev-fasl37-macosx- java/Users/evenson/quicklisp/dists/quicklisp/software/let- plus-20110730-git/package.abcl ... ; Loaded /Users/evenson/.cache/common-lisp/abcl-0.27.0-dev-fasl37-macosx- java/Users/evenson/quicklisp/dists/quicklisp/software/let- plus-20110730-git/package.abcl (0.027 seconds) ; Compiling /Users/evenson/quicklisp/dists/quicklisp/software/let- plus-20110730-git/let-plus.lisp ... ; (IN-PACKAGE #:LET-PLUS) ; (DEFUN IGNORED? ...) ; (DEFUN REPLACE-IGNORED ...) ; (DEFUN EXPAND-SLOT-FORMS ...) ; (DEFUN EXPAND-ENTRY-FORMS ...) ; (DEFUN EXPAND-ARRAY-ELEMENTS ...) ; (DEFGENERIC LET+-EXPANSION ...) ; (DEFGENERIC LET+-EXPANSION-FOR-LIST ...) ; (DEFMACRO LET+ ...) ; (DEFMACRO DEFINE-LET+-EXPANSION ...) #<THREAD "interpreter" {52BBC66F}>: Debugger invoked on condition of type COMPILER-UNSUPPORTED-FEATURE-ERROR COMPILE-FORM unhandled case ((ANAPHORA:IT #:THIS-S2842)) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/168> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #73: "normalize-type" buffering
by armedbear 08 Aug '12

08 Aug '12

#73: "normalize-type" buffering -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: task | Status: new Priority: major | Milestone: Component: CLOS | Version: Keywords: performance | -------------------------+-------------------------------------------------- Peter Graves points out that with his "canonicalize-type" buffering, he achieved measurable performance gain in XCL. We want to do the same in ABCL. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/73> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[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] #32: Modify the currently disabled runtime-class.lisp code to not require ASM
by armedbear 28 Jul '12

28 Jul '12

#32: Modify the currently disabled runtime-class.lisp code to not require ASM --------------------------------------------------------------------+------- Reporter: vvoutilainen | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: jvm bytecode compiler runtime dynamic class generation | --------------------------------------------------------------------+------- It's possible to define classes at runtime, by generating bytecode and loading it from the generated binary data, without ever writing it to a temporary file. runtime-class.lisp does that, but it requires an external bytecode library (ASM). ABCL has all the functionality for this to be done without ASM, so the task is to modify the runtime-class.lisp code so that ASM is no longer required and the code can be taken to be part of the build. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/32> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2