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

[armedbear-devel] How to load a lisp file containing non ascii characters encoded in utf-8?
by pjb＠informatimago.com 19 Nov '10

19 Nov '10

What should be done in abcl to be able to load a lisp file containing non ascii characters encoded in utf-8? CL-USER(3): (load "test.lisp") Error loading /home/pjb/test.lisp at line 2 (offset 46) #<THREAD "interpreter" {74CB02}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xffc3 is malformed while recoding with charset US-ASCII Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4): (lisp-implementation-version) "0.20.0" test.lisp is: ------------------------------------------------------------------------ ;; -*- mode:lisp;coding:utf-8 -*- (defvar *a* "é") ------------------------------------------------------------------------ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

1 0

[armedbear-devel] Patch to get BORDEAUX-THREADS working on post abcl-0.23.0
by Mark Evenson 19 Nov '10

19 Nov '10

As part of my ongoing task of keeping Hunchentoot working with ABCL, I noticed BORDEAUX-THREADS currently (as of 0.8.0) doesn't work with abcl-0.23 or later as we deprecated the thread interface it relies on. I've [created patch][1] that fixes this as well as actually providing an implementation of the CONDITION-WAIT/CONDITION-NOTIFY primitives, which had stopped working due to bit rot in BORDEAUX-THREADS. There is still a little funkiness in the bordeaux-threads-test suite which sometimes seems to generate errors, but I think this is from MOP issues in the fiveam, but I'm not exactly sure. [1]: http://slack.net/~evenson/abcl/hunchentoot/bordeaux-threads-abcl-20101120a.… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] asdf-install strangeness
by Kevin Raison 19 Nov '10

19 Nov '10

I recently started using abcl 0.22.0 but have run into issues installing packages using asdf-install. Here is an example error message. Does anyone know of a solution to this? CL-USER(7): (asdf-install:install 'hunchentoot) Install where? 1) System-wide install: System in /usr/local/asdf-install/site-systems/ Files in /usr/local/asdf-install/site/ 2) Personal installation: System in /home/raison/.asdf-install-dir/systems/ Files in /home/raison/.asdf-install-dir/site/ 0) Abort installation. --> 2 ;;; ASDF-INSTALL: Downloading 139617 bytes from http://weitz.de/files/hunchentoot.tar.gz to /home/raison/asdf-install-0.asdf-install-tmp ... #<THREAD "interpreter" {4DA42824}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xdc4a is malformed while recoding with charset UTF-8 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(8): 0 CL-USER(9): Thanks! Kevin

3 5

[armedbear-devel] Significant increase in build time
by Blake McBride 16 Nov '10

16 Nov '10

Greetings, I hadn't built ABCL in a little while so I checked out the latest version today and built it. It seemed to be significantly slower than before so I decided to investigate. This is what I found. In the past I could build ABCL in 2:43. It now takes me 4:40. That (IMO) represents a pretty significant change in build time. I did a binary search and discovered that all of the change occurred at revision 12918 - Generic Class File Branch Merge. In general, I could't care less about the build time unless it is indicative of a problem that could rear its head in my application. Where is that time being spent? Is there a change in runtime? Loading? Compiling? I'd be real interested in this. Thanks. Blake McBride

4 10

[armedbear-devel] cl+ssl problem
by Cyrus Harmon 15 Nov '10

15 Nov '10

Dear ABCL Developers, Attempting to asdf:load cl+ssl gives the following error: Loadable FASL not found for '/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev-fasl36-darwin-java-1.6/Users/sly/src/clbuild/source/cl+ssl/package.abcl' in 'jar:file:/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev-fasl36-darwin-java-1.6/Users/sly/src/clbuild/source/cl ssl/package.abcl!/package._' [Condition of type FILE-ERROR] A trivial rename of the .asd file (and the contained system) to, say, clssl, allows ABCL to get past this, so it looks like the + in the file name (or ASDF system name) is causing the problem. Of course the trivial fix doesn't really fix things as there's still a CFFI problem, but that's for another email.... thanks, Cyrus

3 3

[armedbear-devel] Java FFI performance enhancement idea: LRU cache
by Erik Huelsmann 12 Nov '10

12 Nov '10

Hi, Today, on IRC, I was approached by 'pmd' whether we have weak hash tables. We really don't, but he was actually looking for a way to memoize Java methods to be called with jmethod/jcall. Since we do kind of 'dynamic dispatch' (which can be a costly operation), I thought it would be a good idea to add this memoization to our Java.java file using an LRU cache to clear old cache elements and maybe with an interface to clear the cache or resize it. Comments? Regards, Erik.

2 1

Re: [armedbear-devel] [armedbear-cvs] r13017 - trunk/abcl/src/org/armedbear/lisp
by Ville Voutilainen 10 Nov '10

10 Nov '10

On 11 November 2010 00:23, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Log: > Check type in MAKE-PATHNAME for :DIRECTORY components. > + error(new TypeError("DIRECTORY argument not a string, list of strings, nil, :WILD, or :UNSPECIFIC.", value, NIL)); Where's :WILD-INFERIORS?

3 2

[armedbear-devel] compilation successfull, but launch fails with the infamous "Failed to find loadable system file 'autoloads' in boot classpath."
by pjb＠informatimago.com 09 Nov '10

09 Nov '10

Hi! I tried to compile abcl-0.22.0 on gentoo x86-64 with SBCL 1.0.19-gentoo and /opt/sun-jdk-1.6.0.22/. It looks like it went well, but I get "Failed to find loadable system file 'autoloads' in boot classpath." when trying to launch abcl. I could find some pages with this diagnostic on the web, but no comment or solution. [pjb@kuiper :0.0 abcl-0.22.0]$ Linux kuiper 2.6.34-xen-r3-kvm-nvidia-joy-c7 #3 SMP Fri Oct 8 12:01:59 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux [pjb@kuiper :0.0 abcl-0.22.0]$ tar zxf /data/src/languages/abcl-src-0.22.0.tar.gz [pjb@kuiper :0.0 abcl-0.22.0]$ mv abcl-src-0.22.0/ src [pjb@kuiper :0.0 abcl-0.22.0]$ cd src [pjb@kuiper :0.0 src]$ cp customizations.lisp.in customizations.lisp [pjb@kuiper :0.0 src]$ ./build-from-lisp.sh sbcl bash: ./build-from-lisp.sh: Permission denied [pjb@kuiper :0.0 src]$ chmod 755 ./build-from-lisp.sh [pjb@kuiper :0.0 src]$ ./build-from-lisp.sh sbcl This is SBCL 1.0.19-gentoo, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ; loading system definition from ; /usr/share/common-lisp/systems/asdf-binary-locations.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM ASDF-BINARY-LOCATIONS {1002BFA1B1}> as ; ASDF-BINARY-LOCATIONS ; in: LAMBDA NIL ; (LET* ((STRING (NAMESTRING PATHNAME)) (BUILD-ABCL::LEN (LENGTH STRING))) ; (WHEN (POSITION #\ STRING) ; (SETF STRING ; (CONCATENATE 'STRING "\"" (BUILD-ABCL::COMP STRING #\\) "\""))) ; STRING) ; ; caught STYLE-WARNING: ; The variable LEN is defined but never used. ; ; compilation unit finished ; caught 1 STYLE-WARNING condition Platform: Linux JDK: /opt/sun-jdk-1.6.0.22/ Java compiler: /opt/sun-jdk-1.6.0.22/bin/javac Compiler options: -g Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: JavaObject.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.228 seconds. Startup completed in 2.617 seconds. #<THREAD "interpreter" {7433B121}>: Debugger invoked on condition of type ERROR Failed to find loadable system file 'system' in boot classpath. [1] CL-USER(1): Build completed successfully in 7.457 seconds. [pjb@kuiper :0.0 src]$ ./abcl --eval '(lisp-implementation-version)' Armed Bear Common Lisp 0.22.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.223 seconds. java.lang.Error at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1570) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.Lisp.error(Lisp.java:354) at org.armedbear.lisp.Load.loadSystemFile(Load.java:272) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:691) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:520) at org.armedbear.lisp.Lisp.eval(Lisp.java:485) at org.armedbear.lisp.Load.loadStream(Load.java:566) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:534) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:424) at org.armedbear.lisp.Load.loadSystemFile(Load.java:323) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:163) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:94) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:662) ERROR placeholder called with arguments: #<ERROR {647109C4}> "Failed to find loadable system file 'autoloads' in boot classpath." [pjb@kuiper :0.0 src]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

2 1

[armedbear-devel] [PATCH] Eliminate duplicate lookups in JHandler
by Mario Lang 09 Nov '10

09 Nov '10

Hi. A simple thing, but I spotted it during reading of the code. Index: src/org/armedbear/lisp/JHandler.java =================================================================== --- src/org/armedbear/lisp/JHandler.java (revision 12738) +++ src/org/armedbear/lisp/JHandler.java (working copy) @@ -66,21 +66,22 @@ public static void callLisp (String s, Object o, String as[], int ai[]) { if (table.containsKey(o)) { - Map<String,Entry> entryTable = (Map<String,Entry>)table.get(o); + Map<String,Entry> entryTable = (Map<String,Entry>)table.get(o); if (entryTable.containsKey(s)) { - Function f = ((Entry)entryTable.get(s)).getHandler(); - LispObject data = ((Entry)entryTable.get(s)).getData(); - Fixnum count = ((Entry)entryTable.get(s)).getCount(); - Fixnum[] lispAi = new Fixnum[ai.length]; + final Entry entry = entryTable.get(s); + final Function f = entry.getHandler(); + final LispObject data = entry.getData(); + final Fixnum count = entry.getCount(); + final Fixnum[] lispAi = new Fixnum[ai.length]; for (int i = 0; i < ai.length; i++) { lispAi[i] = Fixnum.getInstance(ai[i]); } - LispObject lispAiVector = new SimpleVector(lispAi); - SimpleString[] lispAs = new SimpleString[as.length]; + final LispObject lispAiVector = new SimpleVector(lispAi); + final SimpleString[] lispAs = new SimpleString[as.length]; for (int i = 0; i < as.length; i++) { lispAs[i] = new SimpleString(as[i]); } - LispObject lispAsVector = new SimpleVector(lispAs); + final LispObject lispAsVector = new SimpleVector(lispAs); LispObject[] args = new LispObject[] //FIXME: count -> seq_num { data, new JavaObject(o), lispAiVector, lispAsVector, internKeyword(s), count }; f.execute(args); -- CYa, ⡍⠁⠗⠊⠕

2 1

[armedbear-devel] Profiling ABCL exception handling
by Erik Huelsmann 09 Nov '10

09 Nov '10

Yesterday, I started playing around with JRockit's MissionControl tool, now that we run on JRockit. One of the (quite surprising) findings was that we generated over 1.3 million ClassNotFoundExceptions during the compilation of Maxima. With two simple changes nearly all of those have been removed. There are still quite a few exceptions associated with our loading process though, as our ZipCache seems to trigger integer parsing exceptions in URLs internally; from the names of the functions through which the exceptions are being found, it looks like Java wants to parse IPv4-dot-separated tuples as host names. Our URLs don't have hostnames most of the time: we're passing file:// URLs! Running an exception profile on Maxima running its test suite shows lots of non-local transfer of control exceptions: Return, Go and Throw: during a run of ca 10 minutes, I'm finding 5.5 million exceptions being thrown which - as MissionControl calculated for me - should mean an average of little over 12k/s. I guess that's kind of expected with our strategy for non-local transfers of control. However, if rethrows are counted as well, we can probably do better: by minimizing the number of try/catch blocks in our compiled code which reset special bindings. To illustrate what I mean, the example """ (declaim (special *x*)) (defun foo (*X*) (let ((*X* 1)) (let ((*X* 2)) 0))) """ Decompiles into (pseudo code): foo(*X*): function_setup_code reg1 = current_specials_state() try { bind_special(*X*, arg1) reg2 = current_specials_state() try { bind_special(*X*, 1) reg3 = current_specials_state() try { bind_special(*X*, 2) reg4 = integer_0 } catch (Throwable t) { reset_specials_state(reg3) rethrow t } reset_specials_state(reg3) } catch (Throwable t) { reset_specials_state(reg2) rethrow t } reset_specials_state(reg2) } catch (Throwable t) { reset_specials_state(reg1) rethrow t } reset_specials_state(reg1) return reg4 As you see, to handle a single non-local transfer of control, we throw and catch the same exception 3 times. This issue is known as ticket #90 (http://trac.common-lisp.net/armedbear/ticket/90) It would be really nice to hash through all the different situations which may need special-bindings-state to be reset with a few of you and resetting *only* those cases. I'm hoping our general performance - and the Maxima-on-ABCL performance because of its many special variables in particular. BTW: ABCL came from the situation where it tried to use that scheme, but the way it was implemented made it really hard to find out where specials were leaking - and they were. Bye, Erik.

2 3

[armedbear-devel] Performance: Analysis of options to reduce exception handlers
by Erik Huelsmann 09 Nov '10

09 Nov '10

Based on Joel's reaction regarding my profiling attempts on exception rates/exception handling in ABCL, I've been thinking how to do better in the exceptions/specials restoration department. Let me start by describing how our current exception handling/specials restoration is structured. It should be noted that the current strategy works the way it does because we were failing to restore special values all over the place. This made me decide that we should restore specials when leaving the binding block, even if that is through non-local transfer of control, with the contrived example for exception handlers as given in my mail earlier this month. Looking at the profiling results, we're now correct, but probably we're not very efficient at doing it. This is what I've been thinking: If a block binds special variables, there are 3 ways to exit the block: 1. through normal sequential execution of the byte code 2. through a function-local jump out of the block 3. through a non-local transfer of control (modelled using the ControlTransfer exception in ABCL) Case (1) is easy: we just reach the end of the binding block, at which point there is a call to "LispThread.restoreSpecialBindings(mark);". Case (2) is a little more involved: before jumping to the target location the specials are restored at the jump-location. To do this, there's a bit of logic in the compiler to find out which restore point to use. Case (3) is quite involved: at the call site an exception is thrown causing the stack to be unwound. When looking at it like this, the catch-site should restore its specials state. There's no need to do that, currently, because all the intermediate levels restore their state. There is at least one special case here: unwind-protect may be executing lisp code (which needs its specials restored to the right state) without being the final catch location. Final catch requiring forms are quite easily determined: TAGBODY (to catch GO), BLOCK (to catch RETURN) and CATCH (to catch THROW). One of the major drawbacks of this scheme is that all non-local transfers become responsible for restoring their special bindings. BLOCK and TAGBODY forms which don't serve as non-local target are not affected by this reasoning; they fall under case (2). CATCH can never be considered taking only local transfers of control as it However, the entire application may not be binding any specials at all. The overhead involves a call at the start of each block which contains non-local-transfer targets to snapshot the special bindings state and to restore it *in case of a non-local transfer*. The calls involved are markSpecialBindings() and restoreSpecialBindings(), two very short and - I think - efficient functions. So, there's a small drawback in applications which don't use special bindings much. However, the potential gain in applications which do use them is quite relevant: the example I gave before shows that a relatively simple function binding the same special variable three times will cause 3 separate specials-unwinding-exception blocks, each rethrowing the exception to the next level. Thinking about it a bit more, I realize that no additional exception blocks have to be registered. Just only the catch/restore of specials state. Looking at it this way, I propose that we stop restoring specials in finally blocks, moving part of the responsibility of having correct specials bindings to BLOCK, CATCH, TAGBODY and UNWIND-PROTECT. My change should affect both the interpreter and the compiler, to get the full benefit of efficiency. However, I thought I'd implement the LET/LET* binding optimization in the compiler first, just to see how much we benefit from this change in Maxima. Comments? Bye, Erik.

1 0

[armedbear-devel] Increased FASL size support -- was: [armedbear-cvs] r13013 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 09 Nov '10

09 Nov '10

There were some reports with FASLs becoming too large -- ie generating more .cls files than can be loaded in our loader method "<fasl-name>_0" because the code overflows the 64kB method size boundary. The change below drastically reduces the size of the generated loader method, reducing the chances that people run into an issue. Of course, that can't be the final state, but it seems like a good option, as long as we don't implement the means to split this method. Implementing means to split specifically this method however, doesn't seem good enough: all of our methods have the potential of overrunning the 64kB boundary and it would be nice if we could implement general method-splitting logic instead, to be applied when methods overrun their 64kB boundary size. This commit is in our upcoming release, aleviating (but not solving) the Big FASLs problem. Bye, Erik. On Mon, Nov 8, 2010 at 11:34 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Mon Nov 8 17:34:18 2010 > New Revision: 13013 > > Log: > Reduce the impact of the fasl-loader "_0" class's maximum size of 64kB: > this change reduces the size of pprint_0.cls from 23001 to 19380 bytes, > a saving of 18.64%, which is probably much more when counting the size > of the execute() method alone. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compile-file.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compile-file.lisp Mon Nov 8 17:34:18 2010 > @@ -679,7 +679,14 @@ > (defun generate-loader-function () > (let* ((basename (base-classname)) > (expr `(lambda (fasl-loader fn-index) > - (identity fasl-loader) ;;to avoid unused arg > + (declare (type (integer 0 256000) fn-index)) > + (identity fasl-loader) ;;to avoid unused arg > + (jvm::with-inline-code () > + (jvm::emit 'jvm::aload 1) > + (jvm::emit-invokevirtual jvm::+lisp-object+ "javaInstance" > + nil jvm::+java-object+) > + (jvm::emit-checkcast +fasl-classloader+) > + (jvm::emit 'jvm::iload 2)) > (ncase fn-index 0 ,(1- *class-number*) > ,@(loop > :for i :from 1 :to *class-number* > @@ -687,20 +694,14 @@ > (let* ((class (%format nil "org/armedbear/lisp/~A_~A" > basename i)) > (class-name (jvm::make-class-name class))) > - `(,(1- i) > - (jvm::with-inline-code () > - (jvm::emit 'jvm::aload 1) > - (jvm::emit-invokevirtual jvm::+lisp-object+ "javaInstance" > - nil jvm::+java-object+) > - (jvm::emit-checkcast +fasl-classloader+) > - (jvm::emit 'jvm::dup) > - (jvm::emit-push-constant-int ,(1- i)) > - (jvm::emit-new ,class-name) > - (jvm::emit 'jvm::dup) > - (jvm::emit-invokespecial-init ,class-name '()) > - (jvm::emit-invokevirtual +fasl-classloader+ > + `(,(1- i) > + (jvm::with-inline-code () > + (jvm::emit-new ,class-name) > + (jvm::emit 'jvm::dup) > + (jvm::emit-invokespecial-init ,class-name '()) > + (jvm::emit-invokevirtual +fasl-classloader+ > "putFunction" > - (list :int jvm::+lisp-object+) jvm::+lisp-object+) > + (list :int jvm::+lisp-object+) jvm::+lisp-object+) > (jvm::emit 'jvm::pop)) > t)))))) > (classname (fasl-loader-classname)) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Reading a UTF-8 lisp source fails.
by pjb＠informatimago.com 07 Nov '10

07 Nov '10

My sources contain some non US-ASCII characters, so they're all encoded in UTF-8. However, loading them fails: [pjb@kuiper :0.0 lisp]$ LC_CTYPE=en_US.UTF-8 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.266 seconds. Startup completed in 0.726 seconds. Type ":help" for a list of available commands. CL-USER(1): (load"test-abcl-unicode.lisp") Error loading /home/pjb/src/git/public/lisp/test-abcl-unicode.lisp at line 3 (offset 54) #<THREAD "interpreter" {132021A}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xffc2 is malformed while recoding with charset US-ASCII Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): (quit) [pjb@kuiper :0.0 lisp]$ What should I do to let abcl read them as UTF-8 and not try to convert them into US-ASCII? The test file is: ------------------------------------------------------------------------ ;;;; -*- mode:lisp;coding:utf-8 -*- (defvar *test* "45°") ;;;; THE END ;;;; ------------------------------------------------------------------------ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

2 1

[armedbear-devel] directory doesn't honor :wild-inferiors (#P"**/*.*")
by pjb＠informatimago.com 06 Nov '10

06 Nov '10

[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.266 seconds. Startup completed in 0.75 seconds. Type ":help" for a list of available commands. [1] CL-USER(9): (directory "*/*.asd") (#P"/home/pjb/src/git/public/lisp/tools/com.informatimago.common-lisp.tools.make-depends.asd" #P"/home/pjb/src/git/public/lisp/common-lisp/com.informatimago.common-lisp.asd" ...) [1] CL-USER(10): (directory #P"**/*.asd") NIL [1] CL-USER(11): -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 2

[armedbear-devel] Working toward the 0.23 release
by Erik Huelsmann 06 Nov '10

06 Nov '10

We've had a productive number of weeks since our last release. Changes include: * Running the Maxima test suite without failure [Thanks to the Maxima team for their part in this!] * CLOS thread safety fixes * Fixes to be able to run on Oracle JRockit JVM * Numerous tickets fixed * A new class file writer to build further optimizations upon So, I think we should be moving toward a release real soon now. Is there more to be added to trunk? If not, I'll be branching by the end of the weekend; otherwise, let's discuss and see what timelines to set. Everybody, thanks again for your contributions! Bye, Erik.

2 2

[armedbear-devel] Soliciting (updates to) testimonials
by Erik Huelsmann 04 Nov '10

04 Nov '10

In the interest of informing potential users about the various uses, strengths and weaknesses of ABCL, we have a Testimonials page. However, most of the testimonials don't have a date. That's rather unfortunate, because it makes it hard to judge how valid they still are: over the past three years, we had quite a bit of change in our code base. Most of the changes were driven by CLHS compliance, correctness or code cleanup (to support future maintenance). So, there's a good chance some of the older testimonials don't actually apply to current ABCL versions anymore. Just removing those older testimonials (leaving a blank page) isn't really an option for me. OTOH, leaving them up there without a date isn't really indicative of today's ABCL either. That's why I'm asking you to submit your (updated) testimonials. If you're currently using ABCL (or have been using until recently), but there's no testimonial up on the page from you, please take a quick look at the top testimonial at http://common-lisp.net/project/armedbear/testimonials.shtml (the one by David Kirkman). As you see, it doesn't have to be much, so, creating a testimonial doesn't have to take a lot of time. Taking the half hour to create a testimonial is your opportunity to donate back to the ABCL community! Thanks for your time and contributions, Erik.

1 0

[armedbear-devel] ASDF and ABCL
by Faré 31 Oct '10

31 Oct '10

Dear ABCL developers, the one big thing missing in ABCL to fully pass the ASDF test suite is support for (directory "/usr/share/common-lisp/source/**/*.asd") Could you get it to work and update to the latest stable ASDF? That would be great! [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The trouble with opportunity is that it always comes disguised as hard work. — Herbert V. Prochnow

3 12

[armedbear-devel] BUG: armedbear-devel@common-lisp.net
by Alessandro Serra 22 Oct '10

22 Oct '10

Hi, compiling ltk I have the following error: #<THREAD "interpreter" {FE135D}>: Debugger invoked on condition of type SIMPLE-ERROR s2 argument 34666 out of 16-bit signed range. Debugging a bit, I found that the error is in "compiler-pass2.lisp" in the function "code-bytes" during the pass2 (replace labels with calculated offsets). What can I do to avoid this error? Thanks, Alessandro -- The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words. How To Build A Universe That Doesn't Fall Apart Two Days Later Philip K. Dick

2 1

[armedbear-devel] basic support for DEFINE-METHOD-COMBINATION (long form) landed on trunk
by Erik Huelsmann 20 Oct '10

20 Oct '10

Just a minute ago, I committed Mark Evenson's work on DEFINE-METHOD-COMBINATION (long form) [short: D-M-C]. It's a port to ABCL of the D-M-C implementation found in XCL which derives from Sacla. That being the case, I expect the implementation to be little tested. Which can definitely be said of the port. However, some testing with a few self-made tests didn't turn up many problems. However, SBCL has a series of tests for D-M-C. It would be nice if we could port those to ABCL too in an effort to smoke out any issues our D-M-C implementation may have. I smoked out the first one already that way: there was a quote missing is a function which returns a part of a method combination form. Compile times just longer once again - however, there should be no measurable impact for any code which doesn't use the long form of D-M-C itself. Serious request: help smoke out problems! Test! Fix! The sooner we get good confidence in the implementation, the sooner we can release 0.23! Bye, Erik.

2 1

[armedbear-devel] failure to compile big files
by Carlos Ungil 19 Oct '10

19 Oct '10

Dear ABCL developers, trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range." ----------------------------------------------------- (defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i))))) (many-functions 1525) ----------------------------------------------------- There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away... This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it. Cheers, Carlos

3 4

[armedbear-devel] Patch: top-level::repl keyword evaluation and command case-ignore.
by mahmud 16 Oct '10

16 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch fixes these two issues in ABCL 0.22.0: 1) Keyword evaluation in the repl is broken. The repl assumes all keywords are, in fact, repl commands. 2) Repl commands are case sensitive: :help :HELP mean two different things. The patch also contains tests. Regards. - - mahmud -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMoPZ2AAoJEHC3KbywAoue0/4H/0jjeUEP6wsARhBKEIZLYWGc E3UV+XaPyz38R+IjpJFR1ne2w+ernfjJ+XJXslHwerUjet02tOrNDW10QzyvvJJP UcBNOJwtLn/m8sCbcDhE8+Y/SFergnx6HP9wqPE5N3u2MEoaWqoW/CrufcCxfo2E 0r8RkTOSssQi8jJP6n+mdcVpEuLhPbtL3oxThRKBwfpUaRdxdqn5muDkiO6j8TKZ hjldBHU02vPKWyOPNAsJN6tN1mcChCvc3/TwOPTCngEAY3wNOswQxrOkB/VQX+Wc cQgBsFj5b11FzrpKjmUe5lCQwvba1K2H2hkYqHvdPu2nobOrkDpx7wiI6nbh9So= =U43j -----END PGP SIGNATURE-----

2 3

[armedbear-devel] java interop question
by Kevin Raison 14 Oct '10

14 Oct '10

I am an old hand at cl, but java is still a bit of a mystery to me. I am particularly puzzled as to why, when trying to use the apache http components library to do a simple http get in abcl, I cannot make it work. My code: (defun http-get (url) (let* ((url (jnew (jclass "java.lang.String") url)) (client-class (jclass "org.apache.http.impl.client.DefaultHttpClient")) (client-obj (jnew client-class)) (get-class (jclass "org.apache.http.client.methods.HttpGet")) (get-obj (jnew get-class url))) (jcall (jmethod client-class "execute") client-obj get-obj))) And the java code from the apache tutorial http://hc.apache.org/httpcomponents-client-4.0.3/tutorial/html/fundamentals…: HttpClient httpclient = new DefaultHttpClient(); HttpGet httpget = new HttpGet("http://localhost/"); HttpResponse response = httpclient.execute(httpget); ... For some reason, my code fails with No such method: org.apache.http.impl.client.DefaultHttpClient.execute(). I do have the appropriate jars in my class path. The java code specifically calls the execute method on its instantiated httpclient, but I cannot do the same from abcl. This method is inherited from org.apache.http.impl.client.AbstractHttpClient, in case that makes a difference. (http://hc.apache.org/httpcomponents-client-4.0.3/httpclient/apidocs/index.h…) Thanks for any insight! -Kevin

3 4

[armedbear-devel] AbclScriptEngine exits on load
by Ole Myren Rohne 08 Oct '10

08 Oct '10

Hi ABCL-developers, Thank you for releasing abcl-0.22! I'm playing with AbclScriptEngine (with Electric VLSI) and found a tiny problem with config.lisp: EXT:MAKE-THREAD should be THREADS:MAKE-THREAD. Unfortunately the problem was unnecessary hard to debug because in the absence of TPL::REPL the debugger ends up quitting the entire application. I'm wondering if in that case it would be more useful to throw a Java error, eg like SYS::%DEBUGGER-HOOK-FUNCTION? Best regards, Ole

3 3

Re: [armedbear-devel] [armedbear] #83: problem with error reporting on undefined class during make instance
by Mahmud Mohamed 04 Oct '10

04 Oct '10

On 10/4/2010 8:53 AM, armedbear wrote: > mmohamed, thanks for the patch, unfortunately, it completely disables the > possibility (supported by CLHS) to forward-reference classes like this: > Understood. I will rework it later tonight. Cheers!

2 1

[armedbear-devel] Ticket 100: #P deserialization still valid?
by Erik Huelsmann 04 Oct '10

04 Oct '10

Alessio, Could you check ticket #100 (http://trac.common-lisp.net/armedbear/ticket/100)? You reported we don't deserialize well. Since Mark did quite a bit of work on pathnames, has it been fixed? Bye, Erik.

3 3

[armedbear-devel] ABCL Ticket #29: Loading user files off a JAR
by Erik Huelsmann 04 Oct '10

04 Oct '10

Hi Alan, Could you please check ticket #29 (http://trac.common-lisp.net/armedbear/ticket/29)? It's about being able to load files off JARs. However, with Mark Evenson's latest work on loading FASLs off jars, the request may be fulfilled already. Is that the case? With kind regards, Erik.

1 0

[armedbear-devel] CLOS thread safety
by Erik Huelsmann 03 Oct '10

03 Oct '10

Hi David, > Are there any known thread safety issues with CLOS? I've been > getting some weird MOP errors that I made go away by redefining > slot-value such that it has to acquire a global lock before it can do > anything. I assume that the problem is in my code: but the threads > that are executing when I get the failures share no code (or > variables), and every time the errors pop up slot-value is on the > callstack someplace. Well, there have not been any specific threading issues mentioned. Over two years ago, back when I started doing ABCL, there were threading issues which looked like threading issues in CLOS. They turned out to be threading issues in the compiler though. Having said that, I see there have not been taken synchronization measures on a high level: there are no locks and threads:synchronized-on blocks in clos.lisp. There are some synchronized calls on the Java side; I'm not sure the low-level protection is good enough to maintain consistency though. Can you share some examples which show the issues here? Adding thread-safety to clos.lisp - in specific, targeted places - should be well doable. Bye, Erik.

5 15

[armedbear-devel] Bug: (setf (values (struct-slot struct)) (values 42)) fails
by Zach Beane 03 Oct '10

03 Oct '10

(The "Reporting bugs" link on the abcl site doesn't actually link anywhere, so I'm mailing the list.) Here's a file that triggers an ABCL bug: ;;;; abcl-bug.lisp (defpackage #:abcl-bug (:use #:cl) (:export #:trigger)) (in-package #:abcl-bug) (defstruct mystruct slot) (defun trigger () (let ((struct (make-mystruct))) (setf (values (mystruct-slot struct)) (values 42)) struct)) Here's what happens when I run it: Armed Bear Common Lisp 0.22.0 Java 1.6.0_18 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.445 seconds. Startup completed in 1.688 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "abcl-bug")) ; Compiling /tmp/abcl-bug.lisp ... ; (DEFPACKAGE #:ABCL-BUG ...) ; (IN-PACKAGE #:ABCL-BUG) ; (DEFSTRUCT MYSTRUCT ...) ; (DEFUN TRIGGER ...) ; Wrote /tmp/abcl-bug.abcl (0.447 seconds) T CL-USER(2): (abcl-bug:trigger) #<THREAD "interpreter" {1653033E}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function (SETF SYSTEM:STRUCTURE-REF) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {8FE2509}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:353) 3: org.armedbear.lisp.Symbol.getSymbolSetfFunctionOrDie(Symbol.java:399) 4: org.armedbear.lisp.abcl_bug_9.execute(abcl-bug.lisp:11) 5: org.armedbear.lisp.LispThread.execute(LispThread.java:552) 6: org.armedbear.lisp.Lisp.evalCall(Lisp.java:514) 7: org.armedbear.lisp.Lisp.eval(Lisp.java:485) [1] CL-USER(4): I would expect to get a structure back with SLOT set to 42, instead of this error. This is a strange case (you normally wouldn't use VALUES there) but it comes from some larger real code that sets multiple struct slots from a multiple-value-returning function. Zach

3 2

[armedbear-devel] What is the consensus on JFLI and JSS?
by mahmud 26 Sep '10

26 Sep '10

Hi there, First, a big thank you and congratulation on a job well done, everyone! Secondly. What is the community take on jfli[1] and jss[1]? I like them both, and I plan to use them heavily to Lispify a few Java libraries. However, the two are incompatible, they both have features I would like to see merged. Have there been any attempts at wrapping the native FFI with something higher level? I am interested in something that does the following: 1) Automatic importing of java packages and making them into Lisp packages. 2) Succinct, case-indifferent syntax. I would like to extend either of them to do: 3) Subclassing of java classes in Lisp. 4) Ability to implement java interfaces in Lisp classes. I have a few more ideas, most of which are feasible, but would like to get the community's input on FFI wrappers before I head off in a solitary direction. Regards. - mahmud

3 2

[armedbear-devel] [ANNOUNCE] ABCL 0.22.0
by Erik Huelsmann 26 Sep '10

26 Sep '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.20.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. The release is a small maintenance release: most efforts were focussed on work happening on branches some of which has already been merged to trunk for 0.23. The release notes can be viewed at http://common-lisp.net/project/armedbear/release-notes-0.22.shtml. and the list of changes at http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES. Latest and older binary and source distributions can be downloaded from http://common-lisp.net/project/armedbear/releases/

1 1

Re: [armedbear-devel] [armedbear-cvs] r12918 - in trunk/abcl: . src/org/armedbear/lisp test/lisp/abcl test/lisp/ansi
by Erik Huelsmann 25 Sep '10

25 Sep '10

Hi Alessio, Thanks! Great to see the branch on trunk now! Bye, Erik. On Sat, Sep 25, 2010 at 12:35 AM, Alessio Stalla <astalla(a)common-lisp.net>wrote: > Author: astalla > Date: Fri Sep 24 18:35:02 2010 > New Revision: 12918 > > Log: > generic-class-file branch merged. > > > Added: > trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/src/org/armedbear/lisp/jvm-class-file.lisp > trunk/abcl/src/org/armedbear/lisp/jvm-instructions.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/src/org/armedbear/lisp/jvm-instructions.lisp > trunk/abcl/test/lisp/abcl/class-file.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/test/lisp/abcl/class-file.lisp > Removed: > trunk/abcl/src/org/armedbear/lisp/opcodes.lisp > Modified: > trunk/abcl/abcl.asd > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compile-system.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > trunk/abcl/src/org/armedbear/lisp/jvm.lisp > trunk/abcl/src/org/armedbear/lisp/known-symbols.lisp > trunk/abcl/test/lisp/ansi/parse-ansi-errors.lisp > >

1 0

[armedbear-devel] generic-class-file branch landed on trunk: who re-enables runtime-class.lisp/RuntimeClass.java?
by Erik Huelsmann 25 Sep '10

25 Sep '10

Finally, the branch which is about implementing a generic class file generator (en rewriting the compiler output generator in terms of it) has landed on trunk. These are the next steps: 1. Devise an api for external users - there are currently *no* exported symbols 2. Rewrite runtime-class.lisp in terms of this API, instead of the old ASM bytecode modifier library. Any takers? Next to the re-enabling of runtime-class.lisp, the other benefit of the branch is that it's now possible to create Java class files from the compiler which contain much more complicated (but hopefully better performing) method patterns. Regards, Erik.

1 0

[armedbear-devel] How to use JARRAY-SET to fill a byte array?
by Chun Tian (binghe) 14 Sep '10

14 Sep '10

Hi again ... ABCL I want to fill a Java byte[] array. But I don't know how to correctly use JARRAY-SET (I should use it, right?): CL-USER(1): (defvar $*byte (jclass "byte")) $*BYTE CL-USER(2): (setf array (jnew-array $*byte 10)) #<jarray [B@7a2ee7e5 {1D7AAA0E}> CL-USER(3): (jarray-set array 1 0) #<THREAD "interpreter" {6E61A414}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.IllegalArgumentException: argument type mismatch'. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4): 0 CL-USER(5): (jarray-ref array 0) 0 So, a plain number "1" cannot work, but what else I can do? a object of java.lang.Byte? And, is there any quick way I can fill a byte array using contents from a Lisp array? Regards, Chun Tian (binghe)

3 5

[armedbear-devel] How to declare a jconstructor/jmethod which has array arguments?
by Chun Tian (binghe) 14 Sep '10

14 Sep '10

Hi, ABCL I already know how to declare a jconstructor or jmethod which has primitives as arguments: For example, for java.net.DatagramSocket, I have following declarations which works fine: (defvar $*int (jclass "int")) (defvar $*DatagramSocket (jclass "java.net.DatagramSocket")) (defvar $*InetAddress (jclass "java.net.InetAddress")) (defvar $%DatagramSocket/2 (jconstructor $*DatagramSocket $*int $*InetAddress)) (defvar $@close/DatagramSocket/0 (jmethod $*DatagramSocket "close")) ... But how can I declare java.net.DatagramPacket, whose constructor has a byte[] argument: public DatagramPacket (byte[] buf, int offset, int length) Just don't know how to represent "byte[]" ... Regards, Chun Tian (binghe)

3 3

[armedbear-devel] [CfP] 4th European Lisp Symposium, Hamburg, March 31 - April 1st, 2011
by Didier Verna 13 Sep '10

13 Sep '10

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4th European Lisp Symposium Special Focus on Parallelism & Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~~ + Submission Deadline: January 09, 2011 + Author Notification: February 06, 2011 + Final Paper Due: February 28, 2011 + Symposium: March 31 - April 1st, 2011 Authors of accepted research contributions will be invited to submit an extended version of their papers for journal publication. Scope ~~~~~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism & Efficiency". We especially invite submissions in the following areas: + Parallel and distributed computing + Code generation for multi-core architectures + Code generation for HTM + Large and ultra-large systems + Optimization techniques + Embedded applications Contributions are also welcome in other areas, including but not limited to: + Context-, aspect-, domain-oriented and generative programming + Macro-, reflective-, meta- and/or rule-based development approaches + Language design and implementation + Language integration, inter-operation and deployment + Development methodologies, support and environments + Educational approaches and perspectives + Experience reports and case studies Technical Program: ~~~~~~~~~~~~~~~~~~ We invite submissions in the following forms: * Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. * Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=els2011 Programme Chair ~~~~~~~~~~~~~~~~ Didier Verna - EPITA Research and Development Laboratory, France Local Chair ~~~~~~~~~~~~ Ralf Moeller - Hamburg University of Technology, Germany Programme Committee ~~~~~~~~~~~~~~~~~~~~ Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Working toward the 0.22 release?
by Erik Huelsmann 11 Sep '10

11 Sep '10

Since it's now almost 2 months since we did our last release, it's time to work to the next one again. With regret I propose that we release what we currently have in trunk (unless someone quickly wants to do something about that). Then, after we branched, I'll merge the generic-class-writer branch to trunk meaning it should then be tested enough to be included in 0.23. Like any release, we need: * to update CHANGES * to create a release-notes html file * to make sure our code doesn't have regressions by running it through the Maxima test suite and the ANSI tests Volunteers for any of these steps, or maybe people wanting to perform other steps in addition? Bye, Erik.

2 1

[armedbear-devel] Searching for wild-inferiors
by Theam Yong Chew 03 Sep '10

03 Sep '10

Hi everyone, Does ABCL support wild-inferiors in any way at all? DIRECTORY, which calls SYSTEM::LIST-DIRECTORIES-WITH-WILDCARDS, does not return a list of the whole subtree, although ABCL seems to understand the "**" notation for :wild-inferiors. Notably, asdf's :tree directive won't work, which was how I stumbled onto this. CL-USER(56): (pathname-directory "/home/temp/**/") (:ABSOLUTE "home" "temp" :WILD-INFERIORS) CL-USER(55): (system::list-directories-with-wildcards "/home/temp/**/") NIL CL-USER(60): (system::wild-p :wild) T CL-USER(59): (system::wild-p :wild-inferiors) NIL Also, for the following error, I am running armedbear 0.21.0 on Linux ackbar 2.6.28-19-generic #64-Ubuntu SMP Wed Aug 18 20:55:57 UTC 2010 i686 GNU/Linux and with java: java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1~9.04.1) OpenJDK Client VM (build 16.0-b13, mixed mode, sharing) CL-USER(5): (directory #p"/home/*/") #<THREAD "interpreter" {1217E67}>: Debugger invoked on condition of type TYPE-ERROR 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. [1] CL-USER(4): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {1D382AB}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:353) 3: org.armedbear.lisp.Lisp.type_error(Lisp.java:394) 4: org.armedbear.lisp.Lisp.coerceToPathname(Lisp.java:1770) 5: org.armedbear.lisp.Pathname$pf_pathname.execute(Pathname.java:1134) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:776) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:568) Although this works: [1] CL-USER(5): (directory #p"/home/*") (#P"/home/tyc20/" #P"/home/common/") Yong.

4 5

Re: [armedbear-devel] [armedbear-cvs] r12908 - trunk/abcl/examples/pure-lisp-to-java
by Erik Huelsmann 31 Aug '10

31 Aug '10

Hi Ville, You're aware it's 2010 by now? :-) Bye, Erik. On Mon, Aug 30, 2010 at 7:57 PM, Ville Voutilainen < vvoutilainen(a)common-lisp.net> wrote: > Author: vvoutilainen > Date: Mon Aug 30 13:57:43 2010 > New Revision: 12908 > > Log: > Add an example for using a java class with CLASSPATH, invoking java > functions from lisp code and finding the java class automagically > as it's in CLASSPATH. > > > Added: > trunk/abcl/examples/pure-lisp-to-java/ > trunk/abcl/examples/pure-lisp-to-java/Main.java (contents, props > changed) > trunk/abcl/examples/pure-lisp-to-java/README > trunk/abcl/examples/pure-lisp-to-java/lispfunctions.lisp (contents, > props changed) > > Added: trunk/abcl/examples/pure-lisp-to-java/Main.java > > ============================================================================== > --- (empty file) > +++ trunk/abcl/examples/pure-lisp-to-java/Main.java Mon Aug 30 13:57:43 > 2010 > @@ -0,0 +1,39 @@ > +/* > + * Main.java > + * > + * Copyright (C) 2008 Ville Voutilainen > + * $Id$ > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. > + */ > + > +import org.armedbear.lisp.*; > + > +public class Main > +{ > + /** > + * This example creates an Interpreter instance, loads our > + * lisp code from a file and then looks up a function defined > + * in the loaded lisp file and executes the function. > + * > + * The function takes a single parameter and invokes a java method > + * on the object provided. We provide our Main object as the > parameter. > + * > + */ > + public static int addTwoNumbers(int a, int b) > + { > + return a + b; > + } > +} > > Added: trunk/abcl/examples/pure-lisp-to-java/README > > ============================================================================== > --- (empty file) > +++ trunk/abcl/examples/pure-lisp-to-java/README Mon Aug 30 13:57:43 > 2010 > @@ -0,0 +1,38 @@ > +ABCL Examples Building and Running Instructions > +=============================================== > + > +To compile > + > + cmd$ javac -cp ../../dist/abcl.jar Main.java > + > +where the "../../../dist/abcl.jar" represents the path to your > +abcl.jar file, which is built via the Ant based build. This path > +could be slightly different depending on how the system was > +constructed, and possibly due to operating system conventions for > +specifying relative paths. However you resolve this locally, we'll > +refer to this as '$ABCL_ROOT/dist/abcl.jar' for the rest of these > +instructions. > + > +This compiles the Java source file "Main.java" into a JVM runtime or > +class file named "Main.class". > + > +To run the example (Main.class for example) from a Unix-like OS use: > + > + cmd$ export CLASSPATH=. > + cmd$ $ABCL_ROOT/abcl > + > +then, in abcl repl, use: > +(load "lispfunctions") > +(void-function) > + > +or in Windows use: > + > + cmd$ set CLASSPATH=. > + cmd$ $ABCL_ROOT/abcl > + > +then, in abcl repl, use: > +(load "lispfunctions") > +(void-function) > + > +This will result in the Main class being found from the CLASSPATH, and you > +can invoke the functions of the Main class from lisp code. > > Added: trunk/abcl/examples/pure-lisp-to-java/lispfunctions.lisp > > ============================================================================== > --- (empty file) > +++ trunk/abcl/examples/pure-lisp-to-java/lispfunctions.lisp Mon Aug 30 > 13:57:43 2010 > @@ -0,0 +1,34 @@ > +;;; lispfunctions.lisp > +;;; > +;;; Copyright (C) 2008 Ville Voutilainen > +;;; $Id$ > +;;; > +;;; This program is free software; you can redistribute it and/or > +;;; modify it under the terms of the GNU General Public License > +;;; as published by the Free Software Foundation; either version 2 > +;;; of the License, or (at your option) any later version. > +;;; > +;;; This program is distributed in the hope that it will be useful, > +;;; but WITHOUT ANY WARRANTY; without even the implied warranty of > +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +;;; GNU General Public License for more details. > +;;; > +;;; You should have received a copy of the GNU General Public License > +;;; along with this program; if not, write to the Free Software > +;;; Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. > + > +; we need to get the > +; 1) class (Main) > +; 2) classes of the parameters (int) > +; 3) method reference (getting that requires the class > +; of our object and the classes of the parameters > + > +; After that we can invoke the function with jcall, > +; giving the method reference, the object and the parameters. > +; The result is a lisp object (no need to do jobject-lisp-value), > +; unless we invoke the method > +; with jcall-raw. > +(defun void-function () > + (let* ((result (jstatic "addTwoNumbers" "Main" 2 4))) > + (format t "in void-function, result of calling addTwoNumbers(2, 4): > ~a~%" result))) > + > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] ABCL bug report: defstruct :include with :conc-name
by Juliusz Chroboczek 26 Aug '10

26 Aug '10

Hi. The following bug in abcl breaks CL-Yacc. Consider the following: (defstruct item a) (defstruct (item1 (:include item) (:conc-name item-)) b) (defun abcl-bug () (item-a (make-item :a 'a))) According to the last paragraph of the description of the description of :conc-name in the defstruct section of the CLHS, this is legal. However, abcl says: ABCL-BUG(6): (abcl-bug) #<THREAD "interpreter" {108F8E0}>: Debugger invoked on condition of type SIMPLE-TYPE-ERROR The value #<ABCL-BUG::ITEM {537935}> is not of type ABCL-BUG::ITEM1. Restarts: 0: TOP-LEVEL Return to top level. [1] ABCL-BUG(7): Regards, Juliusz

1 0

[armedbear-devel] Can't use ABCL to host SNePS
by David Zhang 26 Aug '10

26 Aug '10

Hello! I just tried to use ABCL to load SNePS, but can't make it anyway. There's always an error message saying "#<THREAD "interpreter" {E1E567}>: Debugger invoked on condition of type PACKAGE-ERROR Package "SNEPS" not found." How can I pass it though? Awaiting David Zhang

2 2

[armedbear-devel] how to load fasls from jar via asdf
by Robert Dodier 26 Aug '10

26 Aug '10

Hi, After looking through various web pages, emails, etc, I gather it's possible to load all the fasls for some program from a jar via asdf. However, I tried the obvious things and I couldn't get it to work. Can someone explain how it's supposed to work? I have all the fasls for Maxima in a subdirectory. (require 'asdf) (asdf:operate 'asdf:load-op :maxima) has the desired effect. So far, so good. I put all the fasls in a jar (either in the subdirectory or without the subdirectory), and then (pushnew "jar:file:/path/to/my.jar" asdf:*central-repository*) But when I try (require 'asdf) (asdf:operate 'asdf:load-op :maxima) I eventually get a message about trying to find the first Lisp file mentioned in the maxima.asd, which I'm pretty sure it didn't find the fasls. Can someone explain how loading all of the fasls from a jar is supposed to work? Or any other method of conglomerating fasls; for example, is it possible to combine multiple fasls into one? Thanks for any info, Robert Dodier

3 5

Re: [armedbear-devel] java/abcl hello-world example
by Robert Dodier 22 Aug '10

22 Aug '10

David, have you seen this page? http://common-lisp.net/project/armedbear/doc/abcl-user.html It has some simple examples of calling from Java to ABCL and vv. Hope this helps, Robert Dodier

3 2

[armedbear-devel] java/abcl hello-world example
by David Dreisigmeyer 21 Aug '10

21 Aug '10

Hi, I'm new to both abcl and java. I was wondering if someone could provide a "hello world" example (the more details the better) where I write the program in java, create a jar file, and then use that from the repl? An example of what I'd like to do using Clojure is (see http://pramode.net/clojure/2010/05/01/clojure-java-interop/ ): 1) counter.java: package demo public class counter{ int c = 0; public void increment() { ++c; } public int get() { return c; } public static int sqr(int x) { return x*x; } } 2) Using in Clojure: ; To get this to run in SLIME do the following (where we're in demo/ to start): ;; ;; > javac counter.java ;; > cd ../ ;; > jar cvf demo.jar demo ;; > mv demo.jar lib/ ;; ;; Remember we were in demo/ to start. The directory lib/ is created when we ;; run lein new. So now we have the jar file we created placed with all of the ;; other jar files on the classpath. So we can continue: ;; ;; > lein swank ;; ;; Now start up emacs and M-x slime-connect (accepting 127.0.0.1 and 4005 defaults). ;; At the repl in emacs do ;; ;; user> (import '(demo counter)) ;; user> (counter/sqr 4) Thanks, I really appreciate any help! -Dave

1 0

[armedbear-devel] jcall jmethod java.lang
by David Dreisigmeyer 20 Aug '10

20 Aug '10

Hi, I don't understand why this doesn't work: (jcall (jmethod "java.lang.Math" "sqrt") 4.0) The error I get is: No such method: java.lang.Math.sqrt() Also, this works: CL-USER> (jcall (jmethod "java.lang.Float" "intValue") 4.0) 4 but when I try this: (jcall (jmethod "java.lang.Float" "compare") 4.0 5.0) I get: No such method: java.lang.Float.compare() I'm not sure if this is the correct forum for these questions. If there's a better place to ask them let me know. Thanks, -Dave

2 4

[armedbear-devel] abcl-contrib.jar
by David Dreisigmeyer 20 Aug '10

20 Aug '10

I downloaded abcl-src-0.21.0 from http://common-lisp.net/project/armedbear/. I ran: ant -f build.xml abcl.conrtib Without creating the directory ./contrib/asdf-install/ 'by hand' the install would not run to completion, complaining that /contrib/asdf-install/ was not a valid directory. -Dave

2 3

[armedbear-devel] Maxima compilation profiling results
by Erik Huelsmann 14 Aug '10

14 Aug '10

To be sure our generic class writer isn't too much of a performance hit when we move it to trunk, I've run a profiling session compiling Maxima sources. The outcome is here: http://paste.lisp.org/display/113517. Conclusion: the old "lets store .cls files before we create a fasl out of them" is still the performance bottleneck (on Windows at least). So, the good thing is that the change in the generator doesn't show up in the list of hot spots (not to be confused with HotSpot). Bye, Erik.

1 0

[armedbear-devel] Long form of D-M-C
by Mark Evenson 11 Aug '10

11 Aug '10

Unbelievably, I seem to have [hacked the version of long DEFINE-METHOD-COMBINATION from Sacla/XCL o pass the long form D-M-C ANSI tests][1]. I'm slightly incredulous that my patch works, because I don't totally understand the code I've integrated here. In particular, neither method combinations which use CALL-METHOD with the optional NEXT-METHOD-LIST, nor use of the MAKE-METHOD macro will work, although their implementation would not be terribly hard if I have the basics correct. An aside: The more I work with our CLOS, the more I want to re-implement it from scratch, or at least separate the base out from the AMOP as a starting point to clean it up. Maybe this wouldn't help as much as I would hope, but reading clos.lisp is an exercise in frustration that doesn't end in admiration for clarity. So, I hereby solicit additional source of tests or failing test cases. I can't promise rapid response to fix things, but I will get to them eventually. If this work doesn't turn out to be too broken, I might commit to trunk in the next few days if the other developers acquiesce, with the rational that an incomplete long D-M-C implementation is better than none. [1]: http://trac.common-lisp.net/armedbear/attachment/ticket/66/run-d-m-c-201008… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] [armedbear-cvs] r12882 - branches/generic-class-file/abcl/src/org/armedbear/lisp
by Ville Voutilainen 09 Aug '10

09 Aug '10

On 9 August 2010 15:23, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Mon Aug 9 08:23:20 2010 > New Revision: 12882 > Log: > Move the u2, s1 and s2 helper functions to jvm.lisp. Could you please give these functions a bit saner names as the next step? :)

3 4

[armedbear-devel] Automatic grovelling for (lisp-defined) autoloads
by Erik Huelsmann 05 Aug '10

05 Aug '10

Today, I had an idea: what if we were to find all symbols which are being declared EXPORTED during the ABCL system compilation in each file? Then, we'd generate a list of all exported symbols and the files they are exported from. The given file would be included in our JAR. At boot-time, the file would be read and the appropriate autoloaders would be installed. The consequence would be that we would not need to maintain 'autoloads.lisp' anymore. It would require us to think better about which symbols need to be in the export lists, though. (I guess that's a good thing in the long run, though.) I'm thinking about groveling macro-expanded forms, because that would allow us to grovel clos.lisp and detect many of its exported symbols. Anybody up for the task? (I'm expecting it to be 4 or 5 evenings of work.) Bye, Erik.

2 1

[armedbear-devel] Ideas about the integration of WITH-CODE-TO-METHOD
by Erik Huelsmann 04 Aug '10

04 Aug '10

The other day, I started to write a mail about integrating the generic class file generator into pass2 in more detail. The main idea being that the macro WITH-CODE-TO-METHOD needed to be used to do the main integration between the generator and pass2. Although I still think the macro is the ticket, I'm refining my ideas about where the macro belongs and why. I'll take some time to write down here what I think the architectural separation between jvm-class-file and pass2 should be. My realization today was that the class file generator should really be independent from whatever source the methods and their instructions are coming from. The same should be true for the opcode-resolvers and other parts. Given the above, I think that concepts as 'current method', 'current code attribute', 'current class file' etc, are really concepts of pass2, not of the class file generator, which doesn't deal with "catching code" itself. As a consequence, I think the specials *code*, *current-code-attribute*, *pool* and *this-class* as well as the to-be-created specials *method* and *class-file* all belong to pass2 managing its submodules. When this is the role of pass2 and its specials, the need to remove the pool-* methods (for example) from pass2 would be less obvious. What still remains is that the resolvers should be side-effect free, meaning that they can't be used anymore to resolve their arguments into pool methods/field references/etc. When this has happened, they can be moved to their own file (or module if you will), but that's an issue to be addressed later. They *can* be used to check instruction arguments, as they are today. Hmm. I hope the above makes sense, or at least provides some material for further discussion. Bye, Erik.

1 0

[armedbear-devel] Ideas about the integration of WITH-CODE-TO-METHOD
by Erik Huelsmann 04 Aug '10

04 Aug '10

The other day, I started to write a mail about integrating the generic class file generator into pass2 in more detail. The main idea being that the macro WITH-CODE-TO-METHOD needed to be used to do the main integration between the generator and pass2. Although I still think the macro is the ticket, I'm refining my ideas about where the macro belongs and why. I'll take some time to write down here what I think the architectural separation between jvm-class-file and pass2 should be. My realization today was that the class file generator should really be independent from whatever source the methods and their instructions are coming from. The same should be true for the opcode-resolvers and other parts. Given the above, I think that concepts as 'current method', 'current code attribute', 'current class file' etc, are really concepts of pass2, not of the class file generator, which doesn't deal with "catching code" itself. As a consequence, I think the specials *code*, *current-code-attribute*, *pool* and *this-class* as well as the to-be-created specials *method* and *class-file* all belong to pass2 managing its submodules. When this is the role of pass2 and its specials, the need to remove the pool-* methods (for example) from pass2 would be less obvious. What still remains is that the resolvers should be side-effect free, meaning that they can't be used anymore to resolve their arguments into pool methods/field references/etc. When this has happened, they can be moved to their own file (or module if you will), but that's an issue to be addressed later. They *can* be used to check instruction arguments, as they are today. Hmm. I hope the above makes sense, or at least provides some material for further discussion. Bye, Erik.

1 0

[armedbear-devel] Progress on generic-class-file branch
by Erik Huelsmann 01 Aug '10

01 Aug '10

Today, updated tests were committed to the branch which allow it to generate ABCL function classes, load them and execute them. That's exciting news! It basically means that the branch is good enough for anybody to write their own lisp code to create new classes (whether or not they are ABCL functions doesn't really matter). So, where does that leave us in the bigger picture? Well, even though it's now possible to generate function classes with your own lisp code, the generator hasn't been fully integrated into the compiler. The bit that I did integrate is the use of the CLASS-NAME structure for identification of classes and class references. Next to that, I adjusted the method invoking emitters to use different pool functions for creation of the method refs. So, what remains to be done? * A test needs to be created which tests nested use of WITH-CODE-TO-METHOD, making sure that register allocation in the nested function generator is correctly transferred to the outer block (more on that below) * The pool handling needs to be switched over to the new pool functions Possibly, there's a quick-path here by changing the pool-* functions in p2 to forward to the ones in j-c-f (jvm-class-file). * The exception handler creation needs to be adjusted to use the new CODE-ADD-EXCEPTION-HANDLER function * Changing the compiler away from *code* and *static-code* toward WITH-CODE-TO-METHOD * Clean up: removal of unused functions (after integration) [especially those currently conflicting] * Documentation: Not all functions in the j-c-f file are documented. All functions except the internal ones (starting with %) should be documented. * API declaration None of the functions in the file are currently exported or autoloaded (unless by accident). In order to help others to create their own classes, we should probably export (some) of the functions, for runtime-class to build upon. It'd be my preference to do the integration work on the branch, unless we find a strategy to keep trunk stable while we change its class file generator - one of the most critical components. When all the above has been completed, I see the following improvements to be made to the code we generate: * multiple methods to handle &optional processing, instead of fastProcessArgs, if the method has less than 8 parameters in total * moving initialization of static variables to a static {} block, instead of in the (re-runnable) constructor; besides being a nice improvement, this is actually a correctness issue: our current constructors call Lisp.recall(), which can't be called more than once for a given string value * Reduction of the number of function classes generated: non-inlined local functions generated as methods in the function class * Re-introduction of XEPs (External entry points): SBCL uses a paradigm where functions which are hard-linked together, use internal entry points: they flatten keywords, pass the right ([un]boxed) values, etc, skipping the "parameter discovery" checks. XEPs discover the right parameters and call the internal entry point. Apart from that, we should (finally) be able to implement runtime-class without depending on ASM. Now, there's the explanation of what should be tested in the test-to-be-written: WITH-CODE-TO-METHOD catches the output from EMIT. Sometimes, pass2 wants to output a small block of code to the constructor method while in the midst of writing an "execute" method. Even fewer times, but in general quite thinkable, you could see the following nesting with output to two methods, method1 and method2: (WITH-CODE-TO-METHOD (file method1) .... (WITH-CODE-TO-METHOD (file method2) .... (WITH-CODE-TO-METHOD (file method1) ...))) The WITH-CODE-TO-METHOD macro provisions for this scenario by saving the values of the compiler-specials to the Code attribute. However, currently, nothing checks if the code works correctly (ie saves enough specials). The test should establish that. Ok. Sorry for the lengthy e-mail :-) Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.21.0 released
by Alessio Stalla 28 Jul '10

28 Jul '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.21.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among other things - a fix for storing literal pathnames in FASLs in an OS-independent way, and enhancements in the CLOS MOP and in Java interop features. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.21.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.21.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.21.0.zip.asc

1 0

[armedbear-devel] DocString Final
by Matt Seddon 25 Jul '10

25 Jul '10

Attached is the final patch for the DocString annotation. It contains documentation for all the functions in Java.java, the functions in LispThread.java, and some miscellaneous others. ETAGs support is also implemented, allowing either ### or @DocString(name="<name>" ...) to name tags. If you find yourself looking at a function with ### instead of @DocString, feel free to update it ;) Awaiting approval, if everyone is happy I will close ticket #99. Regards, Matt

1 1

[armedbear-devel] New patch for latin1 input
by Ville Voutilainen 19 Jul '10

19 Jul '10

This patch contains the same fix for RandomAccessCharacterFile and DecodingReader. The obvious repetition should be refactored away, but this patch should be functionally complete. Holler for any concerns.

1 0

[armedbear-devel] Fix for being able to read latin1 files with scandinavian characters in them
by Ville Voutilainen 19 Jul '10

19 Jul '10

After a lot of headbanging, this patch seems to work. It does one sort of manual replacing, but I've tested with all sorts of evil test data and it seems to survive those, and it still parses valid utf-8 multibyte correctly.

1 0

[armedbear-devel] Working toward a release: objections to branching tomorrow at the latest?
by Erik Huelsmann 17 Jul '10

17 Jul '10

Hi, The time has already past that we should have branched for stabilization of the new release. However, with the recent flurry of activity, I don't want to make the branching decision alone; hence my question: Are we ready for branching? Note: this does not necessarily mean that we need to create a release immediately after that, if we anticipate fixes, we can always backport. Bye, Erik.

1 0

[armedbear-devel] r12666 breaks ASDF compilation on Linux
by Alessio Stalla 17 Jul '10

17 Jul '10

I just tried abcl 0.20 with Snow, and compilation (done with asdf:compile-op) fails early with: Compilation failed: Not an absolute pathname #P"\\___jar___file___root___\\**\\*.*" r11664 works fine. Sorry that I didn't check before the release, I remembered checking it not much time ago but evidently I was wrong (r12666 is two weeks old). Alessio

5 24

[armedbear-devel] Fixing regressions in preparation for the next release
by Alessio Stalla 17 Jul '10

17 Jul '10

Hello everyone, the time for a new release is approaching, and we've found a few regressions that should be fixed before the release happens. With r12804 and r12805 I fixed a few bugs introduced by me lately and one introduced by Erik. Two more tests still fail with respect to 0.20: PATHNAMES-PRINT-AND-READ-PROPERLY and PRINT.PATHNAME.1. I think they are related with Mark's latest changes in how pathnames are printed; for example, #P(:type "txt") is now incorrectly printed as #P(":TYPE "txt")", which then can't be read back. Mark, can you check? If anyone has other outstanding bug reports or feature requests for the new release, I'd say this is the right time for telling :) Cheers, Alessio

2 2

[armedbear-devel] win32 fix for TAGS ant target
by Matt Seddon 17 Jul '10

17 Jul '10

Before I can start actually fixing the TAGS target, I figured making it run under win32 at all would help :) The problem is that with parallel="true", ant seems to send too many parameters to CreateProcess, which then sobs about error=87: the parameter is invalid. The attached patch addresses this issue by specifying maxparallel to prevent argument list overflow, and appending the results to the TAGS file incrementally. This results in two invokations to etags, rather than one. Does this behave as expected for you Mark? Cheers, Matt

3 6

[armedbear-devel] DocString (lazy version)
by Matt Seddon 16 Jul '10

16 Jul '10

To address Allesio's concern, I've now moved the processing of DocStrings into LispObject.getDocumentation. When no FUNCTION documentation has been set for a symbol, it checks to see if there is an annotation it can pull out of the symbol's function in the function slot, and attach and return it if found. Diff from trunk follows: # doc-string.diff Index: org/armedbear/lisp/DocString.java --- org/armedbear/lisp/DocString.java Locally New +++ org/armedbear/lisp/DocString.java Locally New @@ -0,0 +1,44 @@ +/* + * DocString.java + * + * Copyright (C) 2010 Matt Seddon + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * As a special exception, the copyright holders of this library give you + * permission to link this library with independent modules to produce an + * executable, regardless of the license terms of these independent + * modules, and to copy and distribute the resulting executable under + * terms of your choice, provided that you also meet, for each linked + * independent module, the terms and conditions of the license of that + * module. An independent module is a module which is not derived from + * or based on this library. If you modify this library, you may extend + * this exception to your version of the library, but you are not + * obligated to do so. If you do not wish to do so, delete this + * exception statement from your version. + */ +package org.armedbear.lisp; + +import java.lang.annotation.*; + +/** + * An annotation type to expose documentation to ABCL. + */ +(a)Retention(RetentionPolicy.RUNTIME) +public @interface DocString { + public String name() default ""; + public String doc() default ""; + public String args() default ""; +} Index: org/armedbear/lisp/Function.java --- org/armedbear/lisp/Function.java Base (BASE) +++ org/armedbear/lisp/Function.java Locally Modified (Based On LOCAL) @@ -46,6 +46,11 @@ */ private final LispObject loadedFrom; + /** + * Examine this object's class to determine if there is a DocString annotation, and if so, + * add the documentation. + */ + protected Function() { LispObject loadTruename = Symbol.LOAD_TRUENAME.symbolValueNoThrow(); loadedFrom = loadTruename != null ? loadTruename : NIL; @@ -53,7 +58,14 @@ public Function(String name) { + this(name, (String)null); + } + + public Function(String name, String arglist) + { this(); + if(arglist != null) + setLambdaList(new SimpleString(arglist)); if (name != null) { Symbol symbol = Symbol.addFunction(name.toUpperCase(), this); if (cold) @@ -62,14 +74,14 @@ } } + public Function(Symbol symbol) + { + this(symbol, null, null); + } + public Function(Symbol symbol, String arglist) { - this(); - symbol.setSymbolFunction(this); - if (cold) - symbol.setBuiltInFunction(true); - setLambdaName(symbol); - setLambdaList(new SimpleString(arglist)); + this(symbol, arglist, null); } public Function(Symbol symbol, String arglist, String docstring) @@ -79,19 +91,13 @@ if (cold) symbol.setBuiltInFunction(true); setLambdaName(symbol); + if(arglist != null) setLambdaList(new SimpleString(arglist)); - if (docstring != null) { + if (docstring != null) symbol.setDocumentation(Symbol.FUNCTION, new SimpleString(docstring)); } - } - public Function(String name, String arglist) - { - this(name); - setLambdaList(new SimpleString(arglist)); - } - public Function(String name, Package pkg) { this(name, pkg, false); Index: org/armedbear/lisp/Java.java --- org/armedbear/lisp/Java.java Base (BASE) +++ org/armedbear/lisp/Java.java Locally Modified (Based On LOCAL) @@ -60,11 +60,12 @@ } private static final Primitive ENSURE_JAVA_OBJECT = new pf_ensure_java_object(); + @DocString(args="obj", doc="Ensures OBJ is wrapped in a JAVA-OBJECT, wrapping it if necessary.") private static final class pf_ensure_java_object extends Primitive { pf_ensure_java_object() { - super("ensure-java-object", PACKAGE_JAVA, true, "obj"); + super("ensure-java-object", PACKAGE_JAVA, true); } @Override @@ -131,13 +132,13 @@ // ### jclass name-or-class-ref &optional class-loader => class-ref private static final Primitive JCLASS = new pf_jclass(); + @DocString(args="name-or-class-ref &optional class-loader", doc="Returns a reference to the Java class designated by NAME-OR-CLASS-REF. If the CLASS-LOADER parameter is passed, the class is resolved with respect to the given ClassLoader.") private static final class pf_jclass extends Primitive { pf_jclass() { - super(Symbol.JCLASS, "name-or-class-ref &optional class-loader", - "Returns a reference to the Java class designated by NAME-OR-CLASS-REF. If the CLASS-LOADER parameter is passed, the class is resolved with respect to the given ClassLoader."); + super(Symbol.JCLASS); } @Override @@ -294,12 +295,12 @@ // ### jconstructor class-ref &rest parameter-class-refs private static final Primitive JCONSTRUCTOR = new pf_jconstructor(); + @DocString(args="class-ref &rest parameter-class-refs", doc="Returns a reference to the Java constructor of CLASS-REF with the given PARAMETER-CLASS-REFS.") private static final class pf_jconstructor extends Primitive { pf_jconstructor() { - super("jconstructor", PACKAGE_JAVA, true, - "class-ref &rest parameter-class-refs"); + super("jconstructor", PACKAGE_JAVA, true); } @Override @@ -344,12 +345,13 @@ // ### jmethod class-ref name &rest parameter-class-refs private static final Primitive JMETHOD = new pf_jmethod(); + + @DocString(args="class-ref name &rest parameter-class-refs", doc="Returns a reference to the Java method NAME of CLASS-REF with the given PARAMETER-CLASS-REFS.") private static final class pf_jmethod extends Primitive { pf_jmethod() { - super("jmethod", PACKAGE_JAVA, true, - "class-ref name &rest parameter-class-refs"); + super("jmethod", PACKAGE_JAVA, true); } @Override Index: org/armedbear/lisp/LispObject.java --- org/armedbear/lisp/LispObject.java Base (BASE) +++ org/armedbear/lisp/LispObject.java Locally Modified (Based On LOCAL) @@ -657,6 +657,23 @@ if (entry instanceof Cons) return ((Cons)entry).cdr; } + if(docType == Symbol.FUNCTION && this instanceof Symbol) { + Object fn = ((Symbol)this).getSymbolFunction(); + if(fn instanceof Function) { + DocString ds = fn.getClass().getAnnotation(DocString.class); + if(ds != null) { + String arglist = ds.args(); + String docstring = ds.doc(); + if(arglist.length() != 0) + ((Function)fn).setLambdaList(new SimpleString(arglist)); + if(docstring.length() != 0) { + SimpleString doc = new SimpleString(docstring); + ((Symbol)this).setDocumentation(Symbol.FUNCTION, doc); + return doc; + } + } + } + } return NIL; } Index: org/armedbear/lisp/Primitive.java --- org/armedbear/lisp/Primitive.java Base (BASE) +++ org/armedbear/lisp/Primitive.java Locally Modified (Based On LOCAL) @@ -45,6 +45,11 @@ super(name); } + public Primitive(Symbol symbol) + { + super(symbol); + } + public Primitive(Symbol symbol, String arglist) { super(symbol, arglist);

2 1

[armedbear-devel] DocString annotation patch.
by Matt Seddon 15 Jul '10

15 Jul '10

Hi folks, Here's the first go at the DocString annotation. Changes: Added org/armedbear/lisp/DocString.java, defining the @DocString annotation. Modified Function.java. Now it will check to see if there is an annotation, and set its data from there (overriding the arglist and docstring constructor arguments if provided). Also removed some (but not all) existing code duplication in the constructors. Added a constructor to Primitive, Primitive(Symbol), since it wasn't there, and becomes relevant when moving documentation out of a constructor and into a @DocString annotation. Added/replaced a bit of documentation in Java.java using the new annotation syntax, to give a flavour of what it does. (More actual documentation patches in progress). Conformance with ansi.interpreted and ansi.compiled has not been affected, but confirmation would be prudent since this is new to me. Regards, Matt # doc-string.diff Index: org/armedbear/lisp/DocString.java --- org/armedbear/lisp/DocString.java Locally New +++ org/armedbear/lisp/DocString.java Locally New @@ -0,0 +1,44 @@ +/* + * DocString.java + * + * Copyright (C) 2010 Matt Seddon + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * As a special exception, the copyright holders of this library give you + * permission to link this library with independent modules to produce an + * executable, regardless of the license terms of these independent + * modules, and to copy and distribute the resulting executable under + * terms of your choice, provided that you also meet, for each linked + * independent module, the terms and conditions of the license of that + * module. An independent module is a module which is not derived from + * or based on this library. If you modify this library, you may extend + * this exception to your version of the library, but you are not + * obligated to do so. If you do not wish to do so, delete this + * exception statement from your version. + */ +package org.armedbear.lisp; + +import java.lang.annotation.*; + +/** + * An annotation type to expose documentation to ABCL. + */ +(a)Retention(RetentionPolicy.RUNTIME) +public @interface DocString { + public String name() default ""; + public String doc() default ""; + public String args() default ""; +} Index: org/armedbear/lisp/Function.java --- org/armedbear/lisp/Function.java Base (BASE) +++ org/armedbear/lisp/Function.java Locally Modified (Based On LOCAL) @@ -46,6 +46,23 @@ */ private final LispObject loadedFrom; + /** + * Examine this object's class to determine if there is a DocString annotation, and if so, + * add the documentation. + */ + private void installDocString() { + DocString ds = getClass().getAnnotation(DocString.class); + if(ds != null) { + LispObject name = getLambdaName(); + String arglist = ds.args(); + String docstring = ds.doc(); + if(arglist.length() != 0) + setLambdaList(new SimpleString(arglist)); + if(name instanceof Symbol && docstring.length() != 0) + ((Symbol)name).setDocumentation(Symbol.FUNCTION, new SimpleString(docstring)); + } + } + protected Function() { LispObject loadTruename = Symbol.LOAD_TRUENAME.symbolValueNoThrow(); loadedFrom = loadTruename != null ? loadTruename : NIL; @@ -53,23 +70,31 @@ public Function(String name) { + this(name, (String)null); + } + + public Function(String name, String arglist) + { this(); + if(arglist != null) + setLambdaList(new SimpleString(arglist)); if (name != null) { Symbol symbol = Symbol.addFunction(name.toUpperCase(), this); if (cold) symbol.setBuiltInFunction(true); setLambdaName(symbol); + installDocString(); } } + public Function(Symbol symbol) + { + this(symbol, null, null); + } + public Function(Symbol symbol, String arglist) { - this(); - symbol.setSymbolFunction(this); - if (cold) - symbol.setBuiltInFunction(true); - setLambdaName(symbol); - setLambdaList(new SimpleString(arglist)); + this(symbol, arglist, null); } public Function(Symbol symbol, String arglist, String docstring) @@ -79,19 +104,14 @@ if (cold) symbol.setBuiltInFunction(true); setLambdaName(symbol); + if(arglist != null) setLambdaList(new SimpleString(arglist)); - if (docstring != null) { + if (docstring != null) symbol.setDocumentation(Symbol.FUNCTION, new SimpleString(docstring)); + installDocString(); } - } - public Function(String name, String arglist) - { - this(name); - setLambdaList(new SimpleString(arglist)); - } - public Function(String name, Package pkg) { this(name, pkg, false); @@ -127,6 +147,7 @@ if (docstring != null) symbol.setDocumentation(Symbol.FUNCTION, new SimpleString(docstring)); + installDocString(); } } Index: org/armedbear/lisp/Java.java --- org/armedbear/lisp/Java.java Base (BASE) +++ org/armedbear/lisp/Java.java Locally Modified (Based On LOCAL) @@ -60,6 +60,7 @@ } private static final Primitive ENSURE_JAVA_OBJECT = new pf_ensure_java_object(); + @DocString(args="obj", doc="Ensures OBJ is wrapped in a JAVA-OBJECT, wrapping it if necessary.") private static final class pf_ensure_java_object extends Primitive { pf_ensure_java_object() @@ -131,13 +132,13 @@ // ### jclass name-or-class-ref &optional class-loader => class-ref private static final Primitive JCLASS = new pf_jclass(); + @DocString(args="name-or-class-ref &optional class-loader", doc="Returns a reference to the Java class designated by NAME-OR-CLASS-REF. If the CLASS-LOADER parameter is passed, the class is resolved with respect to the given ClassLoader.") private static final class pf_jclass extends Primitive { pf_jclass() { - super(Symbol.JCLASS, "name-or-class-ref &optional class-loader", - "Returns a reference to the Java class designated by NAME-OR-CLASS-REF. If the CLASS-LOADER parameter is passed, the class is resolved with respect to the given ClassLoader."); + super(Symbol.JCLASS); } @Override @@ -294,12 +295,12 @@ // ### jconstructor class-ref &rest parameter-class-refs private static final Primitive JCONSTRUCTOR = new pf_jconstructor(); + @DocString(args="class-ref &rest parameter-class-refs", doc="Returns a reference to the constructor of CLASS-REF with the given PARAMETER-CLASS-REFS.") private static final class pf_jconstructor extends Primitive { pf_jconstructor() { - super("jconstructor", PACKAGE_JAVA, true, - "class-ref &rest parameter-class-refs"); + super("jconstructor", PACKAGE_JAVA, true); } @Override @@ -344,12 +345,13 @@ // ### jmethod class-ref name &rest parameter-class-refs private static final Primitive JMETHOD = new pf_jmethod(); + + @DocString(args="class-ref name &rest parameter-class-refs", doc="Returns a reference to the method NAME of CLASS-REF with the given PARAMETER-CLASS-REFS.") private static final class pf_jmethod extends Primitive { pf_jmethod() { - super("jmethod", PACKAGE_JAVA, true, - "class-ref name &rest parameter-class-refs"); + super("jmethod", PACKAGE_JAVA, true); } @Override Index: org/armedbear/lisp/Primitive.java --- org/armedbear/lisp/Primitive.java Base (BASE) +++ org/armedbear/lisp/Primitive.java Locally Modified (Based On LOCAL) @@ -45,6 +45,11 @@ super(name); } + public Primitive(Symbol symbol) + { + super(symbol); + } + public Primitive(Symbol symbol, String arglist) { super(symbol, arglist);

1 0

[armedbear-devel] Better Java interop
by Alessio Stalla 02 Jul '10

02 Jul '10

Tonight I committed two changes that will hopefully enhance Java interoperability on ABCL: 1) extensible classpath: two new primitives, java:add-to-classpath and java:dump-classpath, allow respectively to add a path/URL (or a list of them) to the classpath at runtime, and to inspect the classpath for debugging purposes. 2) proxying more than one interface: jmake-proxy now can also accept a list of interfaces to implement in Lisp. I also plan to add some other features, but I'd like to hear feedback about them first: 1) generified <T> T LispObject.javaInstance(Class<T>) to typecheck and avoid casts in user code converting Lisp objects to Java objects. 2) a configurable lists of Java packages to search for classes, so that users might write non-fully-qualified class names, e.g. (jclass "String"). 3) JSS-like syntax for easy method invocation (#methodName args), disabled by default 4) capability of jmethod, jfield, jconstructor to access private members (setAccessible(true)) depending on a special variable (or a function parameter). This was proposed by someone else some time ago but never implemented. Bye, Alessio

3 5

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 28 Jun '10

28 Jun '10

Hi, It appears that the compiler mistakenly optimizes out local functions in, say, definer macros. Below is a transcript of a sample session that clarifies the problem: CL-USER(1): (defmacro define-fn (name &body body) `(defun ,name () (flet ((%one () 1)) ,@body))) DEFINE-FN CL-USER(2): (defmacro do-add1 () `(%one)) DO-ADD1 CL-USER(3): (define-fn fn1 (do-add1)) ; Note: deleting unused local function FLET %ONE FN1 CL-USER(4): (fn1) #<THREAD "interpreter" {6DDDCF}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function %ONE is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to %ONE. 3: TOP-LEVEL Return to top level. [1] CL-USER(5): :res Thanks. Martin.

2 2

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 26 Jun '10

26 Jun '10

Hi, (It seems that the original message has disappeared, so I repost it.) The attached transcript demonstrates the problem. (I can't seem to be able to put the contents of the REPL transcript inline without the message being labelled as SPAM). Regards, Martin.

1 0

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 26 Jun '10

26 Jun '10

I forgot to indicate that this happens on the current [as of 26/6/2010] trunk version). I can also confirm that MACROLET and SLOT-VALUE are now working as expected. Thanks Erik and Alessio for your efforts. Martin.

1 0

[armedbear-devel] strange asdf behavior with 0.20.0
by Kevin Raison 25 Jun '10

25 Jun '10

I just installed 0.20.0 and am now unable to load usocket, yet I can still load cl-ppcre and other Edi-ware. Upon rolling back to 0.19.1, the same usocket package compiles and loads just fine. I have tried using the binary distribution of 0.20.0 as well as building my own, with the same result. There does not seem to be anything wrong with the usocket package definition itself. Has anyone else seen this or know what is going on? Here is the output of 0.20.0: raison@mercury:~/.abcl/lib$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.614 seconds. Startup completed in 1.739 seconds. Type ":help" for a list of available commands. CL-USER(1): (asdf:oos 'asdf:load-op 'usocket) ; loading system definition from /home/raison/.abcl/systems/usocket.asd into #<PACKAGE "ASDF0"> Error loading /home/raison/.abcl/site/usocket-svn/usocket.asd at line 38 (offset 1255) #<THREAD "interpreter" {373E38}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system usocket from pathname /home/raison/.abcl/systems/usocket.asd: Unrecognized keyword argument :NAME Restarts: 0: TOP-LEVEL Return to top level. [1] USOCKET-SYSTEM(2): -Kevin

4 4

[armedbear-devel] ASDF 2.003
by Faré 25 Jun '10

25 Jun '10

Can ABCL upgrade its ASDF to 2.003 or whichever is latest in the release branch (if possible NOT the master branch)? That would be great. It should fix several bugs that may have hit ABCL users since then. Xach at least reported that upgrading ASDF on ABCL made his software work. As usual, please test on your specific implementation with a few systems before you commit, and please report any bug. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] One good Husband is worth two good Wives; for the scarcer things are, the more they're valued. — Benjamin Franklin

2 1

[armedbear-devel] compiled MACROLET fails to expand in DEFUN/DEFMETHOD forms
by Mark Evenson 22 Jun '10

22 Jun '10

The following form fails to compile correctly: (macrolet ((output-var (var) `(format t "var = ~A~%" ,var))) (defun baz (bat) (output-var bat))) When the above form has been compiled and loaded CL-USER> (baz 3) errors by complaining. The function OUTPUT-VAR is undefined. Interestingly abcl-0.12.0 behaves correctly, but abcl-0.15.0 fails (For some reason, I don't currently have abcl-0.{13,14} handy to test). I distilled this bug down from trying to compile CXML, so this is a "real-world" problem. CXML bombs on compiling its "xml/xml-parse.lisp" at this point: … (macrolet ((with-context ((validator) &body body) `(let ((*ctx* (context ,validator)) (*validate* t)) (with-scratch-pads () ;nicht schoen ,@body)))) (defmethod sax:start-element ((handler validator) uri lname qname attributes) uri lname (with-context (handler) (validate-start-element *ctx* qname) (process-attributes *ctx* qname attributes))) … with Wrong number of arguments for CXML::HANDLER. [Condition of type PROGRAM-ERROR] I assume that my "distilled" version has the same cause, namely that the precompiler is not expanding macros properly for function/method definitions in top-level MACROLET forms, but I explicitly mention my root problem here if the slightly different error turns out to provide a clue that I have missed. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

[armedbear-devel] New branch: generic-class-file
by Erik Huelsmann 21 Jun '10

21 Jun '10

Some of you know that I have been working on writing a new class file generator. The new class file generator will be replacing the current version which is strictly written for the current compiler. Due to some of the limitations in the class file generator, I'm not even able to change some patterns I'd like to change in it. The new class file generator will allow much more general class file content. It's the explicit intent to support any method type and argument pattern. This goal will allow us to rewrite runtime-class to use our own class writer. The other purpose is to be able to generate more than two methods in a class file: currently we only support 2 (<init> and one of 8 execute(...) methods). I'd like to be able to have many more; for example I want to move initialization of 'final static' fields to <clinit> to make 100% sure they are only initialized once. But that's just one purpose. Another would be to support multiple &optional parameters (but less than 8) without a need to call fastProcessArgs(), but do it in a much more Java-like fashion by generating multiple execute(...) methods. Each method calls the one with more parameters, until all optionals (which were not provided) have been filled, like this; public LispObject execute() { return execute(default1); } public LispObject execute(LispObject arg1) { return execute(arg1, default2); } public LispObject execute(LispObject arg1, LispObject arg2) { .... do actual processing ...; } I'm creating a README on the branch to say the same, for anybody who comes along but did not read this e-mail. Bye, Erik.

1 0

[armedbear-devel] toplevel MACROLET bug?
by William Wadsworth 21 Jun '10

21 Jun '10

Dear List, Nice work going on on the ABCL compiler. Thanks. I have a file test1.lisp: ----- (in-package #:cl-user) (macrolet ((%mac () '(+ 1 1))) (defun test () (%mac))) ---- Compiling it: CL-USER(1): :cf test1.lisp ; Compiling test1.lisp ... ; (IN-PACKAGE #:CL-USER) ; (DEFUN TEST ...) ; Compilation unit finished ; The following functions were used but not defined: ; %MAC I am not 100% sure, but I think the %MAC should be visible within TEST. --- Martin.

2 1

[armedbear-devel] CL:FLOAT on Java Number objects could call {single, double}Float() on them
by Mario Lang 19 Jun '10

19 Jun '10

Hi. Along the lines of the previously submitted string conversion patch, here is some other possible interoperability thing. Index: src/org/armedbear/lisp/SingleFloat.java =================================================================== --- src/org/armedbear/lisp/SingleFloat.java (revision 12758) +++ src/org/armedbear/lisp/SingleFloat.java (working copy) @@ -635,6 +635,11 @@ return new SingleFloat(((Bignum)obj).floatValue()); if (obj instanceof Ratio) return new SingleFloat(((Ratio)obj).floatValue()); + if (obj instanceof JavaObject) { + final Object jobj = ((JavaObject)obj).getObject(); + if (jobj instanceof Number) + return new SingleFloat(((Number)jobj).floatValue()); + } error(new TypeError("The value " + obj.writeToString() + " cannot be converted to type SINGLE-FLOAT.")); // Not reached. Index: src/org/armedbear/lisp/DoubleFloat.java =================================================================== --- src/org/armedbear/lisp/DoubleFloat.java (revision 12758) +++ src/org/armedbear/lisp/DoubleFloat.java (working copy) @@ -646,6 +646,11 @@ return new DoubleFloat(((SingleFloat)obj).value); if (obj instanceof Ratio) return new DoubleFloat(((Ratio)obj).doubleValue()); + if (obj instanceof JavaObject) { + final Object jobj = ((JavaObject)obj).getObject(); + if (jobj instanceof Number) + return new DoubleFloat(((Number)jobj).doubleValue()); + } error(new TypeError("The value " + obj.writeToString() + " cannot be converted to type DOUBLE-FLOAT.")); // Not reached. P.S.: The following conditional is duplicated and could be removed: Index: src/org/armedbear/lisp/Pathname.java =================================================================== --- src/org/armedbear/lisp/Pathname.java (revision 12758) +++ src/org/armedbear/lisp/Pathname.java (working copy) @@ -1290,7 +1290,7 @@ if (host == NIL) { host = defaults.host; } - if (directory == NIL && defaults != null) { + if (directory == NIL) { directory = defaults.directory; } if (!deviceSupplied) { -- CYa, ⡍⠁⠗⠊⠕

1 0

[armedbear-devel] SLOT-VALUE and SLOT-VALUE-USING-CLASS with DEFSTRUCT
by William Wadsworth 18 Jun '10

18 Jun '10

Hi. The following transcript demonstrates the problem. --- BEGIN Armed Bear Common Lisp 0.20.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.667 seconds. Startup completed in 4.849 seconds. Type ":help" for a list of available commands. CL-USER(1): (defstruct x a b c) X CL-USER(2): (slot-value (make-x :a 10) 'a) #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SLOT-VALUE is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to SLOT-VALUE. 3: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4): (slot-value (make-x :a 10) 'a) #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of type SIMPLE-ERROR There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION MOP::SLOT-VALUE-USING-CLASS {932FE} > when called with arguments (#<STRUCTURE-CLASS X {11EF443}> #<X {1184326}> A). Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :res CL-USER(6): --- END DEFCLASS seems to work fine, though I would like to keep using DEFSTRUCT. I understand that the MOP is not really complete. However, Is there a workaround that will not resort in using DEFCLASS? --- Martin.

3 5

[armedbear-devel] JVM Compilation
by Mark Evenson 17 Jun '10

17 Jun '10

http://nerds-central.blogspot.com/2009/09/tuning-jvm-for-unusual-uses-have-… Tersely written from my iPod

2 2

Re: [armedbear-devel] SLOT-VALUE and SLOT-VALUE-USING-CLASS with DEFSTRUCT
by William Wadsworth 17 Jun '10

17 Jun '10

Hi Eric, (Apologies for the belated reply, just saw the message today.) On Mon, Jun 14, 2010 at 9:26 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi William, > > Thanks for your report below! > > On Mon, Jun 14, 2010 at 4:09 AM, William Wadsworth > <will.wadsworth.10(a)gmail.com> wrote: >> Hi. >> >> The following transcript demonstrates the problem. >> >> --- BEGIN >> Armed Bear Common Lisp 0.20.0 >> Java 1.6.0_20 Sun Microsystems Inc. >> Java HotSpot(TM) Client VM >> Low-level initialization completed in 0.667 seconds. >> Startup completed in 4.849 seconds. >> Type ":help" for a list of available commands. >> CL-USER(1): (defstruct x a b c) >> X >> CL-USER(2): (slot-value (make-x :a 10) 'a) >> #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of >> type UNDEFINED-FUNCTION >> The function SLOT-VALUE is undefined. > > Well, you seem to have identified an issue here: you're correct our > MOP isn't fully complete, but it's not *that* bad. The function is > defined in clos.lisp. However, loading of that file happens on the > first use of one of the functions inside it. But: there's no trigger > installed on the function to trigger autoloading. > > It seems we need a list of all functions exported from clos.lisp in > order to fix up the auto-loading triggers. Could you create a list > like that? > I don't know whether I read you clearly, but using the following snippet I got the (manually flattened) results below it: (let ((file #P"clos.lisp")) (with-open-file (in file) (loop for form = (read in nil nil) while form when (and (listp form) (eq (car form) 'cl:export)) nconcing (cdr form)))) CLASS-PRECEDENCE-LIST CLASS-SLOTS COMPUTE-APPLICABLE-METHODS COMPUTE-APPLICABLE-METHODS-USING-CLASSES SLOT-DEFINITION-ALLOCATION SLOT-DEFINITION-INITARGS SLOT-DEFINITION-INITFORM SLOT-DEFINITION-INITFUNCTION SLOT-DEFINITION-NAME (Meanwhile, let me see what I can achieve by modifying autoloads.lisp and/or AutoLoads.java?) > > In order to see if a small commit would help you out, I added this > form to the beginning of your transcript: > > (autoload 'slot-value "clos") > --> T > > Turns out that's not all that's required: the next failure I ran into > is that the function either the function SLOT-VALUE is missing a > special case for structures, or SLOT-VALUE-USING-CLASS is missing a > method for structure classes; the error was "No applicable method"... > > Looks like there's no workaround, but maybe there's a quick patch. > I'll need to look into that a bit more. I thought I'd report you my > findings first. > > Thanks again for reporting and welcome to ABCL! > Thanks for the effort you and the rest of the team are putting into it. > > Bye, > > > Erik. > Martin.

1 0

[armedbear-devel] TYPE-ERROR #<java.lang.String foo {BADEAFFE}> cannot be coerced to a string.
by Mario Lang 16 Jun '10

16 Jun '10

Hi. Just stumbled across this one when I tried to use STRING-EQUAL to compare a value I received via JINTERFACE-IMPLEMENTATION. Now, it appears to be very simple to allow the expression (string (jnew "java.lang.String" "foo")) by overriding STRING() in JavaObject and checking if obj is a (java) String. What do you think? Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12751) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,14 @@ return super.typep(type); } + @Override + public LispObject STRING() + { + if (obj instanceof String) + return new SimpleString(obj.toString()); + return super.STRING(); + } + public final Object getObject() { return obj; -- CYa, ⡍⠁⠗⠊⠕

4 7

[armedbear-devel] less-reflection merge borks SLIME on trunk
by Mark Evenson 16 Jun '10

16 Jun '10

Unfortunately, the 'less-reflection' merge to trunk as of r12742 causes SLIME to fail to compile 'swank-abcl.lisp' as seen in the attached stack trace. To observe this outside of Emacs, obtain a [CVS HEAD snapshot of SLIME][1], start ABCL, point *DEFAULT-PATHNAME-DEFAULTS* to the location of 'swank.asd', then issue CL-USER> (asdf:load-system :asdf) [1]: http://common-lisp.net/project/slime/snapshots/slime-current.tgz -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] jinterface-implementation
by Knut Olav Bøhmer 10 Jun '10

10 Jun '10

Hi, Is it possible to implement two interfaces in one object? -- Knut Olav Bøhmer

3 3

[armedbear-devel] examples in abcl-src ?
by Mario Lang 10 Jun '10

10 Jun '10

Hi. Currently, the examples/ subdirectory is not included with the abcl source distribution. If this is not on purpose, I'd like to suggest the following change to build.xml: Index: build.xml =================================================================== --- build.xml (revision 12738) +++ build.xml (working copy) @@ -463,7 +463,8 @@ <include name="CHANGES"/> <include name="abcl.in"/> <include name="abcl.bat.in"/> - + <include name="examples/**"/> +  -- Thanks, Mario

2 1

Re: [armedbear-devel] [armedbear-cvs] r12748 - in trunk/abcl: . examples examples/google-app-engine examples/gui examples/java-exception examples/java-interface examples/java-to-lisp-1 examples/java-to-lisp-2 examples/jsr-223 examples/lisp-to-java examples/misc nbproj
by Ville Voutilainen 09 Jun '10

09 Jun '10

On 9 June 2010 14:17, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Wed Jun 9 07:17:17 2010 > New Revision: 12748 > Log: > Include 'examples' in release source distribution. > Reported by Mario Lang. > Modified: > trunk/abcl/build.xml > trunk/abcl/nbproject/build-impl.xml > trunk/abcl/nbproject/genfiles.properties > trunk/abcl/src/org/armedbear/lisp/Autoload.java > trunk/abcl/src/org/armedbear/lisp/Function.java > trunk/abcl/src/org/armedbear/lisp/Interpreter.java > trunk/abcl/src/org/armedbear/lisp/Lisp.java > trunk/abcl/src/org/armedbear/lisp/Load.java > trunk/abcl/src/org/armedbear/lisp/Readtable.java > trunk/abcl/src/org/armedbear/lisp/SlotDefinition.java > trunk/abcl/src/org/armedbear/lisp/StandardClass.java > trunk/abcl/src/org/armedbear/lisp/Stream.java > trunk/abcl/src/org/armedbear/lisp/Symbol.java > trunk/abcl/src/org/armedbear/lisp/clos.lisp > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > trunk/abcl/src/org/armedbear/lisp/disassemble.lisp > trunk/abcl/src/org/armedbear/lisp/gui.lisp > trunk/abcl/src/org/armedbear/lisp/load.lisp > trunk/abcl/src/org/armedbear/lisp/precompiler.lisp > trunk/abcl/src/org/armedbear/lisp/proclaim.lisp What the...? Why does this patch modify these files? > trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java > trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngineFactory.java These modifications seem to put removed @Override annotations back, which breaks java 1.5 compatibility, because those are overrides of interface methods which aren't supported by 1.5 version of @Override. The patch looks botched, the only thing it's supposed to do is modify build.xml afaics.

2 1

Re: [armedbear-devel] [armedbear-cvs] r12742 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 09 Jun '10

09 Jun '10

Hi Alessio, Nice work! On Mon, Jun 7, 2010 at 8:30 PM, Alessio Stalla <astalla(a)common-lisp.net> wrote: > Author: astalla > Date: Mon Jun 7 14:30:36 2010 > New Revision: 12742 > > Log: > less-reflection branch merged with trunk. verify-load temporarily disabled. > > > Added: > trunk/abcl/src/org/armedbear/lisp/FaslClassLoader.java > - copied, changed from r12739, /branches/less-reflection/abcl/src/org/armedbear/lisp/FaslClassLoader.java > Modified: > trunk/abcl/src/org/armedbear/lisp/Autoload.java > trunk/abcl/src/org/armedbear/lisp/Function.java > trunk/abcl/src/org/armedbear/lisp/Lisp.java > trunk/abcl/src/org/armedbear/lisp/Load.java > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > trunk/abcl/src/org/armedbear/lisp/disassemble.lisp > trunk/abcl/src/org/armedbear/lisp/gui.lisp > trunk/abcl/src/org/armedbear/lisp/load.lisp > trunk/abcl/src/org/armedbear/lisp/precompiler.lisp > trunk/abcl/src/org/armedbear/lisp/proclaim.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/Autoload.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Autoload.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Autoload.java Mon Jun 7 14:30:36 2010 > @@ -97,7 +97,7 @@ > symbol.setSymbolFunction(new Autoload(symbol, null, > "org.armedbear.lisp.".concat(className))); > } > - > + > public void load() > { > if (className != null) { > @@ -684,6 +684,9 @@ > > autoload(Symbol.COPY_LIST, "copy_list"); > > + autoload(PACKAGE_SYS, "make-fasl-class-loader", "FaslClassLoader", false); > + autoload(PACKAGE_SYS, "get-fasl-function", "FaslClassLoader", false); > + > autoload(Symbol.SET_CHAR, "StringFunctions"); > autoload(Symbol.SET_SCHAR, "StringFunctions"); > > > Copied: trunk/abcl/src/org/armedbear/lisp/FaslClassLoader.java (from r12739, /branches/less-reflection/abcl/src/org/armedbear/lisp/FaslClassLoader.java) > ============================================================================== > --- /branches/less-reflection/abcl/src/org/armedbear/lisp/FaslClassLoader.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/FaslClassLoader.java Mon Jun 7 14:30:36 2010 > @@ -70,7 +70,15 @@ > > public byte[] getFunctionClassBytes(String name) { > Pathname pathname = new Pathname(name.substring("org/armedbear/lisp/".length()) + ".cls"); > - return readFunctionBytes(pathname); > + final LispThread thread = LispThread.currentThread(); > + SpecialBindingsMark mark = thread.markSpecialBindings(); > + try { > + //thread.bindSpecial(Symbol.LOAD_TRUENAME_FASL, NIL); Maybe a code comment why this needs commenting out? Or maybe it was an unintended leftover? > + thread.bindSpecial(Symbol.LOAD_TRUENAME, NIL); > + return readFunctionBytes(pathname); > + } finally { > + thread.resetSpecialBindings(mark); > + } > } > > public byte[] getFunctionClassBytes(Class<?> functionClass) { > > Modified: trunk/abcl/src/org/armedbear/lisp/Function.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Function.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Function.java Mon Jun 7 14:30:36 2010 > @@ -175,23 +175,51 @@ > new JavaObject(bytes)); > } > > + public final LispObject getClassBytes() { > + LispObject o = getf(propertyList, Symbol.CLASS_BYTES, NIL); > + if(o != NIL) { > + return o; > + } else { > + ClassLoader c = getClass().getClassLoader(); > + if(c instanceof FaslClassLoader) { > + return new JavaObject(((FaslClassLoader) c).getFunctionClassBytes(this)); > + } else { > + return NIL; > + } > + } > + } > + > + public static final Primitive FUNCTION_CLASS_BYTES = new pf_function_class_bytes(); > + public static final class pf_function_class_bytes extends Primitive { > + public pf_function_class_bytes() { > + super("function-class-bytes", PACKAGE_SYS, false, "function"); > + } > + @Override > + public LispObject execute(LispObject arg) { > + if (arg instanceof Function) { > + return ((Function) arg).getClassBytes(); > + } > + return type_error(arg, Symbol.FUNCTION); > + } > + } > + > @Override > public LispObject execute() > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 0)); > } > > @Override > public LispObject execute(LispObject arg) > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 1)); > } > > @Override > public LispObject execute(LispObject first, LispObject second) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 2)); > } > > @Override > @@ -199,7 +227,7 @@ > LispObject third) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 3)); > } > > @Override > @@ -207,7 +235,7 @@ > LispObject third, LispObject fourth) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 4)); > } > > @Override > @@ -216,7 +244,7 @@ > LispObject fifth) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 5)); > } > > @Override > @@ -225,7 +253,7 @@ > LispObject fifth, LispObject sixth) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 6)); > } > > @Override > @@ -235,7 +263,7 @@ > LispObject seventh) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 7)); > } > > @Override > @@ -245,7 +273,7 @@ > LispObject seventh, LispObject eighth) > > { > - return error(new WrongNumberOfArgumentsException(this)); > + return error(new WrongNumberOfArgumentsException(this, 8)); > } > > @Override > > Modified: trunk/abcl/src/org/armedbear/lisp/Lisp.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Lisp.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Lisp.java Mon Jun 7 14:30:36 2010 > @@ -43,8 +43,6 @@ > import java.net.URL; > import java.net.URLDecoder; > import java.util.Hashtable; > -import java.util.zip.ZipEntry; > -import java.util.zip.ZipFile; > > public final class Lisp > { > @@ -1266,6 +1264,7 @@ > url = Lisp.class.getResource(name.getNamestring()); > input = url.openStream(); > } catch (IOException e) { > + System.err.println("Failed to read class bytes from boot class " + url); I understand this from a debugging point of view, but maybe we want to make sure ABCL doesn't crash hard if its unable to write to err, for whatever reason? (Like being in a Swing app without console stream bindings.) > error(new LispError("Failed to read class bytes from boot class " + url)); > } > } > @@ -2385,6 +2384,10 @@ > public static final Symbol _LOAD_STREAM_ = > internSpecial("*LOAD-STREAM*", PACKAGE_SYS, NIL); > > + // ### *fasl-loader* > + public static final Symbol _FASL_LOADER_ = > + exportSpecial("*FASL-LOADER*", PACKAGE_SYS, NIL); > + > // ### *source* > // internal symbol > public static final Symbol _SOURCE_ = > @@ -2758,4 +2761,16 @@ > Symbol.DEBUG_IO.initializeSpecial(new TwoWayStream(stdin, stdout, true)); > } > > + private static final SpecialOperator WITH_INLINE_CODE = new with_inline_code(); > + private static class with_inline_code extends SpecialOperator { > + with_inline_code() { > + super("with-inline-code", PACKAGE_JVM, true, "(&optional target repr) &body body"); > + } > + @Override > + public LispObject execute(LispObject args, Environment env) > + { > + return error(new SimpleError("This is a placeholder. It should only be called in compiled code, and tranformed by the compiler using special form handlers.")); > + } > + } > + > } > > Modified: trunk/abcl/src/org/armedbear/lisp/Load.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Load.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Load.java Mon Jun 7 14:30:36 2010 > @@ -242,6 +242,7 @@ > } > } > > + private static final Symbol FASL_LOADER = PACKAGE_SYS.intern("*FASL-LOADER*"); > static final LispObject COMPILE_FILE_INIT_FASL_TYPE = new SimpleString("_"); > > public static final LispObject loadSystemFile(final String filename, > @@ -268,7 +269,7 @@ > String path = pathname.asEntryPath(); > url = Lisp.class.getResource(path); > if (url == null || url.toString().endsWith("/")) { > - url = Lisp.class.getResource(path + ".abcl"); > + url = Lisp.class.getResource(path.replace('-', '_') + ".abcl"); > if (url == null) { > url = Lisp.class.getResource(path + ".lisp"); > } > @@ -322,6 +323,7 @@ > final LispThread thread = LispThread.currentThread(); > final SpecialBindingsMark mark = thread.markSpecialBindings(); > thread.bindSpecial(_WARN_ON_REDEFINITION_, NIL); > + thread.bindSpecial(FASL_LOADER, NIL); > try { > Stream stream = new Stream(Symbol.SYSTEM_STREAM, in, Symbol.CHARACTER); > return loadFileFromStream(pathname, truename, stream, > @@ -567,7 +569,7 @@ > thread, Stream.currentReadtable); > if (obj == EOF) > break; > - result = eval(obj, env, thread); > + result = eval(obj, env, thread); > if (print) { > Stream out = > checkCharacterOutputStream(Symbol.STANDARD_OUTPUT.symbolValue(thread)); > > Modified: trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compile-file.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compile-file.lisp Mon Jun 7 14:30:36 2010 > @@ -40,17 +40,33 @@ > > (defvar *output-file-pathname*) > > +(defun base-classname (&optional (output-file-pathname *output-file-pathname*)) > + (sanitize-class-name (pathname-name output-file-pathname))) > + > +(defun fasl-loader-classname (&optional (output-file-pathname *output-file-pathname*)) > + (%format nil "~A_0" (base-classname output-file-pathname))) > + > (declaim (ftype (function (t) t) compute-classfile-name)) > (defun compute-classfile-name (n &optional (output-file-pathname > *output-file-pathname*)) > "Computes the name of the class file associated with number `n'." > (let ((name > - (%format nil "~A-~D" > - (substitute #\_ #\. > - (pathname-name output-file-pathname)) n))) > + (sanitize-class-name > + (%format nil "~A_~D" (pathname-name output-file-pathname) n)))) > (namestring (merge-pathnames (make-pathname :name name :type "cls") > output-file-pathname)))) > > +(defun sanitize-class-name (name) > + (let ((name (copy-seq name))) > + (dotimes (i (length name)) > + (declare (type fixnum i)) > + (when (or (char= (char name i) #\-) > + (char= (char name i) #\.) > + (char= (char name i) #\Space)) > + (setf (char name i) #\_))) > + name)) > + > + > (declaim (ftype (function () t) next-classfile-name)) > (defun next-classfile-name () > (compute-classfile-name (incf *class-number*))) > @@ -69,12 +85,14 @@ > > (declaim (ftype (function (t) t) verify-load)) > (defun verify-load (classfile) > - (if (> *safety* 0) > - (and classfile > + #|(if (> *safety* 0) > + (and classfile > (let ((*load-truename* *output-file-pathname*)) > (report-error > (load-compiled-function classfile)))) > - t)) > + t)|# > + (declare (ignore classfile)) > + t) > > (declaim (ftype (function (t) t) process-defconstant)) > (defun process-defconstant (form) > @@ -144,6 +162,7 @@ > (parse-body body) > (let* ((expr `(lambda ,lambda-list > ,@decls (block ,block-name ,@body))) > + (saved-class-number *class-number*) > (classfile (next-classfile-name)) > (internal-compiler-errors nil) > (result (with-open-file > @@ -168,7 +187,8 @@ > compiled-function) > (setf form > `(fset ',name > - (proxy-preloaded-function ',name ,(file-namestring classfile)) > + (sys::get-fasl-function *fasl-loader* > + ,saved-class-number) > ,*source-position* > ',lambda-list > ,doc)) > @@ -225,6 +245,7 @@ > (let ((name (second form))) > (eval form) > (let* ((expr (function-lambda-expression (macro-function name))) > + (saved-class-number *class-number*) > (classfile (next-classfile-name))) > (with-open-file > (f classfile > @@ -241,14 +262,10 @@ > (if (special-operator-p name) > `(put ',name 'macroexpand-macro > (make-macro ',name > - (proxy-preloaded-function > - '(macro-function ,name) > - ,(file-namestring classfile)))) > + (sys::get-fasl-function *fasl-loader* ,saved-class-number))) > `(fset ',name > (make-macro ',name > - (proxy-preloaded-function > - '(macro-function ,name) > - ,(file-namestring classfile))) > + (sys::get-fasl-function *fasl-loader* ,saved-class-number)) > ,*source-position* > ',(third form))))))))) > (DEFTYPE > @@ -348,8 +365,12 @@ > ;; to load the compiled functions. Note that this trickery > ;; was already used in verify-load before I used it, > ;; however, binding *load-truename* isn't fully compliant, I think. > - (let ((*load-truename* *output-file-pathname*)) > - (when compile-time-too > + (when compile-time-too > + (let ((*load-truename* *output-file-pathname*) > + (*fasl-loader* (make-fasl-class-loader > + *class-number* > + (concatenate 'string "org.armedbear.lisp." (base-classname)) > + nil))) > (eval form)))) > > (declaim (ftype (function (t) t) convert-ensure-method)) > @@ -366,7 +387,8 @@ > (eq (%car function-form) 'FUNCTION)) > (let ((lambda-expression (cadr function-form))) > (jvm::with-saved-compiler-policy > - (let* ((classfile (next-classfile-name)) > + (let* ((saved-class-number *class-number*) > + (classfile (next-classfile-name)) > (result > (with-open-file > (f classfile > @@ -379,7 +401,8 @@ > (declare (ignore result)) > (cond (compiled-function > (setf (getf tail key) > - `(load-compiled-function ,(file-namestring classfile)))) > + `(sys::get-fasl-function *fasl-loader* ,saved-class-number))) > +;; `(load-compiled-function ,(file-namestring classfile)))) > (t > ;; FIXME This should be a warning or error of some sort... > (format *error-output* "; Unable to compile method~%"))))))))) > @@ -412,6 +435,7 @@ > (return-from convert-toplevel-form > (precompiler:precompile-form form nil *compile-file-environment*))) > (let* ((expr `(lambda () ,form)) > + (saved-class-number *class-number*) > (classfile (next-classfile-name)) > (result > (with-open-file > @@ -425,7 +449,7 @@ > (declare (ignore result)) > (setf form > (if compiled-function > - `(funcall (load-compiled-function ,(file-namestring classfile))) > + `(funcall (sys::get-fasl-function *fasl-loader* ,saved-class-number)) > (precompiler:precompile-form form nil *compile-file-environment*))))) > > > @@ -572,25 +596,22 @@ > (write (list 'setq '*source* *compile-file-truename*) > :stream out) > (%stream-terpri out) > - ;; Note: Beyond this point, you can't use DUMP-FORM, > - ;; because the list of uninterned symbols has been fixed now. > - (when *fasl-uninterned-symbols* > - (write (list 'setq '*fasl-uninterned-symbols* > - (coerce (mapcar #'car > - (nreverse *fasl-uninterned-symbols*)) > - 'vector)) > - :stream out)) > - (%stream-terpri out) > - ;; we work with a fixed variable name here to work around the > - ;; lack of availability of the circle reader in the fasl reader > - ;; but it's a toplevel form anyway > - (write `(dotimes (i ,*class-number*) > - (function-preload > - (%format nil "~A-~D.cls" > - ,(substitute #\_ #\. (pathname-name output-file)) > - (1+ i)))) > - :stream out > - :circle t) > + ;; Note: Beyond this point, you can't use DUMP-FORM, > + ;; because the list of uninterned symbols has been fixed now. > + (when *fasl-uninterned-symbols* > + (write (list 'setq '*fasl-uninterned-symbols* > + (coerce (mapcar #'car > + (nreverse *fasl-uninterned-symbols*)) > + 'vector)) > + :stream out)) > + (%stream-terpri out) > + > + (when (> *class-number* 0) > + (generate-loader-function) > + (write (list 'setq '*fasl-loader* > + `(sys::make-fasl-class-loader > + ,*class-number* > + ,(concatenate 'string "org.armedbear.lisp." (base-classname)))) :stream out)) > (%stream-terpri out)) > > > @@ -609,7 +630,11 @@ > (zipfile (namestring > (merge-pathnames (make-pathname :type type) > output-file))) > - (pathnames ())) > + (pathnames nil) > + (fasl-loader (namestring (merge-pathnames (make-pathname :name (fasl-loader-classname) :type "cls") > + output-file)))) > + (when (probe-file fasl-loader) > + (push fasl-loader pathnames)) > (dotimes (i *class-number*) > (let* ((pathname (compute-classfile-name (1+ i)))) > (when (probe-file pathname) > @@ -632,6 +657,55 @@ > (namestring output-file) elapsed)))) > (values (truename output-file) warnings-p failure-p))) > > +(defmacro ncase (expr min max &rest clauses) > + "A CASE where all test clauses are numbers ranging from a minimum to a maximum." > + ;;Expr is subject to multiple evaluation, but since we only use ncase for > + ;;fn-index below, let's ignore it. > + (let* ((half (floor (/ (- max min) 2))) > + (middle (+ min half))) > + (if (> (- max min) 10) > + `(if (< ,expr ,middle) > + (ncase ,expr ,min ,middle ,@(subseq clauses 0 half)) > + (ncase ,expr ,middle ,max ,@(subseq clauses half))) > + `(case ,expr ,@clauses)))) > + > +(defun generate-loader-function () > + (let* ((basename (base-classname)) > + (expr `(lambda (fasl-loader fn-index) > + (identity fasl-loader) ;;to avoid unused arg > + (ncase fn-index 0 ,(1- *class-number*) > + ,@(loop > + :for i :from 1 :to *class-number* > + :collect > + (let ((class (%format nil "org/armedbear/lisp/~A_~A" basename i))) > + `(,(1- i) > + (jvm::with-inline-code () > + (jvm::emit 'jvm::aload 1) > + (jvm::emit-invokevirtual jvm::+lisp-object-class+ "javaInstance" > + nil jvm::+java-object+) > + (jvm::emit 'jvm::checkcast "org/armedbear/lisp/FaslClassLoader") > + (jvm::emit 'jvm::dup) > + (jvm::emit-push-constant-int ,(1- i)) > + (jvm::emit 'jvm::new ,class) > + (jvm::emit 'jvm::dup) > + (jvm::emit-invokespecial-init ,class '()) > + (jvm::emit-invokevirtual "org/armedbear/lisp/FaslClassLoader" "putFunction" > + (list "I" jvm::+lisp-object+) jvm::+lisp-object+) > + (jvm::emit 'jvm::pop)) > + t)))))) > + (classname (fasl-loader-classname)) > + (classfile (namestring (merge-pathnames (make-pathname :name classname :type "cls") > + *output-file-pathname*)))) > + (jvm::with-saved-compiler-policy > + (jvm::with-file-compilation > + (with-open-file > + (f classfile > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + (jvm:compile-defun nil expr nil > + classfile f nil)))))) > + > (defun compile-file-if-needed (input-file &rest allargs &key force-compile > &allow-other-keys) > (setf input-file (truename input-file)) > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp Mon Jun 7 14:30:36 2010 > @@ -1298,7 +1298,7 @@ > (format t "; inlining call to local function ~S~%" op))) > (return-from p1-function-call > (let ((*inline-declarations* > - (remove op *inline-declarations* :key #'car))) > + (remove op *inline-declarations* :key #'car :test #'equal))) > (p1 expansion)))))) > > ;; FIXME > @@ -1432,7 +1432,8 @@ > (TRULY-THE p1-truly-the) > (UNWIND-PROTECT p1-unwind-protect) > (THREADS:SYNCHRONIZED-ON > - p1-threads-synchronized-on))) > + p1-threads-synchronized-on) > + (JVM::WITH-INLINE-CODE identity))) > (install-p1-handler (%car pair) (%cadr pair)))) > > (initialize-p1-handlers) > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Mon Jun 7 14:30:36 2010 > @@ -198,6 +198,8 @@ > (u2 (if (< n 0) (1+ (logxor (- n) #xFFFF)) > n))) > > +(defconstant +fasl-loader-class+ > + "org/armedbear/lisp/FaslClassLoader") > (defconstant +java-string+ "Ljava/lang/String;") > (defconstant +java-object+ "Ljava/lang/Object;") > (defconstant +lisp-class+ "org/armedbear/lisp/Lisp") > @@ -2267,12 +2269,22 @@ > local-function *declared-functions* ht g > (setf g (symbol-name (gensym "LFUN"))) > (let* ((pathname (abcl-class-file-pathname (local-function-class-file local-function))) > + (class-name (concatenate 'string "org/armedbear/lisp/" (pathname-name pathname))) > (*code* *static-code*)) > ;; fixme *declare-inline* > - (declare-field g +lisp-object+ +field-access-default+) > - (emit 'ldc (pool-string (file-namestring pathname))) > - (emit-invokestatic +lisp-function-proxy-class+ "loadPreloadedFunction" > - (list +java-string+) +lisp-object+) > + (declare-field g +lisp-object+ +field-access-private+) > + (emit 'new class-name) > + (emit 'dup) > + (emit-invokespecial-init class-name '()) > + > + ;(emit 'ldc (pool-string (pathname-name pathname))) > + ;(emit-invokestatic +fasl-loader-class+ "faslLoadFunction" > + ;(list +java-string+) +lisp-object+) > + > +; (emit 'ldc (pool-string (file-namestring pathname))) > + > +; (emit-invokestatic +lisp-function-proxy-class+ "loadPreloadedFunction" > +; (list +java-string+) +lisp-object+) > (emit 'putstatic *this-class* g +lisp-object+) > (setf *static-code* *code*) > (setf (gethash local-function ht) g)))) > @@ -5094,7 +5106,8 @@ > (local-function-function local-function))))) > (emit 'getstatic *this-class* > g +lisp-object+))))) ; Stack: template-function > - ((member name *functions-defined-in-current-file* :test #'equal) > + ((and (member name *functions-defined-in-current-file* :test #'equal) > + (not (notinline-p name))) > (emit 'getstatic *this-class* > (declare-setf-function name) +lisp-object+) > (emit-move-from-stack target)) > @@ -7544,6 +7557,32 @@ > ;; delay resolving the method to run-time; it's unavailable now > (compile-function-call form target representation)))) > > +#|(defknown p2-java-jcall (t t t) t) > +(define-inlined-function p2-java-jcall (form target representation) > + ((and (> *speed* *safety*) > + (< 1 (length form)) > + (eq 'jmethod (car (cadr form))) > + (every #'stringp (cdr (cadr form))))) > + (let ((m (ignore-errors (eval (cadr form))))) > + (if m > + (let ((must-clear-values nil) > + (arg-types (raw-arg-types (jmethod-params m)))) > + (declare (type boolean must-clear-values)) > + (dolist (arg (cddr form)) > + (compile-form arg 'stack nil) > + (unless must-clear-values > + (unless (single-valued-p arg) > + (setf must-clear-values t)))) > + (when must-clear-values > + (emit-clear-values)) > + (dotimes (i (jarray-length raw-arg-types)) > + (push (jarray-ref raw-arg-types i) arg-types)) > + (emit-invokevirtual (jclass-name (jmethod-declaring-class m)) > + (jmethod-name m) > + (nreverse arg-types) > + (jmethod-return-type m))) > + ;; delay resolving the method to run-time; it's unavailable now > + (compile-function-call form target representation))))|# Maybe this can use a comment on why it's commented out? Is this not a good idea? Does it depend on premises which are not (yet) met? > > (defknown p2-char= (t t t) t) > (defun p2-char= (form target representation) > @@ -8220,6 +8259,13 @@ > (setf (method-handlers execute-method) (nreverse *handlers*))) > t) > > +(defun p2-with-inline-code (form target representation) > + ;;form = (with-inline-code (&optional target-var repr-var) ...body...) > + (destructuring-bind (&optional target-var repr-var) (cadr form) > + (eval `(let (,@(when target-var `((,target-var ,target))) > + ,@(when repr-var `((,repr-var ,representation)))) > + ,@(cddr form))))) > + > (defun compile-1 (compiland stream) > (let ((*all-variables* nil) > (*closure-variables* nil) > @@ -8512,6 +8558,7 @@ > (install-p2-handler 'java:jclass 'p2-java-jclass) > (install-p2-handler 'java:jconstructor 'p2-java-jconstructor) > (install-p2-handler 'java:jmethod 'p2-java-jmethod) > +; (install-p2-handler 'java:jcall 'p2-java-jcall) > (install-p2-handler 'char= 'p2-char=) > (install-p2-handler 'characterp 'p2-characterp) > (install-p2-handler 'coerce-to-function 'p2-coerce-to-function) > @@ -8596,6 +8643,7 @@ > (install-p2-handler 'vector-push-extend 'p2-vector-push-extend) > (install-p2-handler 'write-8-bits 'p2-write-8-bits) > (install-p2-handler 'zerop 'p2-zerop) > + (install-p2-handler 'with-inline-code 'p2-with-inline-code) > t) > > (initialize-p2-handlers) > > Modified: trunk/abcl/src/org/armedbear/lisp/disassemble.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/disassemble.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/disassemble.lisp Mon Jun 7 14:30:36 2010 > @@ -47,14 +47,15 @@ > (when (functionp function) > (unless (compiled-function-p function) > (setf function (compile nil function))) > - (when (getf (function-plist function) 'class-bytes) > - (with-input-from-string > - (stream (disassemble-class-bytes (getf (function-plist function) 'class-bytes))) > - (loop > - (let ((line (read-line stream nil))) > - (unless line (return)) > - (write-string "; ") > - (write-string line) > - (terpri)))) > - (return-from disassemble))) > - (%format t "; Disassembly is not available.~%"))) > + (let ((class-bytes (function-class-bytes function))) > + (when class-bytes > + (with-input-from-string > + (stream (disassemble-class-bytes class-bytes)) > + (loop > + (let ((line (read-line stream nil))) > + (unless line (return)) > + (write-string "; ") > + (write-string line) > + (terpri)))) > + (return-from disassemble))) > + (%format t "; Disassembly is not available.~%")))) > > Modified: trunk/abcl/src/org/armedbear/lisp/gui.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/gui.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/gui.lisp Mon Jun 7 14:30:36 2010 > @@ -1,5 +1,7 @@ > (in-package :extensions) > > +(require :java) > + > (defvar *gui-backend* :swing) > > (defun init-gui () > > Modified: trunk/abcl/src/org/armedbear/lisp/load.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/load.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/load.lisp Mon Jun 7 14:30:36 2010 > @@ -38,10 +38,11 @@ > (if-does-not-exist t) > (external-format :default)) > (declare (ignore external-format)) ; FIXME > - (%load (if (streamp filespec) > - filespec > - (merge-pathnames (pathname filespec))) > - verbose print if-does-not-exist)) > + (let (*fasl-loader*) > + (%load (if (streamp filespec) > + filespec > + (merge-pathnames (pathname filespec))) > + verbose print if-does-not-exist))) > > (defun load-returning-last-result (filespec > &key > @@ -50,7 +51,8 @@ > (if-does-not-exist t) > (external-format :default)) > (declare (ignore external-format)) ; FIXME > - (%load-returning-last-result (if (streamp filespec) > - filespec > - (merge-pathnames (pathname filespec))) > - verbose print if-does-not-exist)) > \ No newline at end of file > + (let (*fasl-loader*) > + (%load-returning-last-result (if (streamp filespec) > + filespec > + (merge-pathnames (pathname filespec))) > + verbose print if-does-not-exist))) > \ No newline at end of file > > Modified: trunk/abcl/src/org/armedbear/lisp/precompiler.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/precompiler.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/precompiler.lisp Mon Jun 7 14:30:36 2010 > @@ -32,13 +32,10 @@ > (in-package "SYSTEM") > > > -(export '(*inline-declarations* > - process-optimization-declarations > +(export '(process-optimization-declarations > inline-p notinline-p inline-expansion expand-inline > *defined-functions* *undefined-functions* note-name-defined)) > > -(defvar *inline-declarations* nil) > - > (declaim (ftype (function (t) t) process-optimization-declarations)) > (defun process-optimization-declarations (forms) > (dolist (form forms) > @@ -86,7 +83,7 @@ > (declaim (ftype (function (t) t) inline-p)) > (defun inline-p (name) > (declare (optimize speed)) > - (let ((entry (assoc name *inline-declarations*))) > + (let ((entry (assoc name *inline-declarations* :test #'equal))) > (if entry > (eq (cdr entry) 'INLINE) > (and (symbolp name) (eq (get name '%inline) 'INLINE))))) > @@ -94,7 +91,7 @@ > (declaim (ftype (function (t) t) notinline-p)) > (defun notinline-p (name) > (declare (optimize speed)) > - (let ((entry (assoc name *inline-declarations*))) > + (let ((entry (assoc name *inline-declarations* :test #'equal))) > (if entry > (eq (cdr entry) 'NOTINLINE) > (and (symbolp name) (eq (get name '%inline) 'NOTINLINE))))) > @@ -961,7 +958,8 @@ > (symbol-name symbol)) > 'precompiler)))) > (unless (and handler (fboundp handler)) > - (error "No handler for ~S." symbol)) > + (error "No handler for ~S." (let ((*package* (find-package :keyword))) > + (format nil "~S" symbol)))) > (setf (get symbol 'precompile-handler) handler))) > > (defun install-handlers () > @@ -1024,7 +1022,9 @@ > (TRULY-THE precompile-truly-the) > > (THREADS:SYNCHRONIZED-ON > - precompile-threads-synchronized-on))) > + precompile-threads-synchronized-on) > + > + (JVM::WITH-INLINE-CODE precompile-identity))) > (install-handler (first pair) (second pair)))) > > (install-handlers) > > Modified: trunk/abcl/src/org/armedbear/lisp/proclaim.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/proclaim.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/proclaim.lisp Mon Jun 7 14:30:36 2010 > @@ -31,7 +31,7 @@ > > (in-package #:system) > > -(export '(check-declaration-type proclaimed-type proclaimed-ftype ftype-result-type)) > +(export '(check-declaration-type proclaimed-type proclaimed-ftype ftype-result-type *inline-declarations*)) > > (defmacro declaim (&rest decls) > `(eval-when (:compile-toplevel :load-toplevel :execute) > @@ -43,6 +43,7 @@ > :format-control "The symbol ~S cannot be both the name of a type and the name of a declaration." > :format-arguments (list name))) > > +(defvar *inline-declarations* nil) > (defvar *declaration-types* (make-hash-table :test 'eq)) > > ;; "A symbol cannot be both the name of a type and the name of a declaration. > @@ -91,8 +92,9 @@ > (apply 'proclaim-type (cdr declaration-specifier))) > ((INLINE NOTINLINE) > (dolist (name (cdr declaration-specifier)) > - (when (symbolp name) ; FIXME Need to support non-symbol function names. > - (setf (get name '%inline) (car declaration-specifier))))) > + (if (symbolp name) > + (setf (get name '%inline) (car declaration-specifier)) > + (push (cons name (car declaration-specifier)) *inline-declarations*)))) > (DECLARATION > (dolist (name (cdr declaration-specifier)) > (when (or (get name 'deftype-definition) Thanks again! I hope this helps us getting a common base for things happening in the FASL (such as constants and other stuff that we want to create/instantiate only once; not every function class by itself). Bye, Erik.

2 1

[armedbear-devel] generated abcl shell script executable
by Matthias Cords 08 Jun '10

08 Jun '10

Hi there, just a suggestion. would it be possible to change the generated "abcl" shell script to not use the -cp parameter to the java executable, but set up the classpath like e.g. so export CLASSPATH=`dirname $0`/dist/abcl.jar:$CLASSPATH and then invoke exec .../java org.armedbear.lisp.Main "$@" i.e. without the -cp parameter. This would result in the CLASSPATH environment variable that was in effect before the call to the abcl script to remain available to the lisp interpreter. i.e. jdbc driver classes etc. apart from that I think abcl is a great great piece of software making life a lot more convenient. thanks to everyone participating! Kindly, Matthias

4 3

[armedbear-devel] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[armedbear-devel] ASDF 2.000 released!
by Faré 31 May '10

31 May '10

Dear ABCL hackers, I have finally released ASDF 2, officially starting with release 2.000. http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release and for inclusion in all Common Lisp implementations. I thank all those who helped develop and test this release, including Robert P. Goldman, James Anderson, Juan-Jose Garcia-Ripoll, and many more. We welcome bug reports on our launchpad site: https://launchpad.net/asdf I'm using ASDF 2 at ITA. Recent versions are already included in ABCL, CCL, CMUCL, ECL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portable naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows. * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a Lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). Or just keep the default directory hierarchies being searched empty. * Windows support may have been insufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, ECL, CMUCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] When a pamphlet was published entitled "100 Authors Against Einstein", Einstein retorted "If I were wrong, one would be enough."

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.20.0 release includes its first funded feature
by Erik Huelsmann 27 May '10

27 May '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.20.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release is the first to include a funded feature: funds were provided to implement the CLOS METACLASS feature and tests. Next to that, this release contains a large number of fixes and improvements, such as the ability to use JARs and URLs as pathnames and the a new ASDF version (ASDF2). You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.20.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.20.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.20.0.zip.asc

1 0

[armedbear-devel] Fixes to LispShell.java for 0.23.0
by Frank Pursel 25 May '10

25 May '10

All, I downloaded the latest version of J a couple of days ago (J version 0.23.0) and had some difficulties getting it to compile using java-6-sun's compiler version 1.6 update 20. Here are the modifications I made to LispShell.java to get it to compile cleanly against a fresh build of the newest abcl (ver 0.19.1, though I don't think it matters): diff -c /home/fpp/src/tmp/j-0.23.0/src/org/armedbear/j/LispShell.java /home/fpp/src/j-0.23.0/src/org/armedbear/j/LispShell.java *** /home/fpp/src/tmp/j-0.23.0/src/org/armedbear/j/LispShell.java 2010-04-03 15:04:08.000000000 -0400 --- /home/fpp/src/j-0.23.0/src/org/armedbear/j/LispShell.java 2010-05-22 18:42:29.963613502 -0400 *************** *** 110,120 **** } else { ! File lispHome = File.getInstance(Site.getLispHome()); if (lispHome == null) return null; // FIXME Error message? ! File swankLoader = File.getInstance(lispHome, ! "swank-loader.lisp"); if (swankLoader == null) return null; // FIXME Error message? if (shellCommand.indexOf("sbcl") >= 0 --- 110,121 ---- } else { ! Pathname lispHome = (Pathname)Site.getLispHome(); if (lispHome == null) return null; // FIXME Error message? ! File swankLoader = File.getInstance( ! Pathname.mergePathnames(lispHome, ! new Pathname("swank-loader.lisp"))); if (swankLoader == null) return null; // FIXME Error message? if (shellCommand.indexOf("sbcl") >= 0 *************** *** 902,908 **** sb.append(" -Xmx256M"); if (Platform.isPlatformUnix()) { ! Pathname lispHome = org.armedbear.lisp.Site.getLispHome(); if (lispHome != null) { sb.append(" -Xrs -Djava.library.path="); --- 903,909 ---- sb.append(" -Xmx256M"); if (Platform.isPlatformUnix()) { ! Pathname lispHome = (Pathname)org.armedbear.lisp.Site.getLispHome(); if (lispHome != null) { sb.append(" -Xrs -Djava.library.path="); Diff finished. Sun May 23 19:30:24 2010 I hope it's helpful. I was unable to get abcl to compile cleanly using the lisp build method. It failed with messages telling me that it, variously, could not autoload load or that it could not load 'system'. When I used ant I had no problems. Best wishes on an excellent project. Sincerely, Frank Pursel

3 2

[armedbear-devel] HEADS-UP Swing/AWT code moved to examples; ConsoleREPL added to base
by Mark Evenson 25 May '10

25 May '10

As discussed on #abcl some days ago with Alessio (and Erik?), I have moved the unused code from org.armedbear.lisp.java.* to 'examples/gui' as it is a better fit there. Under the examples I created a simple Ant build.xml with the base outline of a README. The domain of using ABCL to take the tedium out of Swing development and/or the combination with [JSS][1] to produce an interactively built GUI is potentially very interesting to a wider audience, but the examples are currently very thin. But maybe we should just direct people to [Snow][2], as that is where a lot of energy has seemingly been spent. [1]: http://code.google.com/p/lsw2/source/browse/#svn/trunk/jss [2]: http://common-lisp.net/project/snow/ I've [placed the code that Alessio wrote for a minimal Swing REPL console in org.armedbear.lisp.java.swing.REPLConsole][3], which has a suitable Main method so that java -cp abcl.jar org.armedbear.lisp.java.swing.REPLConsole will bring it "up" in the local display. [3]: http://trac.common-lisp.net/armedbear/changeset/12734 This console code is [the current basis][4] for the embedding of ABCL in the Protege ontology editor, although that currently uses its own version. I don't like the creation of Threads in the constructor, but haven't had time to figure out if there is a better way to go. The intention is to provide a standard way for people to embed ABCL with a minimal REPL for their domain-specific Java application, so I when I get the time I will revisit the Protege plugin to use this code. [4]: http://svn.neurocommons.org/svn/trunk/protege/org.sciencecommons.protege.li… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] progress with abcl in protege
by Alan Ruttenberg 23 May '10

23 May '10

Alessio found some threading issues with his console, and with those fixed I am able to use it within protege and it no longer hangs after one or two commands. (Thanks!) Using the latest abcl, there also seems to be some bundle: url goodness happening. I no longer see the unbound variable issue, and I see bundle: uris for abcl-defined lisp code being loaded - snap attached - I recorded a screen movie and grabbed the last it showed before crashing. I then go and try to load some other code and the whole thing crashes. I'm including the relevant portion of the console log. The last complaint is: 4/15/10 6:24:59 PM [0x0-0x15e15e].Protege41[3978] Unable to autoload JAVA:JCLASS-FIELDS Not sure why other bundle: code would load but not this. -Alan

3 25

[armedbear-devel] Optimizing loading times: different strategy for externalizing
by Erik Huelsmann 21 May '10

21 May '10

The other day, there was some discussion regarding object-equality from loaded fasls. I'm going to leave that discussion out of the mail below: the mail below is about efficiency of what we do today. As described by Alessio, it looks like our loading process profiles are dominated by reader functions. So, I've taken a look at what it actually is that we serialize. I found that many things we serialize today - which need to be restored by the reader - can be serialized without requiring the reader to restore it: lists of symbols and lists. That's where I decided to take a look at today's serialization mechanism. Roughly speaking, those are the functions in compiler-pass2.lisp with a function name starting with DECLARE-*; the namespace seems to contain functions for externalizing objects as well as for caching constant values. On trunk, I'm working to: * separate the caching from the externalizing name-spaces * separate serialization and restoring functionalities in different functions (they were conflated in a single function for each type of object) * define serialization functions which allow recursive calling patterns for nested serialization of objects (to be restored without requiring the reader) For each of these bullets, I'm making good progress; the second bullet is done, although not all serialization functions have been moved over to that namespace and approach yet. The last bullet is nearly done. When each of the above is done, we will have all the building blocks required for quick elimination of the reader in a number of obvious cases - such as function argument lists. Hope you find this update useful. Bye, Erik.

5 8

[armedbear-devel] debugAssert again
by Alan Ruttenberg 19 May '10

19 May '10

; Loading #P"/Users/alanr/.cache/common-lisp/armedbear-0.20.0-dev-fasl36-darwin-java-1.6/Users/alanr/repos/lsw2/trunk/util/encapsulate.abcl" ... ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.Package.shadowingImport(Package.java:601) at org.armedbear.lisp.PackageFunctions$9.execute(PackageFunctions.java:186) at org.armedbear.lisp.Primitive.execute(Primitive.java:118) .... internalSymbols.put(symbol.name, symbol); if (shadowingSymbols == null) shadowingSymbols = new HashMap<String,Symbol>(); --> Debug.assertTrue(shadowingSymbols.get(symbolName) == null); shadowingSymbols.put(symbolName, symbol); This seems to be where I'm calling shadowing import. However a small file with just this doesn't trigger the bug, nor does it seem to happen on all loads. (defpackage "ENCAPSULATE" (:USE "CL" "SYSTEM") (:export "TRACE" "UNTRACE" "ADVISE" "UNADVISE" "ARGLIST")) (in-package encapsulate) (shadowing-import '(trace untrace advise unadvise arglist) 'cl-user) -Alan

2 1

[armedbear-devel] Less-reflection branch: profiling and comparison with trunk
by Alessio Stalla 18 May '10

18 May '10

Hello, as I have already informally discussed with Erik and David Miles, I have been working on a branch which changes how functions are compiled in FASLs (and by consequence how they are loaded from FASLs). The purpose was to reduce the use of reflection by using a single classloader per FASL (as opposed to one per function) plus a master "loader" function that will initialize all other function classes using the new operator, rather than passing through reflection. Now such loading is done eagerly, as soon as the FASL is loaded; but with a bit more work, I should be able to restore autoloading semantics, so that a given function object is only instantiated the first time it is called (but the class representing it will always be loaded eagerly). I suspect it won't change much, though. The overall performance results (reported below) are not very encouraging. However, I do think that the branch has a better design than our current approach, and goes towards the objective of having a per-fasl object holding various things (e.g. a FASL constant pool). In the long run, not having functions rely on loadCompiledFunction in their static initialization code is a nice step towards serializable closures, if we'll ever want to have them. The results on load times and overall runtime speed have been insignificant. Apparently by large the most important factor in our load time is I/O and the branch doesn't change anything about that. It just saves ~1% of the loading time spent on reflection. The results on memory consumption are mixed: they do show a great decrease in the number of classloaders, as expected, but the numbers are not tremendously life-changing: 56 objects (live and allocated, for a total of 4032B, 0.1% of total live objects) vs 789 live objects of 1014 allocated, 44.184B, 1.1% of total live objects. There are also less reflection-related objects, but more Lisp objects, presumably due to eager loading. The numbers for those from a quick glance more or less balance out with each other. Doing these profiles showed that a lot of our memory is actually made of the stored byte[] containing class data for compiled functions. Those amount to ~4M on trunk and almost 8M on my branch (probably due the eager loading of compiled functions). Given that I now load all functions with a classloader that knows where functions have been loaded from, I think I should not store the byte[] in the function at all, but rely on the fasl classloader to re-extract them from the FASL on demand. However, I haven't still implemented this. For those who are interested, I'm attaching the memory profiles done with NetBeans. I left out the CPU profiles because they're fatter (~6M) and I'm on a slow connection now; but I can send them separately. Cheers, Alessio

2 3

[armedbear-devel] ABCL 0.20 stabilization status
by Erik Huelsmann 16 May '10

16 May '10

Last week we branched for 0.20. After branching, a number of issues were found. Some with respect to our relatively new pathname code, others with respect to the reader reorganization we've had. All of the issues *I* know of should be fixed. I've run the ansi tests on the branch (on Windows) and the Maxima test suite too. Both succeed without any surprises right now. So, from where I stand it looks like we'll be able to release with our current status. Please test the branch with your own normal usage patterns to make sure the release will work for you too. If things stay stable during the next week and no further regressions will be reported, I'll create a release next weekend. Bye, Erik.

1 0

[armedbear-devel] Objects sharing structure at compile time, get "destructured" in our FASL format
by Erik Huelsmann 16 May '10

16 May '10

The other day, Alessio and I were talking about how unfortunate it is that we use the reader to create relatively simple structures, such as lists in our Java classes. To illustrate: (defun foo () (let ((x '(1 2 3))) x)) In the above definition, if being file-compiled, the litteral list (1 2 3) gets serialized into a string which is - at load time - converted back to an object like this: LispObject theObject = Lisp.readObjectFromString("(1 2 3)"); In our minds, it would be faster to generate: LispObject theObject = new Cons(new Fixnum(1), new Cons(new Fixnum(2), new Cons(new Fixnum(3))))); Because that eliminates the need to set up a stream, reading from a string, running all the characters through the reader, including running of dispatch functions, etc. While that would be a nice optimization, I've run into a correctness issue investigating our current serialization. Now consider the following macro: (defmacro foo (x) `(defun bar () (let ((a ,x) (b ,x)) (eq a b)))) (foo '(1 2 3)) This macro can be used to generate an example of 2 objects sharing structure to the extreme: they are the same object. The same object is supposed to be assigned to A and B. In the interpreter, the result of a function call to BAR returns T. However, after filecompiling the above forms and loading the resulting fasl, the outcome of BAR is NIL. Suddenly, the forms are not the same anymore. The answer to that is too simple: the object assigned to A and B is being read for A and B separately with a readObjectFromString call, like this: LispObject theObjectA = Lisp.readObjectFromString("(1 2 3)"); LispObject theObjectB = Lisp.readObjectFromString("(1 2 3)"); The above is clearly wrong. The solution to this case is very simple: we should detect "duplicates" being serialized by the DECLARE-OBJECT-AS-STRING function. Although the above solution would solve the simple case of object equality, there are other examples which it won't solve, think about the following macro: (defmacro foo (x) `(defun bar () (let ((a ,x) (b `(0 ,,x))) (eq a (cdr b))))) The macro above will generate 2 different values to be serialized by the DECLARE-OBJECT-AS-STRING function, failing to detect the fact that the two share structure. Possibly, we could come up with a way to detect objects with shared structure and generate the right class-setup code to make the above example work. But that's not all there is to this problem: the objects sharing structure can be distributed over multiple Java classes; consider the fact that our local functions are Java classes of their own, each with their own constants. One of the ideas that Alessio and I had was that it would be nice to have a single pool of constants for an entire FASL, for the separate function classes to refer to when required. Looking at the above issue, I'd say we really do need such a facility. The only per-fasl facility for objects being equal that we currently have, is the vector with anonymous symbols. Any ideas on how to tackle this issue? I suppose other lisps don't have this issue because they don't use separate classes for their functions and have more influence over the storage format of their data in the fasl... Bye, Erik.

3 4

[armedbear-devel] more directory and jars
by Alan Ruttenberg 15 May '10

15 May '10

CL-USER> (DIRECTORY "jar:file:/Users/alanr/Desktop/jar2go.jar!/abcl-module-*.lisp") Calling (DIRECTORY "jar:file:/Users/alanr/Desktop/jar2go.jar!/abcl-module-*.lisp") DIRECTORY returned #<FILE-ERROR {E2C42F}> #<FILE-ERROR {E2C42F}> CL-USER> (describe *) #<FILE-ERROR {E2C42F}> is an instance of #<STANDARD-CLASS FILE-ERROR {8917A2}>. The following slots have :INSTANCE allocation: FORMAT-CONTROL "Not a wild pathname." FORMAT-ARGUMENTS NIL PATHNAME #P"jar:file:/Users/alanr/Desktop/jar2go.jar!/abcl-module-*.lisp" ; No value Below is the function I use for directory in jars. Please consider including it until there is a correct implementation in java. (defun directory-in-jar (pathname) (let* ((device (pathname-device pathname)) (jarfile (namestring (car device))) (rest-pathname (namestring (make-pathname :directory `(:absolute ,@(cdr (pathname-directory pathname))) :name (pathname-name pathname) :type (pathname-type pathname))))) (if (or (position #\* (namestring rest-pathname)) (wild-pathname-p rest-pathname)) (let ((jar (jnew "java.util.zip.ZipFile" jarfile))) (let ((els (jcall "entries" jar))) (loop while (jcall "hasMoreElements" els) for name = (jcall "getName" (jcall "nextElement" els)) when (pathname-match-p (concatenate 'string "/" name) rest-pathname) collect (make-pathname :device (pathname-device pathname) :name (pathname-name name) :type (pathname-type name) :directory `(:relative ,@(cdr (pathname-directory name))))))) (let ((truename (probe-file pathname))) (if truename (list truename) nil)))))

2 2

[armedbear-devel] system.lisp and handler-case
by Alan Ruttenberg 14 May '10

14 May '10

I'm trying to use system.lisp as the hook into writing code that reads command line parameters and does stuff - to use abcl for scripting. The problem is that debugging it is ... uncomfortable... , because (handler-case (require 'system) (t ())) Means that any error just stops what's happening. How can I establish that my code running as called from system.lisp runs in a normal debugging environment? Thanks, Alan

2 7

[armedbear-devel] over-agressive handler for module-provide-system
by Alan Ruttenberg 12 May '10

12 May '10

Current: (defun module-provide-system (module) (let ((*readtable* (copy-readtable nil))) (handler-case (load-system-file (string-downcase (string module))) (t (e) (unless (and (typep e 'error) (search "Failed to find loadable system file" (format nil "~A" e))) (format *error-output* "Failed to require ~A because '~A'~%" module e)) nil)))) First, t is too strong - warns will kill it. Second, why not let the debugger handle it if there is an error? -Alan

2 1

[armedbear-devel] lambda-list error at compilation
by Alan Ruttenberg 11 May '10

11 May '10

The following works as expected when evaluated, but throws an error when compiling. (defun hashmap-to-hashtable (hashmap &key (keyfun #'identity) (valfun #'identity) (invert? nil) &allow-other-keys &rest rest) (let ((keyset (#"keySet" hashmap)) (table (apply 'make-hash-table (remf :invert? (remf :valfun (remf :keyfun rest)))))) (with-constant-signature ((iterator "iterator" t) (hasnext "hasNext") (next "next")) (loop with iterator = (iterator keyset) while (hasNext iterator) for item = (next iterator) do (if invert? (setf (gethash (funcall valfun (#"get" hashmap item)) table) (funcall keyfun item)) (setf (gethash (funcall keyfun item) table) (funcall valfun (#"get" hashmap item))))) table))) -> Error &REST/&BODY must be followed by a variable. [Condition of type PROGRAM-ERROR] Restarts: 0: [ABORT] Abort compilation. 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (SYSTEM:MAKE-CLOSURE (LAMBDA (#:G29656 &KEY (# NIL #:G29659) (# NIL #:G29661) (# NIL) &ALLOW-OTHER-KEYS ...) NIL) NIL) 1: (JVM::P1-COMPILAND #S(JVM::COMPILAND :NAME HASHMAP-TO-HASHTABLE :LAMBDA-EXPRESSION (LAMBDA (#1=#:G29656 &KEY ((:KEYFUN #:G29658) NIL #:G29659) ((:VALFUN #:G29660) NIL #:G29661) ((:INVERT? #2=#:G29662).. 2: (JVM::P1-FUNCTION #'(SYSTEM:NAMED-LAMBDA HASHMAP-TO-HASHTABLE (HASHMAP &KEY (KEYFUN #'IDENTITY) (VALFUN #'IDENTITY) (INVERT? NIL) &ALLOW-OTHER-KEYS ...) (BLOCK HASHMAP-TO-HASHTABLE (LET # #)))) 3: (JVM::P1 #'(SYSTEM:NAMED-LAMBDA HASHMAP-TO-HASHTABLE (HASHMAP &KEY (KEYFUN #'IDENTITY) (VALFUN #'IDENTITY) (INVERT? NIL) &ALLOW-OTHER-KEYS ...) (BLOCK HASHMAP-TO-HASHTABLE (LET # #)))) Locals: "??" = "??" 4: (JVM::P1 (SYSTEM:NAMED-LAMBDA HASHMAP-TO-HASHTABLE (HASHMAP &KEY (KEYFUN #'IDENTITY) (VALFUN #'IDENTITY) (INVERT? NIL) &ALLOW-OTHER-KEYS ...) (BLOCK HASHMAP-TO-HASHTABLE (LET # #)))) 5: (JVM::P1-LET*-VARS #S(JVM::LET/LET*-NODE :FORM NIL :COMPILAND #S(JVM::COMPILAND :NAME NIL :LAMBDA-EXPRESSION (LAMBDA NIL (SYSTEM:%DEFUN 'HASHMAP-TO-HASHTABLE (SYSTEM:NAMED-LAMBDA HASHMAP-TO-HASHTABLE .. 6: (JVM::P1-LET/LET* (LET* ((#:G29655 #)) (SYSTEM:%DEFUN 'HASHMAP-TO-HASHTABLE #:G29655))) 7: (JVM::P1 (LET* ((#:G29655 #)) (SYSTEM:%DEFUN 'HASHMAP-TO-HASHTABLE #:G29655))) 8: (JVM::P1-FUNCTION-CALL (SYSTEM:%DEFUN 'HASHMAP-TO-HASHTABLE (SYSTEM:NAMED-LAMBDA HASHMAP-TO-HASHTABLE (HASHMAP &KEY # # # &ALLOW-OTHER-KEYS ...) (BLOCK HASHMAP-TO-HASHTABLE #)))) 9: (JVM::P1-BODY ((SYSTEM:%DEFUN 'HASHMAP-TO-HASHTABLE (SYSTEM:NAMED-LAMBDA HASHMAP-TO-HASHTABLE # #)))) 10: (#<FUNCTION {79F502}>) 11: (#<FUNCTION {C49395}>) 12: (#<FUNCTION {E4ED69}> NIL (LAMBDA NIL (DEFUN HASHMAP-TO-HASHTABLE (HASHMAP &KEY # # # &ALLOW-OTHER-KEYS ...) (LET # #)))) 13: (#<FUNCTION (LAMBDA ()) {B5506C}>) 14: (JRUN-EXCEPTION-PROTECTED #<FUNCTION (LAMBDA ()) {B5506C}>) 15: ((FLET SWANK-BACKEND:SWANK-COMPILE-STRING) "(defun hashmap-to-hashtable (hashmap &key (keyfun #'identity) (valfun #'identity) (invert? nil) &allow-other-keys &rest rest) (let ((keyset (#\"..

4 5

[armedbear-devel] asdf2 meets jar files
by Alan Ruttenberg 11 May '10

11 May '10

(asdf::initialize-source-registry '(:source-registry :ignore-inherited-configuration (:tree "jar:file:/Users/alanr/Desktop/jar2go.jar!/"))) -> WARNING: Error while scanning system definitions under directory #P"jar:file:/Users/alanr/Desktop/jar2go.jar!/": Unsupported directory component :WILD-INFERIORS.

2 1

[armedbear-devel] expecting to find integer on stack
by Alan Ruttenberg 10 May '10

10 May '10

Fresh svn update. Compiled with Java 1.5 on OSX File attached. laptop:~/repos/abcl % ./abcl --noinit Armed Bear Common Lisp 0.20.0-dev Java 1.5.0_19 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.363 seconds. Startup completed in 0.914 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/Users/alanr/repos/lsw/trunk/owlapi3/patmatch.lisp") ; Compiling /Users/alanr/repos/lsw/trunk/owlapi3/patmatch.lisp ... ; (DEFUN VARIABLE-P ...) ; (DEFUN PAT-MATCH ...) ; in (DEFUN PAT-MATCH ...) ; Caught STYLE-WARNING: ; Undefined variable NO-BINDINGS assumed special ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; Caught STYLE-WARNING: ; Undefined variable *OWL2-VOCABULARY-FORMS* assumed special ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (DEFUN SEGMENT-PATTERN-P ...) ; (DEFUN SINGLE-PATTERN-P ...) ; (DEFUN SEGMENT-MATCHER ...) ; (DEFUN SINGLE-MATCHER ...) ; (DEFUN SEGMENT-MATCH-FN ...) ; (DEFUN SINGLE-MATCH-FN ...) ; (DEFUN MATCH-IS ...) ; in (DEFUN MATCH-IS ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-AND ...) ; in (DEFUN MATCH-AND ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-OR ...) ; in (DEFUN MATCH-OR ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-NOT ...) ; in (DEFUN MATCH-NOT ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN SEGMENT-MATCH ...) ; in (DEFUN SEGMENT-MATCH ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN FIRST-MATCH-POS ...) ; (DEFUN SEGMENT-MATCH+ ...) ; (DEFUN SEGMENT-MATCH? ...) ; (DEFUN SEGMENT-ATOM-MATCH? ...) ; (DEFUN MATCH-OPTIONAL-ATOM ...) ; in (DEFUN MATCH-OPTIONAL-ATOM ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-IF ...) ; Compilation unit finished ; Caught 9 STYLE-WARNING conditions ; The following functions were used but not defined: ; MATCH-VARIABLE java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.armedbear.lisp.Lisp.makeCompiledFunctionFromClass(Lisp.java:1286) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1347) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1340) at org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:224) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_7.execute(compile-file.lisp:71) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_5.execute(compile-file.lisp:71) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_10.execute(compile-file.lisp:103) at org.armedbear.lisp.Symbol.execute(Symbol.java:799) at org.armedbear.lisp.LispThread.execute(LispThread.java:602) at org.armedbear.lisp.compile_file_40.execute(compile-file.lisp:486) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_37.execute(compile-file.lisp:486) at org.armedbear.lisp.compiler_pass2_579.execute(compiler-pass2.lisp:8685) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8685) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_35.execute(compile-file.lisp:486) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.eval(Lisp.java:460) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:328) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:278) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:766) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Interpreter.run(Interpreter.java:319) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) #<THREAD "interpreter" {1A3492}>: Debugger invoked on condition of type ERROR Caught java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

4 10

[armedbear-devel] add fasl version to default directory for asdf cache
by Alan Ruttenberg 10 May '10

10 May '10

Otherwise one gets the like of: Error loading /Users/alanr/repos/lsw2/trunk/scripts/system-registry.lisp at line 42 (offset 1356) #<THREAD "interpreter" {7A8516}>: Debugger invoked on condition of type SIMPLE-ERROR Incorrect fasl version: jar:file:/Users/alanr/.cache/common-lisp/armedbear-0.20.0-dev-darwin-unknown/Users/alanr/repos/lsw2/trunk/jss/invoke.abcl!/invoke._ Restarts: -Alan

2 4

[armedbear-devel] "Inconsistent precedence graph" when calling print-object on java instance
by Alan Ruttenberg 09 May '10

09 May '10

This is the javadoc for the class: http://owlapi.sourceforge.net/javadoc/uk/ac/manchester/cs/owl/owlapi/OWLCla… Here is the errors. Suggestions: Catch errors in print-object and print anyways, with flag if you really want to signal error. -Alan Inconsistent precedence graph. [Condition of type SIMPLE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (ERROR "Inconsistent precedence graph.") 1: (MOP::TOPOLOGICAL-SORT (#<BUILT-IN-CLASS T> #<STANDARD-CLASS STANDARD-OBJECT {F2FBFF}> #<JAVA-CLASS {163B1C}> #<JAVA-CLASS {82B591}> #<JAVA-CLASS {5E632A}> #<JAVA-CLASS {C069F9}> ...) ((#<STANDARD-CLA.. 2: (MOP::STD-COMPUTE-CLASS-PRECEDENCE-LIST #<JAVA-CLASS {79BBDF}>) 3: (#<STANDARD-GENERIC-FUNCTION MOP::COMPUTE-CLASS-PRECEDENCE-LIST {B10995}> #<JAVA-CLASS {79BBDF}>) 4: (MOP::STD-FINALIZE-INHERITANCE #<JAVA-CLASS {79BBDF}>) 5: (#<STANDARD-GENERIC-FUNCTION MOP::FINALIZE-INHERITANCE {98068D}> #<JAVA-CLASS {79BBDF}>) 6: (#<FUNCTION {C1F62E}> #<JAVA-CLASS {79BBDF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (#<JAVA-CLASS {C069F9}> #<JAVA-CLASS {5E632A}> #<JAVA-CLASS {82B591}>) ...) 7: (APPLY #<FUNCTION {C1F62E}> #<JAVA-CLASS {79BBDF}> (:NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (# # #) :JAVA-CLASS #<java.lang.Class interface org.semanticweb.owlap.. 8: (#<FUNCTION {D182D6}> #<JAVA-CLASS {79BBDF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (#<JAVA-CLASS {C069F9}> #<JAVA-CLASS {5E632A}> #<JAVA-CLASS {82B591}>) ...) 9: (APPLY #<FUNCTION {D182D6}> (#<JAVA-CLASS {79BBDF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (# # #) :JAVA-CLASS ...)) 10: (#<STANDARD-GENERIC-FUNCTION INITIALIZE-INSTANCE {318C29}> #<JAVA-CLASS {79BBDF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (#<JAVA-CLASS {C069F9}> #<JAVA-CLASS {5.. 11: (APPLY #<STANDARD-GENERIC-FUNCTION INITIALIZE-INSTANCE {318C29}> #<JAVA-CLASS {79BBDF}> (:NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (# # #) :JAVA-CLASS #<java.lang... 12: (#<FUNCTION {E4B5A9}> #<STANDARD-CLASS JAVA-CLASS {67DCEF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (#<JAVA-CLASS {C069F9}> #<JAVA-CLASS {5E632A}> #<JAVA-CLASS {.. 13: (APPLY #<FUNCTION {E4B5A9}> (#<STANDARD-CLASS JAVA-CLASS {67DCEF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (# # #) :JAVA-CLASS ...)) 14: (#<STANDARD-GENERIC-FUNCTION MAKE-INSTANCE {216D6D}> #<STANDARD-CLASS JAVA-CLASS {67DCEF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| :DIRECT-SUPERCLASSES (#<JAVA-CLASS {C069F9}> #<JAVA.. 15: (APPLY #<STANDARD-GENERIC-FUNCTION MAKE-INSTANCE {216D6D}> #<STANDARD-CLASS JAVA-CLASS {67DCEF}> :NAME #:|org.semanticweb.owlapi.model.OWLClassExpression| (:DIRECT-SUPERCLASSES (# # #) :JAVA-CLASS #<j.. 16: (SYSTEM:ENSURE-CLASS #:|org.semanticweb.owlapi.model.OWLClassExpression| :METACLASS #<STANDARD-CLASS JAVA-CLASS {67DCEF}> :DIRECT-SUPERCLASSES (#<JAVA-CLASS {C069F9}> #<JAVA-CLASS {5E632A}> #<JAVA-CLA.. 17: (ENSURE-JAVA-CLASS #<java.lang.Class interface org.semanticweb.owlapi... {1D3D9D}>) 18: (ENSURE-JAVA-CLASS #<java.lang.Class class uk.ac.manchester.cs.owl.ow... {B8486F}>) 19: (PRINT-OBJECT #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #S(SYSTEM::STRING-OUTPUT-STREAM)) 20: (SYSTEM::OUTPUT-UGLY-OBJECT #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #S(SYSTEM::STRING-OUTPUT-STREAM)) 21: (SYSTEM::%PRINT-OBJECT #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #S(SYSTEM::STRING-OUTPUT-STREAM)) 22: (SYSTEM:OUTPUT-OBJECT #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #S(SYSTEM::STRING-OUTPUT-STREAM)) 23: (SYSTEM::OUTPUT-LIST (#<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ccdb.ucsd.edu/NDPO/1.0/N... {E1F.. 24: (SYSTEM::OUTPUT-UGLY-OBJECT (#<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ccdb.ucsd.edu/NDPO/1.0/N... 25: (SYSTEM::%PRINT-OBJECT (#<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ccdb.ucsd.edu/NDPO/1.0/N... {E.. 26: (SYSTEM:OUTPUT-OBJECT (#<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ccdb.ucsd.edu/NDPO/1.0/N... {E1.. 27: (PRIN1-TO-STRING (#<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ccdb.ucsd.edu/NDPO/1.0/N... {E1F4D8}.. 28: (SWANK::PRESENT-REPL-RESULTS ((#<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ontology.neuinfo.org/NIF... {9B8B79}> #<uk.ac.manchester.cs.owl.owlapi.OWLClassImpl < http://ccdb.ucsd.edu/NDPO/1.0/.. 29: (#<FUNCTION {68B350}>) 30: (SWANK::TRACK-PACKAGE #<FUNCTION {68B350}>) 31: (#<FUNCTION {D47FC3}>) 32: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #<FUNCTION {D47FC3}>) 33: (#<FUNCTION {101CC5}>) 34: (FUNCALL #<FUNCTION {101CC5}>) 35: (#<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {4616CA}> #<FUNCTION {101CC5}>) 36: (APPLY #<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {4616CA}> #<FUNCTION {101CC5}> NIL) 37: (SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS #<FUNCTION {101CC5}>) 38: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<FUNCTION {101CC5}>) 39: (SWANK::REPL-EVAL "(imports-declarations @) ") 40: (SWANK:LISTENER-EVAL "(imports-declarations @) ") 41: (SYSTEM::%EVAL (SWANK:LISTENER-EVAL "(imports-declarations @) ")) 42: (EVAL (SWANK:LISTENER-EVAL "(imports-declarations @) ")) 43: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(imports-declarations @) ") "COMMON-LISP-USER" 712) 44: (APPLY #<FUNCTION SWANK::EVAL-FOR-EMACS {825BB7}> ((SWANK:LISTENER-EVAL "(imports-declarations @) ") "COMMON-LISP-USER" 712)) 45: (SWANK::PROCESS-REQUESTS NIL) 46: (#<FUNCTION {D0F6AE}>) 47: (FUNCALL #<FUNCTION {D0F6AE}>) 48: ((FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK {E26AA1}> #<FUNCTION {D0F6AE}>) 49: (APPLY #<FUNCTION (FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) {F31E8A}> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK {E26AA1}> #<FUNCTION {D0F6AE}> NIL) 50: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK {E26AA1}> #<FUNCTION {D0F6AE}>) 51: (#<FUNCTION {5A3285}>) 52: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*STANDARD-INPUT* . #S(SLIME-INPUT-STREAM)) (*TRACE-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*ERROR-OUTPUT* . #S(SLIME-OUTPUT-STREA.. 53: (#<FUNCTION {5F32BE}>) 54: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {5F32BE}>) 55: (#<FUNCTION {FC7979}>) 56: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {FC7979}>) 57: (SWANK::CALL-WITH-CONNECTION #S(SWANK::CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0.... {8B2078}> :SOCKET-IO #<TWO-WAY-STREAM {DF7E}> :DEDICATED-OUTPUT NIL :USER-INPUT #S.. 58: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {50D4FE}>) 59: (#<FUNCTION {CF8D9B}>)

2 3

[armedbear-devel] enter debug repl when eval command line gets error?
by Alan Ruttenberg 08 May '10

08 May '10

Currently abcl quits if an error is signaled while processing a form in a --eval option. I can see that one might sometimes want this to happen - perhaps another switch then? -Alan

1 0

[armedbear-devel] passing adjustable strings to java
by Alan Ruttenberg 08 May '10

08 May '10

Looks like fill pointer isn't taken into account: (jcall "toString" (make-array 10 :element-type 'character :adjustable t :fill-pointer 3 :initial-contents "fooxxxxxxx")) -> "fooxxxxxxx" -Alan

1 1

Re: [armedbear-devel] [armedbear-cvs] r12620 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 07 May '10

07 May '10

Hi Mark, On Fri, Apr 16, 2010 at 3:41 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Fri Apr 16 09:41:21 2010 > New Revision: 12620 > > Log: > Use interpreted form in a FASL if compliation fails. Although I think this is a great fallback, it seems to be automatically selected right now. I'm affraid of the negative side effects of that scenario: people will not notice that their code wasn't compiled, but is now interpreted instead. The ultimate side effect could be that we don't get any reports anymore regarding brokenness of our compiler. In my eyes, there are 2 ways forward with this: 1) We undo this option; this leaves users at a loss when compilation fails; they'll need to use the entire file uncompiled. 2) We make the fallback a selectable restart; this way, compilation gets interrupted, the user is aware and we're much more likely to receive our feedback. But the user isn't restricted to using a fully interpreted file anymore. Quite possibly, you can read my preference through the lines already: I think option (2) is *really* nice. What's your opinion on the matter? Bye, Erik.

3 4

[armedbear-devel] Including ASDF 2 in the next ABCL release
by Faré 06 May '10

06 May '10

Dear ABCL developers, could you test for inclusion with your implementation the current release candidate of ASDF 2 (version 1.715 as of this writing)? http://common-lisp.net/project/asdf/ ASDF 2 is an evolution of ASDF that tries to be backwards compatible with previous releases and their many extensions, while at the same time improving the user experience in many important ways. I have worked hard towards reaching the current state, which I believe is now suitable for release. Could you please send us fixes for any glaring bugs, and otherwise include ASDF 2 in any alpha-testing release channel for users of your implementation? I think it's mostly ready, and I'd like to have it widely tested before the actual release, which I hope will happen this month of May 2010, hopefully without any code change (except maybe for some tweaks to enhance support for some Lisp implementations on some operating systems), and with slightly enhanced documentation (notably based on your feedback). I'm using ASDF 2 at ITA. Recent versions are already included in ECL and ABCL. Several hackers have tried building plenty of packages with it. While it's far from my ideal of perfection, and admittedly only a relatively small limited of previous code, I believe it's enough of an advance over the previous generation of ASDF that I'd like to get it out to the world. The code has been extensively cleaned up while preserving previous semantics everywhere that it was well-defined. Our testing has revealed no regressions from ASDF 1. What has changed since ASDF 1 is documented at the following page: http://common-lisp.net/project/asdf/asdf/FAQ.html Improvements include: * portably handle naming of files wrt directory, type, host/device, etc. * a builtin user-configurable output translation mechanism, superseding asdf-binary-locations and previous hacks in common-lisp-controller and cl-launch. * a user-configurable source registry system for finding systems (the old *central-registry* is still available). * improved portability to many implementations. * improved support for Windows (though we still lack implementation-dependent configuration support except on LispWorks). [NOTE: I couldn't parse this item. I juggled the sentence structure, but I still don't get it. What kind of configuration support is needed for Windows? What aspects of configuration that we have on other OSes is missing from Windows?] * many bug fixes * better documentation * the test suite, while still largely incomplete, covers more cases and is more robust across implementations. * substantial performance improvements when processing large systems with thousands of components. * API improvements: load-system, system-relative-pathname, etc. * a sensible versioning system for ASDF 2 itself. * ASDF can be now be upgraded in a running lisp image. Using this in-place upgrade, ASDF releases can be decoupled from implementation releases. * better support for various extensions used by ECL and ABCL, and also by POIU, ASDF-DEPENDENCY-GROVEL. Pitfalls include: * Output translations is enabled by default. This may surprise some users, most of them in pleasant way (we hope), a few of them in an unpleasant way. It is trivial to disable output translations. Simply put (ASDF:DISABLE-OUTPUT-TRANSLATIONS) in a lisp startup file. * Some systems in the large have been known not to play well with asdf output translations. They were easy to fix. The most likely issue is to have chaining of operations (e.g., a preprocessing before a load) where the INPUT-FILES of one operation are related to the OUTPUT-FILES of another. In this case many issues can be avoided by simply making the OUTPUT-FILES primary, and having later operations' INPUT-FILES be defined in terms of the OUTPUT-FILES of other operations instead of directly defining the INPUT-FILES. It is also easy to disable output translations or override its configuration. * ASDF 2 output translations do not work with ASDF-Binary-Locations. They replace A-B-L, and include a compatibility mode to emulate your previous A-B-L configuration. See ENABLE-ASDF-BINARY-LOCATIONS-COMPATIBILITY. But you shouldn't load ABL on top of ASDF 2. * A notable performance bug on SBCL (and possibly other implementations, too): the recursive search of configured paths in your source-registry with (DIRECTORY "/configured/path/**/*.asd") can waste a few seconds when initially searching for asd files (depending on your configuration). If it is essential for you to avoid this pause, you should override the default source-registry and only use non-recursive :DIRECTORY options (or shallow trees). * On Windows, when not using cygwin, only LispWorks has proper defaults for configuration pathnames. Other implementations make do. Patches welcome. * Windows support has not been sufficiently well tested. As to how to best include ASDF in your implementation, here is an excerpt from the FAQ section of our manual: 12.3.2 "I'm a Common Lisp implementation vendor. When and how should I upgrade ASDF?" Starting with current candidate releases of ASDF 2, it should always be a good time to upgrade to a recent version of ASDF. You may consult with the maintainer for which specific version they recommend, but the latest RELEASE should be correct. We trust you to thoroughly test it with your implementation before you release it. If there are any issues with the current release, it's a bug that you should report upstream and that we will fix ASAP. In order to report bugs, please use the launchpad bug tracker. Information about launchpad is contained in the manual. As to how to include ASDF, we recommend the following: * If ASDF isn't installed yet, then (require :asdf) should load the version of ASDF that is bundled with your system. You may have it load some other version configured by the user, if you allow such configuration. * If your system provides a mechanism to hook into CL:REQUIRE, then it would be nice to add ASDF to this hook the same way that SBCL, CCL and ABCL do. * You may, like SBCL, have ASDF be implicitly used to require systems that are bundled with your Lisp distribution. If you do have a few magic systems that come with your implementation in a precompiled way such that one should only use the binary version that goes with your distribution, like SBCL does, then you should add them in the beginning of wrapping-source-registry. Please consult with the ASDF maintainers about that. * If you have magic systems as above, then we explicitly ask you to NOT distribute asdf.asd as part of those magic systems. You should still include the file asdf.lisp in your source distribution and precompile it in your binary distribution, but asdf.asd if included at all, should be secluded from the magic systems, in a separate file hierarchy, or you may otherwise rename the system and its file to e.g. asdf-ecl and asdf-ecl.asd, or sb-asdf and sb-asdf.asd. If you make asdf.asd a magic system, then users will no longer be able to upgrade ASDF using ASDF itself. It is helpful to be able to do this in order for users to be able to use an ASDF version of their own choosing that they maintain independently from your Lisp distribution. * If you do not have any such magic systems, or have other non-magic systems that you want to bundle with your implementation, then you may add them to the default-source-registry, and you are welcome to include asdf.asd amongst them. * Please send us upstream any patches you make to ASDF itself, so we can merge them back in for the benefit of your users when they upgrade to the upstream version. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. THAT'S relativity. — Albert Einstein

2 1

[armedbear-devel] debug assert considered bad for health
by Alan Ruttenberg 06 May '10

06 May '10

Blood pressure, specifically. What does one do with this: ABCL Debug.assertTrue() assertion failed! java.lang.Error: ABCL Debug.assertTrue() assertion failed! at org.armedbear.lisp.Debug.assertTrue(Debug.java:46) at org.armedbear.lisp.Package.shadowingImport(Package.java:601) at org.armedbear.lisp.PackageFunctions$9.execute(PackageFunctions.java:190) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) No message - go hunt in source code. Yuck. -Alan

5 11

Re: [armedbear-devel] debug assert considered bad for health
by Ville Voutilainen 06 May '10

06 May '10

> On 6 May 2010 20:18, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: >> With the above example, you could show _how_ the boolean is computed. >> That assert would print stuff like >> "Assertion failed at foobar.java:123: ((5 + 6 + 8) == 18)" > Yes, but I think what's needed is more like: > Debug.fail("Expected pathname host of '"+ p + "' to be a > string, symbol, or cons"); Yes, that would be helpful. We could start with that at least, and pipe-dream about macros later. :)

1 0

[armedbear-devel] Moving toward a release
by Erik Huelsmann 06 May '10

06 May '10

Just writing a note that it's time to move toward a release. Over the past days a number of fixes have been committed, especially with respect to pathname code, but in other areas as well. If you have time to excersize some testing, please do and report any failure (or succes!). Before branching the 0.20.x branch, I hope to be able to see 2 additional changes: * finishing METACLASS tests - this is my action item, but is more or less blocked by the next item * ABCL being able to run its own tests - on Windows, this is currently broken by one of the Pathname changes; if you have time to contribute (and hence take some weight off Mark's shoulders) please do! Once again, any feedback appreciated. Bye, Erik.

3 5

[armedbear-devel] Idea to fix ticket 79: identical uninterned symbols coalesced in fasl
by Erik Huelsmann 02 May '10

02 May '10

Ticket 79 is one of the "correctness" category: we do something which we shouldn't (although it hasn't been seen in real life yet). When we compile a file containing 2 *different* -yet similarly named - uninterned symbols, they are coalesced into the same object when reading that fasl. The above behaviour is a consequence of the design choice: the same uninterned symbol may occur in multiple places in the sources, meaning that multiple CompiledClosures may need to refer to the same symbol in their constructor. ABCL solved this problem by interning all unintered symbols into the same anonymous package. When that happens, all occurrances of the same uninterned symbols are coalesced into the same object. However, the same happens to all equally named uninterned symbols which are *not* the same symbol. Here's my idea to resolve this situation, in a simple step-by-step representation: 0. Install a dispatch macro function (in some unused dispatch macro character); something like #n# 1. Adjust DUMP-FORM to generate the dispatch output for uninterned symbols 1. Create all uninterned symbols at the start of the FASL (filling a table with them) 2. Let the reader resolve the uninterned symbols by looking up in the table This approach has the nice side-effect that we can eliminate the need for the anonymous package - although we will need to maintain a table. It will resolve the issues we currently have with the coalesced symbols. It uses standard Lisp infrastructure; no heavy code changes required. Comments? Bye, Erik.

4 9

[armedbear-devel] Ticket #93: (VALUES) interpreted as NIL by the reader
by Erik Huelsmann 01 May '10

01 May '10

Hi James, Working towards an 0.20 release, I had a look at ticket 93 which was filed by you (from the wording I concluded that it must have been a regression). Although it didn't turn out to be a regression: this issue must have been in our sources for a looong time, it turned out to be easy to fix: r12645 fixes this bug and its cousin in read-delimited-list, which caused the same error. Anyway, the issue you reported has been fixed. Thanks for your report! Bye, Erik.

1 0

[armedbear-devel] Patches for ABCL against asdf-1.641
by Mark Evenson 01 May '10

01 May '10

Attached are patches in 'abcl-asdf.patch' to get asdf-1.641 to work against ABCL for the run-tests.sh. Unfortunately, you will need to build [ABCL from trunk][1] using at least svn r12550, because I had to patch ABCL to work with ASDF. And you'll need to apply the 'abcl-translate-pathname.patch'. [1]: svn://common-lisp.net/project/armedbear/svn/trunk/abcl Notes: 1. The fugliness of the conditional around ASDF:GET-UID works around a bug in the ABCL compiler. We are in the process of [analyzing the error][2]. [2]: http://trac.common-lisp.net/armedbear/ticket/89 2. There is some undiagnosed problem in translating the binary location for the new ASDF2 "~/.cache" conventions, as ABCL seems to "collapses" everything into a single directory. Somehow, the default *output-translations* have a "/**/**/*.*" where there should be "/**/*.*". I'm not sure if this is a problem in "abcl-translate-pathname.patch", which is why I didn't apply this to ABCL trunk. 3. ASDF's run-tests.sh seems to ignore the "flags" setting, which seems to be broken on the ASDF side. 4. The changes for ASDF look quite interesting. However I would advocate that you should make ASDF2 work *exactly* like ASDF1 out of the box, meaning you shouldn't do any of the subsumed ASDF-BINARY-LOCATIONS stuff without being asked to by configuration. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 28

[armedbear-devel] Running "ant test.abcl": Pathname error
by Erik Huelsmann 01 May '10

01 May '10

Hi Mark, Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows: [java] Error while trying to load definition for system abcl from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log. While I'm not asking you to fix it, could you indicate where I should start looking? Thanks in advance! Bye, Erik.

3 5

[armedbear-devel] debug stack overflow? (to track down regression)
by Alan Ruttenberg 01 May '10

01 May '10

Hi, This (a call in my LSW system) used to work for me and is now failing in trunk. However I don't seem to have anything to go on in the stack trace. Any suggestions? Thanks, Alan CL-USER(2): (load-ontology "~/repos/obi/ontology/obi.owl") #<THREAD "interpreter" {FE90EF}>: Debugger invoked on condition of type STORAGE-CONDITION Stack overflow. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (APPLY #<FUNCTION SYSTEM:BACKTRACE {55C752}> NIL) 2: (SYSTEM:BACKTRACE) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {1985DA}>) 4: org.armedbear.lisp.Lisp$1.execute(Lisp.java:288) 5: org.armedbear.lisp.Symbol.execute(Symbol.java:776) 6: org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92)

4 8

[armedbear-devel] READ-LINE inlining fixed, but READ-LINE shouldn't be inlined?
by Erik Huelsmann 30 Apr '10

30 Apr '10

Ticket 89 was about a class verification error which is now fixed, I'm wondering whether we should be inlining calls to Stream.readLine() at all: it seems like this would be incompatible with Gray streams support, after we complete it. Regards, Erik.

1 0

[armedbear-devel] Stack issues fixed: what to do with their workaround?
by Erik Huelsmann 30 Apr '10

30 Apr '10

Hi Mark, A while ago, it looked we had a few regressions in the compiler regarding stack consistency: ticket #89 and the issue reported by Alan (PROGV inside AND). The former you ran into when trying to get ASDF2 running on ABCL. As it turned out, these were both were not regressions, but very old bugs. Both are fixed too. For ticket 89, you implemented a work-around, where the compiler would ask the user to replace the compiled form with an interpreted version. Other than this question, are there any side effects of your change? Anything we might want to consider reverting before our next release? Regards, Erik.

1 0

Re: [armedbear-devel] [armedbear] #89: compiler stack inconsistency
by Mark Evenson 27 Apr '10

27 Apr '10

I tracked this back to before the split of 'abcl' from 'j' observing the error through [rev0 of the copy of abcl][1] I keep in Mercurial], so can confirm the lack of regression back to 2008-12-20. 0 e7def953d497 2008-12-20 20:35 +0100 ehuelsmann [svn r11457] Create separate project directories for ABCL and J. [1]: http://trac.common-lisp.net/armedbear/changeset/11457/trunk/abcl -- "No, this is not a disentanglement from, but a progressive /knotting-into/ […]"

1 0

[armedbear-devel] encoding bug in Stream.readPreservingWhitespace (classpath)
by Eric Marsden 25 Apr '10

25 Apr '10

Hi, Attempting to run ABCL with jamvm (which uses the classpath libraires), I get ,---- | Armed Bear Common Lisp 0.20.0-dev | Java 1.5.0 GNU Classpath | JamVM | Low-level initialization completed in 0.371 seconds. | Exception in thread "interpreter" java.lang.IllegalStateException | at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:163) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:168) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:156) | at org.armedbear.lisp.Stream._unreadChar(Stream.java:1708) | at org.armedbear.lisp.Stream._readToken(Stream.java:1144) | at org.armedbear.lisp.Stream.readToken(Stream.java:1009) | at org.armedbear.lisp.Stream.processChar(Stream.java:508) | at org.armedbear.lisp.Stream.readList(Stream.java:660) | at org.armedbear.lisp.LispReader$3.execute(LispReader.java:88) | at org.armedbear.lisp.Stream.processChar(Stream.java:505) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:484) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:492) | at org.armedbear.lisp.Stream.read(Stream.java:430) | at org.armedbear.lisp.Load.loadStream(Load.java:556) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:522) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:412) | at org.armedbear.lisp.Load.loadSystemFile(Load.java:337) | at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:159) | at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:93) | at org.armedbear.lisp.Main$1.run(Main.java:48) | at java.lang.Thread.run(Thread.java:745) `---- I see in org.armedbear.lisp.Stream.read() a sequence int n = _readChar(); if (n >= 0) { char c = (char) n; // ### BUG: Codepoint conversion Readtable rt = rta.rt(thread); if (!rt.isWhitespace(c)) _unreadChar(c); } which seems likely to be related to this problem. If I print the offending character in DecodingReader.unread() it looks like a #\space. Any suggestions on how to proceed? -- Eric Marsden

2 3

[armedbear-devel] eql for java objects
by Alan Ruttenberg 25 Apr '10

25 Apr '10

(eql (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle") (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle")) -> NIL I think it should be eql, probably eq. I know they are equal. The documentation for eq says: Returns true if its arguments are the same, identical object; otherwise, returns false. They are and they are not. That they are not is only a quirk of the implementation. eql adds equality for characters and numbers I'd argue that was done because of uncertainly over boxing in different implementations and not wanting to fall back to a more expensive equal call. Seems that java objects are an equivalent case. Where this matters is that case and friends use eql for comparison. One ought to be able to write a standard case statement that switches off of an enum defined java, but one can't at the moment. That's all, Alan

6 18

[armedbear-devel] Fwd: threads, join, clos
by Erik Huelsmann 25 Apr '10

25 Apr '10

Sent mail to David personally; meant to include the list. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Sat, Apr 24, 2010 at 9:37 AM Subject: Re: [armedbear-devel] threads, join, clos To: David Kirkman <dkirkman(a)ucsd.edu> Hi David, On Sat, Apr 24, 2010 at 6:52 AM, David Kirkman <dkirkman(a)ucsd.edu> wrote: > Hi, > > Is there an equivalent of java.lang.Thread.join() on the lisp side of > things? I looked around in LispThread.java and threads.lisp, but I > don't see anything obvious. I'd like to be able to write something > like: > > (let ((threads (loop for i from 0 to 5 > collect > (make-thread #'(lambda() > (format t "hey~%")))))) > (mapc #'thread-join threads) > (format t "is for horses~%")) > > I've attached a patch that implements this version of thread-join. It > implements java semantics, this thread-join always returns nil. I guess we didn't join our threads until now :-) Thanks for taking the time to code it up. I have one question regarding the patch though: How would the caller know the difference between the scenario where an Interrupted exception occurs and the one where the thread is really joined? Should we use the return value NIL to signal "not joined" and T for "joined"? Bye, Erik.

3 8

[armedbear-devel] loading stale fasls
by David Kirkman 25 Apr '10

25 Apr '10

While trying to come up with reproducible thread errors this morning, I ran into trouble with abcl loading stale fasls. e.g., If I change a lisp file, and don't recompile it (load "foo") will load "foo.abcl" and not the more recent "foo.lisp". I think that Load.java (line 91) is not doing (what I think) it's supposed to: if (abclLastModified > lispLastModified) { return lispPathname; } else { return abclPathname; } I think we need to switcheroo lispPathname and abclPathname. At least that makes abcl behave the way that I expect! If that's the way it's supposed to work, here is a patch. -david

2 1

[armedbear-devel] threads, join, clos
by David Kirkman 23 Apr '10

23 Apr '10

Hi, Is there an equivalent of java.lang.Thread.join() on the lisp side of things? I looked around in LispThread.java and threads.lisp, but I don't see anything obvious. I'd like to be able to write something like: (let ((threads (loop for i from 0 to 5 collect (make-thread #'(lambda() (format t "hey~%")))))) (mapc #'thread-join threads) (format t "is for horses~%")) I've attached a patch that implements this version of thread-join. It implements java semantics, this thread-join always returns nil. I guess java doesn't really have a way to return arbitrary values, but we easily do! I was thinking about hacking it up a bit more so that thread-join would return the value of the function passed to make-thread, e.g. so that (thread-join (make-thread #'(lambda () 1))) would return 1. But then it occurred to me that this functionality is probably already in there under a different name. So, how do you guys join your threads? Cheers, -david k. P.S. Are there any known thread safety issues with CLOS? I've been getting some weird MOP errors that I made go away by redefining slot-value such that it has to acquire a global lock before it can do anything. I assume that the problem is in my code: but the threads that are executing when I get the failures share no code (or variables), and every time the errors pop up slot-value is on the callstack someplace.

1 0

[armedbear-devel] ELW 2010 deadline extension -- April 25th
by Didier Verna 21 Apr '10

21 Apr '10

+------------------------------------------------------------+ | CALL FOR PAPERS | | 7th European Lisp Workshop | | June 22 2010, Maribor, Slovenia, co-located with ECOOP | +------------------------------------------------------------+ Important Dates =============== Submission deadline: April 25, 2010 ** EXTENDED ** Notification of acceptance: May 05, 2010 ECOOP early registration deadline: May 10, 2010 7th European Lisp Workshop: June 22, 2010 Please note that registration must be done with ECOOP itself. For more information visit http://www.european-lisp-workshop.org Contact: Didier Verna, didier(a)lrde.epita.fr Invited Speaker =============== Manuel Serrano (INRIA, France) http://www-sop.inria.fr/members/Manuel.Serrano/ Overview ======== "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp, one of the eldest computer languages still in use today, is gaining momentum again. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch, making it the ideal candidate for writing Domain Specific Languages. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and remains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. This workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit contributions that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components: there will be formal talks, and interactive turorial/demo/coding sessions. Papers ====== Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. Suggested topics include (but are not limited to): - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Protocol meta-programming and libraries - New language features and abstractions - Software evolution - Development aids - Persistent systems - Dynamic optimization - Implementation techniques - Hardware Support - Efficiency, distribution and parallel programming - Educational approaches and perspectives - Experience reports and case studies Interactive Tutorial/Demo/Coding Sessions ========================================= Additionally, we invite less formal talks in the form of interactive tutorial/demo/coding sessions. The purpose of these sessions is both to demonstrate and receive feedback on any interesting Lisp system, either stable or under development. Being less formal than technical paper presentations, these sessions are expected to be highly interactive. Submission Guidelines ===================== Potential contributors are encouraged to submit: - a long paper (around 10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes, - a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future, - a proposal for an interactive tutorial/demo/coding session (1-2 pages) describing the involved library or application, and the subject of the session. Papers (both long and short) should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms (see below). Authors will later be required to sign an ACM copyright form, as the workshop proceedings will be published in the ACM Digital Library. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=elw2010 Organizers ========== Didier Verna, EPITA Research and Development Laboratory, Paris Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel Robert Strandh, LaBRI, University of Bordeaux 1, France Christophe Rhodes, Goldsmiths College, University of London -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22

1 0

[armedbear-devel] Expecting to find integer on stack
by Alan Ruttenberg 18 Apr '10

18 Apr '10

Not even sure where to begin to try to help you with this... This is with a just checked out abcl. -Alan Exception in thread "interpreter" java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.armedbear.lisp.Lisp.makeCompiledFunctionFromClass(Lisp.java:1286) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1347) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1340) at org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:224) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_7.execute(compile-file.lisp:71) at org.armedbear.lisp.LispThread.execute(LispThread.java:550) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_5.execute(compile-file.lisp:71) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_10.execute(compile-file.lisp:103) at org.armedbear.lisp.Symbol.execute(Symbol.java:799) at org.armedbear.lisp.LispThread.execute(LispThread.java:600) at org.armedbear.lisp.compile_file_40.execute(compile-file.lisp:486) at org.armedbear.lisp.LispThread.execute(LispThread.java:550) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_37.execute(compile-file.lisp:486) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8680) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.compile_file_35.execute(compile-file.lisp:486) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:160) at org.armedbear.lisp.LispThread.execute(LispThread.java:600) at org.armedbear.lisp.Lisp.funcall(Lisp.java:170) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2829) at org.armedbear.lisp.Primitive.execute(Primitive.java:158) at org.armedbear.lisp.Symbol.execute(Symbol.java:825) at org.armedbear.lisp.LispThread.execute(LispThread.java:636) at org.armedbear.lisp.asdf_312.execute(asdf.lisp:1542) at org.armedbear.lisp.clos_178.execute(clos.lisp:1484) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.clos_167.execute(clos.lisp:1418) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.clos_157.execute(clos.lisp:1252) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.asdf_327.execute(asdf.lisp:1600) at org.armedbear.lisp.clos_177.execute(clos.lisp:1484) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.clos_167.execute(clos.lisp:1418) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.clos_157.execute(clos.lisp:1252) at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:787) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.asdf_366.execute(asdf.lisp:1685) at org.armedbear.lisp.compiler_pass2_579.execute(compiler-pass2.lisp:8680) at org.armedbear.lisp.LispThread.execute(LispThread.java:550) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8680) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:566) at org.armedbear.lisp.asdf_365.execute(asdf.lisp:1685) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.Lisp.funcall(Lisp.java:168) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2829) at org.armedbear.lisp.Primitive.execute(Primitive.java:143) at org.armedbear.lisp.Symbol.execute(Symbol.java:811) at org.armedbear.lisp.LispThread.execute(LispThread.java:618) at org.armedbear.lisp.asdf_377.execute(asdf.lisp:1725) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:583) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:504) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:529) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:266) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:98) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:613) Process inferior-lisp finished

2 1

[armedbear-devel] Generating class files instead of functions-as-class-files
by Erik Huelsmann 18 Apr '10

18 Apr '10

Over the past months, I've been thinking about changing the way we generate our class files. Currently all of our class file generation is centered around producing a execute() method, with a constructor to support object initialization. This scheme seriously limits our flexibility. Imagine a function of 2 arguments, one required and one optional. Currently, we require a call to fastProcessArgs(), where we could have done with a class which implements the single as well as the two-argument execute() methods. Along the same lines, I'm looking to clean up our constructors: In my ideal world all the static field initializers will be moved to the class constructor <clinit>() which isn't called more than exactly once. To support this type of output, I started jvm-class-file.lisp. It's a file which centers around generation of true class files (with arbitrary numbers of methods), instead of "functions-as-classes" which are modelled using exactly 2 methods. The jvm-class-file.lisp file is local to my working copy for now, although I did send a version to Alessio some time ago. Apart from the flexibility this would achieve, I think I have another benefit: it would allow catching the full class file before it's a serialized. The resulting in-memory class file representation could be analysed, for example to find the stack inconsistencies we're looking (but not yet finding). There are serveral reasons to send this mail: 1. To keep you all in the loop 2. To see about your comments regarding the above direction 3. To see if there's anybody here who wants to help out As a general direction forward, I was thinking to start a branch so that there's some place to store my currently-private jvm-class-file.lisp. I'll have to create a BRANCH-README to document what the branch is about, what the status is and what is left to be done. The first step forward, I'd like to do on the trunk however: a first separation of code generation and class file writing. That would allow me to write a GUI tool for inspecting the resulting class files from a single COMPILE call and hence creating a tool which should help finding our "stack inconsistency" problems. Comments? Helpers? Bye, Erik.

1 0

[armedbear-devel] Stack inconsistency now uses interpreted form in FASL
by Mark Evenson 16 Apr '10

16 Apr '10

Since we seem to be up against a bit of a wall in [analysis of the stack inconsistencies in bytecode for some instances of HANDLER-BIND][1], I've [changed the compiler to fall back to using hte interpreted form][2] if the stack verification fails. To do this, I've introduced INTERNAL-COMPILER-ERROR which when signaled at any point in the compilation pass, causes PROCESS-TOPLEVEL-FORM to fall back to using the interpreted form. In its current form, the faulty bytecode is still included in the packed FASL which as a further optimization should not be included. [1]: http://trac.common-lisp.net/armedbear/ticket/89 [2]: http://trac.common-lisp.net/armedbear/changeset/12620 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Consolidating copy/paste code
by Erik Huelsmann 15 Apr '10

15 Apr '10

Yesterday Ville and I dedicated some time to the consolidation of copy/paste code and unnecessary virtual methods. There's quite a bit of copy/paste code in ABCL. A good example are LispReader, FaslReader and Stream.java. FaslReader had a number of functions which were *exactly* equal to functions in LispReader. A number of functions contained the same logic, but used different readtables. The same applies to functions in Stream.java where functions were declared twice - once with a faslRead* prefix and once with a read* prefix. The solution is - in this case, of course - to abstract the code from the readtable to be used. In other places the reasons for copy/pasting will be different. If you're lurking at this list, thinking of contributing but you don't know how: this is a much appreciated way to help out! We try to reduce the number of (copy/pasted) lines of code in ABCL; not at the expense of functionality, but as a way to ensure consistent maintenance in the future. Still no idea where to start? I left some remaining work in LispReader.java and FaslReader.java where there is more copy/pasted code. My idea is that the common bits get moved to Stream.java, using the ReadtableAccessor class to abstract from the readtables themselves. Looking forward to your contributions! Bye, Erik.

7 17

[armedbear-devel] ASDF2 in trunk
by Mark Evenson 15 Apr '10

15 Apr '10

I've committed a snapshot of ASDF2 [in trunk][1], including [a copy of the texinfo manual][2]. [1]: http://trac.common-lisp.net/armedbear/changeset/12618 [2]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/asdf/asdf.texi… A potential gotcha for moving from ASDF: there is a translation mechanism for FASL locations in place by default (this code supersedes the ASDF-BINARY-LOCATIONS addon), so your FASLs end up in a central FASL cache by default. This output mechanism is *very* configurable, see the manual for examples. To totally disable output translations, one can simply eval (asdf:disable-output-translations) after loading ASDF2. With output translations, one may have the problem with code that wrangles *LOAD-TRUENAME* or *LOAD-PATHNAME* to get the source directory. The official ASDF2 recommendation is to rewrite your code to use ASDF:SYSTEM-RELATIVE-PATHNAME, possibly utilizing the presence of :ASDF2 in *FEATURES* to conditionalize old code. Examples of such definitions can be found in my patch as I adapted our ASDF definitions for test code. We still have to solve the problem arising from the possibility of not having a writable filesystem in an applet or servlet context, but that problem was present with the old ASDF as well. Anyone with problems in using ASDF2 please let me know. I have tested it quite a bit in the past months finding it generally much improved. The ASDF group is quite active in fixing things, so please be vocal and we should be able get you to a stable state. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] URL pathname code in trunk
by Mark Evenson 15 Apr '10

15 Apr '10

I've pushed the code for handling URLs in pathnames to the trunk in commits r12605-r12616. The [design documents what I was aiming for][1], namely allowing resources addressed by URL (i.e. a URI with a network authority) to be used as Lisp pathnames. I expect that this will work for anything that 'java.net.URL' works with, although I have yet to "shake down" the OSGi code using the "bundle:" scheme. After I push ASDF2 to the trunk, this will be the goal my next effort. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathnam… Incomplete at this point: 1. The implementation is lacking proper URI/URL escaping. I intend to not have anything automagically happen, but rather provide functions for the user to encode/decode pathnames to string forms. It is a matter of writing (stealing?) decent URI escaping code at this point. Noteworthy changes: 1. JAR-PATHNAME and URL-PATHNAME are now subtypes of PATHNAME. 2. Both JAR-PATHNME and URL-PATHNAME are now valid arguments to OPEN with :DIRECTION :INPUT. 3. QUERY and FRAGMENTS are stored in the HOST plist. Not my favorite part of the design, but better than any other choice I could come up with. Users are expected to use the DEFSETF PATHNAME-URL-QUERY and PATHNAME-URL-FRAGEMENT functions to manipulate these quantities. 4. Fixed some fugliness with *LOAD-TRUENAME* and *LOAD-PATHNAME* with jar pathnames returning more of the expected values. 5. Jar pathnames use of a String to denote URLs has been replaced by the use of proper URL pathnames. If someone has code that I have brooken because it depended on the internal structure of jar pathnames from 0.19, shout out, and we'll figure out something. Hopefully, everyone was using namestrings anwyays, so everything should "just work". Feedback, bug reports, success stories welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Fwd: Consolidating copy/paste code
by Erik Huelsmann 13 Apr '10

13 Apr '10

Forgot to include the list. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Tue, Apr 13, 2010 at 10:00 AM Subject: Re: [armedbear-devel] Consolidating copy/paste code To: David Kirkman <dkirkman(a)ucsd.edu> Hi David, Let me start by thanking you for your contribution! Welcome! On Mon, Apr 12, 2010 at 2:59 AM, David Kirkman <dkirkman(a)ucsd.edu> wrote: > OK, Sounds like a nice afternoon project. Here's a patch that does what I > think you're asking in FaslReader and LispReader. > > But I ran into some trouble testing the changes. Following the > instructions at > http://common-lisp.net/project/armedbear/contributing.shtml > I end up with an OutOfMemoryError when running both test.ansi.interpreted > and test.ansi.compiled > > Is there an enviroment variable that needs to be set to get these > to run? I can make it work by putting <jvmarg value="-Xmx500M"> > lines in build.xml, which I've attached as a second patch. > > When I ran the tests after I made the change, I got one additional error > when running test.ansi.interpreted: PRINT.BACKQUOTE.RANDOM.14. I've also > attached the error. I can't figure it out. I eventually decided that a > 'random' test might give a different result if I run it again ... so I ran it > again (and again and again) ... and the error did not happen again. So I now > suspect that my patch does not introduce any new errors, but that > PRINT.BACKQUOTE.RANDOM.14 fails randomly from time to time. I saw Mark addressed the memory problems you had. That's good. I experience the PRINT.BACKQUOTE.RANDOM and some other random printing issues too. This is really something to look into. However, well, they're random... Unfortunately yesterday evening was very hectic, so I didn't get to have a look at your changes. I'll look at them at my earliest convenience; no later than the end of this week, hopefully tonight. Thanks again for your contribution! Bye, Erik.

1 0

[armedbear-devel] abcl hangs when building cl-pdf component pdf-geom.lisp
by james anderson 12 Apr '10

12 Apr '10

good afternoon; attached below is the transcript of an aborted build of cl-pdf. abcl hangs when it attempts to compile pdf-geom.lisp. is the cause clear from the stack? asdf@ip-10-251-122-82:/development/source/library$ sh ../metadata/com: 8000/fractalconcept/www/cl-pdf/build-system.sh abcl cd: 17: can't cd to /ebs/source/metadata/com\:8000/fractalconcept/www/ cl-pdf/ Armed Bear Common Lisp 0.19.1 Java 1.6.0_0 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 1.55 seconds. Startup completed in 3.804 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading #P"jar:file:/development/downloads/abcl- bin-0.19.1/abcl.jar!/org/armedbear/lisp/delete.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/delete.abcl" (0.048 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.143 seconds) ;Build root: #P"/ebs/source/metadata/lib/build-init.lisp". ;Incorporating asdf anew from #P"/ebs/source/metadata/lib/asdf.lisp". ; Loading #P"/ebs/source/metadata/lib/asdf.abcl" ... ; Loaded #P"/ebs/source/metadata/lib/asdf.abcl" (2.396 seconds) T CL-USER(2): ;For project :CL-PDF-PARSER, using ASDF registry (#P"/ebs/ source/upload/com:8000/fractalconcept/www/cl-pdf/" #P"/ebs/source/ library/asdf-registry/") ... ;System definition purged: :CL-PDF-PARSER... ;Load system :CL-PDF-PARSER... ; loading system definition from /ebs/source/upload/com:8000/ fractalconcept/www/cl-pdf/cl-pdf-parser.asd into #<PACKAGE "ASDF0"> ; Loading #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf-parser.asd" ... ; registering #<SYSTEM :CL-PDF-PARSER {194566D}> as CL-PDF-PARSER ; Loaded #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf-parser.asd" (0.216 seconds) ; loading system definition from /ebs/source/upload/com:8000/ fractalconcept/www/cl-pdf/cl-pdf.asd into #<PACKAGE "ASDF0"> ; Loading #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf.asd" ... ; registering #<SYSTEM :CL-PDF {D38C3D}> as CL-PDF ; Loaded #P"/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/cl- pdf.asd" (0.037 seconds) ; loading system definition from /ebs/source/library/asdf-registry/ iterate.asd into #<PACKAGE "ASDF0"> ; Loading #P"/ebs/source/library/net/common-lisp/iterate/ iterate.asd" ... ; registering #<SYSTEM :ITERATE {148B272}> as ITERATE ; registering #<SYSTEM :ITERATE-PG {1BB6A69}> as ITERATE-PG ; registering #<SYSTEM :ITERATE-TESTS {28DF48}> as ITERATE-TESTS ; Loaded #P"/ebs/source/library/net/common-lisp/iterate/ iterate.asd" (0.206 seconds) WARNING: No architecture feature found in ((X86-64 AMD64 X86_64 X8664- TARGET) (X86 I686 I586 PENTIUM3 I486 I386 PC386 IAPX386 X8632-TARGET PENTIUM4) HPPA64 HPPA PPC64 (PPC32 PPC POWERPC) SPARC64 SPARC). WARNING: No architecture feature found in ((X86-64 AMD64 X86_64 X8664- TARGET) (X86 I686 I586 PENTIUM3 I486 I386 PC386 IAPX386 X8632-TARGET PENTIUM4) HPPA64 HPPA PPC64 (PPC32 PPC POWERPC) SPARC64 SPARC). ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/loop.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/loop.abcl" (0.924 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-types.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-types.abcl" (0.146 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-error.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-error.abcl" (0.001 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-functions.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-functions.abcl" (0.021 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-symbols.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/known-symbols.abcl" (0.595 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/dump-form.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/dump-form.abcl" (0.001 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/opcodes.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/opcodes.abcl" (0.059 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.148 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass1.abcl" ... ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.022 seconds) ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass1.abcl" (0.194 seconds) ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass2.abcl" ... ; Loading #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" ... ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/java.abcl" (0.055 seconds) ; Loaded #P"jar:file:/development/downloads/abcl-bin-0.19.1/ abcl.jar!/org/armedbear/lisp/compiler-pass2.abcl" (1.221 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/package.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/ package.abcl" (0.001 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/iterate.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/library/net/common-lisp/iterate/ iterate.abcl" (0.632 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ defpackage.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ defpackage.abcl" (0.001 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/x11- colors.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/x11- colors.abcl" (0.784 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ encodings.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ encodings.abcl" (2.371 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ config.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ config.abcl" (0.006 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/font- metrics.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/font- metrics.abcl" (2.652 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/t1- font.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/t1- font.abcl" (0.527 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ font.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ font.abcl" (15.887 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ pdf.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/ pdf.abcl" (3.353 seconds) ; Loading #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/pdf- base.abcl" ... ; Loaded #P"/home/asdf/.cache/common-lisp/armedbear-0.19.1-linux- unknown/ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/pdf- base.abcl" (0.464 seconds) ; Compiling /ebs/source/upload/com:8000/fractalconcept/www/cl-pdf/pdf- geom.lisp ... ; (IN-PACKAGE #:PDF) ^\Quit asdf@ip-10-251-122-82:/development/source/library$ 2010-04-12 11:44:59 Full thread dump OpenJDK Client VM (14.0-b16 mixed mode, sharing): "DestroyJavaVM" prio=10 tid=0x08e7e000 nid=0x22f2 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "interpreter" prio=10 tid=0x08f2d000 nid=0x22fa runnable [0xb4413000] java.lang.Thread.State: RUNNABLE at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77) at sun.nio.cs.UTF_8$Decoder.xflow(UTF_8.java:183) at sun.nio.cs.UTF_8$Decoder.decodeArrayLoop(UTF_8.java:242) at sun.nio.cs.UTF_8$Decoder.decodeLoop(UTF_8.java:324) at java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:561) at org.armedbear.lisp.util.RandomAccessCharacterFile.read (RandomAccessCharacterFile.java:375) at org.armedbear.lisp.util.RandomAccessCharacterFile $RandomAccessReader.read(RandomAccessCharacterFile.java:224) at org.armedbear.lisp.util.RandomAccessCharacterFile $RandomAccessReader.read(RandomAccessCharacterFile.java:190) at org.armedbear.lisp.Stream._readChar(Stream.java:1684) at org.armedbear.lisp.LispReader$1.execute(LispReader.java:52) at org.armedbear.lisp.Stream.processChar(Stream.java:529) at org.armedbear.lisp.Stream.readPreservingWhitespace (Stream.java:449) at org.armedbear.lisp.Stream.readPreservingWhitespace (Stream.java:457) at org.armedbear.lisp.Stream.read(Stream.java:396) at org.armedbear.lisp.Stream$14.execute(Stream.java:2332) at org.armedbear.lisp.Symbol.execute(Symbol.java:798) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.compile_file_35.execute(compile- file.lisp:469) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.compile_file_32.execute(compile- file.lisp:469) at org.armedbear.lisp.compiler_pass2_578.execute(compiler- pass2.lisp:8691) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.compile_file_30.execute(compile- file.lisp:469) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:124) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:160) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.Lisp.funcall(Lisp.java:170) at org.armedbear.lisp.Primitives$pf_apply.execute (Primitives.java:2829) at org.armedbear.lisp.Primitive.execute(Primitive.java:158) at org.armedbear.lisp.Symbol.execute(Symbol.java:824) at org.armedbear.lisp.LispThread.execute(LispThread.java:632) at org.armedbear.lisp.asdf_303.execute(asdf.lisp:1503) at org.armedbear.lisp.clos_153.execute(clos.lisp:1437) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.clos_142.execute(clos.lisp:1371) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.clos_132.execute(clos.lisp:1205) at org.armedbear.lisp.StandardGenericFunction.execute (StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.asdf_318.execute(asdf.lisp:1561) at org.armedbear.lisp.clos_152.execute(clos.lisp:1437) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.clos_142.execute(clos.lisp:1371) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.clos_132.execute(clos.lisp:1205) at org.armedbear.lisp.StandardGenericFunction.execute (StandardGenericFunction.java:138) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.asdf_359.execute(asdf.lisp:1646) at org.armedbear.lisp.compiler_pass2_582.execute(compiler- pass2.lisp:8691) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.compiler_pass2_578.execute(compiler- pass2.lisp:8691) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.Autoload.execute(Autoload.java:168) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.asdf_358.execute(asdf.lisp:1646) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.funcall(Lisp.java:168) at org.armedbear.lisp.Primitives$pf_apply.execute (Primitives.java:2829) at org.armedbear.lisp.Primitive.execute(Primitive.java:143) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.asdf_373.execute(asdf.lisp:1716) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators._let (SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute (SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Primitives$sf_return_from.execute (Primitives.java:3750) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators$sf_progn.execute (SpecialOperators.java:275) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.execute(Closure.java:421) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators._let (SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute (SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.eval(Lisp.java:455) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:770) at org.armedbear.lisp.Primitives$sf_tagbody.execute (Primitives.java:3667) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.SpecialOperators._let (SpecialOperators.java:169) at org.armedbear.lisp.SpecialOperators$sf_let.execute (SpecialOperators.java:101) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute (Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.eval(Lisp.java:455) at org.armedbear.lisp.Primitives$pf__eval.execute (Primitives.java:328) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute (Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.bindParametersAndExecute (Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:278) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute (CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:765) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute (AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:318) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:636) "Low Memory Detector" daemon prio=10 tid=0x08ebb800 nid=0x22f8 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x08eb8800 nid=0x22f7 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x08eb6c00 nid=0x22f6 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=10 tid=0x08eae000 nid=0x22f5 in Object.wait() [0xb46d3000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7181b310> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133) - locked <0x7181b310> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149) at java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:177) "Reference Handler" daemon prio=10 tid=0x08eac800 nid=0x22f4 in Object.wait() [0xb4724000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7181b0a8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run (Reference.java:133) - locked <0x7181b0a8> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x08eaac00 nid=0x22f3 runnable "VM Periodic Task Thread" prio=10 tid=0x08ebd400 nid=0x22f9 waiting on condition JNI global references: 695 Heap def new generation total 2112K, used 1035K [0x6f0a0000, 0x6f2e0000, 0x71800000) eden space 1920K, 43% used [0x6f0a0000, 0x6f172c78, 0x6f280000) from space 192K, 100% used [0x6f2b0000, 0x6f2e0000, 0x6f2e0000) to space 192K, 0% used [0x6f280000, 0x6f280000, 0x6f2b0000) tenured generation total 26796K, used 21848K [0x71800000, 0x7322b000, 0x8f0a0000) the space 26796K, 81% used [0x71800000, 0x72d56308, 0x72d56400, 0x7322b000) compacting perm gen total 12288K, used 10968K [0x8f0a0000, 0x8fca0000, 0x930a0000) the space 12288K, 89% used [0x8f0a0000, 0x8fb563d8, 0x8fb56400, 0x8fca0000) ro space 8192K, 89% used [0x930a0000, 0x937cd318, 0x937cd400, 0x938a0000) rw space 12288K, 59% used [0x938a0000, 0x93fcc748, 0x93fcc800, 0x944a0000) ^C asdf@ip-10-251-122-82:/development/source/library$ mor

3 3

[armedbear-devel] Bug in metaclass support
by Alessio Stalla 11 Apr '10

11 Apr '10

Hello, this piece of code produces an error: (defclass foo () () (:METACLASS STANDARD-CLASS) (:DOCUMENTATION "bar")) condition of type PROGRAM-ERROR: Invalid initarg :DOCUMENTATION while it works perfectly fine without :metaclass, presumably because make-instance is not called to create the class metaobject. On class redefinition (say, I define foo without :documentation, and redefine it with it), it gives no error. This breaks Cells which always puts in a :metaclass option even when superfluous. Bye, Alessio

2 1

[armedbear-devel] Ticket #88: Predicate to distinguish Java-based and lisp-compiled functions
by Erik Huelsmann 10 Apr '10

10 Apr '10

Regarding ticket 88, I have the following idea: Lisp functions inherit from either Primitive or CompiledClosure. CompiledClosure isn't used elsewhere, but Primitive is used everywhere in Java too. How about creating an (empty) CompiledPrimitive which isn't used Java-side. Then, with a simple 'instanceof' test, functions can be tested to have been compiled from Lisp or created from Java. How about that? Bye, Erik.

1 0

[armedbear-devel] Low memory condition signalling
by Erik Huelsmann 09 Apr '10

09 Apr '10

Hi, Yesterday I completed an abcl-dev blogpost about 0.18 which handles out of memory (OOM) conditions much better than earlier versions. However, as the post concludes, it would be even lispier to have a low-memory signal instead of OOM, because in that case the condition system can be used to handle the situation right in the call stack where the condition occurred, in order to be able to continue execution after handling the condition. Douglas Miles suggested we use JMX memory management notifications to create this behaviour. Before we can implement such behaviour, a number of questions need to be answered: * How does an application tell the difference between our current OOM condition and the new behaviour? -> this is important, because the current behaviour unwinds the stack; the future one won't * Do we remove the current behaviour? * Do we let the user select the parameters for signalling the requested condition? * Should we let the user install handlers to be called when a condition like this occurs? * <others>? Regards, Erik.

3 3

[armedbear-devel] Unicode support vs spec conformance
by Erik Huelsmann 05 Apr '10

05 Apr '10

This started with Douglas Miles remarking that 2 tests in the ansi test suite have been failing ever since we increased CHAR-CODE-LIMIT to #x10000.That change was associated with our intended support for Unicode. As it turns out, Unicode has defined characters which conflict with a requirement from the CLHS: CLHS requires that characters be defined in exact pairs, if they have 'case'. This means that the functions char-upcase and char-downcase can be used to retrieve the character's "other case" equivalent. However, in Unicode there are characters which don't have that property: for example LATIN SMALL LETTER DOTLESS I maps to the LATIN CAPITAL LETTER I, just as the LATIN SMALL LETTER I. Obviously, the capital can't map back to both. See here the issue with CLHS compliance emerge. Three possible solutions have come up: 1a. Be CLHS compliant, but not Unicode 1b. Same as (1a), but provide specific Unicode up/down casing functions 2. Be Unicode compliant and not CLHS. SBCL (and from Sam Steingold's remark CLISP too) chooses 1a: I haven't found a function to do Unicode up/down casing; it defines the uppercase of the dotless i to be itself (caseless). This solution results in CLHS compliance, but in my opinion, isn't the solution with the least surprise: if you decide you want to upcase a string - without in-depth awareness of the issue - you're suddenly faced with a string which is upcased, except for a number of characters. I would propose we - documentedly - diverge from the CLHS on this issue: we follow Unicode and the upper case version of the dotless i is just the capital i. From a user perspective, this seems like the solution of least surprise: I would expect people who use characters which can't be round-tripped to understand about that. Sam suggests there's an issue with symbol i/o. He's probably referring to *readtable-case* and *print-case*. My reasoning here too is that people using characters like these in their symbols would expect to be familiar with both the casing behaviour of the Common Lisp reader/printer and the behaviour of their letters in such circumstances: if a string were uppercased in a certain way, wouldn't it be extremely weird if your symbols wouldn't too - given that your Common Lisp claims Unicode support? So, my proposal here is to diverge. What are your opinions? Bye, Erik.

2 1

[armedbear-devel] Where is ASDF2?
by Blake McBride 05 Apr '10

05 Apr '10

git clone http://common-lisp.net/project/asdf/asdf.git seems to have the latest ASDF 1. I can't seem to find ASDF 2. A pointer would be appreciated. Thanks. Blake McBride

2 1

[armedbear-devel] Understanding Unicode support
by Erik Huelsmann 04 Apr '10

04 Apr '10

Hi all, In an effort to make our Unicode support comprehensible, I've started a wiki page to document what's all to be considered. The page is at http://trac.common-lisp.net/armedbear/wiki/CharsetSupport Please contribute directly to the page or send your amendments here for inclusion. Bye, Erik.

1 0

[armedbear-devel] Unicode, CHAR-UPCASE/CHAR-DOWNCASE and char-upcase.1/char-upcase.2
by Erik Huelsmann 04 Apr '10

04 Apr '10

Ever since ABCL raised its CHAR-CODE-LIMIT from 256 to #x10000, 2 tests started failing: char-upcase.1 and char-upcase.2. These 2 tests iterate through all integers between 0 and CHAR-CODE-LIMIT. While doing so, they test for the property that upcasing and downcasing returns the same character again ("round-tripping"). This property of characters is specified in section 13.1.4.3 (http://www.lispworks.com/documentation/lw51/CLHS/Body/13_adc.htm) "Characters with case". In short: characters with case are defined in pairs; additional characters with case have to be defined in pairs too. The spec provides char-upcase and char-downcase to convert characters-with-case to their 'other-case equivalent'. However, in section 13.1.10, there seems to be an escape hatch: "Documentation of implementation-defined scripts". A script is a subtype of CHARACTER, nothing more nothing less. An implementation-defined script gets to document the effect on CHAR-UPCASE and CHAR-DOWNCASE. Now, if I were to define our Unicode script to be every character except those in the base set, char-upcase and char-downcase may have different semantics, except for the standard characters. That way, there's no need to have the round-tripping requirement apply to most of unicode - as can't be expected, see latin-small-letter-dotless-i for an example. In the light above, is it really portable for the tests to assume all characters must be round-tripped? I think it's not. What are your opinions? Bye, Erik.

3 4

[armedbear-devel] Loading from jar - status
by Reinhard Oldenburg 03 Apr '10

03 Apr '10

Dear ABCL-Team, some time a go the theme of loading compiled files from jar-archives has been discussed on this list but somehow I missed the final conclusion. There seems to be no example or documentaion of this feature. Especially I'm interested in loading Maxima from a jar file - is this possible? Yours, Reinhard Oldenburg

2 1

[armedbear-devel] lisp interpreter inside a beanshell JConsole?
by Alan Ruttenberg 02 Apr '10

02 Apr '10

Hi, I'm trying to set up a lisp shell inside protege, by copy pasting from the bean shell example they have: http://code.google.com/p/co-ode-owl-plugins/source/browse/trunk/org.coode.s… (see http://www.beanshell.org/manual/jconsole.html) Unfortunately I'm losing, with the first eval I call resulting in a null pointer exception. I expect I don't know how to set up the top level loop to run with the JConsole streams. Can anyone help? Thanks, Alan

3 8

[armedbear-devel] Proposal for URL to be used as Pathnames
by Mark Evenson 02 Apr '10

02 Apr '10

I've [committed to an initial design][1] for URLs to be used as Pathnames, which I am in the process of implementing. The primary use of this functionality will be to be able to eventually express OSGi bundles within ASDF system definitions. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/url-pat… The gist of the proposal is to represent a URL with a Pathname whose HOST component is a list. The list will be an association list with the key :SCHEME containing the URL scheme and :AUTHORITY containing the URL authority. The DIRECTORY, NAME, and TYPE components will be used to construct the PATH of the URL. As an example, "http://example.org:8080/org/armedbear/lisp/boot.lisp" would be converted to a Pathname as follows pathname: { host: (:SCHEME "http" :AUTHORITY "example.org:8080"), directory: (:ABSOLUTE "org" "armedbear" "lisp"), name: "boot", type: "lisp" } As an answer to Alessio's question (long ago) about whether URLs should really be a Pathname or if we are better off using a class, I think that they really are better abstracted as a Pathname because they a) have a hierarchical path b) the network location has a strong resemblance to how HOST is used for UNC mounts under Windows and c) being able to express OSGi bundles in ASDF has a chance of working. Critique welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

5 10

Re: [armedbear-devel] [armedbear-cvs] r12577 - branches/metaclass
by Erik Huelsmann 28 Mar '10

28 Mar '10

This commit completes the METACLASS functionality I was planning to provide on trunk/. The only thing which remains is writing regression tests. I don't see any problems to do that with the code on trunk, as the ANSI tests show no new breakage. Since 0.20 is scheduled to be released beginning of may - as per our normal release cycle - please test this functionality as much as possible and report any issues you find. It will help improve the quality of our 0.20 release: this functionality has the potential of destabilizing our code, although I haven't found that to have acctually happened. Thanks in advance, Erik. On Sun, Mar 28, 2010 at 9:20 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Mar 28 16:20:09 2010 > New Revision: 12577 > > Log: > Re #38: Delete merged metaclass branch. > > Removed: > branches/metaclass/ > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] SEQUENCE == SlotClass?
by Erik Huelsmann 27 Mar '10

27 Mar '10

Hi Alessio, You implemented the user-extensible sequence protocol. Did you by any chance change the type of Sequence from BUILT-IN-CLASS to SLOT-CLASS? If so, I have a little bit of a negative interaction with my METACLASS changes. Nothing that can't be fixed; I'll probably need to study AMOP for the solution, but I was just wondering. Does crhodes specify the new class of SEQUENCE in his protocol? Should we switch it to STANDARD-CLASS? Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.19.1 released
by Erik Huelsmann 27 Mar '10

27 Mar '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.19.1 release. Version 0.19.0 was never released. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - a fix for unbinding PROGV bound variables upon exiting the PROGV scope and a much improved integration of access to filenames specified by URLs. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.19.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.zip.asc

1 0

[armedbear-devel] Losing type information after storing in java.util.ArrayList
by David Kirkman 24 Mar '10

24 Mar '10

I've got a subtle problem: if I create a byte array, store it in a java.util.ArrayList, and then retrieve the stored byte array, what I get back is not quite the same type as the original byte array. I think that everything is the same, except that the JavaObjects have different values for the intendedClass field. Here is an example: (setq array1 (jnew-array "byte" 1)) (setq array2 (let ((array-list (jnew (jconstructor "java.util.ArrayList")))) ;; put the byte array into the ArrayList (jcall (jmethod "java.util.AbstractList" "add" "java.lang.Object") array-list array1) ;; and pull it back out (jcall (jmethod "java.util.AbstractList" "get" "int") array-list 0))) (describe array1) ;#<jarray [B@c4ff22 {4A44DD}> is an object of type JAVA-OBJECT. ;The wrapped Java object is an array of bytes with 1 element.; No value (describe array2) ;#<jarray [B@c4ff22 {5E6B62}> is an object of type JAVA-OBJECT. ;The wrapped Java object is an array of bytes with 1 element.; No value At this point array1 and array2 look pretty compatible, but ... (sys::%make-byte-array-input-stream array1) ; works fine, gives a #S(SYSTEM::SYSTEM-STREAM) (sys::%make-byte-array-input-stream array2) ; gives a TYPE-ERROR, with message "java.lang.Object is not assignable to [B" The TYPE-ERROR comes from JavaObject.javaInstance(Class<?> c) (line 248 of JavaObject.java). It seems that array1 has intendedClass="[B", and array2 has intendedClass="java.lang.Object", so I'm pretty sure that's my problem. Is there a way to specify the intendedClass of array2? Thanks, -david k.

4 6

Re: [armedbear-devel] long
by Alan Ruttenberg 23 Mar '10

23 Mar '10

On Mar 16, 2010, at 8:47 AM, dmiles(a)users.sourceforge.net wrote: > This is because ABCL: > Fixnum => int > Bignum => BigInteger > > ABCL does not have a 'long' type so it is normal workaround to produce > a new 'long in your case. > > So depends who is desiring: There is no real spec other than Allegro > http://www.franz.com/support/documentation/8.0/doc/jlinker.htm#data=types-c… > But Allegro spec here is lossy.. > (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would > scaled back to Long.MAX_VALUE) So their spec is even more > undesirable. Agreed. > It would be possible that when the Bignum is within normal java long > range the javaInstance() could return a java.lang.Long instead. > > Does everyone think this would be better behavior than current ABCL and Allegro? I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup. -Alan > > > On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg > <alanruttenberg(a)gmail.com> wrote: >> >> Am I right to observe that abcl coerces any number > fixnum size to bigint? >> I'm having trouble calling a java method that takes a long. I seem to >> have worked around it calling the method with (new 'long >> "9223372036854775807") rather than 9223372036854775807 . >> >> Is this the desired behavior? >> >> -Alan >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 5

[armedbear-devel] Fwd: [Openmcl-devel] [2nd CfP] 7th European Lisp Workshop at ECOOP'10, June 21/22
by Erik Huelsmann 18 Mar '10

18 Mar '10

FYI. ---------- Forwarded message ---------- From: Didier Verna <didier(a)lrde.epita.fr> Date: Wed, Mar 17, 2010 at 2:25 PM Subject: [Openmcl-devel] [2nd CfP] 7th European Lisp Workshop at ECOOP'10, June 21/22 To: Open MCL Development <openmcl-devel(a)clozure.com> +------------------------------------------------------------+ | 2ND CALL FOR PAPERS | | 7th European Lisp Workshop | | June 21/22, Maribor, Slovenia - co-located with ECOOP 2010 | +------------------------------------------------------------+ News ==== Our invited speaker, Manuel Serrano, will talk about "diffuse programming" and HOP. The abstract of his presentation can be found on the website at: http://european-lisp-workshop.org/upcoming/programme.php Important Dates =============== Submission deadline: April 19, 2010 Notification of acceptance: May 05, 2010 ECOOP early registration deadline: May 10, 2010 7th European Lisp Workshop: June 21 or 22, 2010 (tbdl) Please note that registration must be done with ECOOP itself. For more information visit http://www.european-lisp-workshop.org Contact: Didier Verna, didier(a)lrde.epita.fr Invited Speaker =============== Manuel Serrano (INRIA, France) http://www-sop.inria.fr/members/Manuel.Serrano/ Overview ======== "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp, one of the eldest computer languages still in use today, is gaining momentum again. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch, making it the ideal candidate for writing Domain Specific Languages. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and remains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. This workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit contributions that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components: there will be formal talks, and interactive turorial/demo/coding sessions. Papers ====== Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. Suggested topics include (but are not limited to): - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Protocol meta-programming and libraries - New language features and abstractions - Software evolution - Development aids - Persistent systems - Dynamic optimization - Implementation techniques - Hardware Support - Efficiency, distribution and parallel programming - Educational approaches and perspectives - Experience reports and case studies Interactive Tutorial/Demo/Coding Sessions ========================================= Additionally, we invite less formal talks in the form of interactive tutorial/demo/coding sessions. The purpose of these sessions is both to demonstrate and receive feedback on any interesting Lisp system, either stable or under development. Being less formal than technical paper presentations, these sessions are expected to be highly interactive. Submission Guidelines ===================== Potential contributors are encouraged to submit: - a long paper (around 10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes, - a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future, - a proposal for an interactive tutorial/demo/coding session (1-2 pages) describing the involved library or application, and the subject of the session. Papers (both long and short) should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms (see below). Authors will later be required to sign an ACM copyright form, as the workshop proceedings will be published in the ACM Digital Library. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=elw2010 Organizers ========== Didier Verna, EPITA Research and Development Laboratory, Paris Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel Robert Strandh, LaBRI, University of Bordeaux 1, France Christophe Rhodes, Goldsmiths College, University of London -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ Openmcl-devel mailing list Openmcl-devel(a)clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

1 0

[armedbear-devel] 0.19 release status
by Mark Evenson 17 Mar '10

17 Mar '10

Some quick notes on status of 0.19 for release where I see things. 1. [r12550][1] should probably be backported if anything. [1]: http://trac.common-lisp.net/armedbear/changeset/12550 2. [r12549][2] is probably mostly just cosmetic, but brings up questions of how well the Pathname use of :UNSPECIFIC should be. [2]: http://trac.common-lisp.net/armedbear/changeset/12549 3. I'm still unhappy about the state of the Pathname support, but its a goal that should be postponed until 0.20, as the current implementation is no worse that what shipped in 0.18.1. Most notably, I think I really need to a) support URLs as Pathnames and b) allow all Pathnames to be arguments of OPEN which probably means subclassing Stream.java. And this is a whole lot of work, so postpone. 4. Disturbingly, I uncovered a [compiler stack inconsistency error][3] today in working on ASDF. I checked that this was *NOT* induced by the recent PROGV fix, and exists at least as far back at 0.18.1. So, it should not affect the decision to release unless we feel we should fix it before release. [3]: http://trac.common-lisp.net/armedbear/ticket/89 So, if we're in a "lets get this thing out the door", just release what's on 0.19 (after updating the README). If you want to backport [r12550], I think it should not affect any of the existing test results, but they should be re-run just to make sure. I probably won't have such time until tomorrow (Wednesday). -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

Re: [armedbear-devel] [asdf-devel] ABCL trunk r12551 works with asdf-1.643
by Faré 16 Mar '10

16 Mar '10

> Attached is a (trivial) patch so that 'run-tests.sh' actually uses the flags > argument. Thanks. It was applied, and many small bugs were fixed in ASDF 1.647 as I did more testing and improved the test infrastructure. > ABCL now passes the ASDF test suite: > > -#--------------------------------------- > Using abcl --noinit > Ran 21 tests: > 21 passing and 0 failing > all tests apparently successful > -#--------------------------------------- > Yay! > After discussion on IRC and further thought, I no longer advocate that ASDF2 > not make the relocating the FASLs the default. There are certainly decent > arguments for it, and we do want progress in ASDF2, right? Instead, I would > advise that you make a section in the (really excellent looking) manual that > explicates the changes that an ASDF1 user—both with and without using > ASDF-BINARY-LOCATIONS—should expect in ASDF2. And I would include the > *LOAD-TRUENAME*/*LOAD-PATHNAME* issue (i.e. use a conditionalized > ASDF:SYSTEM-DEFINITION-PATHNAME invocation) in that section. > Yes. We need a FAQ section for migration from ASDF1 to ASDF2, with questions each in its own subsection, and a rationale for each change. Sigh. > Otherwise, ASDF2 looks quite cool. What's your timeframe for an official > release? I'd include it as-is in ABCL, but don't want to chase all the > release candidates to ASDF2. > Hopefully we'd like to release ASDF2 before summer. I suggest that at some point (e.g. now) you pick one of the release candidates that you consider not too broken after testing, then upgrade to the real ASDF2 release when it's out, and otherwise only upgrade when there's a good reason to (i.e. fixing major brokenness, or adding major feature, or there's been a stable version for 6 months that you haven't upgraded to yet). Thanks a lot for your support! And don't forget to implement the long DEFINE-METHOD-COMBINATION :) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, "What Is Seen and What is Not Seen", 1850

1 0

[armedbear-devel] pathname-directory
by Alan Ruttenberg 16 Mar '10

16 Mar '10

CL-USER(1): (PATHNAME-DIRECTORY #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") -> (:RELATIVE "lsw" "jss") I think that's wrong. Should be :absolute, right? -Alan

4 21

[armedbear-devel] ABCL and ASDF 1.636
by Faré 16 Mar '10

16 Mar '10

In ASDF 1.636, I removed the dreaded DEFINE-METHOD-COMBINATION that has made ASDF hard to port to ABCL. Can someone in the ABCL team check whether the latest ABCL works with ASDF? Can you contribute a patch to run-tests.sh so it will run with ABCL? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Nothing is particularly hard if you divide it into small jobs. — Henry Ford

2 1

[armedbear-devel] long
by Alan Ruttenberg 16 Mar '10

16 Mar '10

Am I right to observe that abcl coerces any number > fixnum size to bigint? I'm having trouble calling a java method that takes a long. I seem to have worked around it calling the method with (new 'long "9223372036854775807") rather than 9223372036854775807 . Is this the desired behavior? -Alan

1 0

Re: [armedbear-devel] [armedbear-cvs] r12546 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 15 Mar '10

15 Mar '10

Now that we need to do 0.19.1 anyway, this looks like a nice candidate for inclusion. Bye, Erik. On Mon, Mar 15, 2010 at 5:09 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Mon Mar 15 12:09:42 2010 > New Revision: 12546 > > Log: > nreverse() *command-line-arguments-list* to natural order. > > Found by Alan Ruttenburg. > > > Modified: > trunk/abcl/src/org/armedbear/lisp/Interpreter.java > > Modified: trunk/abcl/src/org/armedbear/lisp/Interpreter.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Interpreter.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Interpreter.java Mon Mar 15 12:09:42 2010 > @@ -247,6 +247,7 @@ > } > } > } > + arglist.nreverse(); > > _COMMAND_LINE_ARGUMENT_LIST_.setSymbolValue(arglist); > } > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] startup message
by Alan Ruttenberg 15 Mar '10

15 Mar '10

Is there a way to suppress the startup banner: Armed Bear Common Lisp 0.20.0-dev Java 1.5.0_19 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.374 seconds. Startup completed in 0.912 seconds. ? Thanks, Alan

2 1

[armedbear-devel] *command-line-argument-list* backwards
by Alan Ruttenberg 15 Mar '10

15 Mar '10

java -cp ~/Desktop/test.jar org.armedbear.lisp.Main --noinit -a -b -c -d Armed Bear Common Lisp 0.20.0-dev Java 1.5.0_19 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.364 seconds. Startup completed in 0.893 seconds. lType ":help" for a list of available commands. CL-USER(1): *command-line-argument-list* ("-d" "-c" "-b" "-a")

3 2

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #38: CLOS :metaclass support
by Erik Huelsmann 13 Mar '10

13 Mar '10

The mail below was induced by the "automatic ticket annotator" from Trac. While I installed it many moons ago, I was under the impression it wasn't working. Nothing like that was the case: I just didn't get it enough. See http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-com… on how you can annotate or close tickets from your commit message. Bye, Erik. On Sat, Mar 13, 2010 at 8:05 PM, armedbear <armedbear-devel(a)common-lisp.net> wrote: > #38: CLOS :metaclass support > -------------------------+-------------------------------------------------- > Reporter: ehuelsmann | Owner: ehuelsmann > Type: defect | Status: accepted > Priority: major | Milestone: 0.20 > Component: other | Version: > Resolution: | Keywords: > -------------------------+-------------------------------------------------- > > Comment(by ehuelsmann): > > (In [12527]) Make all class accessor functions generic functions instead > of normal ones, to support METACLASS. Additionally, make > it possible to store general objects in Layout.lispClass. > Because classes may be of a different Java type than > StandardClass, fall back to the generic functions to access > the required fields from Java. > > See #38. > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/38#comment:2> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0

[armedbear-devel] Maxima status: Can't compile due to i18n changes
by Erik Huelsmann 13 Mar '10

13 Mar '10

Dear Robert, Maxima developers, >From time to time, I check ABCL's status with Maxima. Today I updated to the latest, but found that I can't compile anymore. The issue is with intl.lisp: the defvar form defining *default-domain* contains an _N reader macro, which expands into multiple symbols on ABCL: This is what I found after expansion: --- fasl content (DEFVAR *DEFAULT-DOMAIN* "maxima" NIL "The message-lookup domain used by INTL:GETTEXT and INTL:NGETTEXT. Use (INTL:TEXTDOMAIN \"whatever\") in each source file to set this.") --- fasl content As you see, there's an additional NIL there. I'm hoping to work out together with you what's going on here, as support for Maxima is one of the important items on the list of ABCL developers. With kind regards, Erik ABCL developer

2 1

Re: [armedbear-devel] [armedbear-cvs] r12526 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 13 Mar '10

13 Mar '10

This e-mail was caused by me testing the post-commit hookscript. Sorry. Bye, Erik. On Sat, Mar 13, 2010 at 7:49 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Mar 12 17:38:32 2010 > New Revision: 12526 > > Log: > Fix ticket #85: CL-JSON throws an error where SBCL doesn't. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp Fri Mar 12 17:38:32 2010 > @@ -1078,9 +1078,9 @@ > ;; (dolist (name (second symbols-form)) > ;; (let ((variable (make-variable :name name :special-p t))) > ;; (push > - (setf (progv-form block) > - `(progv ,symbols-form ,values-form ,@(p1-body body)) > - (progv-environment-register block) t) > + (setf (progv-environment-register block) t > + (progv-form block) > + `(progv ,symbols-form ,values-form ,@(p1-body body))) > block)) > > (defknown rewrite-progv (t) t) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Error: value is not of type CONS
by Axel Rauschmayer 12 Mar '10

12 Mar '10

CL-JSON throws an error under ABCL where SBCL doesn't. The code is: (require 'asdf) (asdf:operate 'asdf:load-op :cl-json) (json:decode-json-from-string "{\"foo\": [10,20,50], \"bar\": true}") The error message is: The value 50 is not of type CONS. I'm using Yason as a work-around, but thought that you guys might want to know, maybe this points to a deeper issue. Greetings, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

2 2

[armedbear-devel] integrating abcl into Protege
by Alan Ruttenberg 12 Mar '10

12 Mar '10

Protege is an ontology development tool. I'm interested in using abcl to develop plugins and TIm Redmond was kind enough to have a stab at doing a first pass integration, but ran into trouble. I wonder if his report makes rings a bell? -Alan ---------- Forwarded message ---------- From: Timothy Redmond <tredmond(a)stanford.edu> Date: Wed, Mar 10, 2010 at 2:12 PM Subject: [POSSIBLE VIRUS:###] Re: further on common lisp integration To: Alan Ruttenberg <alanruttenberg(a)gmail.com> There is something of a difficulty in using this library. It is doing some funky stuff with urls and class loaders and this doesn't work with Protege. Probably could be made to work by making some changes to the abcl sources. In particular it seems to detect that it is loading through the class loader if the prefix begins with jar which is not a correct assumption in general. But here is a start if you want to debug a bit more. -Timothy java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.armedbear.lisp.ZipCache.getZip(ZipCache.java:54) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1305) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1462) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:770) at org.armedbear.lisp.Lisp.error(Lisp.java:354) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1329) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619)

5 14

[armedbear-devel] class-prototype
by Alan Ruttenberg 10 Mar '10

10 Mar '10

Hi, Thanks for adding class-prototype. Unfortunately I realize that the specification doesn't guarantee the behavior I was looking for, so I though I would solicit advise. Basically I want to be able to access class-allocated slot values before I create any real instances. I thought I could grab the class prototype and do slot value on them, but according to the doc below initialize is not called, which I guess is when class-allocated slots are being set up. Is there a portable way of asking for the values of class slots absent the creation of at least one initialized instance? -Alan http://www.franz.com/support/documentation/8.2/doc/mop/dictionary.html#clas… Generic Function class-prototype class Returns a prototype instance of class. Whether the instance is initialized is not specified. The results are undefined if a portable program modifies the binding of any slot of prototype instance. This generic function signals an error if class has not been finalized.

3 11

[armedbear-devel] Problems with compiled PROGV?
by Mark Evenson 09 Mar '10

09 Mar '10

In analyzing the [bug with CL-JSON][1], I think the culprit lies in improper compilation of PROGV forms, although I have yet to come up with a simple example factored out of the CL-JSON codebase. Reading last night's #abcl logs, I saw that Erik made a comment about problems with PROGV as well, without specifics. Thinking that if I had other examples of how PROGV misbehaves it might shed some light on my problems, I'd like to ask for details about other misbehavior of compiled PROGV forms however scant. Cases that are reproducible would be most welcome. [1]: http://trac.common-lisp.net/armedbear/ticket/85 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 7

[armedbear-devel] regarding ticket #87: input history for REPL
by Ville Voutilainen 03 Mar '10

03 Mar '10

We don't necessarily need to use jline for this, there's an utility called rlwrap that provides GNU Readline functionality for the wrapped application. I'm not sure about the availablity of rlwrap on windows, though.

5 4

[armedbear-devel] [PATCH] SYS:GETPID
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

The following patch adds SYS:GETPID which works by making the abcl wrapper shell script store the current PID as a system property. For some reason, I see the following behaviour: tcr@thaleron:~/src/from-upstream/abcl$ abcl-svn Armed Bear Common Lisp 0.19.0-dev Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.47 seconds. Startup completed in 1.099 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:getpid) Unable to autoload SYSTEM:GETPID tcr@thaleron:~/src/from-upstream/abcl$ I.e. the patch is not yet finished; I hope that it'll be clear what's missing to the more experienced ABCL hackers on the list. On Windows, (SYS:GETPID) will just return NIL. There may be some way to do similiar magic with batch files, but googling didn't reveal anything promising. -T.

2 1

[armedbear-devel] #P"SRC"
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

Could ABCL set up a #P"SRC:", or #P"SYS:SRC:" logical pathname to the source directory that was used for the build? -T.

2 5

[armedbear-devel] recording source file locations
by Alan Ruttenberg 03 Mar '10

03 Mar '10

Can anyone summarize what kinds of source information are recorded? Is source location for generic function methods recorded? Variables? Constants? Stuctures? I'd like to extend source recording for functions defined interactively in slime as well, if I can understand what needs to be done on the abcl side. I could hunt around the source but figured I'd ask in case someone has thought of this recently. I'm losing in slime most of the time I meta-point things. On another debugging front, is it possible to get local variables for functions that are interpreted, in the context of an exception? I understand it's more difficult for compiled functions. -Alan

3 3

[armedbear-devel] COMPILE-SYSTEM and file dependencies
by Tobias C. Rittweiler 03 Mar '10

03 Mar '10

How much of a full CL is available for COMPILE-SYSTEM? Have you contemplated using (perhaps a stripped down version of) ASDF for specifying the exact dependencies for the *.lisp files? Getting that right in a descriptive manner is important as the system grows otherwise you end up with a mess like in SBCL where a mere mortal has no idea what in the build may break if you change something. -T.

1 0

[armedbear-devel] tentative patch: extensible sequences (following the same protocol as SBCL)
by Alessio Stalla 02 Mar '10

02 Mar '10

Greetings everyone, I'm happy to announce that I have a preliminary version of user-extensible sequences working on ABCL, following the protocol proposed and implemented by Christophe Rhodes on SBCL ("User-extensible sequences in Common Lisp", http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.1604&rep=rep1&t…) This includes: - the possibility for the user to write subclasses of CL:SEQUENCE - all functions operating on sequences have a corresponding generic function in the SEQUENCE package that is called on user-defined sequence types, and for which the user can write methods to implement his/her custom sequences - make-sequence works with user-defined sequences (using sequence:make-sequence-like as in SBCL) - mop::class-prototype has been added (as a tiny wrapper around mop::allocate-instance) - iterating over user-defined sequences integrated with LOOP (untested, but should work as our loop implementation is derived from CMUCL like SBCL's) - MAP and MAP-INTO should work unchanged limitations/things missing wrt. SBCL (that I know of): - no integration with DOSEQUENCE - to use extensible sequences you must explicitly (require :extensible-sequences) in advance - much less attention to precise sequence type information (but probably my patch doesn't improve nor worsen the situation before it) the patch doesn't seem to break any new ANSI tests; however I've tested the extensible sequences proper very lightly, and I don't consider the patch ready for trunk yet. My long-term goal is to use the new extensible sequences support to make Java collections be Lisp sequences. That should include Clojure collections as well, since afaik they implement the Collection API. If anyone has comments or critiques, or wants to help, you're welcome. Cheers, Alessio

2 3

[armedbear-devel] Synthetic Method Removal
by dmiles＠users.sourceforge.net 02 Mar '10

02 Mar '10

This is the .patch file that removes synthetic access to private fields/constructors and methods. Its intention is to make stack traces easier to read. And will have a miniscule speedup. And shrink classfile sizes 1-4%

1 0

[armedbear-devel] Unfair fresh-line.5 ANSI-TEST?
by dmiles＠users.sourceforge.net 01 Mar '10

01 Mar '10

Fresh-line.5 is a when we compare the output string againt a string read from the file.. this means the test is contigent on the line ending style of ABCL matching what SVN checkout did. (deftest (let (result) (values (with-output-to-string (s) (write-char #\Space s) (setq result (list (multiple-value-list (notnot-mv (fresh-line s))) (multiple-value-list (fresh-line s)) (multiple-value-list (fresh-line s))))) result)) " " ((t) (nil) (nil))) I am thinking the compared to litteral needs to be a constant programmatily contructed. Such as a write-char #\Space + write-char #\Newline Any thoughts of patch ideas for the ansi-tests?

1 0

[armedbear-devel] Changes to CHANGES
by Mark Evenson 27 Feb '10

27 Feb '10

I've updated the [CHANGES][1] file on trunk in preparation for the upcoming release. Erik asked me to write up my changes, but I took at stab at recapitulating everything as best I could interpret it. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=8a0bf88cca6dd… Deliberately missing from this summary: 1) Alessio's recent work on lambda inlining. In my opinion we have to address the bug Alan Ruttenberg has found or backout these changes before release. 2) Ville's work on string functions, as it's incomplete. And it was hard to understand from the commit messages if it is purely optimization or if it involves bug fixing as well. Anything else is something I missed. I've adopted a little more verbose format than previously, including references to svn changesets and tickets where possible. There are now three sections: "Features" which tries to summarize the features that would be interesting to end users "Fixes/Optimizations" summarizing all the fixes or optimizations that might prompt an end user to retry something that previously didn't work or was too slow, and "Other" which mostly summarizes changes to implementation details of interest to ABCL development. Comments (or direct changes in SVN) are welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 14

[armedbear-devel] some questions about r12503
by Ville Voutilainen 22 Feb '10

22 Feb '10

The separate pathname matcher for jars looks odd to me. I'd expect the listing to give whatever it gives, and the matching condition in directory.lisp to filter it. Is jar filtering so different that it requires a different matcher? Same question applies to the wildcard matching, jar listing seems to do the wildcard matching in java, rather than in lisp? That's also different from the way directory listings are handled. The list-directory primitive sorely needs to be split into two functions (listJar and listDirectory), it's getting long-winded. That's not a high-priority issue, but we need to mind function length, it's a huge readability issue.

2 2

[armedbear-devel] commit r12491
by Ville Voutilainen 21 Feb '10

21 Feb '10

I object to this patch. We have previously rejected code that sprinkles jnews and jcalls all over directory.java. I believe the proper way to introduce jar support for DIRECTORY would be to do it in the list-directory primitive in Pathname.java. At any rate, if we don't want that and want to do the jar logic in directory.lisp, then fine, add whatever primitives you need for the bare minimum, but _don't_ implement it as lisp code that only calls java code. That makes no sense (*). (*) Yes, it may make sense for user code that has to call java. I don't, however, think it makes sense for abcl internals, or namely directory.lisp. It looks ugly as sin, and it prevents using the code in non-java environments, if such ever arrive. We have a design where lisp code calls primitives that provide the bare minimum support from the java side, I think we should stick to that design.

2 4

[armedbear-devel] TypeError woes
by Ville Voutilainen 20 Feb '10

20 Feb '10

The String constructor for TypeError doesn't result in the message string to be printed. That's because the message is never set anywhere. Condition will give the message in getMessage(), and TypeError.getMessage() will use that if non-null, but nothing sets it. I'll attach a patch that corrects this, but I don't want to commit it yet - it looks woefully incorrect to me. Is this really what we have to do in all Condition-extending classes? Set a protected member? We already set the formatControl, why does that not work?

1 0

[armedbear-devel] ASDF-INSTALL committed to trunk
by Mark Evenson 20 Feb '10

20 Feb '10

A port of ASDF-INSTALL has been [committed to trunk][1]. [1]: http://trac.common-lisp.net/armedbear/changeset/12487 I have a lot of issues with the shape of this package. This is a commit to both get feedback and to leave a "stake in the ground" so I can move to the more pressing issue of the long form of DEFINE-METHOD-COMBINATION. I really don't expect ASDF-INSTALL to work well under Windows, but you at least need [cgywin installed][2] for the 'tar' and 'gpg' binaries to have a fighting chance. [2]: http://www.cygwin.com/ To use this package, one must invoke Ant with the target "abcl.contrib" whereupon a jar named "dist/abcl-contrib.jar" is created. Use the following in your ~/.abclrc (replacing ${dist.dir} with the absolute path of 'abcl-contrib.jar'): (require 'asdf) (pushnew "jar:file:${dist.dir}/abcl-contrib.jar!/asdf-install/" asdf:*central-registry*) Then issuing CL-USER> (require 'asdf-install) will load ASDF-INSTALL. After you have loaded ASDF-INSTALL, you use it by issuing commands of the form: CL-USER> (asdf-install:install :PACKAGE) where PACKAGE is [an asdf installable system identifier][3]. This will attempt to install that system and all of its dependencies under ~/.asdf-install-dir. [3]: http://www.cliki.net/ASDF-Install To use the system, you need to inform ADSF of the location to load systems by having (pushnew '(merge-pathnames ".asdf-install-dir/systems/" (user-homedir-pathname)) asdf:*central-registry*) in your '~/.abclrc'. What are my "issues"? 1. A large part of the value proposition of ASDF-INSTALL is that it is supposed to be help people newish to Lisp manage the installation of a lot of libraries to "get something running fast" but we don't have it as a standard part of ABCL. Why? Because ABCL should simply mean "you need Java x.x to run Common Lisp" leaving the platform distinctions behind. But since under Microsoft Windows ASDF-INSTALL relies on a) cygwin and b) symbolic links, it requires even *more* steps to get working for the hypothetical newcomer (who is likely coming from Windows in the first place). So we currently have no choice (or so I have argued myself into the position of) other than making ASDF-INSTALL an optional part of ABCL, if we wish to preserve the worthwhile semantics of platform independence. 2. The determination of the location of 'tar' and 'gpg' binaries should be better handled. 3. A lot of ASDF packages don't work well with ABCL, at least without patches. It would be nice to have something sort of like [Lispy][4] that could "intervene" for patching and recommendations for versions to install. In fact, a much more distributed manner of naming ADSF installable systems would be welcome. [4]: http://common-lisp.net/project/lispy/ 4. The #+windows conditionals make the asdf-contrib.jar non-platform independent. They should be replaced with (find :windows *features*) type forms. 5. The location of the 'abcl-contrib.jar' should at least be inferred from the location of 'abcl.jar' if they are in the same directory, but there isn't currently a reasonable proposal for how this would work to specify the ASDF location. 6. SBCL's version of asdf-install, although listed as "0.2" compared to the "0.6.10" that I ported seems to have more sophisticated conditionals for Microsoft Windows conditionals that should be examined for inclusion. Patches and comments welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] how to debug?
by Alan Ruttenberg 20 Feb '10

20 Feb '10

Could this be the result of some corruption of my java environment? Error loading /Users/alanr/repos/lsw/trunk/util/armedbear-0.19.0-dev-darwin-unknown/obo.abcl at line 16 (offset 951) Debugger invoked on condition of type ERROR: Class verification failed: (class: org/armedbear/lisp/obo_10, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Accessing value from uninitialized register 10 Restarts: 0: RETRY Retry performing #<ASDF:LOAD-OP (:VERBOSE NIL) {A3513D}> on #<ASDF:CL-SOURCE-FILE "obo" {DD5547}>. 1: ACCEPT Continue, treating #<ASDF:LOAD-OP (:VERBOSE NIL) {A3513D}> on #<ASDF:CL-SOURCE-FILE "obo" {DD5547}> as having been successful. [1] CL-USER(1): :bt 0: (SYSTEM:BACKTRACE) 1: (APPLY #<FUNCTION SYSTEM:BACKTRACE {59067}> NIL) 2: (SYSTEM:BACKTRACE) 3: (INVOKE-DEBUGGER #<ERROR {690C8E}>) 4: org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:237) 5: org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) 6: org.armedbear.lisp.Load.faslLoadStream(Load.java:548) 7: org.armedbear.lisp.Load.access$100(Load.java:54) [1] CL-USER(2):

3 14

[armedbear-devel] no restart on stack overflow
by Alan Ruttenberg 18 Feb '10

18 Feb '10

Stack overflow. [Condition of type STORAGE-CONDITION] Restarts: Backtrace: 0: org.armedbear.lisp.Java$23.execute(Java.java:1013) 1: org.armedbear.lisp.Symbol.execute(Symbol.java:775) 2: org.armedbear.lisp.swank_145.execute(swank.lisp:423) ... How do we abort this and recover the stack? -Alan

1 0

[armedbear-devel] It it worth cacheing jmethod and jclass calls?
by Blake McBride 16 Feb '10

16 Feb '10

I do: (let ((meth (jmethod "java.lang...." "javaMethodName" "arg-type")) (cls (jclass "java.lang....."))) (defun lisp-fun (arg) (jcall meth cls arg))) Rather than: (defun lisp-fun (arg) (jcall (jmethod "java.lang...." "javaMethodName" "arg-type") (jclass "java.lang.....") arg)) In order to cache the jmethod and jclass calls. I read in another post that this had no value because (essentially) this is what the compiler is doing anyway. Is this true? Does it make any difference which way I do it in terms of speed? Thanks. Blake McBride

2 1

[armedbear-devel] Better error reporting for wrong number of arguments
by Blake McBride 15 Feb '10

15 Feb '10

Greetings, When I call ABCL from Java and the Lisp code has an error ABCL reports various levels of detail about the error depending on the type of error. Sometimes the level of detail is very helpful, sometimes it's too vague. One error that's clearly too vague is: "Wrong number of arguments." If it told me what function had the wrong number of arguments it would be very helpful. Thanks. Blake McBride

1 0

[armedbear-devel] ABCL r12444 java.lang.IllegalStateException: zip file closed
by dmiles＠users.sourceforge.net 12 Feb '10

12 Feb '10

Heads up in ANSI-TESTS (btw this is reverting clos.lisp to r12422 so the ansi tests can be ran) COMPILE-FILE.3 "/development/ABCL/ansi-tests/compile-file-test-file-3.abcl" "/development/ABCL/ansi-tests/compile-file-test-file-3.abcl" 253.82 seconds real time 171506133 cons cells java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:403) at java.util.zip.ZipFile.getEntry(ZipFile.java:148) at org.armedbear.lisp.Pathname.truename(Pathname.java:1671) at org.armedbear.lisp.Pathname.truename(Pathname.java:1575) at org.armedbear.lisp.Load.load(Load.java:164) at org.armedbear.lisp.Load.load(Load.java:623) at org.armedbear.lisp.Load.access$200(Load.java:54) at org.armedbear.lisp.Load$_load.execute(Load.java:573) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators$8.execute(SpecialOperators.java:270) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:496) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:96) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:493) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at abcl_094a9fb9_5102_45fb_b8d5_a5e9c9b58404.execute(Unknown Source) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.rt_72.execute(rt.lsp:228) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_71.execute(rt.lsp:228) at org.armedbear.lisp.rt_75.execute(rt.lsp:228) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_70.execute(rt.lsp:228) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.rt_86.execute(rt.lsp:348) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_85.execute(rt.lsp:335) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:488) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.execute(Closure.java:421) at org.armedbear.lisp.Time$1.execute(Time.java:56) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Load.loadStream(Load.java:514) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.load(Load.java:185) at org.armedbear.lisp.Load.load(Load.java:623) at org.armedbear.lisp.Load.access$200(Load.java:54) at org.armedbear.lisp.Load$_load.execute(Load.java:573) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.eval(Lisp.java:457) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators$8.execute(SpecialOperators.java:270) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Primitives$16.execute(Primitives.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:275) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:765) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:619) Debugger invoked on condition of type ERROR: Caught java.lang.IllegalStateException: zip file closed. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

2 3

[armedbear-devel] [PATCH] Access command line arguments
by Dennis Lambe Jr. 12 Feb '10

12 Feb '10

I've written a small patch to ABCL that copies unrecognized command line arguments into ext:*command-line-argument-list*. This is analogous to SBCL's sb-ext:*posix-argv* or CLISP's ext:*argv* (but without the executable name that heads up those variables, since that's not passed in to the Java main() function). I hope you find it useful enough to merge in. --Dennis Lambe Jr. malsyned(a)malsyned.net

2 1

[armedbear-devel] Building with Netbeans
by Paul Griffioen 12 Feb '10

12 Feb '10

Hi everybody I'm having trouble building the latest version of ABCL from Netbeans. Can you help me out? I work with Netbeans 6.8 (just upgraded for ANT) and run the build from the menu. Running the generated jar with 'java -jar abcl.jar geeft' gives the following message: Failed to load Main-Class manifest attribute from abcl.jar I noticed that the manifest.mf just contains the following: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.1 Created-By: 1.6.0_0-b11 (Sun Microsystems Inc.) Class-Path: Is the Netbeans build supposed to work? Does anybody have any idea why the Main is not in the generated manifest? A second question is what the best way is to include the jna library. I'm trying to compile CFFI with ABCL but that required jna as the following quote from CFFI's code shows: ;;; This implementation requires the Java Native Access (JNA) library. ;;; <http://jna.dev.java.net/> I downloaded the required jna.jar and figured that I could include it somehow in abcl.jar after building that. Unfortunately that build failed but I would like to be able to use it from Netbeans anyway. Does anybody know how to do that? My knowledge of the Java ecosystem is limited so figuring this out for ABCL specifically is not easy. Finally I would appreciate feedback on the following patch for TRIVIAL-FEATURES I needed to write to get CFFI to compile. It turned out that the endianess feature wasn't set. diff -rN old-trivial-features/src/tf-abcl.lisp new-trivial-features/src/tf-abcl.lisp 31c31,38 < ;;; TODO --- > (pushnew (let ((order (jcall "toString" > (jstatic "nativeOrder" "java.nio.ByteOrder")))) > (cond ((string-equal order "LITTLE_ENDIAN") > :little-endian) > ((string-equal order "BIG_ENDIAN") > :big-endian) > (t (error "Byte order ~A unknown" order)))) > *features*) Like I said, I'm no Java expert and feedback would be helpful. Any comment, help or pointers would be appreciated. Paul

2 3

[armedbear-devel] Passing lisp objects from java to lisp
by Blake McBride 11 Feb '10

11 Feb '10

Greetings, If I have a lisp function as follows: (defun myfun (a b) (+ a b)) I want to be able to call it from lisp or java. In other words I don't want the lisp side to have to use jobject-lisp-value. Therefore, from the java side, how do I take a java object and translate into a lisp object so that when I call the execute method the lisp function doesn't need jobject-lisp-value? Thanks. Blake McBride

2 1

[armedbear-devel] [PATCH] Access command line arguments
by Dennis Lambe Jr. 11 Feb '10

11 Feb '10

I've written a small patch to ABCL that copies unrecognized command line arguments into ext:*command-line-argument-list*. This is analogous to SBCL's sb-ext:*posix-argv* or CLISP's ext:*argv* (but without the executable name that heads up those variables, since that's not passed in to the Java main() function). I hope you find it useful enough to merge in. --Dennis Lambe Jr. malsyned(a)malsyned.net P.S. I tried to send this e-mail before my mailing list registration was complete. Moderators, please feel free to disregard that in-limbo copy.

1 0

[armedbear-devel] How to access Java fields?
by Blake McBride 10 Feb '10

10 Feb '10

Greetings, I know how to gain access to and execute Java methods via jmethod and jcall, however, I don't know how to get and set instance and static fields (or variables) within a Java class. Any help would be greatly appreciated. BTW, I've now got a Lisp macro that maps all the methods in a Java class into a corresponding CLOS class. Thanks. Blake McBride

3 7

[armedbear-devel] compiler problem?
by Alan Ruttenberg 09 Feb '10

09 Feb '10

So I'm getting intermittent compiler errors, which reduce to this case. Unfortunately just putting these forms in a file and executing or compiling them doesn't trigger the bug - so I don't have a repeatable case for you yet. Here's minimal code required to trigger it, assuming jss is loaded. I haven't seen this in the past, fwiw, and I've been using this code for a long time. This has been present in the last couple of trunk builds. (defun regex-replace-all (regex string replacement) (#"replaceAll" string regex replacement)) (define-compiler-macro regex-replace-all (&whole form regex string replacement) "Compile constant regex to pattern at compile time" (cond ((stringp regex) `(#"replaceAll" (#0"matcher" (load-time-value (#0"compile" 'java.util.regex.Pattern ,regex)) ,string) ,replacement)) (t form))) (defun foo (value) (regex-replace-all "\\s*" value "")) (compile 'foo) After the compile I get java backtrace in the repl, and the following after "&&&" in the slime debugger. java.lang.VerifyError: (class: abcl_0f7a315e_ee1b_47ea_a29c_3f6403dd238b, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Illegal local variable number at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.armedbear.lisp.Lisp.makeCompiledFunctionFromClass(Lisp.java:1266) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1327) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1320) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:236) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.compiler_pass2_596.execute(compiler-pass2.lisp:8737) at org.armedbear.lisp.compiler_pass2_582.execute(compiler-pass2.lisp:8692) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.compiler_pass2_578.execute(compiler-pass2.lisp:8692) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.compiler_pass2_595.execute(compiler-pass2.lisp:8737) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.compiler_pass2_601.execute(compiler-pass2.lisp:8754) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.compiler_pass2_597.execute(compiler-pass2.lisp:8754) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.compiler_pass2_602.execute(compiler-pass2.lisp:8825) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Primitives$16.execute(Primitives.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_412.execute(swank.lisp:2030) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_429.execute(swank.lisp:2107) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.swank_430.execute(swank.lisp:2120) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_428.execute(swank.lisp:2107) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.swank_149.execute(swank.lisp:433) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_427.execute(swank.lisp:2107) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Primitives$112.execute(Primitives.java:2539) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbe; Caught STYLE-WARNING: ; The variable LAMBDAS::G13 is defined but never used. ; Caught STYLE-WARNING: ; The variable LAMBDAS::G14 is defined but never used. ; Caught STYLE-WARNING: ; The variable LAMBDAS::G15 is defined but never used. ; Caught STYLE-WARNING: ; The variable LAMBDAS::G16 is defined but never used. ar.lisp.Lisp.funcall(Lisp.java:163) at org.armedbear.lisp.Primitives$113.execute(Primitives.java:2686) at org.armedbear.lisp.Symbol.execute(Symbol.java:798) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.swank_backend_41.execute(swank-backend.lisp:382) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_370.execute(swank.lisp:1774) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_426.execute(swank.lisp:2107) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_425.execute(swank.lisp:2102) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Primitives$16.execute(Primitives.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_400.execute(swank.lisp:1979) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.Primitives$113.execute(Primitives.java:2655) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_222.execute(swank.lisp:905) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_218.execute(swank.lisp:892) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Primitives$112.execute(Primitives.java:2539) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:96) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:493) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.funcall(Lisp.java:165) at org.armedbear.lisp.Primitives$113.execute(Primitives.java:2707) at org.armedbear.lisp.Primitive.execute(Primitive.java:143) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.swank_backend_74.execute(swank-backend.lisp:663) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_148.execute(swank.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.swank_1.execute(swank.lisp:174) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_147.execute(swank.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_145.execute(swank.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_143.execute(swank.lisp:423) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_217.execute(swank.lisp:892) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_272.execute(swank.lisp:1173) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.swank_254.execute(swank.lisp:1031) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.swank_1.execute(swank.lisp:174) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.swank_253.execute(swank.lisp:1031) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Primitives$112.execute(Primitives.java:2539) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.execute(Closure.java:421) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Lisp.funcall(Lisp.java:161) at org.armedbear.lisp.LispThread$2.run(LispThread.java:88) at java.lang.Thread.run(Thread.java:613) ; Compilation unit finished ; Caught 4 STYLE-WARNING conditions ; Evaluation aborted. CL-USER> &&& Unable to load #<jarray [B@7811a1 {CD8218}> [Condition of type ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. Backtrace: 0: org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:239) 1: org.armedbear.lisp.Symbol.execute(Symbol.java:775) 2: org.armedbear.lisp.compiler_pass2_596.execute(compiler-pass2.lisp:8737) 3: org.armedbear.lisp.compiler_pass2_582.execute(compiler-pass2.lisp:8692) 4: org.armedbear.lisp.Java$23.execute(Java.java:1007) 5: org.armedbear.lisp.Symbol.execute(Symbol.java:775) 6: org.armedbear.lisp.compiler_pass2_578.execute(compiler-pass2.lisp:8692) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:775) 9: org.armedbear.lisp.compiler_pass2_595.execute(compiler-pass2.lisp:8737) 10: org.armedbear.lisp.Symbol.execute(Symbol.java:810) 11: org.armedbear.lisp.compiler_pass2_601.execute(compiler-pass2.lisp:8754) 12: org.armedbear.lisp.Java$23.execute(Java.java:1007) 13: org.armedbear.lisp.Symbol.execute(Symbol.java:775) 14: org.armedbear.lisp.compiler_pass2_597.execute(compiler-pass2.lisp:8754) 15: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) 16: org.armedbear.lisp.Symbol.execute(Symbol.java:786) 17: org.armedbear.lisp.compiler_pass2_602.execute(compiler-pass2.lisp:8825) 18: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) 19: (#<FUNCTION {50EF1A}>) 20: (#<FUNCTION {81CF9E}>) 21: (#<FUNCTION {65C63C}> FOO) 22: (SYSTEM::%EVAL (COMPILE 'FOO)) 23: (EVAL (COMPILE 'FOO)) 24: (SWANK::EVAL-REGION "(compile 'foo) ") 25: (#<FUNCTION {B9C125}>) 26: (SWANK::TRACK-PACKAGE #<FUNCTION {B9C125}>) 27: (#<FUNCTION {37A41C}>) 28: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #<FUNCTION {37A41C}>) 29: (#<FUNCTION {F72DF7}>) 30: (FUNCALL #<FUNCTION {F72DF7}>) 31: (#<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {EADF38}> #<FUNCTION {F72DF7}>) 32: (APPLY #<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {EADF38}> #<FUNCTION {F72DF7}> NIL) 33: (SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS #<FUNCTION {F72DF7}>) 34: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<FUNCTION {F72DF7}>) 35: (SWANK::REPL-EVAL "(compile 'foo) ") 36: (SWANK:LISTENER-EVAL "(compile 'foo) ") 37: (SYSTEM::%EVAL (SWANK:LISTENER-EVAL "(compile 'foo) ")) 38: (EVAL (SWANK:LISTENER-EVAL "(compile 'foo) ")) 39: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(compile 'foo) ") "COMMON-LISP-USER" 42) 40: (APPLY #<FUNCTION SWANK::EVAL-FOR-EMACS {E5021C}> ((SWANK:LISTENER-EVAL "(compile 'foo) ") "COMMON-LISP-USER" 42)) 41: (SWANK::PROCESS-REQUESTS NIL) 42: (#<FUNCTION {EDA852}>) 43: (FUNCALL #<FUNCTION {EDA852}>) 44: (#<FUNCTION (LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) {C5B70C}> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK {749CB7}> #<FUNCTION {EDA852}>) 45: (APPLY #<FUNCTION (LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) {C5B70C}> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK {749CB7}> #<FUNCTION {EDA852}> NIL) 46: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK {749CB7}> #<FUNCTION {EDA852}>) 47: (#<FUNCTION {DCEB8B}>) 48: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*STANDARD-INPUT* . #S(SLIME-INPUT-STREAM)) (*TRACE-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*ERROR-OUTPUT* . #S(SLIME-OUTPUT-STREA.. 49: (#<FUNCTION {230AB0}>) 50: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {230AB0}>) 51: (#<FUNCTION {92B531}>) 52: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {92B531}>) 53: (SWANK::CALL-WITH-CONNECTION #S(SWANK::CONNECTION :SOCKET-IO #<TWO-WAY-STREAM {B5B6B9}> :DEDICATED-OUTPUT NIL :USER-INPUT #S(SLIME-INPUT-STREAM) :USER-OUTPUT #S(SLIME-OUTPUT-STREAM) :USER-IO #<TWO-WAY.. 54: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #<FUNCTION {EF39E5}>) 55: (#<FUNCTION {C20590}>) 56: (FUNCALL #<FUNCTION {C20590}>) 57: (#<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {EADF38}> #<FUNCTION {C20590}>) 58: (APPLY #<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {EADF38}> #<FUNCTION {C20590}> NIL) 59: (SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS #<FUNCTION {C20590}>) --more--

1 0

[armedbear-devel] Small problem with DESCRIBE
by Blake McBride 09 Feb '10

09 Feb '10

Below there is a line that reads "IV3 unboundThe following slots have :CLASS allocation:" There should be a carriage return before the "The". $ java -jar abcl.jar Armed Bear Common Lisp 0.19.0-dev Java 1.6.0_17 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.374 seconds. Startup completed in 1.086 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass myclass () (iv1 iv2 iv3 (cv1 :allocation :class))) #<STANDARD-CLASS MYCLASS {5EE04FD}> CL-USER(2): (setq i1 (make-instance 'myclass)) #<MYCLASS {195B6AAD}> CL-USER(3): i1 #<MYCLASS {195B6AAD}> CL-USER(4): (describe i1) #<MYCLASS {195B6AAD}> is an instance of #<STANDARD-CLASS MYCLASS {5EE04FD}>. The following slots have :INSTANCE allocation: IV1 unbound IV2 unbound IV3 unboundThe following slots have :CLASS allocation: CV1 unbound CL-USER(5):

2 1

[armedbear-devel] ABCL -r12424 fails ANSI-TESTS with ClassCastException
by dmiles＠users.sourceforge.net 07 Feb '10

07 Feb '10

FYI: Test COMPILE-FILE.18 failed Form: (LET ((FILE (LOGICAL-PATHNAME "CLTEST:COMPILE-FILE-TEST-LP.OUT"))) (WITH-OPEN-FILE (S FILE :DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE :IF-DOES-NOT-EXIST :CREATE)) (COMPILE-FILE-TEST "compile-file-test-file.lsp" (QUOTE COMPILE-FILE-TEST-FUN.1) :OUTPUT-FILE FILE)) Expected values: T NIL Actual value: #<READER-ERROR {C13538}> [Invalid character #\Backspace] "/development/ABCL/ansi-tests/compile-file-test-file.abcl" "/development/ABCL/ansi-tests/compile-file-test-file.abcl" COMPILE-FILE.19 "/development/ABCL/ansi-tests/compile-file-test-file.abcl" "/development/ABCL/ansi-tests/compile-file-test-file.abcl" COMPILE-FILE.20 COMPILE-FILE-PATHNAME.1 COMPILE-FILE-TRUENAME.1 COMPILE-FILE.ERROR.1 COMPILE-FILE.ERROR.2 LOAD.1 LOAD.2 309.52 seconds real time 302546363 cons cells java.lang.ClassCastException: org.armedbear.lisp.Nil cannot be cast to org.armedbear.lisp.Pathname at org.armedbear.lisp.Load.loadFileFromStream(Load.java:409) at org.armedbear.lisp.Load.load(Load.java:592) at org.armedbear.lisp.Load.access$200(Load.java:54) at org.armedbear.lisp.Load$_load.execute(Load.java:555) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.Lisp.funcall(Lisp.java:167) at org.armedbear.lisp.Primitives$113.execute(Primitives.java:2707) at org.armedbear.lisp.Primitive.execute(Primitive.java:158) at org.armedbear.lisp.LispThread.execute(LispThread.java:632) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:522) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Primitives$145.execute(Primitives.java:3686) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:96) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Primitives$152.execute(Primitives.java:3953) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:141) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$4.execute(SpecialOperators.java:110) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:493) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators$8.execute(SpecialOperators.java:270) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Primitives$148.execute(Primitives.java:3819) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Primitives$145.execute(Primitives.java:3686) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:167) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:40) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:96) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Primitives$16.execute(Primitives.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_72.execute(rt.lsp:228) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_71.execute(rt.lsp:228) at org.armedbear.lisp.rt_75.execute(rt.lsp:228) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Java$23.execute(Java.java:1007) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_70.execute(rt.lsp:228) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.Symbol.execute(Symbol.java:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.rt_86.execute(rt.lsp:348) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.rt_85.execute(rt.lsp:335) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:488) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.execute(Closure.java:421) at org.armedbear.lisp.Time$1.execute(Time.java:56) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Load.loadStream(Load.java:496) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:459) at org.armedbear.lisp.Load.load(Load.java:187) at org.armedbear.lisp.Load.load(Load.java:605) at org.armedbear.lisp.Load.access$200(Load.java:54) at org.armedbear.lisp.Load$_load.execute(Load.java:555) at org.armedbear.lisp.Symbol.execute(Symbol.java:810) at org.armedbear.lisp.LispThread.execute(LispThread.java:614) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.eval(Lisp.java:457) at org.armedbear.lisp.Primitives$16.execute(Primitives.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Primitives$141.execute(Primitives.java:3579) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Lisp.progn(Lisp.java:628) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:275) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:765) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:619) Debugger invoked on condition of type ERROR: Caught java.lang.ClassCastException: org.armedbear.lisp.Nil cannot be cast to org.armedbear.lisp.Pathname. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

2 5

[armedbear-devel] ABCL -r12425 cannot load ANSI-TESTS both compied and interpreted
by dmiles＠users.sourceforge.net 06 Feb '10

06 Feb '10

FYI: [root@titan ansi-tests]# java -jar /development/ABCL/abcl-trunk/dist/abcl.jar Armed Bear Common Lisp 0.19.0-dev Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.287 seconds. Startup completed in 0.888 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "compileit.lsp") WARNING: ABCL doesn't support the long form of DEFINE-METHOD-COMBINATION; randomized testing disabled. WARNING: Redefining test LOOP.10.106 Error loading /development/ABCL/ansi-tests/defclass-01.lsp at line 799 (offset 18177) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :NAME. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-TEST(2): (quit) [root@titan ansi-tests]# java -jar /development/ABCL/abcl-trunk/dist/abcl.jar Armed Bear Common Lisp 0.19.0-dev Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.29 seconds. Startup completed in 0.895 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "doit.lsp") ; Compilation unit finished ; The following functions were used but not defined: ; REGRESSION-TEST::COPY-ENTRY WARNING: ABCL doesn't support the long form of DEFINE-METHOD-COMBINATION; randomized testing disabled. WARNING: Redefining test LOOP.10.106 ; in (DEFMACRO DEFCLASS-WITH-TESTS ...) ; Caught STYLE-WARNING: ; The variable INITARG-LIST is defined but never used. ; Caught STYLE-WARNING: ; The variable ALLOCATION is defined but never used. ; Compilation unit finished ; Caught 2 STYLE-WARNING conditions Error loading /development/ABCL/ansi-tests/defclass-01.lsp at line 799 (offset 18177) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :NAME. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-TEST(2): (quit)

1 0

[armedbear-devel] JAR file support patches
by Mark Evenson 06 Feb '10

06 Feb '10

Implementing true support for JAR files in ABCL has taken quite a bit more time and effort as can be seen by the rejection of my mail of few minutes ago to the list for being too long. I've posted my [patches with explanation to the web][1], as I am not sure when or if the moderator will let the original message through. [1]: http://slack.net/~evenson/abcl/jar-file About the only disadvantage for the current patch is that I had to remove the use of ZipCache for entries as I was developing as it didn't make much sense. I haven't really noticed too much of a time difference for loading or compiling ABCL. Comments? Once I get things tested under Windows, and play around with the loading from http support, I intend to commit to trunk. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 16

[armedbear-devel] Question about calling Java
by Mark Evenson 04 Feb '10

04 Feb '10

Usually, I can find a way to translate given Java code into the ABCL equivalent. Sometimes it takes quite a while to figure the correct syntax which I attribute to the organically evolved nature of our Java integration, but I have never found something ultimately unexpressable. Until now, although I think this has to do with me trying to debug ABCL internals with the ABCL REPL, but I want to document it. Have I missed some way of making this call? The code: SimpleString h = new SimpleString("FOO"); Pathname.LOGICAL_PATHNAME_TRANSLATIONS.get(h)); LOGICAL_PATHNAME_TRANSLATIONS is a EqualHashTable object whose signature of get() is LispObject get(LispObject key) This fails (jcall "get" (jfield "org.armedbear.lisp.Pathname" "LOGICAL_PATHNAME_TRANSLATIONS) (jnew "org.armedbear.lisp.SimpleString" "FOO")) with the error The value "org.armedbear.lisp.SimpleString" is not of type JAVA-OBJECT Diving into the code shows that the Java.translateMethodArguments() call is always going to translate the SimpleString argument into a instance of java.lang.String as this is what SimpleString.javaInstance() returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect that we don't need JCALL-NAKED for anyone not using Java objects that are descendents of org.armedbear.lisp.LispObject but I'm not exactly sure how to prove this claim. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

8 20

Re: [armedbear-devel] translate-logical-pathname and :wild-inferiors regression
by Alan Ruttenberg 04 Feb '10

04 Feb '10

Thanks Mark! A confusing area of common lisp for sure... -Alan On Thursday, February 4, 2010, Mark Evenson <evenson(a)panix.com> wrote: > On 2/3/10 8:22 PM, Alan Ruttenberg wrote: > […] > > pre-r12283 ABCL was buggy in a different way. My best understanding is > that the behavior observed in sbcl and my patched abcl is correct. > > > Ok, now I think I understand the problem Sorry for the confusion on my part. > > Your fix [has been committed in r12147][1]. > > [1]: http://trac.common-lisp.net/armedbear/changeset/12417 > > > -- > "A screaming comes across the sky. It has happened before, but there > is nothing to compare to it now." >

1 0

[armedbear-devel] translate-logical-pathname and :wild-inferiors regression
by Alan Ruttenberg 04 Feb '10

04 Feb '10

A recent commit (dec 2009) seems to have changed the behavior of wild-inferiors. Prior to the change :wild-inferiors would match 0 or more pathname components. After the change 1 or more. e.g. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") Used to work, but now fails. Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS. -Alan

3 12

[armedbear-devel] Lisp / Java interface utilities and examples
by Blake McBride 03 Feb '10

03 Feb '10

Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL. Thanks. Blake McBride

4 10

[armedbear-devel] Maxima status: performance measurement
by Erik Huelsmann 01 Feb '10

01 Feb '10

Hi Robert, hi all, Today, I ran Maxima through ABCL's profiler to see what's our current status. With our combined changes, we seem to have reduced the throughput time of the Maxima tests on my system from 2200 secs to roughly 1800 secs between October and now. These are the hotest spots now: 3.0 4352336 SIGN01 3.0 4354363 $SIGN 3.1 4531219 MEVALARGS 3.2 4633287 MREAD-RAW 3.2 4633902 MREAD 3.3 4740203 SIGN1 3.7 5402701 SIMPEXPT 4.4 6365392 $FLOAT 4.5 6469447 RECUR-APPLY 4.5 6521950 TEST-BATCH 5.8 8452081 SIMPLIFYA 8.4 12224550 NUD-CALL 11.3 16314266 DLSF 11.3 16362213 DLS 12.2 17658492 PRSMATCH 12.4 17982535 DGRF 12.5 18054353 DGR 20.6 29854294 PARSE-INFIX 22.3 32246473 MEVAL* 22.4 32372076 MEVALN 54.5 78912363 LED-CALL 55.5 80291167 PARSE 59.5 86114793 MEVAL1 60.7 87813616 MEVAL 64.2 92947288 MHEADER 65.2 94346436 STREAM-NAME 65.2 94346559 INSTREAM-NAME 65.2 94346854 PATHNAME 65.2 94347835 ADD-LINEINFO As you can see, the DGR(F) functions which relate to the integrator tests have now been removed from being the main bottle necks. It looks like some evaluator is now our 'hottest' spot. Robert, could you help us to see what we should do to optimize the functions which are now our main performance issue? Thanks in advance! Bye, Erik.

2 1

[armedbear-devel] Development status recap
by Erik Huelsmann 30 Jan '10

30 Jan '10

A lot of different efforts are going on at the moment. So I thought I'd try to write down the efforts and their status as far as I know. Both to be informational, or to comment upon to correct my understanding. 1. The Gray streams effort We're slowly progressing on this issue: a design was agreed upon and Ville has added that to the wiki. Next steps include setting up the right java and lisp code for the structure ANSI-STREAM to hold closures used for I/O processing. Basically this design was taken from SBCL. 2. Better inlining of lambda functions and inlined named functions By inlining lambda functions as much as we can, we can reduce the number of reflection calls required to instantiate all our function classes. Alessio is working on creating a function argument matcher which binds the newest PARSE-LAMBDA-LIST on trunk with the function call arguments in order to generate a LET* form instead of a function call. 3. Pathnames as a way to address JAR file content ABCL extends the pathname scheme in CL to address resources in JAR files. However, this support was limited to a small number of pathnames related functions. Mark Evenson is working to improve the situation. 4. DEFINE-METHOD-COMBINATION Mark Evenson started on this issue; however post-poned it to work on item (3). Feel free to pick it up! 5. Local functions in same class file as the function they're defined in Some time ago, I started working on a general class file writer to make it possible to store local functions inside the same class as the function in which they're defined. This effort is progressing very slowly; it's more of a side project to other improvements in the project. It has the same goal as (2): reduction of the number of required reflection calls to get our classes loaded. Bye, Erik.

1 0

[armedbear-devel] long form of define-method-combination
by Tobias C. Rittweiler 30 Jan '10

30 Jan '10

SACLA seems to contain an implementation of the long form of D-M-C: http://homepage1.nifty.com/bmonkey/lisp/sacla/html/lisp/clos.lisp.html It's released under a BSD license, so just copying it into ABCL is viable, but the code may also just be used for inspiration. -T.

3 3

[armedbear-devel] Common central location for system-wide configuration.
by Olsen, Peter C. 30 Jan '10

30 Jan '10

Ladies and Gentlemen, I've come to the point where it would be convenient for me to establish a system-wide run-time configuration so that every invocation of ABCL for every user starts with a few common packages. The only way I can find to do that is to have everyone put the appropriate code in their .abclrc files. I've tried to put a load command in the shell script that starts the interpreter, but it doesn't work. /usr/bin/java -classpath abcl.jar:jscheme.jar org.armedbear.lisp.Main "(load \"invoke.lisp\")" $@ I suggest that we consider changing the processInitializationFile method in Interpreter.java to look for some sort of initialization file in the directory in which abcl.jar is located when the Interpreter starts. That seems to be a simple change. A more elegant solution would be add some code to determine the OS and then look for configuration files in an appropriate place for each one. I'm a newbie to this project, so I don't want to overstep my bounds. Having said that, I'd be happy to make and test the changes I've proposed. Comments (particularly on the OS variation)? Thanks! Peter -- Peter Olsen, P.E., Ae.E. Registered Professional Engineer, Maryland License 12283 The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road, M/S 17-214 Laurel, Maryland, 20723 Baltimore: 443-778-2577; Washington DC 240-228-2577 Heterogeneity is inevitable and must be supported by design. (RFC 1958)

4 4

[armedbear-devel] [BUG] EXT:ARGLIST produces bogus case-sensitive arglists
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

`arglist' in `arglist.java' calls `readObjectFromString' which uses the FASL Readtable which is case sensitive. This ain't good because this way the lambda-list keywords (&OPTIONAL etc.) are not properly read back (EXTENSIONS:|&optional|) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] No restarts available on error in thread
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

Evaluating the following (threads:make-thread #'(lambda () (error "foof")) :name "foof") will get you into the debugger. But there's not restart available. As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an error occuring in a thread, I think there should be a TERMINATE-THREAD restart instead. And the debugger should probably print the thread's name the error occured in. -T.

2 1

[armedbear-devel] Autoloads
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

I *always* forget what the autoload stuff is about, and when I have to add something to it. Could anyone please add a comment to Autoload.java and autoloads.lisp? -T.

2 3