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

[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] #248: More clear error handling for toString throwing an exception
by armedbear 09 Dec '12

09 Dec '12

#248: More clear error handling for toString throwing an exception --------------------------------------------+------------------------------- Reporter: https://openid.fau.de/eg74yneg | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: interpreter | Version: Keywords: | --------------------------------------------+------------------------------- For some class *test* imported from Java {{{ PKG> (#"toString" *test*) ; Evaluation aborted on #<JAVA-EXCEPTION java.lang.NullPointerException {FD82F5}>. PKG> *test* ; Evaluation aborted on NIL. }}} so the second form could include some indication on what goes wrong especially as toString is called fairly regular in a interactive LISP session -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/248> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[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

[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] #250: SYS:256 does not compile
by armedbear 07 Dec '12

07 Dec '12

#250: SYS:256 does not compile ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: blocker | Milestone: 1.1.0 Component: build | Version: 1.1.0-dev Keywords: | ----------------------+----------------------------------------------------- http://article.gmane.org/gmane.lisp.armedbear.devel/2584 -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/250> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[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] #232: Allow wrapper script to reference install directory instead of build directory
by armedbear 10 Nov '12

10 Nov '12

#232: Allow wrapper script to reference install directory instead of build directory -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: mevenson Type: enhancement | Status: new Priority: major | Milestone: Component: build | Version: Keywords: patch | -------------------------+-------------------------------------------------- PSau on #abcl submitted this patch which is used for building ABCL on NetBSD. I think generalization and including is appropriate. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/232> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #229: JSS method resolution failure
by armedbear 09 Nov '12

09 Nov '12

#229: JSS method resolution failure ------------------------------------------------+--------------------------- Reporter: mevenson | Owner: nobody Type: defect | Status: new Priority: critical | Milestone: 1.1.0 Component: java | Version: Keywords: jss method-resolution abcl-contrib | ------------------------------------------------+--------------------------- [http://article.gmane.org/gmane.lisp.armedbear.devel/2402 Jonathan Bona reports]: {{{ #| We found this issue while working with LSW. It seems to be a bug in how public methods are found for inner classes. The last line of code below results in an exception rather than finding and running the size() method: |# (require :abcl-contrib) (require :jss) (jss::ensure-compatibility) (setq headers (#"getHeaderFields" (#"openConnection" (jss::new 'java.net.url "http://google.com")))) ; a java.util.Collections$UnmodifiableRandomAccessList (setq ural (#"get" headers (second (jss::set-to-list (#"keySet" headers))))) ;finds: #<method public int java.util.Collections$UnmodifiableCollection.size()> (find "size" (#"getMethods" (#"getClass" ural) ) :test 'string-equal :key #"getName") ; Java exception 'java.lang.NoSuchMethodException: No applicable ; method named size found in java.lang.Object or ; java.util.Collections$UnmodifiableRandomAccessList'. (#"size" ural) #| I chased this into org.armedbear.lisp.Java, where findMethod is returning null. |# }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/229> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #243: ClassCastException in MAKE-PATHNAME
by armedbear 09 Nov '12

09 Nov '12

#243: ClassCastException in MAKE-PATHNAME ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: java | Version: Keywords: | ------------------------+--------------------------------------------------- ,---- | Armed Bear Common Lisp 1.1.0-dev-svn-14131M | Java 1.7.0_03 Oracle Corporation | OpenJDK 64-Bit Server VM | Low-level initialization completed in 0.3 seconds. | Startup completed in 1.456 seconds. | Loading /home/emarsden/.abclrc completed in 0.66 seconds. | Type ":help" for a list of available commands. | CL-USER(1): (make-pathname :device (list "foo")) | java.lang.ClassCastException: org.armedbear.lisp.SimpleString cannot be cast to org.armedbear.lisp.Pathname | at org.armedbear.lisp.Pathname.getNamestring(Pathname.java:657) | at org.armedbear.lisp.Pathname.printObject(Pathname.java:909) | at org.armedbear.lisp.Primitives$pf__output_object.execute(Primitives.java:907) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) | at org.armedbear.lisp.print_8.execute(print.lisp:127) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) | at org.armedbear.lisp.print_14.execute(print.lisp:281) | at org.armedbear.lisp.Symbol.execute(Symbol.java:813) | at org.armedbear.lisp.LispThread.execute(LispThread.java:653) `---- -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/243> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #246: CFFI: dynamically generated classes referred from .fasl can not be found after ABCL restart
by armedbear 09 Nov '12

09 Nov '12

#246: CFFI: dynamically generated classes referred from .fasl can not be found after ABCL restart ------------------------+--------------------------------------------------- Reporter: avodonosov | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- Armed Bear Common Lisp 1.1.0-dev-svn-14181 Java 1.6.0_24 Sun Microsystems Inc. {{{ (java:add-to-classpath "my-jna/jna.jar") (provide 'jna) (ql:quickload :drakma) ;; depends on CL+SSL }}} Do it first time after removing ~/.cache/common-lisp/. Works OK. Restart ABCL. Try the same code: {{{ Error loading C:/Users/anton/AppData/Local/common-lisp/cache/abcl-1.1.0 -dev- svn-14181-fasl39-win-x86/C/Users/anton/quicklisp/dists/quicklisp/software/cl+ssl-20120703-git/ffi.abcl at line 168 (offset 9483) #<THREAD "interpreter" {1A705D7}>: Debugger invoked on condition of type ERROR Class not found: org.armedbear.jna.dynamic.callbacks.G91513 Restarts: 0: TRY-RECOMPILING Recompile ffi and try loading it again 1: RETRY Retry loading FASL for #<ASDF:CL-SOURCE-FILE "cl+ssl" "ffi">. 2: ACCEPT Continue, treating loading FASL for #<ASDF:CL-SOURCE- FILE "cl+ssl" "ffi"> as having been successful. 3: ABORT Give up on "drakma" 4: TOP-LEVEL Return to top level. [1] CL+SSL(4): }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/246> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #249: Problems under Ubuntu
by armedbear 09 Nov '12

09 Nov '12

#249: Problems under Ubuntu -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: blocker | Milestone: 1.1.0 Component: libraries | Version: 1.1.0-dev Keywords: | -----------------------+---------------------------------------------------- stas has reported http://article.gmane.org/gmane.lisp.armedbear.devel/2573 http://lists.common-lisp.net/pipermail/armedbear- devel/attachments/20121011/fb8785ed/attachment-0001.txt -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/249> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #235: Compiled cl+ssl sources not reloadable
by armedbear 08 Nov '12

08 Nov '12

#235: Compiled cl+ssl sources not reloadable ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: compiler | Version: Keywords: | ------------------------+--------------------------------------------------- When loading compiled cl+ssl sources, abcl throws the following error: {{{ Error loading /home/ehuelsmann/.cache/common-lisp/abcl-1.1.0-dev- svn-14068-fasl39-linux- java/home/ehuelsmann/quicklisp/dists/quicklisp/software/cl+ssl-20120703-git/ffi.abcl at line 168 (offset 9318) #<THREAD "interpreter" {1513F3}>: Debugger invoked on condition of type ERROR Class not found: org.armedbear.jna.dynamic.callbacks.G15349 }}} It seems a reference to a dynamic class is saved, but the class is not regenerated upon loading in a fresh image. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/235> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 5

[armedbear-ticket] [armedbear] #255: ASDF file encoding specification don't work
by armedbear 28 Oct '12

28 Oct '12

#255: ASDF file encoding specification don't work ------------------------------------------------------------------+--------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: ASDF | Version: 1.1.0-dev Keywords: quicklisp asdf com.informatimago.common-lisp.diagram | ------------------------------------------------------------------+--------- Anton reports in http://article.gmane.org/gmane.lisp.armedbear.devel/2599 that specifying file encodings in ASDF isn't working. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/255> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #254: Cannot load ASDF systems in jar archives with ASDF-BINARY-LOCATIONS-COMPATIBILTY enabled
by armedbear 21 Oct '12

21 Oct '12

#254: Cannot load ASDF systems in jar archives with ASDF-BINARY-LOCATIONS- COMPATIBILTY enabled ------------------------------------+--------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 1.1.0 Component: ASDF | Version: 1.1.0-dev Keywords: asdf jar-pathnames jss | ------------------------------------+--------------------------------------- Stas' reported on armedbear-devel@ in http://article.gmane.org/gmane.lisp.armedbear.devel/2597 that JSS, which is an ASDF system stored in the abcl-contrib.jar archive, fails to load. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/254> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #252: MOP rework broke profiler?
by armedbear 21 Oct '12

21 Oct '12

#252: MOP rework broke profiler? --------------------------------------------+------------------------------- Reporter: https://openid.fau.de/eg74yneg | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: (A)MOP | Version: Keywords: | --------------------------------------------+------------------------------- {{{ Missing slot FUNCTION [Condition of type ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {1F5E14C}> #<ERROR {19A6876}> #<FUNCTION {1F5E14C}>) 1: (APPLY #<FUNCTION {1F5E14C}> (#<ERROR {19A6876}> #<FUNCTION {1F5E14C}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ERROR {19A6876}> #<FUNCTION {1F5E14C}>) 3: (INVOKE-DEBUGGER #<ERROR {19A6876}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.StandardObject.getInstanceSlotValue(StandardObject.java:307) 6: org.armedbear.lisp.Profiler$1.execute(Profiler.java:86) 7: org.armedbear.lisp.Symbol.execute(Symbol.java:813) 8: org.armedbear.lisp.LispThread.execute(LispThread.java:653) 9: org.armedbear.lisp.profiler_29.execute(profiler.lisp:165) 10: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) 11: org.armedbear.lisp.LispThread.execute(LispThread.java:628) 12: org.armedbear.lisp.Lisp.evalCall(Lisp.java:547) 13: org.armedbear.lisp.Lisp.eval(Lisp.java:518) 14: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 15: (PROFILER:%START-PROFILER :TIME 1) 16: (PROFILER::START-PROFILER) 17: (SYSTEM::%EVAL (PROFILER::START-PROFILER)) 18: (EVAL (PROFILER::START-PROFILER)) }}} I was referred to this being due to MOP rework on IRC #abcl -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/252> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #215: ABCL-ASDF:RESOLVE should work in more (some?) cases
by armedbear 13 Oct '12

13 Oct '12

#215: ABCL-ASDF:RESOLVE should work in more (some?) cases -----------------------------+---------------------------------------------- Reporter: mevenson | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: 1.1.0 Component: other | Version: 1.1.0-dev Keywords: abcl-asdf maven | -----------------------------+---------------------------------------------- Failure #1: {{{ (abcl-asdf:resolve "com.sun.jna:jna") WARNING: Using LATEST for unspecified version. METADATA_RESOLVING com.sun.jna:jna/maven-metadata.xml @ /home/evenson/.m2/repository (enhanced) METADATA_RESOLVED com.sun.jna:jna/maven-metadata.xml @ /home/evenson/.m2/repository (enhanced) METADATA_RESOLVING com.sun.jna:jna/maven-metadata.xml @ central (, releases+snapshots) METADATA_DOWNLOADING com.sun.jna:jna/maven-metadata.xml @ central (, releases+snapshots) METADATA_DOWNLOADED com.sun.jna:jna/maven-metadata.xml (/home/evenson/.m2/repository/com/sun/jna/jna/maven-metadata-central.xml) @ central (, releases+snapshots) METADATA_RESOLVED com.sun.jna:jna/maven-metadata.xml @ central (, releases+snapshots) ; Evaluation aborted on #<JAVA-EXCEPTION org.sonatype.aether.collection.DependencyCollectionException: Failed to collect dependencies for com.sun.jna:jna:jar:LATEST (runtime) {39D9F91C}>. CL-USER> }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/215> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

Re: [armedbear-ticket] [armedbear] #198: Hunchentoot run failure
by armedbear 13 Oct '12

13 Oct '12

#198: Hunchentoot run failure ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: accepted Priority: blocker | Milestone: 1.1.0 Component: compiler | Version: 1.1.0-dev Keywords: | ----------------------+----------------------------------------------------- Changes (by mevenson): * status: assigned => accepted Comment: Invoking (abcl:test-system :hunchentoot) gives the following overflow as grabbed by SLIME {{{ Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: 0: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {631A2693}> #<STORAGE-CONDITION {49DAAFB9}> #<FUNCTION {631A2693}>) 1: (APPLY #<FUNCTION {631A2693}> (#<STORAGE-CONDITION {49DAAFB9}> #<FUNCTION {631A2693}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {49DAAFB9}> #<FUNCTION {631A2693}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {49DAAFB9}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1315) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:802) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:640) 8: org.armedbear.lisp.ASDF_TMP_acceptor_140.execute(acceptor.lisp:631) 9: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:653) 11: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2793) 12: (#<FUNCTION {3446C090}>) 13: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {3446C090}>) 14: (#<FUNCTION {110C48C0}> #<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> 302) 15: (APPLY #<FUNCTION {110C48C0}> (#<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> 302)) 16: (HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE #<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> 302) 17: (#<FUNCTION {27CA0E3B}>) 18: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {27CA0E3B}>) 19: (#<FUNCTION {426C57E5}>) 20: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {426C57E5}>) 21: (#<FUNCTION {3CC425B2}>) 22: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {3CC425B2}>) 23: (HUNCHENTOOT:PROCESS-REQUEST #<HUNCHENTOOT:REQUEST {7186E848}>) 24: (#<FUNCTION {4FFC0932}>) 25: (HUNCHENTOOT::DO-WITH-ACCEPTOR-REQUEST-COUNT-INCREMENTED #<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> #<FUNCTION {4FFC0932}>) 26: (#<FUNCTION {2BBFDAA4}> (#<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> #<USOCKET:STREAM-USOCKET {40AB5B6C}>)) 27: (#<FUNCTION {31FF309F}>) 28: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {31FF309F}>) 29: (#<FUNCTION {68D1305D}>) 30: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {68D1305D}>) 31: (#<FUNCTION {7DBE5F6D}> #<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> #<USOCKET:STREAM-USOCKET {40AB5B6C}>) 32: (APPLY #<FUNCTION {7DBE5F6D}> (#<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> #<USOCKET:STREAM-USOCKET {40AB5B6C}>)) 33: (HUNCHENTOOT:PROCESS-CONNECTION #<HUNCHENTOOT:EASY-ACCEPTOR {3D7C3DFE}> #<USOCKET:STREAM-USOCKET {40AB5B6C}>) }}} Related to this in the *inferior-list* buffer: {{{ ; Loaded /home/evenson/.slime/fasl/2012-09-04/armedbear-1.1.0-dev- solaris-x86-64/contrib/swank-repl.abcl (0.12 seconds) WARNING: Session secret is unbound. Using Lisp's RANDOM function to initialize it. java.lang.StackOverflowError at org.armedbear.lisp.LispThread.execute(LispThread.java:643) at org.armedbear.lisp.ASDF_TMP_util_41.execute(util.lisp:296) at org.armedbear.lisp.LispThread.execute(LispThread.java:640) at org.armedbear.lisp.ASDF_TMP_util_41.execute(util.lisp:296) at org.armedbear.lisp.LispThread.execute(LispThread.java:640) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/198#comment:13> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #237: JNA fails to load blocking CFFI
by armedbear 13 Oct '12

13 Oct '12

#237: JNA fails to load blocking CFFI -------------------------------+-------------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: blocker | Milestone: 1.1.0 Component: libraries | Version: 1.1.0-dev Keywords: abcl-contrib, jna | -------------------------------+-------------------------------------------- {{{ Error while trying to load definition for system jna from pathname jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/mvn/jna.asd: Can't create directory /. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/237> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4

[armedbear-ticket] [armedbear] #234: ASDF-MVN errors with VERSION slot unbound
by armedbear 13 Oct '12

13 Oct '12

#234: ASDF-MVN errors with VERSION slot unbound ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: Component: ASDF | Version: Keywords: | ------------------------+--------------------------------------------------- 50,852 bytes in 0.48 seconds (102.60KB/sec) ; Loading "drakma" ................................................jnaASDF could not load because The slot VERSION is unbound in the object #<MVN {1B44E59}>.. Error loading C:/Users/Erik/AppData/Local/common-lisp/cache/abcl-1.1.0 -dev-svn-1 4063m- fasl39-win-x86/C/Users/Erik/quicklisp/dists/quicklisp/software/cffi_0.10.7 .1/src/cffi-abcl.abcl at line 8 (offset 578) #<THREAD "interpreter" {1C32B82}>: Debugger invoked on condition of type UNBOUND -SLOT The slot VERSION is unbound in the object #<MVN {1B44E59}>. Restarts: 0: RETRY Retry compiling #<ASDF:MVN "jna" "com.sun.jna/jna/3.0.9">. 1: ACCEPT Continue, treating compiling #<ASDF:MVN "jna" "com.sun.jna/ jna/3.0.9"> as having been successful. 2: TRY-RECOMPILING Recompile cffi-abcl and try loading it again 3: RETRY Retry loading FASL for #<ASDF:CL-SOURCE-FILE "cffi" "src" " cffi-abcl">. 4: ACCEPT Continue, treating loading FASL for #<ASDF:CL-SOURCE- FILE " cffi" "src" "cffi-abcl"> as having been successful. 5: ABORT Give up on "drakma" 6: TOP-LEVEL Return to top level. [1] CL-USER(37): -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/234> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 4