#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
#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
#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
#208: Files loaded via "--load <FILE>" on the command line have no pathname
defaults
-------------------------+--------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone: 1.1.0
Component: interpreter | Version: 1.1.0-dev
Keywords: |
-------------------------+--------------------------------------------------
[http://article.gmane.org/gmane.lisp.armedbear.devel/2291 Wei-Lun Chiu
reports]
{{{
I have a file:
---- load-pathname.lisp -----
(print *load-pathname*)
-----------------------------
When loaded, I get this:
java.exe -cp "abcl.jar" org.armedbear.lisp.Main --load load-path.lisp==>
#P"load-path.lisp"
According to CLHS, I believe this is wrong?
During a call to load, *load-pathname* is bound to the pathname denoted
by the the first argument to load, merged against the defaults; that is,
it is bound to (pathname (merge-pathnames filespec)).
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/208>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#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
#195: prompt is displayed twice when evaluating NIL at the REPL
-------------------------+--------------------------------------------------
Reporter: rschlatte | Owner: ehuelsmann
Type: defect | Status: new
Priority: trivial | Milestone:
Component: interpreter | Version:
Keywords: |
-------------------------+--------------------------------------------------
{{{
$ abcl
Armed Bear Common Lisp 1.1.0-dev
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.724 seconds.
Startup completed in 2.336 seconds.
Loading /home/rudi/.abclrc completed in 11.57 seconds.
Type ":help" for a list of available commands.
CL-USER(1): NIL
NIL
CL-USER(2): CL-USER(2):
}}}
Reported by Blake McBride Jan 16, 2012
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/195>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#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