August 2012 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] Issue finding methods in JSS
by Jonathan P. Bona 09 Nov '12

09 Nov '12

Hello, 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. - Jonathan Bona

4 7

[armedbear-devel] Unbound initargs slot in slot-definitions
by Stas Boukarev 30 Sep '12

30 Sep '12

Having two classes: (defclass slot-d-1 (mop:standard-direct-slot-definition) ()) (defclass slot-d-2 (mop:standard-direct-slot-definition) (a)) (slot-boundp (make-instance 'slot-d-2) 'sys::initargs) => T (slot-boundp (make-instance 'slot-d-2) 'sys::initargs) => NIL So, having a slot makes initargs unbound. Below is the actual code which suffers from it: (defpackage test (:use :cl :mop)) (in-package test) (defclass storable-class (standard-class) ()) (defmethod validate-superclass ((class standard-class) (superclass storable-class)) t) (defmethod validate-superclass ((class storable-class) (superclass standard-class)) t) (defclass storable-direct-slot-definition (standard-direct-slot-definition) ((storep :initarg :storep :initform t :reader store-slot-p))) (defmethod direct-slot-definition-class ((class storable-class) &key) (find-class 'storable-direct-slot-definition)) ;;; (defclass identifiable () ((id :accessor id :initform nil :storep nil)) (:metaclass storable-class)) The last form receives an error: The slot INITARGS is unbound in the object #<STORABLE-DIRECT-SLOT-DEFINITION {34C1EFE7}>. -- With best regards, Stas.

2 6

[armedbear-devel] Closer-mop support for ABCL
by Rudi Schlatte 19 Sep '12

19 Sep '12

Greetings, ABCL 1.1, expected in 2-3 months from now, will have a mop implementation that passes the mop test suite without missing features. The work is finished in svn and can be checked out at http://svn.common-lisp.net/armedbear/trunk/abcl/. It would be great if we had closer-mop support by release time; attached is a naive patch (which assumes that abcl needs nothing in closer-mop-shared). I also re-send the abcl patch for mop-feature-tests. The closer-mop patch is written to give an error if :mop isn't on *features*, this feature is present in the mop-supporting svn version of abcl and will be in the released version as well, so if you decide to merge the patch, users of the old release will get a sensible error message. Cheers, Rudi

3 17

[armedbear-devel] Ansi tests fail to execute
by Rudolf Schlatte 05 Sep '12

05 Sep '12

Hi, Currently the ansi test suite crashes with this error: Error loading /Users/rudi/Source/ansi-tests/load-arrays.lsp at line 3 (offset 55) #<THREAD "interpreter" {712A95C7}>: Debugger invoked on condition of type TYPE-ERROR The value CL-TEST::OPTIONS is not of type LIST. Restarts: 0: TOP-LEVEL Return to top level. According to git bisect, the offending commit is r14130 (Replace a Java primitive LAMBDA-LIST-NAMES with a lisp function) although I haven't investigated further yet. Rudi

2 2

[armedbear-devel] CLOS / D-M-C tests failure DMC-TEST-MC.1 help requested
by Erik Huelsmann 31 Aug '12

31 Aug '12

Hi all, In an attempt to solve ticket 201 and everything related (now that I'm into it anyway), I've been staring at the failure of one of ABCL's own tests and can't seem to understand what's going on. So, DMC-TEST-MC.1 is failing because it uses a non-standard METHOD-QUALIFIER. STD-COMPUTE-EFFECTIVE-METHOD throws an error when matching the qualifiers of the defined methods with the method groups and finds that the method combination isn't one of type long-form. However, the problem is: it really *is* of type long form. However, this seems to happen *only* in the compiled case....s So, I inserted a trace: (eval-when (:compile-toplevel) (trace mop::STD-COMPUTE-EFFECTIVE-METHOD)) and extracted the test form from outside the test case, in order to be able to see the error triggered (RT just prints #<simple-error >): (dmc-test-mc.1 :k 1) The result is this backtrace: [java] 0: (MOP::STD-COMPUTE-EFFECTIVE-METHOD #<STANDARD-GENERIC-FUNCTION DMC-TEST-MC.1 {10D3D99}> #<METHOD-COMBINATION {69B861}> (#<STANDARD-METHOD {C821EF}>)) which clearly shows the method combination is of type METHOD-COMBINATION and not of type LONG-METHOD-COMBINATION. I do understand that this is the error, but I can't for the life of me figure out how we get into the situation that the method combination being instantiated is of the resulting type METHOD-COMBINATION... Any help on debugging or additional insights would be extremely appreciated! Bye, Erik.

3 12

[armedbear-devel] asdf 2.24 released
by Faré 26 Aug '12

26 Aug '12

I am pleased to announce the release of ASDF 2.24. Since previous release 2.23, the changes are as follow: Portability: * ACL: handle SMP vs non-SMP builds in Allegro 9.0 * MKCL: add support for ManKai Common Lisp * ECL: merge improvements from ECL git. Refactor ECL support somewhat. * Remove broken-fasl-support: first, cormanlisp is supposed to have fixed it; second, cormanlisp is dead; third, one can now (setf *load-system-operation* 'load-source-op) instead. Internals: * renaming ends-with to string-suffix-p to avoid conflict with alexandria. * Refactor load-system to use *load-system-operation*, and change require-system and module-provide-asdf to use that. Also note: * We recommend you use asdf-utils to access the utilities in asdf. Some time next year, we may stop exporting the utilities from asdf itself. * To avoid conflicts between alexandria, fare-utils, xcvb-driver, asdf-utils, etc., you can use xcvb-utils that solves the conflicts. Or you can use fare-utils:define-package-mix that will help you automatically resolve them. These changes are few and subtle, but nonetheless significant to those who'd use these features. As usual, developers, please test and enjoy, vendors, please update your implementation or distribution. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Obscenity is the crutch of inarticulate motherfuckers.

1 0

[armedbear-devel] Recommended ABCL development setup
by Jonathan P. Bona 24 Aug '12

24 Aug '12

Greetings, As a user of ABCL, I've found it useful to browse the Java source, make slight modifications, run it in a debugger, and so on. I'm doing this rather inelegantly right now by linking to the source folder in an Eclipse project, and it's not working very well. Is there a recommended IDE setup that ABCL developers use? Regards, Jonathan Bona

2 1

Re: [armedbear-devel] Inflexible logic in FIND-SYSTEM-JAR and FIND-CONTRIB
by Mark 22 Aug '12

22 Aug '12

The point of the current procedure is that abcl-contrib.jar is not on the classpath at all, so it should be less configuration. That being said, I'm always open to easier ways for deployment as long as it doesn't break existing usages. I'm "on the road" camping right now so I really won't be able to work on this until perhaps September. A thought might be that the user can extend the CL:REQUIRE mechanism by pushing closures into a special variable whose name is something like *module-provider-hooks*, perhaps in a local system.lisp. This path may allow some experimentation before we merge those semantics with those of ABCL-CONTRIB.

1 0

[armedbear-devel] Inflexible logic in FIND-SYSTEM-JAR and FIND-CONTRIB
by Eric Marsden 22 Aug '12

22 Aug '12

Hi, I am trying to use the new abcl-contrib JSS functionality, which looks very useful; thanks. I have the ABCL classes (and in fact the ABCL-CONTRIB classes) embedded into a jar file containing other code, and both the FIND-SYSTEM-JAR and FIND-CONTRIB logic are failing. Would it be possible perhaps to search for abcl-contrib.jar on the classpath, instead of assuming that it is installed next to abcl-XXX.jar? Thanks, -- Eric Marsden

1 1