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

[armedbear-ticket] [armedbear] #225: One of the paths in STD-COMPUTE-DISCRIMINATING function not working
by armedbear 01 Sep '12

01 Sep '12

#225: One of the paths in STD-COMPUTE-DISCRIMINATING function not working ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: CLOS | Version: Keywords: | ------------------------+--------------------------------------------------- In r14021, I've committed a note regarding a code path that's not working. Creating this ticket to create a log of the fact that I've been investigating and my findings so far. (Which are in the code now.) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/225> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #216: JVM stack inconsistency triggered by compiler
by armedbear 01 Sep '12

01 Sep '12

#216: JVM stack inconsistency triggered by compiler -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -----------------------+---------------------------------------------------- {{{ CL-USER(50): (lisp-implementation-version) "1.1.0-dev-svn-13998M" CL-USER(51): (lambda (a b c) (declare (optimize (safety 0))) (ash 3 (min 2 (the integer (block b (catch 'ct a)))))) #<FUNCTION (LAMBDA (A B C)) {374FB6BE}> CL-USER(52): (compile nil *) ; Caught STYLE-WARNING: ; The variable B is defined but never used. ; Caught STYLE-WARNING: ; The variable C is defined but never used. #<THREAD "interpreter" {5D4AAA93}>: Debugger invoked on condition of type INTERNAL-COMPILER-ERROR Stack inconsistency detected in NIL at index 36: found 2, expected 1. Restarts: 0: CONTINUE Eventually use interpreted form instead 1: TOP-LEVEL Return to top level. }}} (reported by Eric Marsden on armedbear-devel July 10, 2012) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/216> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #189: Compiler fails for 'unsigned-byte type declaration
by armedbear 01 Sep '12

01 Sep '12

#189: Compiler fails for 'unsigned-byte type declaration --------------------------------+------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: 1.0.1 Component: compiler | Version: 1.0 Keywords: compiler, has-test | --------------------------------+------------------------------------------- From [http://article.gmane.org/gmane.lisp.armedbear.devel/2122 On <armedbear-devel@…>, Eric Marsden reports]: The following code seems to be miscompiled (works fine with an INTEGER type declaration). {{{ CL-USER(23): (lisp-implementation-version) "1.1.0-dev-svn-13695M" CL-USER(24): (compile nil (lambda (a) (declare (type unsigned-byte a)) (max 28105919 a 1016934843))) #<FUNCTION (LAMBDA (A)) {2D53EAFD}> NIL NIL CL-USER(25): (funcall * 10545160975) 1955226383 }}} (From ansi-test/random suite) -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/189> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #207: DECLARE should signal conditions when type declaration are violated
by armedbear 01 Sep '12

01 Sep '12

#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

1 3

[armedbear-ticket] [armedbear] #219: Keyword argument checking for lambda lists is too lenient for ANSI
by armedbear 21 Aug '12

21 Aug '12

#219: Keyword argument checking for lambda lists is too lenient for ANSI ------------------------------+--------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.0.1 Keywords: ansi-conformance | ------------------------------+--------------------------------------------- From #abcl on Thu Jul 26 2012 {{{ <chturne> I don't run the latest and greatest ABCL, but you allow &BODY in ordinary lambda lists, which is an ANSI violation. There are probably other such violations, as I see little discrimination in the argument parsing code. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/219> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[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] #238: Bad error when reading #S(...) for a partially defined structure
by armedbear 14 Aug '12

14 Aug '12

#238: Bad error when reading #S(...) for a partially defined structure -----------------------+---------------------------------------------------- Reporter: sboukarev | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | -----------------------+---------------------------------------------------- {{{ (defstruct struct a) (defvar *t* #S(struct :a 1)) }}} Running compile-file on it results in "The assertion NIL failed." At compile-time defstruct lets the compiler know that the structure exists, but the constructor and predicate functions are not defined until load time. #S tries to call a stump version of one of these functions. After exiting the debugger calling either (make-struct) or (struct-p) results in the same assertion failure -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/238> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #236: Bad error message for malformed forms
by armedbear 14 Aug '12

14 Aug '12

#236: Bad error message for malformed forms ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=aitoawngxgnmuwky5p6prytkvosetygr8i… | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | ----------------------------------------------------------------------------------------------+ Evaluating (1 2 3) yields "The value 1 is not of type LIST." The fix for this is trivial, attached. And compiling: {{{ (compile nil '(lambda () (1 2 3))) }}} {{{ ; Caught ERROR: ; COMPILE-FORM unhandled case (1 2 3) #<THREAD "interpreter" {1775831E}>: Debugger invoked on condition of type TYPE-ERROR The value #<EQUAL HASH-TABLE 0 entries, 11 buckets {23F3329A}> is not of type STRUCTURE-OBJECT. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/236> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3