#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
#240: FIND-CLASS does not implement 3-argument behavior
-----------------------+----------------------------------------------------
Reporter: rschlatte | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: CLOS | Version:
Keywords: |
-----------------------+----------------------------------------------------
Currently find-class does not use a supplied third (environment)
parameter. (LispClass.java line 331 has a FIXME to that effect.) This
blocks the fix for #239 since classes cannot be inspected at compile-time.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/240>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#159: COMPILE-FILE-16 and -17 failing for the wrong reason
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone:
Component: java | Version:
Keywords: |
------------------------+---------------------------------------------------
The error emitted from COMPILE-FILE-16 and -17 is "Could not form URL for
"CLTEST:COMPILE-FILE-16", with a similar message for -17.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/159>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#155: ABCL fails to start with '#' in Path
----------------------+-----------------------------------------------------
Reporter: mevenson | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone: 0.26
Component: other | Version: 0.24
Keywords: |
----------------------+-----------------------------------------------------
{{{
evenson@saturn:~/work/abcl-#154$ pwd
/export/home/evenson/work/abcl-#154
evenson@saturn:~/work/abcl-#154$ ./abcl
Armed Bear Common Lisp 0.26.0-dev
Java 1.6.0_25 Sun Microsystems Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.645 seconds.
org.armedbear.lisp.IntegrityError
at
org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1588)
at org.armedbear.lisp.Primitive.execute(Primitive.java:113)
at org.armedbear.lisp.Symbol.execute(Symbol.java:790)
at org.armedbear.lisp.Lisp.error(Lisp.java:374)
at org.armedbear.lisp.ZipCache.get(ZipCache.java:213)
at org.armedbear.lisp.ZipCache.get(ZipCache.java:102)
at org.armedbear.lisp.Pathname.truename(Pathname.java:2187)
at org.armedbear.lisp.Load.findLoadableFile(Load.java:68)
at org.armedbear.lisp.Load.loadSystemFile(Load.java:261)
at
org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172)
at
org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102)
at org.armedbear.lisp.Main$1.run(Main.java:46)
at java.lang.Thread.run(Thread.java:662)
ERROR placeholder called with arguments:
#<FILE-ERROR {163DC0BB}>
Failed to get cached ZipFile because java.util.zip.ZipException: error in
opening zip file
Exception in thread "interpreter" org.armedbear.lisp.IntegrityError
at
org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1588)
at org.armedbear.lisp.Primitive.execute(Primitive.java:113)
at org.armedbear.lisp.Symbol.execute(Symbol.java:790)
at org.armedbear.lisp.Lisp.error(Lisp.java:374)
at org.armedbear.lisp.ZipCache.get(ZipCache.java:213)
at org.armedbear.lisp.ZipCache.get(ZipCache.java:102)
at org.armedbear.lisp.Pathname.truename(Pathname.java:2187)
at org.armedbear.lisp.Load.findLoadableFile(Load.java:68)
at org.armedbear.lisp.Load.loadSystemFile(Load.java:261)
at
org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172)
at
org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102)
at org.armedbear.lisp.Main$1.run(Main.java:46)
at java.lang.Thread.run(Thread.java:662)
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/155>
armedbear <http://common-lisp.net/project/armedbear>
armedbear