#228: Need to implement autoloader facility for SETF functions
-------------------------+--------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone: 1.2.0
Component: java | Version:
Keywords: |
-------------------------+--------------------------------------------------
The subject says it all: we currently have infrastructure for normal
functions, but we need infrastructure for SETF functions as well.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/228>
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
#251: ffi callbacks don't unbox integer values
-----------------------+----------------------------------------------------
Reporter: sboukarev | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone: 1.1.0
Component: java | Version: 1.1.0-dev
Keywords: |
-----------------------+----------------------------------------------------
It very well may be a cffi issue.
Compile the following C code
with gcc -shared test.c -o test.so
{{{
#ifdef WIN32
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT
#endif
DLLEXPORT
short test(short (*f)(short, short))
{
return f(23, 24);
}
}}}
Then
{{{
(cffi:load-foreign-library "/tmp/test.so")
(cffi:defcfun test :short
(function :pointer))
(cffi:defcallback (test-callback)
:short ((a :short) (b :short))
(+ a b))
}}}
And finally
{{{
(test (cffi:get-callback 'test-callback)) =>
The value #<java.lang.Short 23 {5EE76547}> is not of type NUMBER.
}}}
That's on 64-bit x86 linux, with OpenJDK 1.6.0_24 and jna downloaded by
maven.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/251>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#258: Compiler bug in call to MAX
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: 1.1.0
Component: compiler | Version: 1.1.0-dev
Keywords: |
----------------------+-----------------------------------------------------
Eric Marsten reports in
http://article.gmane.org/gmane.lisp.armedbear.devel/2611:
The following illustrates what looks like a bug in the compiler's
handling of type propagation (bug disappears without the type
declaration).
{{{
CL-USER(25): (lisp-implementation-version)
"1.1.0-dev-svn-14222M"
"OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_03-b21)"
"amd64-Linux-3.3.0-trunk-amd64)"
CL-USER(26): (defun foo (a b)
(declare (type (integer * 6488318769) b))
(max 1 (the (integer * 5711538578) a) b 2 1351352470))
FOO
CL-USER(27): (foo 5711538444 6488318765)
6488318765
CL-USER(28): (compile 'foo)
FOO
NIL
NIL
CL-USER(29): (foo 5711538444 6488318765)
1351352470
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/258>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#262: fails to (require :jna)
--------------------------------------------+-------------------------------
Reporter: https://openid.fau.de/eg74yneg | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone:
Component: abcl-contrib | Version:
Keywords: |
--------------------------------------------+-------------------------------
{{{
The value NIL is not of type REAL.
[Condition of type TYPE-ERROR]
}}}
backtrace attached. maven 3.0.4 is installed
{{{
mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get
-DrepoUrl=repo.maven.apache.org -Dartifact=net.java.dev.jna:jna:3.5.1
}}}
Works just fine and downloads jna
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/262>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
-------------------------+--------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: minor | Milestone: 1.0.1
Component: interpreter | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
[http://article.gmane.org/gmane.lisp.armedbear.devel/2138 Marshall Abrams
reports:]
{{{
It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's
handling of negative numbers when it has to round up. (Forgive me if this
is a known issue--I didn't find it when I searched the bug list and
mailing list archives--or if there's something I'm misunderstanding.)
The first group of examples use the F directive for comparison to show
that the problem seems to be specific to dollarsign. (I added blank lines
between example groups for easy reading.)
The second group of examples illustrates a problem using dollarsign with
negative numbers. The output is about 10x too large, and doesn't seem to
be getting rounded properly. I'm guessing that the out of bounds error is
the result of the same issue.
The third group of examples shows that the problem doesn't seem to occur
with positive numbers, although there's still an extra negative sign
preprended.
Thank you-
Marshall Abrams
Armed Bear Common Lisp 1.0.0-svn-13663
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.7 seconds.
Startup completed in 2.211 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (format t "~,vf" 3 -0.1768522)
-0.177
NIL
CL-USER(2): (format t "~,vf" 2 -0.1768522)
-0.18
NIL
CL-USER(3): (format t "~,vf" 1 -0.1768522)
-0.2
NIL
CL-USER(4): (format t "~,vf" 0 -0.1768522)
-0.
NIL
CL-USER(5): (format t "~$" -0.1768522)
--1.6
NIL
CL-USER(6): (format t "~v$" 3 -0.1768522)
--1.75
NIL
CL-USER(7): (format t "~v$" 2 -0.1768522)
--1.6
NIL
CL-USER(8): (format t "~v$" 1 -0.1768522)
#<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type
TYPE-ERROR
Array index out of bounds: 2
Restarts:
0: TOP-LEVEL Return to top level.
[1] CL-USER(9): 0
CL-USER(10): (format t "~v$" 0 -0.1768522)
--0.
NIL
CL-USER(11): (format t "~$" 0.1768522)
0.18
NIL
CL-USER(12): (format t "~v$" 3 0.1768522)
0.177
NIL
CL-USER(13): (format t "~v$" 2 0.1768522)
0.18
NIL
CL-USER(14): (format t "~v$" 1 0.1768522)
0.2
NIL
CL-USER(15): (format t "~v$" 0 0.1768522)
0.
NIL
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/190>
armedbear <http://common-lisp.net/project/armedbear>
armedbear