#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
#226: Generate list of symbols for autoloading at build-time
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: enhancement | Status: new
Priority: major | Milestone:
Component: build | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently, our list of symbols to be set up for auto-loading is
a manual maintenance effort which makes ABCL fragile with respect
to refactoring.
My idea would be to have an auto-collected list, with two (hand-coded)
lists: one to include additional symbols and the other to exclude symbols
(e.g. to reduce the size of the symbol list).
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/226>
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
#202: ENSURE-GENERIC-FUNCTION assumes LAMBDA-LIST is NIL
--------------------+-------------------------------------------------------
Reporter: gpfeil | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: (A)MOP | Version: 1.1.0-dev
Keywords: |
--------------------+-------------------------------------------------------
I know ABCL's MOP isn't complete yet, but I just saw this with ENSURE-
GENERIC-FUNCTION.
{{{
(ensure-generic-function 'make-instance
:method-combination *contract-method-
combination*)
}}}
complains that the lambda list NIL isn't compatible with MAKE-INSTANCE's
lambda list. If I don't pass the :LAMBDA-LIST parameter, it shouldn't
attempt to change the lambda list.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/202>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#221: Stack exhaustion on invocation of function in non-existing package
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: defect | Status: new
Priority: blocker | Milestone: 1.1.0
Component: interpreter | Version:
Keywords: |
-------------------------+--------------------------------------------------
Note that it's not related to Hunchentoot or Quicklisp, but can be
triggered by any function.
Armed Bear Common Lisp 1.1.0-dev-svn-14016M
Java 1.6.0_26 Sun Microsystems Inc.
Java HotSpot(TM) Client VM
Low-level initialization completed in 0.317 seconds.
Startup completed in 1.76 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (ql:quickload :hunchentoot)
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
READER-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
#<THREAD "interpreter" {1479EF9}>: Debugger invoked on condition of type
SIMPLE-ERROR
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/221>
armedbear <http://common-lisp.net/project/armedbear>
armedbear