#227: Invocation of an undefined function in a fresh ABCL crashes
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: somebody
Type: defect | Status: new
Priority: blocker | Milestone:
Component: other | Version:
Keywords: |
------------------------+---------------------------------------------------
Evaluating (slot-boundp) in a freshly started ABCL ("naked", not in SLIME)
causes too many errors and terminates ABCL hard. No idea where the error
is yet, but it's probably something to do with auto loading.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/227>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#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
#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
#224: Autoloader fails when *read-XXXX* variables bound to non-standard values
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone: 1.1.0
Component: java | Version: 1.1.0-dev
Keywords: |
------------------------+---------------------------------------------------
Durward McDonell reports:
(defmacro foo-bar (s)
`(sublis '((foo . bar)) ,s))
(defun foo-bar-rb ()
(let ((*read-base* #x10)
(it (read)))
(eval it)))
Load this code, then execute (foo-bar-rb).
It will wait for input. Type (foo-bar '(foo)).
I would expect this to evaluate to (bar), but
abcl gives a FASL version mismatch, where it
seems that it is reading the FASL in the new
base (16 instead of 10), and reports "found '56'
but expected '38' in sublis".
Blake McBride comments:
I put his code in a file named yyy.lisp. I did not compile it. There is
no yyy.fasl.
CL-USER(1): (load "yyy.lisp")
T
CL-USER(2): (foo-bar-rb)
(foo-bar '(foo))
Maximum error depth exceeded (11 nested errors) with 'FASL version
mismatch; found '57' but expected '39' in with-standard-io-syntax'.
CL-USER(3):
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/224>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#206: COMPILER-UNSUPPORTED-FEATURE-ERROR is derived from condition, rather than
from ERROR
----------------------------------------------------------------------------------------------+
Reporter: https://www.google.com/accounts/o8/id?id=aitoawmcq6mzgezjmpqv2tjhvs6isymf6t… | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone:
Component: compiler | Version:
Keywords: |
----------------------------------------------------------------------------------------------+
Hello.
My coade loads some ASDF systems, and wraps the asdf:operate call
into handler-case
{{{
(handler-case (asdf:operate ...)
(serious-condition (condition) (...
}}}
This should help me to handle the build errors.
But when I load the let-plus library, ABCL falls into debugger:
{{{
#<THREAD "interpreter" {53B73EA7}>: Debugger invoked on condition of type
COMPILER-UNSUPPORTED-FEATURE-ERROR
COMPILE-FORM unhandled case ((ANAPHORA:IT #:THIS-S100224))
Restarts:
0: RETRY Retry compiling #<ASDF:CL-SOURCE-FILE "let-plus" "let-plus">.
1: ACCEPT Continue, treating compiling #<ASDF:CL-SOURCE-FILE "let-plus"
"let-plus"> as having been successful.
2: ABORT Give up on "let-plus"
[1] LET-PLUS(1): 0
}}}
This happens because COMPILER-UNSUPPORTED-FEATURE-ERROR is derived from
CONDITION (see
src/org/armedbear/lisp/CompilerUnsupportedFeatureError.java)
CLHS says: "Conditions of type error might be signaled by the compiler in
situations where the compilation cannot proceed without intervention."
http://www.lispworks.com/documentation/lw51/CLHS/Body/03_be.htm
It would be better to derive COMPILER-UNSUPPORTED-FEATURE-ERROR from ERROR
(or at least from SERIOUS-CONDITION)
- Anton Vodonosov
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/206>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#198: Hunchentoot load failure
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: assigned
Priority: blocker | Milestone: 1.1.0
Component: compiler | Version: 1.1.0-dev
Keywords: |
----------------------+-----------------------------------------------------
Comment(by mevenson):
The taskmaster.abcl fasl doesn't seem to be a problem any more.
But Hunchentoot still fails to load, as (require :jna) fails even with a
suitable mvn installed.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/198#comment:9>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#220: Lambda list checking too lenient
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone: 1.1.0
Component: java | Version: 1.1.0-dev
Keywords: |
------------------------+---------------------------------------------------
ArgumentListProcessor allows &body as a variable indicator, which is in
violation with the spec
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/220>
armedbear <http://common-lisp.net/project/armedbear>
armedbear