#334: Forms evaluated with `--eval` not in a "correct" interpreter environment
-----------------------+-----------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.3.0
Component: other | Version: 1.3.0-dev
Resolution: | Keywords: asdf
-----------------------+-----------------------
Comment (by mevenson):
The attached patch now correctly throws an semi-intelligble error on the
Java side when a SHARPSIGN-DOT macro is passed as part of an '--eval'
argument.
This confirms that the problem seems to lie in the use of REQUIRE forms
within '--eval' args.
{{{
quoth:~/work/asdf$ abcl --noinit --eval '`#.(load (string `|test
/script-support.lisp|) :verbose t :print t)'
Armed Bear Common Lisp 1.3.0-dev
Java 1.7.0_45 Oracle Corporation
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.475 seconds.
Startup completed in 2.41 seconds.
; Loading /Users/evenson/work/asdf/test/script-support.lisp ...
#<PACKAGE ASDF-TEST>
#<PACKAGE ASDF-TEST>
NIL
NIL
*TRACE-SYMBOLS*
*DEBUG-ASDF*
*QUIT-WHEN-DONE*
VERBOSE
NIL
NIL
ASYM
ACALL
ASYMVAL
ASYMVAL
Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function
object: (bqv).'.
CL-USER(1):
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/334#comment:1>
armedbear <http://abcl.org>
armedbear
#314: CL:FORMAT problems with ~F
------------------------------+---------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone: 1.2.0
Component: interpreter | Version: 1.2.0-dev
Keywords: ansi-conformance |
------------------------------+---------------------------------------------
[http://article.gmane.org/gmane.lisp.armedbear.devel/2838 Carlos Ungil
reports]
{{{
> (format t "~,2f" 0.999)
1.0 ;; should be 1.00
}}}
I think there is a problem here as well:
{{{
> (format t "~5f" 0.00000001)
.0000 ;; should print " 0.0"
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/314>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#313: (COERCE 3 '(FLOAT * *)) fails
----------------------------------------------------------------------------------------------+
Reporter: https://www.google.com/accounts/o8/id?id=aitoawmirmkhhsmhgi36otvnjvwc_guuvf… | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: other | Version: 1.2.0-dev
Keywords: coerce, float |
----------------------------------------------------------------------------------------------+
(COERCE 3 '(FLOAT * *)) fails with "3 cannot be converted to type (FLOAT *
*)".
Similar expressions with other float types, e.g. with DOUBLE-FLOAT,
SINGLE-FLOAT, LONG-FLOAT, SHORT-FLOAT, all fail.
Similar expressions with explicit bounds, e.g. (COERCE 3 '(FLOAT -10f0
10f0)) and other float types, all fail.
ABCL version = Armed Bear Common Lisp 1.2.0-dev (built from svn r14454).
Found this while running Maxima test suite. ev(zeta(3 + %i), numer)
triggers this error.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/313>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#311: UIOP fails to load
-----------------------+----------------------------------------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone: 1.2.0
Component: libraries | Version: 1.2.0-dev
Keywords: |
-----------------------+----------------------------------------------------
Anton noticed with the cl-test-grid results that UIOP fails to load on
abcl-1.2.0-dev which I bisected to the following changeset
{{{
The first bad revision is:
changeset: 2305:fbc9c3f7befc
user: mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f
date: Sun Jan 27 09:47:48 2013 +0000
summary: asdf-2.26.143.1: pre asdf-2.27 plus workaround for SETF
autoloader problems.
}}}
which corresponds to http://trac.common-lisp.net/armedbear/changeset/14362
.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/311>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#312: BORDEAUX-THREADS-TEST::CONDITION-VARIABLE hangs
---------------------------------------------------+------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: 1.2.0
Component: (A)MOP | Version: 1.2.0-dev
Keywords: quicklisp-regression bordeaux-threads |
---------------------------------------------------+------------------------
[http://news.gmane.org/gmane.lisp.armedbear.devel Stellian notes that]
after loading BORDEAUX-THREADS via Quicklisp, the following test hangs the
invoking thread:
{{{
(fiveam:run 'bordeaux-threads-test::condition-variable)
}}}
Problem does not appear to exist with abcl-1.1.0
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/312>
armedbear <http://common-lisp.net/project/armedbear>
armedbear