July 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] Stack overflow when compiler macro with fallback is triggered
by James M. Lawrence 12 Aug '12

12 Aug '12

(eval-when (:compile-toplevel :load-toplevel :execute) (defun foo () 99) (define-compiler-macro foo () `(locally (declare (notinline foo)) (foo)))) (defun call-foo () (foo)) Of course, the use case is a compiler macro that says, "OK, let's optimize! ... Never mind, I don't want to optimize that." Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.7.0_04 Oracle Corporation [...] ; (DEFUN FOO ...) ; (DEFINE-COMPILER-MACRO FOO ...) ; (DEFUN CALL-FOO ...) java.lang.StackOverflowError at org.armedbear.lisp.StructureObject$pf_make_structure.execute(StructureObject.java:671) at org.armedbear.lisp.Symbol.execute(Symbol.java:865) at org.armedbear.lisp.LispThread.execute(LispThread.java:760) at org.armedbear.lisp.jvm_714.execute(jvm.lisp:567) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.jvm_746.execute(jvm.lisp:572) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) [...]

5 5

[armedbear-devel] Double printing of the prompt
by Blake McBride 12 Aug '12

12 Aug '12

Greetings, The latest version of ABCL is double printing the prompt at times as follows: Armed Bear Common Lisp 1.1.0-dev-svn-13783 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.465 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): 3 3 CL-USER(2): 'hello HELLO CL-USER(3): '(a b c) (A B C) CL-USER(4): nil NIL CL-USER(5): CL-USER(5): 77 77 CL-USER(6): (cdr '(hello)) NIL CL-USER(7): nil NIL CL-USER(8): CL-USER(8): 3 3 CL-USER(9):

3 3

[armedbear-devel] destroy-thread and unwind-protect
by James Lawrence 08 Aug '12

08 Aug '12

(defun test-cleanup () (let* ((cleanedp nil) (thread (threads:make-thread (lambda () (unwind-protect (sleep 999) (setf cleanedp t)))))) (sleep 0.5) (threads:destroy-thread thread) (sleep 0.5) cleanedp)) (test-cleanup) ABCL-1.0.0 and ABCL-0.27.0 return NIL. Other implementations I tested all return T -- Allegro, Clozure, LispWorks, SBCL (changing "threads" to "bordeaux-threads"). Of course this isn't a bug since ABCL is free to do what it wishes. Does ABCL wish that?

5 5

[armedbear-devel] Simpe swing examples using JSS and JFLI
by fsmunoz＠gmail.com 01 Aug '12

01 Aug '12

Greetings, I've been playing around with ABCL for some days now, especially in terms of the Java interop abilities and Swing. This is because I was searching for a Lisp that could be easily used for cross-platform GUI programming and easy deployed (for the user). This narrowed it down to the several JVM-based Lisps (ABCL, Kawa, etc) and Clojure. While I like Clojure - and "lein uberjar" is a great facility, for example - I'm more confortable in CL, so I did this two small examples that can perhaps be useful as a way to compare ABCL's different interop facilities with themselves and Clojure. In a way I used this to get a "feel" on how things would work out and make a decision. ABCL JSS Swing Example: http://paste.lisp.org/display/130606 ABCL JFLI Swing Example: http://paste.lisp.org/display/130605 I'm going to make another use using the lower-level API (jcall, etc), for the sake of completeness, but I think that perhaps this examples can be helpful to others as a small reference, using a well-known example. For me it was quite fun and my overall impressions thus far is that: 1) ABCL offers different interop facilities that taken as a whole make it a quite capable solution for overall Java interop, including GUI programming. 2) The JSS approach has the advantage of being less verbose since the methods need not contain the class name (which looks cleaner IMO). It is also simpler to setup, i.e. no need for def-java-class et. al. 3) The JFLI approach integrates well with Lisp, since it provides completion of methods, amongst other small things. The lack of #"foo" syntax is also visually appealing IMO. It can also - theoretically - be used by JFLI installations in other Lisps. It is more verbose though, since methods must be preceeded with the class (class.foomethod) 4) Clojure's approach is (naturally) conceptually quite similar to JFLI, in the "feel" that it provides, although the use of (.fooMethod instance) is similar to (#"fooMethod" instance) in terms of synxtax. The use of macros (like doto) significantly reduces number of words used. 5) I see nothing in the way of implementing similar macro mechanisms on top of either JSS or JFLI - but I can be simplifying things brutally here. In the most simple scenario syntax differences are as follows: ABCL JSS: (#"setText" my-label "The Larch") ABCL JFLI: (jlabel.settext my-label "The Larch") Clojure: (.setText my-label "The Larch") The Clojure approach seems quite similar to the javadot approach of jscheme (http://jscheme.sourceforge.net/jscheme/doc/javadot.html) as noted in the ABCL blog - I was unaware of that. More complex approachs envolving the need for proxies contain more differences of course. I would greatly welcome any comments concerning style and approach: I am completely new to this so I am probably missing a lot. It was quite enjoyable though, even if there are still some rough edges here and there (quite understandable since for JFLI I had to used trunk). I think that this is an area worth exploration, easy (meaning well-integrated, clear syntax, small impact) interop is a huge advantage. Thank you for your hard work, highly appreciated. Cheers, Frederico

4 4

[armedbear-devel] Autoloading && method definitions
by Erik Huelsmann 01 Aug '12

01 Aug '12

Hi all, Today I've been playing around with ways to automatically extract symbols from our build to automate (most) of the autoloads.lisp maintenance. So, I've created a small adjustment to COMPILE-FILE which saves the top-level DEFUNs, DEFMETHODs and DEFGENERICs which have been compiled. The result is interesting even in light of today's file: analysis shows we have several generic functions for which methods have been defined across multiple files. An example: we have definitions for PRINT-OBJECT in print-object.lisp, but also in java.lisp and format.lisp. This is a problem, because the autoloader has been instructed to load "print-object.lisp" only, when finding references to the print-object generic function. My conclusion so far is that we need to be able to trigger auto-loading of more than one source file *and* that we need a way to determine in which order to load them: we'd typically want to load the file containing the DEFGENERIC before we load the one with the other method definitions. While the former isn't trivial (think threading) but doable, I'm still thinking how to achieve the latter. So, why do we want autoloading at all? Well, we want to make sure we get a short start up time and to achieve that, we don't load the parts of the system that we don't need. How much extra time it would take to load the full system? I have no idea at this moment. (But we could experiment and code to that extent would be greatly appreciated!) And why do I want to part with our current system? Well, from analysis of the DEFUN/DEFGENERIC/DEFMETHOD data (and thus excluding the DEFMACRO data) we have 2512 definitions each of which may be referenced by our users. Currently only a few hundred of them actually exist before the file gets autoloaded. Which ones will exist is hard to tell from the sources themselves. Maintaining the file is somewhat a trial and error process: if ABCL doesn't load without the autoloads, add them to the autoloads.lisp file. I'd like our process to be both more automatic and less trial and error. [I started to write the above yesterday, but apparently didn't send it...] Bye, Erik.

2 1

[armedbear-devel] ANSI bugs in call-next-method
by Rudi Schlatte 31 Jul '12

31 Jul '12

Hi, Just wanted to mention that the two test failures for call-next-method are much easier to fix now that we have mop:make-method-lambda, which gets passed the method metaobject. I can have a look this month (still busy with family matters until next week). Rudi

1 0

[armedbear-devel] Autoloader progress and experiences
by Erik Huelsmann 31 Jul '12

31 Jul '12

Hi all, Although I wanted to work on ticket #201 (&whole broken in DEFINE-METHOD-COMBINATION), I found a regression (ticket #227) which I believe is strongly correlated with how our process of auto loading works (ticket #226). So, I've done a bit of work, some of which already committed, to extract the symbols of toplevel defined functions/methods and macros from our bootstrap build. I'm now working to use that list to create a more complete "autoloads.lisp" file. During that work I found at least one cause of instability regarding our autoloading and the definition of generic functions: we were resolving (autoloading) symbols with an autoloader in the function slot when defining a generic function on them. Usually however, the reason to be defining a generic function on a symbol with an autoloader in the function slot will be the fact that autoloading has been triggered. The only reason this worked in the past is that our list of autoloaded symbols was so small we haven't run into this situation. Should that ever have happened, that'd have been very hard to find though. Another thing I found is that MACROEXPAND-1 (and by extension of its use in PRECOMPILE, the precompilation) try to resolve symbols with autoloaders on them. That's a problem as well, because we have forward-referenced functions: e.g. we forward-reference SLOT-VALUE-USING-CLASS from SLOT-VALUE. When clos.lisp is being loaded and SLOT-VALUE is being defined using DEFUN, it's being "precompiled": translated to an efficient execution form. However, that process finds a reference to SLOT-VALUE-USING-CLASS, which it will autoload. This recursively triggers loading of clos.lisp. Do we still want to do precompilation? Yes, I think so, because on my machine usual build times are ~ 6 minutes for a full build; this time goes up to ~16 minutes without precompilation. So, the process does what it's designed to do well. The answer then - I think - is to stop precompiling during function definition and delay that until the first actual invocation. ---- breaking news: While writing the above, I came up with another option, which is to make MACROEXPAND-1 only resolve symbols which are macro functions. That worked, or at least, that's what it looks like. I had a successful build and will run the compiled tests in a minute. As things stand, we'd be able to start generating most of our autoloads.lisp file. [even later: seems the test suite is completing now. I'm having a PSETF regression, I think, but no idea why yet.] ----- So, I think I'll work out the remainder of the change and make sure it gets committed. After that, I'll have a look at the PSETF failure - which is hopefully fall-out from another change or at least has a workaround in a different way: having automated autoloaders seems a valuable asset. Bye, Erik.

1 0

[armedbear-devel] Autoloading && method definitions
by Erik Huelsmann 30 Jul '12

30 Jul '12

Hi all, Today I've been playing around with ways to automatically extract symbols from our build to automate (most) of the autoloads.lisp maintenance. So, I've created a small adjustment to COMPILE-FILE which saves the top-level DEFUNs, DEFMETHODs and DEFGENERICs which have been compiled. The result is interesting even in light of today's file: analysis shows we have several generic functions for which methods have been defined across multiple files. An example: we have definitions for PRINT-OBJECT in print-object.lisp, but also in java.lisp and format.lisp. This is a problem, because the autoloader has been instructed to load "print-object.lisp" only, when finding references to the print-object generic function. My conclusion so far is that we need to be able to trigger auto-loading of more than one source file *and* that we need a way to determine in which order to load them: we'd typically want to load the file containing the DEFGENERIC before we load the one with the other method definitions. While the former isn't trivial (think threading) but doable, I'm still thinking how to achieve the latter. So, why do we want autoloading at all? Well, we want to make sure we get a short start up time and to achieve that, we don't load the parts of the system that we don't need. How much extra time it would take to load the full system? I have no idea at this moment. (But we could experiment and code to that extent would be greatly appreciated!) And why do I want to part with our current system? Well, from analysis of the DEFUN/DEFGENERIC/DEFMETHOD data (and thus excluding the DEFMACRO data) we have 2512 definitions each of which may be referenced by our users. Currently we define a subset "likely to be used" which causes autoloading to happen. However, since we regularly break that subset ourselves, I want to automate the task by collecting the symbols during the build (and allow for manual additions and deletions - which should be much more rare). Any comments, complementing experiments or proposed solutions are very welcome! Bye, Erik.

1 0