#290: Compiling (defvar *foo* '(quote . x)) throws an error
-----------------------+----------------------------------------------------
Reporter: sboukarev | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-----------------------+----------------------------------------------------
The value X is not of type LIST.
The attached patch fixes it by using proper-list-of-length-p instead of
length.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/290>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#212: ABCL crash when running test suites of many libraryies
----------------------------------------------------------------------------------------------+
Reporter: https://www.google.com/accounts/o8/id?id=aitoawmcq6mzgezjmpqv2tjhvs6isymf6t… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: other | Version: 1.0.1
Keywords: |
----------------------------------------------------------------------------------------------+
I encountered crash of ABCL 1.0.1 when running tests of many libraries.
(Some work may be done to isolate the problem by experimenting with the
set of libraries used, but I didn't find time for this during the last 2
month, so decided to just submit an exact way to reproduce the bug).
I supposed it may be a memory issue, and increased memory by JVM options
(as shown below), but it doesn't help.
To ensure the problem is reproducible I've created a branch of my project
and create a script which load particular version of quicklisp
(quicklisp is bootstrapped in local directory to avoid interference with
the quickips installation user may have on his computer).
The steps to reproduce:
git clone git://github.com/cl-test-grid/cl-test-grid.git
cd cl-test-grid
git checkout abcl-crash-reproduce
java -Xmx2048M -XX:ThreadStackSize=12048 -XX:MaxPermSize=256m -jar
C:\Users\anton\unpacked\abcl\abcl-bin-1.0.1\abcl.jar --noinit --nosystem
--batch --load crash-abcl.lisp > crash-abcl.log 2>&1
[ ... lot of output, and after ~20 mins ABCL crashed ]
crash-abcl.log is attached. The stacktrace of interest is at the bottom.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/212>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#284: checks in ensure-generic-function-using-class should occur later
-------------------------+--------------------------------------------------
Reporter: rschlatte | Owner: rschlatte
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: (A)MOP | Version:
Keywords: |
-------------------------+--------------------------------------------------
In ensure-generic-function-using-class, abcl is making a few sanity checks
and issuing errors, and it is correct to do so according to the HyperSpec.
However, since they are done already at such an early stage, some useful
MOP idioms are not easily expressible, or at least need to be expressed
differently, and I think it would be better to perform the checks at a
later stage, for example inside shared-initialize.
The concrete case that I encounter is the :lambda-list initialization
parameter. In AspectL and filtered-functions, I need to be able to modify
the lambda list internally, by adding one or two extra required
parameters. I do this, extremely roughly, as follows:
{{{
(defmethod initialize-instance :around ((gf my-generic-function) &rest
initargs &key lambda-list)
(apply #'call-next-method gf
:lambda-list (list* extra-parameters… lambda-list)
initargs))
}}}
All methods that are added to such generic functions also get the extra
parameters padded in during method metaobject initialization. However, due
to this, the lambda list that ensure-generic-function-using-class sees is,
by definition, not congruent with potentially existing methods, and thus
complains about this fact with an error. If the check would only occur
later (for example in shared-initialize on standard-generic-function),
then the modifications would correctly pass through. At least, that is the
case in all the other MOP implementations in which AspectL and filtered-
functions work.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/284>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#292: Large generated functions problems
-----------------------+----------------------------------------------------
Reporter: sboukarev | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
-----------------------+----------------------------------------------------
Some components of f2cl, which are generated from Fortran, have functions
with lots of code in it.
If there's too much code between go and a label, ABCL can't compile it.
{{{
(defmacro labels-galore (n)
`(prog ()
(go label1)
label2
,@(loop for i to n
collect `(print ,i) )
(return)
label1
(go label2)))
(defun test ()
(labels-galore 10000))
}}}
The assertion (<= -32768 JVM::OFFSET 32767) failed.
Increasing the number will eventually lead to a stack overflow.
Just a large body:
{{{
(defmacro large-body (n)
`(progn
,@(loop for i to n
collect `(print ,i))))
(defun test ()
(large-body 10000))
}}}
The assertion (< 0 (LENGTH JVM::C) 65536) failed.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/292>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#286: #+nil(a . ) fails
-----------------------+----------------------------------------------------
Reporter: sboukarev | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: other | Version:
Keywords: |
-----------------------+----------------------------------------------------
"Unmatched right parenthesis."
While #+nil(a . . ) is ok
And #+nil(. a ) is "The variable A is unbound."
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/286>
armedbear <http://common-lisp.net/project/armedbear>
armedbear