armedbear-ticket January 2012

armedbear-ticket@common-lisp.net

1 participants
37 discussions

[armedbear-ticket] [armedbear] #166: Stream wrapping streams conflict with pretty printer
by armedbear 31 Mar '13

31 Mar '13

#166: Stream wrapping streams conflict with pretty printer ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- The stream wrapping streams * BroadcastStream * CaseFrobStream * EchoStream * TwoWayStream * ConcatenatedStream can't wrap Gray streams and the XP-STRUCTURE pretty printer structure. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/166> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 11

[armedbear-ticket] [armedbear] #188: FLEXI-STREAMS fails when testing CL-PPCRE
by armedbear 12 Mar '13

12 Mar '13

#188: FLEXI-STREAMS fails when testing CL-PPCRE ------------------------------------------------------------------+--------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.0.1 Component: libraries | Version: Keywords: quicklisp, asdf, flexi-stream,cl-ppcre, asdf:test-op | ------------------------------------------------------------------+--------- {{{ ; Wrote /home/weblogic/.cache/common-lisp/abcl-1.1.0-dev- fasl38-linux-x64/home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/ASDF-TMP-tests.abcl (0.13 seconds) ; Loading /home/weblogic/.cache/common-lisp/abcl-1.1.0-dev- fasl38-linux-x64/home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/tests.abcl ... ; Loaded /home/weblogic/.cache/common-lisp/abcl-1.1.0-dev- fasl38-linux-x64/home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/tests.abcl (0.016 seconds) ; Compiling /home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/perl-tests.lisp ... ; (IN-PACKAGE :CL-PPCRE-TEST) ; (DEFVAR *TESTS-TO-SKIP* ...) ; (DEFUN CREATE-STRING-FROM-INPUT ...) ; (DEFUN PERL-TEST ...) ; Wrote /home/weblogic/.cache/common-lisp/abcl-1.1.0-dev- fasl38-linux-x64/home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/ASDF-TMP-perl-tests.abcl (0.098 seconds) ; Loading /home/weblogic/.cache/common-lisp/abcl-1.1.0-dev- fasl38-linux-x64/home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/perl-tests.abcl ... ; Loaded /home/weblogic/.cache/common-lisp/abcl-1.1.0-dev- fasl38-linux-x64/home/weblogic/quicklisp/dists/quicklisp/software/cl- ppcre-2.0.3/test/perl-tests.abcl (0.026 seconds) Test: Running tests in file "perltestdata" 1: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 2: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 3: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 4: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 5: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 6: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 7: got an unexpected error: The value #<FLEXI-STREAMS:FLEXI-INPUT-STREAM {47275E71}> is not of type STREAM. 8: }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/188> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #65: UTF-32 strings support
by armedbear 11 Mar '13

11 Mar '13

#65: UTF-32 strings support ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- ABCL uses Java char[]s to represent its strings. However, the char type can only represent values in the BMP (Basic Multilingual Plane), because only the BMP can be represented using 16 bits. For supplementary characters (all Unicode chars outside the BMP), it uses a pair of surrogate characters (UTF-16). Common Lisp programs don't expect this and need strings to be represented using complete characters. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/65> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 6

[armedbear-ticket] [armedbear] #152: ql:closer-mop doesn't work
by armedbear 14 Feb '13

14 Feb '13

#152: ql:closer-mop doesn't work --------------------------------+------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 0.26 Component: CLOS | Version: 1.0 Keywords: clos quicklisp mop | --------------------------------+------------------------------------------- [http://common-lisp.net/project/closer/closer-mop.html CLOSER-MOP] fails to load via [http://quicklisp.org QuickLisp]. As part of resolving this ticket, it would be nice to produce a summary of what is incomplete in ABCL wrt. MOP. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/152> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 16

[armedbear-ticket] [armedbear] #190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
by armedbear 09 Dec '12

09 Dec '12

#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

1 4

[armedbear-ticket] [armedbear] #159: COMPILE-FILE-16 and -17 failing for the wrong reason
by armedbear 09 Dec '12

09 Dec '12

#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

1 8

[armedbear-ticket] [armedbear] #155: ABCL fails to start with '#' in Path
by armedbear 09 Dec '12

09 Dec '12

#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

1 5

[armedbear-ticket] [armedbear] #133: Mixed case inconsistency in TRANSLATE-LOGICAL-PATHNAMES
by armedbear 09 Dec '12

09 Dec '12

#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

1 11

[armedbear-ticket] [armedbear] #180: stack overflow with lparallel
by armedbear 09 Dec '12

09 Dec '12

#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

1 2

[armedbear-ticket] [armedbear] #169: Conformance with section 3.2.4.4 (externalized objects in COMPILE-FILE)
by armedbear 09 Dec '12

09 Dec '12

#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

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-ticket January 2012