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

[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] #226: Generate list of symbols for autoloading at build-time
by armedbear 18 Aug '12

18 Aug '12

#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

1 8

[armedbear-ticket] [armedbear] #208: Files loaded via "--load <FILE>" on the command line have no pathname defaults
by armedbear 14 Aug '12

14 Aug '12

#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

1 1

[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] #214: Stack overflow when compiler macro with fallback is triggered
by armedbear 12 Aug '12

12 Aug '12

#214: Stack overflow when compiler macro with fallback is triggered ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: compiler | Version: 1.0.1 Keywords: | ----------------------+----------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2352 James Lawerence reports] {{{ (eval-when (:compile-toplevel :load-toplevel :execute) (defun foo () 99) (define-compiler-macro foo () `(locally (declare (notinline foo)) (foo)))) (defun call-foo () (foo)) }}} Of course, the use case is a compiler macro that says, "OK, let's optimize! ... Never mind, I don't want to optimize that." {{{ Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.7.0_04 Oracle Corporation [...] ; (DEFUN FOO ...) ; (DEFINE-COMPILER-MACRO FOO ...) ; (DEFUN CALL-FOO ...) java.lang.StackOverflowError at org.armedbear.lisp.StructureObject$pf_make_structure.execute(StructureObject.java:671) at org.armedbear.lisp.Symbol.execute(Symbol.java:865) at org.armedbear.lisp.LispThread.execute(LispThread.java:760) at org.armedbear.lisp.jvm_714.execute(jvm.lisp:567) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/214> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #195: prompt is displayed twice when evaluating NIL at the REPL
by armedbear 11 Aug '12

11 Aug '12

#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

1 3

[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] #202: ENSURE-GENERIC-FUNCTION assumes LAMBDA-LIST is NIL
by armedbear 06 Aug '12

06 Aug '12

#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

1 2

[armedbear-ticket] [armedbear] #221: Stack exhaustion on invocation of function in non-existing package
by armedbear 05 Aug '12

05 Aug '12

#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

1 1