#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
#133: Mixed case inconsistency in TRANSLATE-LOGICAL-PATHNAMES
-------------------------+--------------------------------------------------
Reporter: mevenson | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: 0.25
Component: interpreter | Version: 0.24
Keywords: |
-------------------------+--------------------------------------------------
Jonathan Boca reports
{{{
As the following code and transcript demonstrate,
translate-logical-pathname appears to be downcasing paths
inconsistently:
;;; test.cl
(setf (logical-pathname-translations "foo")
'(("foo:bar;*.lisp" "/FooRoot/bar/*.lisp")
("foo:*.lisp" "/FooRoot/*.lisp")))
;;; In the following pathname translation, the entire path is downcased
(pprint (translate-logical-pathname "foo:bar;foobar.lisp"))
;;; In each of the next two, the entire path EXCEPT for the host is
downcased --
;;; the host is unchanged
(pprint (translate-logical-pathname "foo:foobar.lisp"))
(pprint (translate-logical-pathname "foo:Foobar.lisp"))
---
Armed Bear Common Lisp 0.24.0
Java 1.6.0_22 Apple Inc.
Java HotSpot(TM) Client VM
Low-level initialization completed in 0.478 seconds.
Startup completed in 1.386 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (load "test.cl")
#P"/fooroot/bar/foobar.lisp"
#P"/FooRoot/foobar.lisp"
#P"/FooRoot/foobar.lisp"
T
CL-USER(2):
---
SBCL and CLISP both produce the following output for the above code:
#P"/FooRoot/bar/foobar.lisp"
#P"/FooRoot/foobar.lisp"
#P"/FooRoot/foobar.lisp"
Allegro's ALISP and MLISP both produce the following:
#P"/FooRoot/bar/foobar.lisp"
#P"/FooRoot/foobar.lisp"
#P"/FooRoot/Foobar.lisp"
}}}
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/133>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#180: stack overflow with lparallel
---------------------------------------------------------+------------------
Reporter: mevenson | Owner: mevenson
Type: defect | Status: new
Priority: major | Milestone: unscheduled
Component: other | Version: 1.0
Keywords: lparallel stack-overflow jvm multi-threaded |
---------------------------------------------------------+------------------
With the [http://lparallel.com very interesting lparallel library], ABCL
can get into some stack overflow situations (especially on newer JVM
implementations).
Also, I get the feeling that the BORDEAUX-THREADS mapping for ABCL is not
optimal, as when I run LPARALLEL full out on a many worker kernel, I don't
maximize the actual available CPU/RAM on a multicore x64 system.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/180>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#244: compile doesn't return correct values for warnings-p and failure-p
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone: 1.1.0
Component: compiler | Version:
Keywords: |
------------------------+---------------------------------------------------
(compile nil '(lambda () (char=)))
; Caught WARNING:
; Wrong number of arguments for CHAR=.
; Compilation unit finished
; Caught 1 WARNING condition
#<FUNCTION (LAMBDA ()) {456E3EB3}>
NIL
NIL
while it should be T, T.
jvm-compile, which handles this doesn't succeed because the underlying
with-compilation-unit eats all the warnings and errors so that
jvm-compile's handler-bind doesn't get a piece of them. Binding
*resignal-compiler-warnings* to T inside jvm-compile resolves this.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/244>
armedbear <http://common-lisp.net/project/armedbear>
armedbear
#169: Conformance with section 3.2.4.4 (externalized objects in COMPILE-FILE)
------------------------+---------------------------------------------------
Reporter: ehuelsmann | Owner: ehuelsmann
Type: defect | Status: new
Priority: major | Milestone:
Component: compiler | Version:
Keywords: |
------------------------+---------------------------------------------------
Currently, if the same object is encountered in multiple forms being
compiled, that object is externalized on each encounter.
The spec requires that identical objects in the source be identical in the
compiled file as per the first sentence of
[http://www.lispworks.com/documentation/HyperSpec/Body/03_bdd.htm section
3.2.4.4].
As a consequence, we'll need an ''object table'' of some kind, allowing
the object to be referenced further down in the file compilation.
--
Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/169>
armedbear <http://common-lisp.net/project/armedbear>
armedbear