September 2012 - armedbear-ticket - mailman3.common-lisp.net

[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] #230: Implement macro expansions for custom special operators to support generic code walkers
by armedbear 24 Mar '13

24 Mar '13

#230: Implement macro expansions for custom special operators to support generic code walkers -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: mevenson Type: enhancement | Status: new Priority: major | Milestone: 1.1.0 Component: libraries | Version: Keywords: | -------------------------+-------------------------------------------------- Pascal J. Bourguignon requests the following on our mailing list: The following special operators don't have a corresponding macro definition. THREADS:SYNCHRONIZED-ON EXTENSIONS:TRULY-THE JVM:WITH-INLINE-CODE While the standard doesn't specify anything for special operators not in the CL package, it would still be nice if they followed the same rule as for CL macros implemented as special operators: 3.1.2.1.2.2 Macro Forms An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided. since this would ensure that portable code walkers can be written. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/230> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #200: ABCL compiler fails to produce loadable fasl for XPATH
by armedbear 23 Mar '13

23 Mar '13

#200: ABCL compiler fails to produce loadable fasl for XPATH ----------------------------------------------------+----------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: quicklisp xpath jvm-class-verify-error | ----------------------------------------------------+----------------------- For the :XPATH system loaded from 2012-03-05 Quicklisp the plexippus- xpath-20110219-darcs fails to load {{{ Compiled function can't be loaded: org.armedbear.lisp.ASDF_TMP_xpath_test_11 from org.armedbear.lisp.Pathname@40f69ae7 }}} which results from the class verifier error {{{ java.lang.VerifyError: (class: org/armedbear/lisp/ASDF_TMP_xpath_test_11, method: execute signature: ()Lorg/armedbear/lisp/LispObject;) Accessing value from uninitialized register 20 at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.newInstance0(Class.java:326) at java.lang.Class.newInstance(Class.java:308) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:132) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/200> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 13

[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] #203: Failure as build host for SBCL
by armedbear 08 Mar '13

08 Mar '13

#203: Failure as build host for SBCL ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: unscheduled Component: other | Version: 1.1.0-dev Keywords: sbcl | ----------------------+----------------------------------------------------- Using ABCL as a build host for SBCL via {{{ sbcl-1.0.55$ sh make.sh --xc-host=abcl }}} fails in the make-host-2 phase for creating target object files {{{ ; compiling file "/Users/evenson/work/sbcl/src/code/kernel.lisp" (written 23 MAR 2012 07:01:13 AM): ; x-compiling (IN-PACKAGE "SB!KERNEL") ; x-compiling (DEFUN GET-HEADER-DATA ...) ; x-compiling (DEFUN SET-HEADER-DATA ...) ; x-compiling (DEFUN GET-CLOSURE-LENGTH ...) ; x-compiling (DEFUN LOWTAG-OF ...) ; x-compiling (DEFUN WIDETAG-OF ...) ; x-compiling (DECLAIM (INLINE %OTHER-POINTER-WIDETAG)) ; x-compiling (DEFUN %OTHER-POINTER-WIDETAG ...) ; x-compiling (DEFUN VECTOR-SAP ...) ; x-compiling (DEFUN BINDING-STACK-POINTER-SAP ...) ; x-compiling (DEFUN DYNAMIC-SPACE-FREE-POINTER ...) ; x-compiling (DEFUN CONTROL-STACK-POINTER-SAP ...) ; x-compiling (DEFUN FUN-SUBTYPE ...) ; x-compiling (DEFUN (SETF FUN-SUBTYPE) ...) ; x-compiling (DECLAIM (INLINE SIMPLE-FUN-P)) ; x-compiling (DEFUN SIMPLE-FUN-P ...) ; x-compiling (DEFTYPE SIMPLE-FUN ...) ; x-compiling (DEFUN %SIMPLE-FUN-DOC ...) ; x-compiling (DEFUN (SETF %SIMPLE-FUN-DOC) ...) ; x-compiling (DEFUN %SIMPLE-FUN-XREFS ...) ; x-compiling (DEFUN %SIMPLE-FUN-ARGLIST ...) ; x-compiling (DEFUN (SETF %SIMPLE-FUN-ARGLIST) ...) ; x-compiling (DEFUN %SIMPLE-FUN-NAME ...) ; x-compiling (DEFUN (SETF %SIMPLE-FUN-NAME) ...) ; x-compiling (DEFUN %SIMPLE-FUN-TYPE ...) ; x-compiling (DEFUN %SIMPLE-FUN-NEXT ...) ; x-compiling (DEFUN %SIMPLE-FUN-SELF ...) ; x-compiling (DECLAIM (INLINE CLOSUREP)) ; x-compiling (DEFUN CLOSUREP ...) ; x-compiling (DEFTYPE CLOSURE ...) ; x-compiling (DEFMACRO DO-CLOSURE-VALUES ...) ; x-compiling (DEFUN %CLOSURE-VALUES ...) ; x-compiling (DEFUN %CLOSURE-FUN ...) ; x-compiling (DEFUN %CLOSURE-INDEX-REF ...) ; x-compiling (DEFUN SB!C::VECTOR-LENGTH ...) ; x-compiling (DEFUN ALLOCATE-VECTOR ...) ; x-compiling (DEFUN MAKE-ARRAY-HEADER ...) ; x-compiling (DEFUN CODE-INSTRUCTIONS ...) ; x-compiling (DEFUN CODE-HEADER-REF ...) ; x-compiling (DEFUN CODE-HEADER-SET ...) ; x-compiling (DEFUN %VECTOR-RAW-BITS ...) ; x-compiling (DEFUN %SET-VECTOR-RAW-BITS ...) ; x-compiling (DEFUN MAKE-SINGLE-FLOAT ...) Error loading /Users/evenson/work/sbcl/src/cold/compile-cold-sbcl.lisp at line 27 (offset 1039) #<THREAD "interpreter" {45A8BF4}>: Debugger invoked on condition of type TYPE-ERROR The value #(((:QWORD . -4294967296) . #<SB!ASSEM:LABEL 1>) ((:QWORD . 4294967294) . #<SB!ASSEM:LABEL 2>)) is not of type SIMPLE-VECTOR. Restarts: 0: TOP-LEVEL Return to top level. [1] SB!KERNEL(16): ; ; compilation unit aborted ; caught 1 fatal ERROR condition }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/203> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #223: XP-STRUCTURE should be a proper subtype of STREAM
by armedbear 08 Mar '13

08 Mar '13

#223: XP-STRUCTURE should be a proper subtype of STREAM ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | ------------------------+--------------------------------------------------- An attempt has been made to create a proper "implementation super type of all streams" by making a "STREAM" structure (see boot.lisp). There's a design document. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/223> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[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] #228: Need to implement autoloader facility for SETF functions
by armedbear 14 Feb '13

14 Feb '13

#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

1 3

[armedbear-ticket] [armedbear] #212: ABCL crash when running test suites of many libraryies
by armedbear 13 Feb '13

13 Feb '13

#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

1 10

[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] #240: FIND-CLASS does not implement 3-argument behavior
by armedbear 09 Dec '12

09 Dec '12

#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

1 2

[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] #244: compile doesn't return correct values for warnings-p and failure-p
by armedbear 09 Dec '12

09 Dec '12

#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

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

[armedbear-ticket] [armedbear] #132: Inconsistent use of :case :common for pathnames
by armedbear 09 Dec '12

09 Dec '12

#132: Inconsistent use of :case :common for pathnames -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 0.25 Component: interpreter | Version: 0.24 Keywords: | -------------------------+-------------------------------------------------- Pascal Bourguignon notes: {{{ CLHS says: 19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving. [pjb@kuiper :0.0 lisp]$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.265 seconds. Startup completed in 0.718 seconds. Type ":help" for a list of available commands. CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common) #P"TEST.LISP" CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common)) "TEST.LISP" I'm on a linux system on a ext3 file system. The customary case is lower case (case significant on this particular file system, but 99.999% of the files on unix are lower case). Therefore I would expect to get #P"test.lisp" Notice that: (make-pathname :name "test" :type "lisp" :case :common) should produce #P"TEST.LISP" and that: (make-pathname :name "Test" :type "Lisp" :case :common) should produce #P"Test.Lisp" }}} {{{ Mark Evenson writes: > > On 11/7/10 5:02 AM, Pascal J. Bourguignon wrote: >> >> >> >> CLHS says: >> >> >> >> 19.2.2.1.2.2 Common Case in Pathname Components >> >> >> >> For the functions in Figure 19-2, a value of :common for the :case >> >> argument that these functions should receive and yield strings in >> >> component values according to the following conventions: >> >> >> >> * All uppercase means to use a file system's customary case. >> >> * All lowercase means to use the opposite of the customary case. >> >> * Mixed case represents itself. >> >> >> >> Note that these conventions have been chosen in such a way that >> >> translation from :local to :common and back to :local is >> >> information-preserving. > > > > What an odd corner of the CLHS, littered with the bones of extinct > > filesystems! This behavior that seems like it would produce > > unpleasantries much more than it would help anyone, violating the > > principle of least surprise. But we claim that ABCL will be ANSI first > > and foremost, so I guess we have to pay attention here… I should mention that I use routinely logical pathnames, and they work very well, on all implementations that conformantly implement them. That means that all my logical pathnames are always upcase letters, and no special symbols (apart from an occasional dash). I understand that using implementation dependant syntax (special characters, lower-case, mixed-case) in logical pathnames can lead to surprises, but I avoid them. Now, it's not a question of extinct file systems. You still have to deal with at least two different major syntaxes: POSIX and MS-Windows/MS-DOS. I just cannot use in programs that will have to run on both Linux or MacOSX and MS-Windows physical pathname literals, because they don't use the same syntax. On the other hand, #P"HOME:SRC;LISP;EXAMPLE.LISP" can be translated to either #P"C:\\Users Files\\Pascal\\src\\lisp\\example.lisp" or #P"/home/pjb/src/lisp/example.lisp" portably on these targets. The point for an implementation is to know what it's targets are, and to implement proper behavior when translating and merging logical pathnames. You must be careful when merging logical pathnames with physical pathnames, notably when it's done in make-pathname: the :case parameter must have effect only on the new strings, not on the :defaults parameter. > > I suppose there is no definition of "customary case", huh? Indeed. > > Pascal suggests a notion of filesystem statistics ("99.999% of files > > are lowercase") but for a developer dealing with lots of Java files > > this isn't very releavant. Does Java provide its own file system, or does it map to the host file system? Notice that logical pathnames don't have to be able to represent all the physical pathnames, without an explicit translation. If you have a file system that is case sensitive, then you may write: (setf (logical-pathname-translations "APP") (list (list #P"APP:EXAMPLE;FILE.LISP" #P"/MyApp/Example/File.lisp") (list #P"APP:EXAMPLE;ANOTHER-FILE.LISP" #P"/MyApp/Example/AnotherFile.lisp") (list #P"APP:EXAMPLE;*.DATA" #P"/MyApp/Example/*.appdata") (list #P"APP:EXAMPLE;SOME-MODULE.*" #P"/MyApp/Example/SomeBigModule.*") (list #P"APP:APP.CONFIGURATION" #P"/MyApp/.config") (list #P"APP:CUSTOMARY;**;*" #P"/MyApp;**;*") (list #P"APP:CUSTOMARY;**;*.*" #P"/MyApp;**;*.*"))) to be able to access to files with strange physical names. The question indeed is to decide what is the customary case. You can choose uppercase or you can choose lowercase. This matters only for file systems that are case sensitive, but even file systems that are not case sensitive, such as MS-DOS, have a prefered way to display the names. > > Lacking a more precise definition, I would then advocate that we declare > > lowercase to be the customary case across UNIX, OSX, and Windows for > > ABCL, patching our behavior accordingly. That would be good. > > I thought briefly about advocating Windows to have "uppercase" as its > > customary case, but that is only really true in a DOS world which > > "modern" Windows systems really aren't any more. Yes. > > And although we theoretically run on JVMs on say VMS, if we run into > > such needs, we might devote a user-accessible special variable to > > control the implementation. This is also a good option. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/132> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 10

[armedbear-ticket] [armedbear] #197: JAR-PATHNAME errors and ambiguities
by armedbear 09 Dec '12

09 Dec '12

#197: JAR-PATHNAME errors and ambiguities --------------------------+------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.0.1 Keywords: jar-pathname | --------------------------+------------------------------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2200 Yong reports on armedbear@devel]: {{{ CL-USER> (make-pathname :device '("c:/a.b.jar") :directory '(:absolute "cl-ppcre")) ; Evaluation aborted on NIL. }}} Why am I not getting any errors (and not dropping into a debugger)? I know the error is because the device is not a list of a pathname ie missing a #P. 2. What's printed out is not what was read in (trailing /) {{{ CL-USER> #P"jar:file:c:/a/b.jar!/cl-ppcre/" #P"jar:file:c:/a/b.jar!/cl-ppcre" }}} 3. Should this repeated jar:file:jar:file thing throw an error? {{{ #P"jar:file:jar:file:c:/a/b.jar!/cl-ppcre/" ==> #P"jar:file:jar:file:c:/a/b.jar!/cl-ppcre" }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/197> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #233: Evaluation of (DIRECTORY "/*/") fails
by armedbear 09 Dec '12

09 Dec '12

#233: Evaluation of (DIRECTORY "/*/") fails ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: 1.1.0-dev Keywords: | ------------------------+--------------------------------------------------- Reported by Stas Boukarev on #abcl: (DIRECTORY "/*/") ---> #<THREAD "interpreter" {E2B9E5}>: Debugger invoked on condition of type TYPE-ERR OR The value NIL is not of type (OR PATHNAME STRING FILE-STREAM SYSTEM:JAR- STREAM SYSTEM:URL-STREAM). Restarts: 0: TOP-LEVEL Return to top level. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/233> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #239: defgeneric with unsuitable :generic-function-class gives incomprehensible error
by armedbear 07 Dec '12

07 Dec '12

#239: defgeneric with unsuitable :generic-function-class gives incomprehensible error -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: (A)MOP | Version: Keywords: | -----------------------+---------------------------------------------------- Compiling and loading the following (incorrect) file gives an error saying that foo-generic-function is not of type standard-generic-function. The real error is that foo-generic-function must be defined with (:metaclass funcallable-standard-class) to be suitable as a generic function class. {{{ (require :clos) (defclass foo-generic-function (standard-generic-function)) (defgeneric goo (a b) (:generic-function-class foo-generic-function) (:method (a b) (princ "default method"))) (print #'goo) }}} The attached patch would emit a full warning in defgeneric, but currently find-class does not implement correct behavior when called with 3 parameters. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/239> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #242: Unused &key warnings in defmethod forms should not cause style-warnings
by armedbear 07 Dec '12

07 Dec '12

#242: Unused &key warnings in defmethod forms should not cause style-warnings -----------------------+---------------------------------------------------- Reporter: rschlatte | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: Component: compiler | Version: Keywords: | -----------------------+---------------------------------------------------- CLHS 7.6.5 says: "The lambda list congruence rules require that each method accept all of the keyword arguments mentioned after &key in the generic function definition, by accepting them explicitly, by specifying &allow-other-keys, or by specifying &rest but not &key." Currently, when compiling a file containing the form {{{(defmethod foo ((x fixnum) &key y z) x)}}} we get style warnings about unused variables y and z. I think that these style warnings can be safely elided, since a typo in the arglist will lead to another style warning "Undefined variable A assumed special". -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/242> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #231: DEFSTRUCT accessor functions overwrite accessors in :INCLUDEd structs
by armedbear 07 Dec '12

07 Dec '12

#231: DEFSTRUCT accessor functions overwrite accessors in :INCLUDEd structs ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Ralf Moeller reports: The following file causes a problem in ABCL (1.1.0-dev-svn-14041) when compiled (!) and loaded. (in-package cl-user) (defstruct a (s1 nil)) (defstruct (b (:include a) (:conc-name foo-)) (s2 nil)) (defstruct (c (:include a) (:conc-name foo-)) (s3 nil)) (defun test () (let ((x (make-b :s1 1 :s2 2))) (foo-s1 x))) CL-USER(4): (test) #<THREAD "interpreter" {2EF7D41F}>: Debugger invoked on condition of type SIMPLE-TYPE-ERROR The value #<B {564434F7}> is not of type C. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(6): (lisp-implementation-version) "1.1.0-dev-svn-14041" [1] CL-USER(7): The problem is that the defstruct declaration for c "overwrites" the accessor foo-s1 generated by defstruct b. If foo-s1 is called for a b instance, the type assertions introduced by define-reader (and define-writer, see the ABCL implementation for defstruct) cause the error described above. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/231> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #165: pprint-logical-block fails for format with list directive
by armedbear 07 Dec '12

07 Dec '12

#165: pprint-logical-block fails for format with list directive ----------------------------+----------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: major | Milestone: 0.27 Component: other | Version: 0.27 Keywords: sbcl-buildhost | ----------------------------+----------------------------------------------- Derived from the problems getting SBCL to compile, the following test fails with complaints in the XP package: {{{ (defparameter *stream* *error-output*) (defun pprint-test () (pprint-logical-block (*stream* nil :prefix "---") (format *stream* "~(~A~)" '(1 2 3 4)))) }}} with this error {{{ The value #S(XP::XP-STRUCTURE :BASE-STREAM #S(SLIME-OUTPUT-STREAM) :LINE- LENGTH 70 :LINE-LIMIT NIL :LINE-NO 1 :DEPTH-IN-BLOCKS 2 :BLOCK-STACK #(0 0 3 NIL NIL NIL NIL NIL NIL NIL ...) :BLOCK-STACK-PTR 2 :BUFFER … is not of type STREAM. [Condition of type TYPE-ERROR] -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/165> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 11