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

[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

[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] #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

[armedbear-ticket] [armedbear] #118: Lisp.getUpgradedElementType returns more types than supported by 'make_array.java'
by armedbear 07 Dec '12

07 Dec '12

#118: Lisp.getUpgradedElementType returns more types than supported by 'make_array.java' ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- The above leads to possible failure: each upgraded element type has its own associated defaultInitialValue. If the code does not specify the right initial value, NIL is taken, which probably is not a good fit. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/118> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 8

[armedbear-ticket] [armedbear] #174: Conformance bug in time implementation
by armedbear 17 Nov '12

17 Nov '12

#174: Conformance bug in time implementation ----------------------------------------------------------------------------------------------+ Reporter: https://www.google.com/accounts/o8/id?id=AItOawkDgxhblL5hWamZidYhAD6W-l7W_L… | Owner: somebody Type: defect | Status: new Priority: trivial | Milestone: Component: other | Version: 0.27 Keywords: time, macro, conformance bug | ----------------------------------------------------------------------------------------------+ ABCL's time implementation does not return multiple values as specified in HyperSpec. (time (values 1 2)) => 1 instead of 1 and 2 a test could be (assert (= 2 (length (multiple-value-list (time (values 1 2)))))) an implementation is given [http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/file/6afcecc6bb2c/src/mac… here]. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/174> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 15

[armedbear-ticket] [armedbear] #211: closure-common fails to load correctly after compilation
by armedbear 17 Nov '12

17 Nov '12

#211: closure-common fails to load correctly after compilation ---------------------------------------------------------------+------------ Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: minor | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: clos compiler needs-test quicklisp closure-common | ---------------------------------------------------------------+------------ When compiling the fasl for closure-common/ystream.abcl an error in StandardClass.getClassLayout(StandardClass:205) in reading back the parameters. Interestingly, if the system is restarted, the fasl *can* be loaded without complaint, so there seems to be some artifact of the compilation process "hanging around" in memory which causes this problem. Unknown whether this affects the actual us of closure-common This error existed in abcl-1.0.1 as well, so it has nothing to do with the recent work on the MOP. {{{ 0: (#<FUNCTION {50F2A460}> #<TYPE-ERROR {79D34CA}> #<FUNCTION {50F2A460}>) 1: (APPLY #<FUNCTION {50F2A460}> (#<TYPE-ERROR {79D34CA}> #<FUNCTION {50F2A460}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {79D34CA}> #<FUNCTION {50F2A460}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {79D34CA}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:379) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:420) 6: org.armedbear.lisp.Cons.length(Cons.java:240) 7: org.armedbear.lisp.Cons.copyToArray(Cons.java:352) 8: org.armedbear.lisp.LispThread.pprint(LispThread.java:896) 9: org.armedbear.lisp.LispThread.pprint(LispThread.java:916) 10: org.armedbear.lisp.LispThread.pprint(LispThread.java:916) 11: org.armedbear.lisp.LispThread.printBacktrace(LispThread.java:825) 12: org.armedbear.lisp.LispThread.printBacktrace(LispThread.java:807) 13: org.armedbear.lisp.StandardClass.getClassLayout(StandardClass.java:206) 14: org.armedbear.lisp.Layout$6.execute(Layout.java:269) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 17: org.armedbear.lisp.clos_728.execute(clos.lisp:3470) 18: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:185) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:760) 20: org.armedbear.lisp.Lisp.funcall(Lisp.java:186) 21: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2817) 22: (SYSTEM:%MAKE-INSTANCES-OBSOLETE #<STANDARD-CLASS RUNES::OCTET-INPUT- STREAM {7F83698F}>) 23: (#<FUNCTION {1455BCD7}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS :TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5}> #<STANDARD-CLASS GRAY-S.. 24: (APPLY #<FUNCTION {1455BCD7}> (#<STANDARD-CLASS RUNES::OCTET-INPUT- STREAM {7F83698F}> :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY- STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5}> #<STANDARD-CLASS.. 25: (#<STANDARD-GENERIC-FUNCTION REINITIALIZE-INSTANCE {665C1EAE}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> :DIRECT- SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM- MI.. 26: (APPLY #<STANDARD-GENERIC-FUNCTION REINITIALIZE-INSTANCE {665C1EAE}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> :DIRECT- SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STR.. 27: (#<FUNCTION {5FE63CB6}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> RUNES::OCTET-INPUT-STREAM :DIRECT-SUPERCLASSES (#<STANDARD- CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5.. 28: (APPLY #<FUNCTION {5FE63CB6}> (#<STANDARD-CLASS RUNES::OCTET-INPUT- STREAM {7F83698F}> RUNES::OCTET-INPUT-STREAM :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7.. 29: (#<STANDARD-GENERIC-FUNCTION ENSURE-CLASS-USING-CLASS {1A3526CF}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> RUNES::OCTET-INPUT- STREAM :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-S.. 30: (APPLY #<STANDARD-GENERIC-FUNCTION ENSURE-CLASS-USING-CLASS {1A3526CF}> #<STANDARD-CLASS RUNES::OCTET-INPUT-STREAM {7F83698F}> RUNES ::OCTET-INPUT-STREAM (:DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL.. 31: (SYSTEM:ENSURE-CLASS RUNES::OCTET-INPUT-STREAM :DIRECT-SUPERCLASSES (#<STANDARD-CLASS TRIVIAL-GRAY-STREAMS:TRIVIAL-GRAY-STREAM-MIXIN {7203E3B5}> #<STANDARD-CLASS GRAY-STREAMS:FUNDAMENTAL-BINARY-INPUT-.. }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/211> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #213: ABCL-ASDF breakage on trunk
by armedbear 12 Sep '12

12 Sep '12

#213: ABCL-ASDF breakage on trunk -------------------------+-------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: interpreter | Version: 1.1.0-dev Keywords: | -------------------------+-------------------------------------------------- Changeset 1834:d7370bc12860: bad The first bad revision is: changeset: 1834:d7370bc12860 user: ehuelsmann@1c010e3e-69d0-11dd-93a8-456734b0d56f date: Sun Jan 29 20:56:08 2012 +0000 summary: (Re)factor function call argument matching out of Closure.java. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/213> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5